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.

PSA: Software Development Tip: Clean out your Code Base

There is a diplomatic mindset that many developers have: It’s better to orphan code, than it is to delete it. This, although less destructive in the short term, can become very destructive in the long run. Leaving orphaned code may:

  • Encourage Reuse later on
  • Dramatically increase build times
  • Increase the amount of time needed to perform version control [A bigger code base takes longer to examine]
  • Reduces one’s ability to navigate through the code.
  • Increase the executable size
  • Increase maintenance times

So in short: If the code is no longer needed and used, remove the dead code. If you’re using source control properly, the change can be reverted.

If the team you are working with still insists on orphaning code, at least have them to agree on periodic spring cleaning of the project.


 

Good News to those who use Maven and are working on J2EE web projects in IntelliJ: Here’s a guide.

 

Two Issues I have With IntelliJ: Inconsistent building, and GUIs

During the massive end-of-days sale, I bought a copy of IntelliJ. I have been primarily a NetBeans developer, but I have used IntelliJ at a previous job. So two of the things that irritated me have been: the inconsistent build support and IntelliJ’s handling of Java GUIs.

IntelliJ has its own internal build system. However, it also has support for Maven. When you have a Maven project, it adds in dependencies to the Maven file, but continues to build with its internal build manager. If you need to add a dependency, IntelliJ will automatically add the dependency in the POM file, but you have to manually add it in its own build manager. Given this inconsistency, it is possible to have two different build configurations within the same project.

Additionally, converting a project from a Netbeans based project with a GUI doesn’t work in IntelliJ. IntelliJ will not interpret the Swing code generated by Netbeans. This means that for anything GUI related, I will have to use Netbeans.

What would be nice?

Support a non-proprietary build system. NetBeans defaults to ANT, and can support Maven natively. If this is not an option, then write an adapter for Maven/ANT/Gradle.

GUI: Reuse the Mattese code. Make Mattise a plugin and write an adaptor for IntelliJ.

I’m a student, what [language, framework, API, concept] should I learn?

Part one of a continuing series.

There are two ways to learn something. The first way is to learn from another’s advice [the easy way], and then there is the hard way [through experience and making mistakes]. When starting out in a Computer Science degree, learning the material and concepts will require a lot of effort. [the hard way] It’s not a wrong way to go about it. The hard route helps to reinforce the material. However, not everything in your journey to become a software developer has to be difficult.

One of the most frustrating things for a student, when in a Computer Science program, is producing a deliverable to submit. Many students, outside of the introductory course, quickly find out that a few quick hacks won’t get the highest grade available. Many professors require documentation, specific file layouts, compliable code, funky submission instructions, build instructions, shout-outs in the comments (1), or even coding conventions. These extra/non-technical requirements add to more complexity and make assignments more difficult. However, they do have merit and “build” the student’s technical character. In academia, there are very few courses in the US that will teach the tools of the trade, this is something that the student is left to learn on his or her own.

So what does this have to do with answering the question: What should I [as a current Computer Science student] learn? Build systems. Learning how to consume a web service to Facebook or writing the next twitter client is great, however learning how to use a build system will make your professor’s, and your life much easier. A build system is an external tool [usually separated from an IDE] that defines the instructions on how to build an application. In addition, it makes your life easier when questioning if your attempt was worthy enough to submit. Did the build system pass and produce a deliverable? If you have all of the rules and unit tests configured to run, the answer is easy… Yes! Once you are confident that the assignment was completed to satisfaction, you can go party err study ‘social algorithms.’

So let’s imagine that you have the following requirements from a professor:

  • Build a chat system [One client, and one server]
  • Include unit tests for every method used
  • Include Java Doc
  • Email to: professor@university.com
  • FTP The resulting zip file to: ftp server.
  • Create a readme at the base, and include your name and the word “Screaming Monkeys” within the readme file.
  • Include instructions on how to build your software
  • Use the following file format:
    • /
    • Readme
    • BuildDoc
    • Doc/
    • Source/Client/*….
    • Source/Server/*…
    • Binary/*…

Building a working chat client and server solution may be difficult for someone that has just learned about sockets and lacks experience. The non-technical requirements could become overwhelming. However the assignment never required all of the non-technical instructions to be performed manually. I have NEVER heard of a professor that will take points off for using these tools. If anything, using a build tool will improve your grade. It allows for you to plan for these requirements ahead of time, and let software handle the rest for you.

“But hey! That looks like a lot of work to do a few simple steps!” You’re right; all of those steps can be performed manually and probably quicker. However, if you screw up part of your final deliverable , you’ll have to perform all of those menial tasks all over again. With all of those tasks, Ant can perform those automatically by just typing in “ant.” You can configure ant to build the software, run all of the unit tests [and stop the build if one fails], configure the output of the java doc, run utilities [to confirm that your name is there, and the “special word”], perform all of the file manipulation and deliverable locations, and even submit the result [ftp, email, source control]. If there is an ant task for the action, you can use ant to do it.  Another benefit is that it can even run the source code through a “coding convention” checker. Have a professor that requires you to use the K&R coding convention? No problem, just add a check or reformator in the build environment. Problem solved.

In summary, assignments in computer science are difficult with the shear amount of demands. Reduce the potential for mistakes by automating the tedious tasks. Learn a build system early in your education. It will help ensure consistency in your code, get rid of annoying non-technical requirements, and make your work a lot simpler.

Need another reason? Do it for getting a job after you get out of school. There are very few students that have even used a build system prior to entering the work world. Most students entering the work world have to learn at least one build system as soon as they start their first job. The software industry thrives on build systems. If they aren’t working, the developers are unable to progress. Hey, worst case scenario: Let’s assume that you’re not a very good CS student, and you barely pass with your CS degree. If you know a build system extremely well, you can still proceed with a career of being a “Build Systems engineer.” Those guys can still make quite a lot of money. [Indeed claims that a build engineer starts at $50k and has a sizable amount of jobs that will earn $130k+ a year]

Some of the build systems that are currently in use:

  • Ant [Good for nearly every language out there]
  • MSBuild [Good for the MS supported language (VC++, VB?, anything .NET)]
  • Maven
  • Gradle
  • Make [Good for C++, and bash]
  • Apache Ivy

(1)    In my prior work as a teaching assistant I am guilty for supporting the shout-outs rule. The requirement was for the student to include his or her name in the top of the file. This was mentioned on the grading rubric (included in the assignment writeup/specs).  It’s a simple request to complete, and it makes the grader/professor’s life a lot easier. It’s akin to asking elementary school children to write their name on top of the assignment. A lot of new students don’t add their name to their code.