I don’t like Virtual Machines

I don’t like virtual machines. Give that my current position and employer involves building, maintaining, supporting, optimizing, and selling solutions/services this statement is a bit ironic. I don’t hate the benefits that the technology has given us. It’s amazing about what it has provided. It’s also amazing how you can scale up a service without having to bring in lots of new hardware and maintain that as well. It’s more efficient and cost effective than the old way of doing things. It has progressed development of operating systems, and drivers.

The problem I have with virtual machines involves more of the context of what they are. In a very simple manner, a VM is an emulation of a physical machine run within a computer, also known as a hypervisor. Oftentimes, lots of virtual machines are run on the same box by using systems like VMWare ESX server, Zen, or KVM. Very frequently the difference between a physical machine and a virtual machine are very little. The differences show up with 3D/low-latency applications and VMs that depend on hardware input that cannot be emulated (I.E. number generation on VMs).  After reading that previous statement, and considering the downside, there should be something that sticks out to you. It’s something that should make you feel uncomfortable.

For me, I’m made very uncomfortable in the fact that we have many VMs running on the same box. Much of the processing, storage, and memory are consumed by redundant operating system processes, and/or files associated.  This seems really inefficient to have 30 instances of Windows Server 2012 all running IIS at the same time. The alternative to this madness is through the use of containers. I like the idea. I would love to get a chance to learn more about OpenVZ and LXC when I get more time. I like containers because they are sandboxed/managed containers which pushes the processing ability onto the actual job being performed. It feels more efficient, and more inlined with solving the problem rather than creating more infrastructure.

Prior to the virtualization era: We were encouraged to build grid services. This was great, you could throw a lot of machines at a problem and had them work in harmony. However, that didn’t work as well as we hoped due to the immature tools and frameworks offered at the time. In replacement of grid computing, the next approach was to split the problem up into individual processing united and to just to throw a lot of machines at the problem. After VMs are “nearly-free.” This really doesn’t fix the problem, it just seems like we’re timesharing on a powerful server once again.

Protip of the Day: Always Delay your Email From Being Sent

This is a rather simple and should be obvious pro-tip: Delay all email from being sent. This helps to catch emails that have the wrong tone, message, audience or content before it’s sent. This tip has saved me from sending an badly formed email, or to the wrong audience many times. Just today I caught a work email that was missing information. It makes a difference from sending a brief and context email into sending a fully detailed email.


Why does this work really well?

I believe that this works really well because, like unit testing, it causes the author to separate the content creation with the later review. It forces one to reflect on what was created rather than to falsely believe what was written was perfect. It also gives us a chance to give more meaning and promotes a stronger signal to noise ratio in your messages. From my person experience little is gained from responding and sending anything immediately. Delays are a well accepted and expected situation when dealing with human to human communication.


That’s nice, but how would I do that?

Why your PodCast May Irritate It’s Listeners

Radio programs have evolved over time. Their broadcasts have transformed from a strict, informative purpose into many different formats. However, one of the main changes of the radio programs has been a wide reach of an audience and more listener-friendly formats/mediums.

In contrast, podcasts are rather slow to catch up. Podcasts suffer from amateur-dominated issues. I listen to quite a few Podcasts while I’m working, driving, or in my spare time.

A few issues that I have with the podcast technologies have been:

  1. Tools for synchronization/downloading, there is no standard way to grab and listen to podcasts. I’m looking for a tool that is similar to the old Google Reader.
  2. I would love to have a replication system that would put the podcast on my phone/wifi-connected mp3 player/etc.

Those two issues aside, there have been other problems that I’ve found with many podcasts:

  1. Production quality is less than stellar: When the audience member listens to the episode, they have to imagine what the broadcasters are describing. The Java Posse conferences is a good example – there are a lot of non-audio actions occurring and it becomes distracting. Other problems are related to background noises (cars, animals, talking in the background,etc). If the broadcasters wish to improve their quality: get better quality mics/filters, storyboard/plan out the show, and cut irrelevant sections of the recording.
  2. Rambling: This becomes irritating as it is more difficult to skip over unrelated tangents. I’m not suggesting that all non-topic communication should be avoided, but there are sometimes where the rambling is endless. I see this issue in the Java Posse podcasts when there are arguments on topics such as patents, DRM, or other topics that would be better left on Slashdot, Hacker News, or Reddit.
  3. Uncomfortable conversations: I have been turned off to the Programming Throwdown. Often times the conversations don’t flow, or it feels like the speakers are fishing for conversation.  Systm, with Kevin Rose, (if I recall correctly) use to start out with the two presenters having a conversation over a beer. There have been many episodes with the Java Posse that have been conversations over a glass of wine or beer. These episodes feel more informal and easier to listen to.
  4. Teaching rather than conversing: With Programming Throwdown, I get the sense that they are trying to teach something, where the listener would be better suited for learning by example and resources. To learn something from this show, it requires quite a bit of attention, and comprehension. If you’re going to teach something, do it in a way to trick the audience into learning about it explain why a technology is so amazing and then go into the details, rather than trying to inform and then engaging the listener.
  5. Not putting breaks or introductions: The podcasts Man Show (by Caleb Bacon) and the Art Of Charm (a dating podcast) do a very good job at this. Man Show has a quick introduction, which is one of the most interesting statements of the show. Both of the shows also put in breaks. Like advertisements on the radio and TV, this allows for the listeners to pause and contemplate what was said.
  6. Not producing show notes: I don’t have a direct example of individual podcasts that don’t do this, however having show notes helps the listener to research topics mentioned in the podcast, and to find podcasts via searching topics.
  7. Tone, interest, and presentation: Podcasts as a medium are all about telling a story or convincing someone to consider ideas. This American Life by Ira Glass captures the listener’s interest via the delivery of the content. There are a few episodes of the Hacker Podcast that are less than stellar. It irritates me quite a bit when a speaker doesn’t have interest in what they’re saying – it wastes everyone’s time. I would be more tolerant of this issue if the medium was a live broadcast, however it’s not.
  8. Video podcasts: This is a personal peeve of mine. I don’t like to be restricted to a video-cast. Audio allows for me to listen to them while work. Video has to compete with my focused attention, and with other videos on youtube and/or television production-quality programs. That being said, I do enjoy a lot of the InfoQA presentations, only when I get the time to watch them.
  9. Length: Each episode should be long enough to get into detail on the topic, but short enough to avoid overwhelming the listener. My friend Warren calls this “terse verbosity”.
  10. File names should reflect the topic of the episode, and the Podcast name: When you’re dealing with names like “hpr3234.mp3”, it becomes difficult to pick the podcast you want to hear. Man School does a great job with this by naming their files: MS-<Interviewee>.mp3.
  11. Metadata: Fill it in. If you have a decent stereo in your car, and it plays MP3s from storage, then it is very helpful to pick out the podcast by its metadata. I can understand that it’s a little irritating to put in the data after making the show and editing it. But it’s one of the little things that make listening to the podcast just a little easier.

I find Podcasts incredibly useful, if not more so than most magazines. They’re free, they can go into depth on interesting topics, they tend to be focused on the interviewee, and lastly they’re convenient.

Why I’ll buy more Logitech Wireless mice

If you’ve read much of my blog, I tend to be a bit more critical rather than rewarding. It’s human nature, the negative emotions/experiences tend to be amplified more than the positive ones. However, I feel that I must mention my experience with the Logitech wireless mice. I first bought a Bluetooth wireless mouse and I had a horrible experience with it. The battery would last 1-2 weeks at most. However, a friend of mine owned a m325 [which has its own custom wireless protocol and adaptor]. From my experience, I have never had to change the battery that comes with the mouse, and it’s been nearly a year now.

Recently, I have moved and one of the USB micro adaptors broke. I bought a new mouse and found out another one of the mice got lost. [I previously had two] It turns out that the adaptors are easily reprogrammable with the “Logitech Unifying Connectors.” Although this software is for Windows/Mac only, this is slick. Additionally, you can program multiple keyboards and mice to one adaptor.

This Week I Learned [19 May 2013 Edition]

This week I learned about:

  • There is a new change to how network devices are named. This may change your network device from eth0 to something like env10p0.
  • Archlinux is very similar to Gentoo, but it is based on a script to install everything.
  • 2to3 is a python script that will convert a python script from a version Python 2.0 to a 3.0 compatible script.
    • One major difference between 2 and 3 is that the print statement became a function, thus requiring parenthesis.
  • It is easier to hard code the Python 2 environment, rather than to convert the script into a Python 3.0 script.
    • #!/usr/bin/env python2.7 [or whatever Python 2 environment that is installed] should be used in the shell definition of the script.
  • OpenVAS– Open Vulnerability Scanner: I haven’t tried this yet, but this is a neat utility that can help you keep tabs on the software you currently have installed and the possible vulnerabilities that they may have.
  • Always snapshot your VM after you finish major installs. [This saved my butt this week]
  • Ansible –  This looks like a nice Open Source version of HP Operations Orchestration.

Apache Wicket [In Action]: A Review and How It Relates to the Java World

Java is a great tool for creating software. It is well designed, modular, has a wide array of platforms that it can run on, performs well, it’s very extendable, and it has a large community with lots of support. However, it’s support for websites and related services is severely lacking. It’s bad enough that frameworks that extend the existing infrastructure have massive pitfalls that you later discover.

For the most part Apache Wicket solves many of the web related issues that J2EE (JSP) has. If you are to follow the prescribed way of doing things, it can actually be quite pleasant. However, there are a few thorny patches with Wicket. I will get to those later.

Wicket In Action like a marriage. During the honeymoon, everything is great. Everyone is happy, and then later discontent grows and things go up and down. However, unlike a marriage, you don’t really get an ending. This is a rather good way to end things, but some of the lesser parts of the book were rather disappointing. One of the big selling points of Wicket is that it is a framework that assumes that the developer has already prototyped the pages in HTML prior to starting with Wicket [The pages are adapted into Wicket-ized and previewable pages]. This upside was enough to ignore the placement of the HTML files, in the class path rather than the web resources section.

I jumped into this book with lots of enthusiasm after reading the introduction. I even bore through some of the non-stated setup issues in the book. The book starts off by creating a project, from scratch, however I went the Maven route (which I discovered is the better way to go). The book mentions maven, but it doesn’t mention how to build your application or to generate a project. I believe that I went the correct way because Maven helped to setup all of the application servers and the folder structures. The book started by having the user to jump in, examine a few code segments, and then to start on a sample (full featured) e-commerces application. The store was oddly pleasant; the goal was to sell cheeses online. The application started from a few sample view pages, it went on to creating a reusable shopping cart, and finally on to a membership mechanism. This is a very straightforward and to-the point way of starting a new framework. It’s already addressing the needs of the majority of its audience.

Another nice thing to point out about the introduction is that it did not try to cover all of the material at once. It would frequently describe what you were doing, but would mention the chapter where the concepts were explained in depth later on. Something that pleased me was that the code listings did not include a listing number. They were place in the correct location of the text. After you’re done with the sample application, you should be quite proud of yourself. This is similar to your first website.

However, the book got a little disappointing when describing the more detailed interworkings of Wicket: sessions, bookmarkable pages, and layering/rendering. The book improves when it gets to the Ajax functionality and a brief mention of dependency injection and Wicket. The book gets a little rough in the Spring through Hibernate sections and then better in the testing section. The book ends in a rather low note on SEO, production configuration, and JMX. If I had known more about JMX, I would have probably had a better opinion of the ending.

Overall I am not sure if I can say that the less than stellar sections of the book were entirely the authors’ or the book’s fault. It quite possibly may be the technology’s fault.  I would strongly recommend the book if you are new to Wicket.

Lastly, here are some direct tips that I had to discover on my own that helped out a lot:


Progress on Tech Resolutions of 2013

Earlier this year I made a few resolutions for this year.

So far I have completed the following:

  1. Finished and reviewed “Groovy In Action”
  2. Refresh on networking

Despite this not being much, I have learned many new things about disk storage, and Maven. Also, I’ve created a new GitHub repository for a ogg2mp3 script that I created.

Things left to learn/do:

  1. Finally get around to learning GridGain.   [I would love to see a well published book, or at least a Kindle eBook to get some headway on this] HazelCast would also be interesting, but GridGain has more of what I’m looking for.
  2. Finally understand how network routing works.
  3. Get more experience with DNS, and DNS tools
  4. Master NMap [not just learn the basic uses of it, but to really excel with the tool] This would be similar to the reading up on SSH I did last year.
  5. Get up to conversational level German. [Living outside of German speaking nations makes this incredibly difficult]
  6. Finally develop some strong time management habits.
  7. Learn how to use Python [to the point where you can do some cool stuff with it]
  8. Learn R [rather than haphazardly hack]
  9. Meet/talk with some of the gurus of airfare scheduling/decoding, and the famous Tom Stuker.
  10. Learn how to use GraphViz [This is one of the odd ones here, but it’s interesting]
  11. Get better with Erlang and to find/make real world uses.
  12. Learn/Create a GUI in Apache Pivot
  13. Create a web interface with either Stripes and/or Wicket.


Part 1 of 2: How To Make Your Life Easier As A Tech Worker (IT/Software Engineering/System Administrator): Automation

After some time of being a student, and a tech worker [Software Engineer, IT Consultant, or  System Administrator], you should start to find ways to make your job easier.  These are some of the things I found helpful:

  • Create templates for daily status emails. If your employer/ client requires a daily status, this makes the task of writing up the daily status easier. Outlook has the ability to keep track of email templates.
    • If the daily status is being sent to multiple people it may be helpful to create a distribution list. A distribution list is less likely to lose contacts between statuses.
    • One template a coworker of mine uses is this template.
  • Create filters for emails. This can help reduce the amount of email that requires attention. For example if a group communicates with a shared distribution list then create a rule or a filter that can organize that into a separate folder. This can also clear out “Build succeeded” emails [if your company automatically subscribes you to those]
    How To Create Rules In Outlook.
    How to Create GMail Filters.
  • Use SSH keys: SSH Keys can save a little bit of time by creating password-less logins. Also with SSH keys, scripts are able to run commands on other SSH enabled boxes. This means that much of the repetitive system administrative tasks can be automated. Gentoo Guide to SSH [This include generic non-gentoo instructions.
  • SSH Commands: SSH Commands are shell-less sessions in which a user logs into a SSH box with a key to kick off only one specific command. For example, say you had to reset an environment, and it required quite a few commands. With an SSH command, you would combine all of those commands and then kick off the command as an SSH command with its own key. From there on, you could kick off those commands by connecting to the SSH box with the key.  More information.
  • Backups- It can’t hurt to backup your data. I’ve never found a single person that was reliable at doing this frequently. Setting up rsync, SSH-keys and making it a cron job is a good first step. I’ve heard good things about luckyBackup, but I haven’t had a chance to try it. 
  • Using Salt/Puppet to automate system administrative tasks on multiple machines. This would be a bit more helpful for those who regularly roll out new software to multiple machines, or need to perform other system admin tasks.
  • IfThisThenThat (Review) is an online service that connects other online services to perform the intended result. For example, if a Google search reveals specific keywords, you can have that update a twitter account.

Stackoverflow Is A Difficult Community to Participate In

These are a few of the reasons why I have difficulty in participating in the StackOverflow community. I was once a very active user, but due to these reasons, and a few unstated, I am unable to participate in the community anymore. 
  1. The Eternal September Issue. Many new users of StackOverflow [SO] rarely ever follow the guidelines of the community. I’m not sure how to solve this, but it is annoying to see questions posted as a plea for help. Stackoverflow moderates its self as a very terse question and answer site. It’s not a discussion forum. [This is a crutch and a gift] Another issue with this is that duplicates show up despite the crotchety moderators complaining about it. One example of this is questions asking about where to find free stock quote data.
  2. Questions that deal with software development that are not inherently technical are frequently down voted/closed. One example of this is that a question asking about a specific data set [for training/development purposes] was closed for the reason that it “didn’t fit with the community.” Until there is a dataset related StackExchange site that the question can be moved to, that was a perfectly acceptable development related question. By a “StackExchange site that the question can be moved to” I mean a fully functioning site, one not currently being “developed”/on Area51. Closing the question as “not relevant” does not help the author, nor does it help people that are looking for a similar dataset.
  3. Down voting as a means of closing a question. To vote-to-close a question a user must have 250 reputation points. This does not take very long to get, if you participate in the community. Down voting should be a way of saying, this is either wrong information, misleading, or not helpful. If the user believes that the question should be closed, but does not have the reputation needed to close, then make a comment and give evidence on why you believe that this should be the case.
  4. The down voting of correct, but not exact-answers. This gets to be an issue when there are questions that can have multiple answers. For an example: A question about optimization of a Java application, the common answer will be to use a more efficient algorithm. That answer will probably be the most voted answer. However, another valid answer is that the process could be rewritten in a more low-level language and connected to via a pipe [Socket, inproc, JNI, etc] to the main application. The latter is better suited for rather unique situations, but it is still a valid and workable answer. From my experience, the second answer will be downvoted, despite that it gave correct information. I have had a discussion with a moderator about this [Shog9] and, according to him, that strategy is a perfectly acceptable strategy to down-vote a creditable answer.
  5. Timing/Duplicate answers. Since I have stopped participating in the community, I have not seen this as often. However, when there is a question posted there is frequently a rush of answers to be posted there. After some time, someone will post a duplicate answer, and get it to be voted on more than the original answer. This is harder to find, but it does happen and it’s very frustrating.
  6. Misattributing credit on answers: If there are other answers that assist you in answering the question, please cite those other authors. It is polite and it gives their question credibility. [Also those that you cite, you should vote for their answer as well].
  7. This is another one of the odd cases on StackOverflow. A few of the “Exact Duplicate” questions are not duplicates due to minor, but important, differences. I cannot come up with an example now, but commenters, frequently, are quick to claim that it is an exact duplicate without verifying the claim. Sometimes the accusation isn’t backed up by evidence. Links to the other questions are sufficient evidence.
  8. The value of reputation: After the global recalculation, the site’s creators made a bold statement that participation is not valued on the site. The recalculation devalued questions, and the new policy was applied retroactively. This caused a loss of reputation. The creators of the site made a claim that “reputation was useless,” which falls contrary to their claim that reputation is a “value of how much the community trusts you.” Operating on the prior claim would make a statement that a user with 500 reputation points is as valued as Jon Skeet. [A well known user in the community, and an author of many technical books]

EDIT: Correction: Vote to close requires 3k in reputation, the ability to downvote requires a reputation of 125 or better. I still stand by my statement that downvoting


Dear Google Analytics for WordPress, Stop It.

An update of your recent plugin. Now has a popup notification when you go to log in.

“Help Improve Google Analytics for WordPress popup”

If you are using a non admin account, you’ll be sent to a page that claims that  “You do not have sufficient permission to access this page.” This is despite any of using any of the options that it supplies. To get this box to go away, you must log into the Admin account and select one of the options. The box cannot be ignored, and it prevents you from using the WordPress functionality.