devnulled: A stream for software developers and engineers

As both a fan and user of the great technologies Python, and the Sun JVM (primarily via Java), I was very happy to come across this eWeek article which says that Sun announced the hiring of two key Python engineers. You can read more about the hiring of Ted Leung and Frank Wierzbicki at their respective blogs.

I had pretty much written off Jython as being dead quite some time ago, but luckily it has had a lot of recent activity and is starting to catch back up with C-Python. By both hiring key JRuby and Jython developers, it looks like Sun is making sure the JVM stays relevant beyond Java and continues to evolve as what in my opinion is the best option for cross-platform applications.

Having a long background in ColdFusion (an Adobe language which compiles down to Java bytecode and runs on the JVM), I’ve seen first hand the benefits of moving a language to the JVM, and I look forward to seeing more progress on both JRuby and Jython on the JVM.

For those many of you (including myself) who have been waiting almost a year now for Java 6 to be properly supported on the Mac, the wait is over if you’re a developer– Landon Fuller has released SoyLatte 1.0, which is a port of FreeBSD Java 6 to MacOS X which will eventually end-up as part of the OpenJDK. This seemed to come together very quickly once Leopard came-out and was missing Java 6.

Though Java 6 didn’t provide quite as much new syntactic sugar as Java 5, the performance increases in Java 6 are pretty dramatic. I highly recommend giving Java 6 a look if you’re doing any development which runs on the JVM if you haven’t already switched.

Keep in mind that this is mostly a developers port as it’s not yet integrated into Cocoa, the MacOS X native GUI. Desktop applications will run under X11, but this is the next hurdle to tackle (though it seems to be a pretty big one).

Having came across several interesting stories within the past week or two which were all career related, it reminded me of all of the good resources I’ve came across over the past few years related to the craft of Software Engineering. Maybe you’re just looking to get started in Software Development and aren’t sure if it’s for you, or maybe you’re a manager wondering why your employees are leaving– all of these items and more are covered here.

1. Getting Started

Not sure if you were cut-out to be writing code for the rest of your days? Are you feeling different than your peers? Justin James wrote an interesting list– 10 signs that you aren’t cut-out to be a developer.
Now that you’ve decided you are genuinely interested in becoming a programmer, there are many, many ways to go about this. If you don’t have any idea what direction to head to, a good starting point is Getting Started in Programming.

2. Get Your Resume In Shape

Resumes are yet another major thing to get right. A resume is what can get your foot into the door into the company of your dreams, or put you in an infinite job search loop with very little feedback. There are many opinions and guides to creating the perfect programming resume, and here a couple which I’ve found to be the most helpful are Writing a Resume That Will Land You a Programming Job and Resume Pitfalls Every Programmer Should Avoid. Most programmers are notoriously bad at presentation and should also think about giving their resume a face lift. It also might not hurt to take a look at the 100 most searched for resume keywords and add them to your resume if they match your skills and experience.

3. Starting your Job Search

One of the best ways to get jobs is to reach-out and network with people you know to see what jobs they know about. The most natural and unobtrusive way to do this is to sign-up for LinkedIn and import your address book.

A good way to see what sort of jobs are out there and what the market is like is to use a job aggregator and search engine like indeed.com. There are also some other sites to take a look at which it doesn’t have permission to index such as craigslist. You may also find out about jobs through local mailing lists or user groups. You could also check into companies that you like and are interested in by going to their website and seeing if they have any open positions which fit your skills and experience.

There are of course many large and popular job sites which you might want to hit individually if you aren’t finding what you’re looking for via indeed.com– sites like Monster, HotJobs, and Dice are all good places to start.

4. Prepare For The Big Interview

If you’ve been in the industry for awhile you know that what you can expect during the interview process is it being completely unexpected. There are a wide variety of interview techniques used by companies, and none of them seem to be the same. I think one really good overview on what to do is Preparing for a Software Engineering Interview. While that is a good overview, you have to prepare for a very wide variety of questions. Here are a lot of resources to prepare you for an intense Software Engineering interview process including some general interview tips as well:

• How To Pass a Silicon Valley Software Engineering Interview
• Google & Microsoft Algorithm Questions
• 50 Common Interview Questions & Answers
• Everything You Wanted to Know About Getting a Job in Silicon Valley But Didn’t Know Who to Ask
• Programming Interview Questions
• Developer Job Interview Questions and Answers - This is probably the most exhaustive list of technical questions I have ever seen!
• How To Answer 23 Of The Most Common Interview Questions
• Answers To Technical Interview Questions
• Questions At A Google Job Interview
• IT Interview Open Questions Database
• “Why Should I Hire You?” and Other Favorite Interview Questions
• How To Answer The Toughest Interview Questions
• Five Essential Phone Screen Questions
• 25 Most Difficult Job Interview Questions (and their answers)
• The Top 10 Questions Every Programmer Should Ask on a Job Interview

Although you should be prepared for a wide variety of potential interview questions, you should also be prepared to ask plenty of questions of your own. Bruce Eckel provides a good list of questions which you should ask during an interview, and you should also be prepared to take some ownership during the process as well.

You should also make sure to dress appropriately for an interview– it is not the time to break-out your DEFCON 1999 shirt, nor should you make an unnecessary trip to your local department store for a suit. Unlike most other white-collar professions, you are actually at a disadvantage if you wear a suit to an interview, but you should at least take the time to clean yourself-up and look like a well adjusted adult.

If you happen to be on a team trying to land a new developer and you experience great candidates turning you down over and over again. One thing to be conscious of is how poor interviewers drive away talent.

If you didn’t get the job, it wouldn’t hurt to read 25 Reasons You Didn’t get the Gig to brush-up on your interviewing and presentation skills before you give it a try again. Or maybe it’s just a sign that you’re ready to start your own company or do freelance work from home, there are plenty of reasons you don’t need a job.

5. Got The Job? Improve Your Situation

There are many things you should be doing to improve your career and general well being even while employed. For one, you should always continue learning– whether this be new languages, frameworks, or even learning more of the classic Computer Science topics in depth, don’t forget to prevent yourself from becoming stale. The one constant about technology is that it’s always changing, and you will need to keep-up on your own time to stay competitive.

At the same time, being the master of a particular domain is not all it’s cracked-up to be– make sure you spend plenty of time outside of programming as well for a balanced life. I try to learn as much about as many topics as I can, and from time to time find some interesting lessons in life you can later apply to what you do. Travel to new places, try things you normally wouldn’t do, try new cuisines, and in general find ways to grow your mind.

Programmers aren’t known to be the most extroverted, gregarious people in the world (myself included), but you should make an active effort to meet new people in your field. Whether that be at user group meetings, conferences, chat rooms, mailing lists, message boards, etc, you’ll find that having connections in the industry is a very good thing to have. I’ve mentioned it before, but LinkedIn (no affiliation other than a user of their service) is a really great place to keep in touch with your network.

A topic that many programmers overlook is budgeting and investing– we’ve all been guilty of it at one time or another! It’s easy to be wasteful when making a decent salary as many software developers do. Here are a few resources which will help you get a handle on your money and start making it work for you by doing more with less, and investing more:

• 15 Ways To Keep More Of Your Money
• The Spending Plan: Budgeting for Non-Budgeters
• 9-Step Beginner’s Budget
• Healthy Food on an Unhealthy Budget
• 2006 Makeover, Step #2: Budgeting and Saving
• How to Create a Zero-based Budget
• Budgeting For Non-Budgeters
• 50 Smartest Things To Do With Your Money
• Where to Put $5,000 Now
• How To Save $1 Million For Retirement
• How To Invest $20, $100 and $1,000+
• 20 Investments: Introduction
• MoneyChimp: learn Stock Market Investing, Index Funds, Valuation Models, and more.

6. All Things Must Come To An End

Once you’ve been in a job for awhile, it’s pretty much inevitable that you will leave for greener pastures for a variety of reasons, or be forced to move for various reasons. You might even find yourself alone after many of your co-workers leave via a mass exodus in which management has no control over. If you feel that you’re in a salvageable position, some links which might help you analyze what the problems are in hopes of fixing them include:

• Why Top Employees Quit
• 50 Ways a Manager Can get Employees to Quit
• How To Lose Half of Your new Hires Within A Year
• Managers fail to find out why employees leave
• 1/5 Employees Quit Within The First Two Years
• Why Great Employees Quit, And What You Can Do To Keep Them
• Top 10 Reasons People Quit Their Jobs

Perhaps you’re tired of your job for various reasons and are weighing whether or not you should stay? A couple of articles which might help you make the decision on what to do include What To Do When the Thrill is Gone and Do I Stay or Do I Go.

Although this is quite an exhaustive list which took me quite a long time to write about and assemble, I’m sure I’ve missed plenty of tips or resources to pass-on. If you have any to add, be sure to leave them in the comments!

Thanks to Flickr user McBeth for the perfect photo.

One great thing about the blogowebs is that you never know what sorts of posts you might run across, and this post about self-modifying code and the Space Shuttle OS is a prime example of that:

And it reminded me of my days during the early 1990s working as a software engineer on the Space Shuttle operating system (FCOS). Many people don’t know that the Space Shuttle OS implements self-modifying code for the purpose of “fault-tolerance”. The Shuttle computer systems consist of four primary computers running the same software, and a fifth backup computer running different software that is equal in functionality. The goal is to be Fail Operational if one or more computers fail, and Fail Safe if all primary computers fail; this is called a Fail Operational/Fail Safe system.

An interesting read, especially if you’re a software developer who doesn’t work in embedded systems but likes to read about them.

One of the newer features of Java as of 1.4 is non-blocking IO, yet it’s very hard to find decent documentation about it or even a simple tutorial. NIO is a very powerful feature but easy to get wrong given it’s complexity. However, James Greenfield, an engineer for Amazon, recently announced that he’d put up a tutorial for NIO, including a lot of important details of using NIO with SSL.

Fillp Hanik recently posted a blog entry about a load test comparison he did using Glassfish, Jetty, and Tomcat 6 using the new NIO (non-blocking io) connectors in which Tomcat 6 was able to handle 16,000 connections. As always load tests should always be taken with a grain of salt, but it certainly did produce some interesting results (especially when compared to other servlet containers).

I’ve been working on a sizable project at work that uses NIO under the hood, but luckily I’m using a 3rd party library which provides the network connectivity for me. It seems that NIO is very hard to implement correctly, but if you can, the performance advantages are definitely worth the effort. I’m only a few days away from starting to do some load testing on my work, so I’ll be interested in seeing the performance improvement over the section of code I’m replacing which uses standard IO (not to mention the various synchronization and thread consumption problems I’ll be fixing).

Being able to quickly handle a large number of concurrent connections is definitely a requirement for today’s AJAX applications, and it’s good to see an NIO based connector from someone other than Jetty.

Google recently released yet another interesting piece of Java machinery, Guice. Given the direction that Spring 2.0 is going in, this looks like a good alternative if you’re looking for a simple dependency injection framework. If you’re curious about what is different between Guice and Spring, you can read more about their differences here.

This past Friday marked the end of the second week at my new job which has brought many changes for me. I left a good sized development team at large company for the uncertainty for a VC funded start-up without revenue, I’m miles from a ColdFusion server and instead am working on a Java distributed platform (though I had been working in Java exclusively for about 6 months before changing jobs), and I switched to a MacBook Pro among other changes. All of the changes have been great choices so far, and it was good time to make a big jump just from a personal standpoint as I felt that I was starting to stagnate. I pretty much had the option to use whatever platform worked best for me, and I took a leap of faith and decided to go with a MacBook. I got equipped with a very nice one– I have the 2.33 Ghz Dual Core w/ 2 GB of RAM.

The first day or two I felt like a bull in a China shop on the MacBook. The process for installing software didn’t make any sense to me, I kept using the control key for common shortcuts, and in general I was trying to figure-out how to setup the full software stack I’m now working on without really having a good understanding of the OS I was using on my workstation. I’m sure I’ve looked retarded to my new co-workers for the most part so far, but I feel like making the switch is really starting to pay dividends.

For starters, there is just no comparison between the fit and feel of a MacBook Pro to a Dell laptop. My Dell seems like a total piece of crap now, and it annoys me to have to use it. It’s big, heavy, clumsy, and shodily assembled compared to the MacBook. I look at some of my co-workers Dell laptops and am very glad that I picked the Mac, though some of them have some 12″ Lenovo’s which are pretty sweet.

Since I’m only a couple of weeks in, I hesitate to list all of the various software and so forth that I’ve found useful, but I’ll get around to posting that in a couple of weeks once I feel like that list is more finalized. Instead, I thought it might be useful to post some of the pros and cons I’ve noticed coming from using Windows and Linux:

Pros:

• Unix with a very nice GUI. That’s really enough to sell someone right there. I’m a command line junkie and it’s nice to have Bash and all of the assorted Unix facilities and software available
• The hardware is really good– it has great fit and finish. I can even use the MacBook Pro on my lap without getting scalded. There are just so many little things that you notice over time about the MacBook which are ingenious (like the light sensitive keyboard backlighting for instance)
• Everything just works. Had I attempted to set the same environment up on Windows I would have had to bludgeon myself with Cygwin. I haven’t had to deal with any of the annoying dependency problems that Linux has.
• I actually like the hardware lock-in. It makes it much easier to find accessories for your given hardware, and you can easily compare specs and application performance with other users, etc. I’m sure this also helps make the OS a lot better as well since they don’t have to support every chipset and piece of hardware under the sun.

Cons:

• Some of the software seems like it’s dumbed down too much. I understand it’s a design philosophy of the Mac, but with some software I find myself looking for the “Advanced” mode. I’m not sure what you would call the file browsing software, but it was my primary complaint until I found Path Finder
• The concept of Free Software seems to be beyond a lot of people in the Mac community. Every little add-on that makes software suck less is likely to cost you $12-$15.
• There aren’t really any Mac specific ergonomic keyboards. I’m currently using an MS Natural keyboard when I dock at work, but I find it hard to get used to shortcuts because I’m still using a keyboard with a Windows layout

All that I can say is that from the perspective of a big Unix fan who does Java development, I feel like the Mac offers a great platform for both software development as well as an everyday workstation OS. I’ll get around to posting a list of software that I’ve found to be useful in a couple of weeks once I feel like I’ve got most of what I need.

Not to directly pick on Peter Bell at all (he’s a very smart guy and I really enjoy his blog, so this is nothing personal at all), I just noticed something he mentioned in a recent comment on a blog entry and felt that it was something I should address in a blog post rather than a comment. Also, writing this entry gives me a good reference point later to send to people when they present the same talking point to me.

Anyhow, here is the comment that Peter made which inspired this blog entry (which in context, is a quip):

I also have to question why you’d even consider using CF for a performance critical app - even Java is a little sluggish. If you want bare metal performance and think your time is worth less than the cost of a server, go for it and write the darn app in C++!

I wanted to point out and correct a common fallacy that I see repeated over and over again are statements rooted in comments like “If you need speed, you could convert your Java application to C or C++”. I don’t claim to be a Java expert by any means, but I do think I have a good enough understanding of the Java platform as well as basic operating systems & compiler theory and the like to explain why this is a false argument. The answer is actually more along the lines of “it depends on what you are doing”, and I’ll explain why.

It’s very easy to see where this misconception started– pretty much every software developer or system administrator has encountered a slow Swing/AWT based Java application which took forever to start, and generally seemed pretty sluggish. Not to mention it probably looked terrible. One of the best Java based desktop applications, Eclipse, even takes awhile to start. On the contrary, C++ desktop applications typically start very quickly, and are very responsive to user input. Generally speaking the symptoms of running a Java desktop application match the reality– C++ is almost always faster for short running programs such as desktop applications.

Another common assumption is that it would seem that the JVM itself is an abstraction above machine level code because it acts as an interpreter, and that C/C++ will always be faster because the resulting compiled code is “closer to the hardware” which is also false. In the early days of Java, the JVM did in fact interpret code, but eventually it started using a Just In Time compiler in Java 1.2 to compile the code down to the machine level. Different implementations of the JVM use various JIT compilers, but the Sun JVM uses the HotSpot JIT. Not only are Java programs compiled down to machine specific code, but the longer a program runs, the better it gets optimized.

The HotSpot compiler monitors and analyzes an applications performance over time, and uses adaptive optimization to eliminate bottlenecks in the machine code, known as “hotspots”. It essentially looks for pieces of code that are ran time and time again, and marks them for optimization. Those pieces of code are then recompiled again into machine specific code for performance. This allows for ongoing performance enhancements that you would never get from machine code produced by a C or C++ compiler such as branch prediction hints.

All of these things are not just unfounded theory, there have been several independent studies about this including this one by the University of Southern California.

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

This study is several years old now and doesn’t include testing against the many performance enhancements which were made available in the 1.5 JVM, so I’d be interested in seeing an updated study.

That said, Java is probably much faster than you think. One way I’ve seen the Hotspot compiler in action (and you can try at home) is when working on a simple “Hello World” JSP and keeping track of it’s execution time. Typically on the initial run or two, the JSP page is pretty quick, but then after a few calls of the page the Hotspot compiler kicks in and makes it wicked fast so that it’s execution time is effectively nil.

Now that we’ve spoke to the “Java Is Slow” audience, we should cover the answer to the earlier question of “Is Java slower than C/C++?”. This is more of an “it depends” answer. Generally speaking C++ has the advantage in short running applications, and Java is as fast if not faster than C/C++ in long running applications such as servers, web applications, etc. It also might surprise you to know that Java is also very good in real time systems, but that is another blog post of its own.

I was quite surprised to come across a post by Bruce Eckel, one of the founders of the C++ ISO committee as well as a popular Java author and trainer, essentially evangelizing the use of Flash and Flex to get around UI problems which exist in traditional web applications. I think it’s quite an informative post, and it’s interesting to see a response from one of the main voices in Java land about much of the recent hoopla about how “Java is dead”.

So here’s my question. Allow for a moment the possibility that, after 10 years, Java is not going to take over the world of RIAs. Further allow that Ajax is just “how JavaScript was supposed to work in the first place,” but that the limitations imposed by browsers, HTML and CSS committees seem unlikely to let it expand beyond its current bounds. What are we going to use to build RIAs?

In my own search, I’d really like such a system to solve not just some, but all of my UI problems. If I’m going to go to the trouble of learning it, I don’t want to run into a wall just when I start to develop some speed. That’s happened plenty of times already.

The only obvious solution is Flash. Flash has always been all about cross-platform multimedia experiences and user interfaces. People are very familiar and comfortable with Flash, and it is installed on almost all machines in the world. It’s trusted, stable and reliable.

Apparently we might also see him advocating Flex soon as well:

I believe that to solve the user interface problem, we need the equivalent of a domain-specific language dedicated to the user experience. For me, Flash-based technologies like Flex are the best solution to this problem. (Full disclosure: I’m in the process of working out a consulting contract with Adobe, to help them teach people about Flex. But long before this, I became convinced that Flash, and Flex in particular, was the best solution for the user-interface problem, and I began writing this article long before Adobe expressed interest in my assistance).

That is a pretty interesting tidbit in and of itself. I think having someone like Bruce Eckel behind Flex would be a really great move by Adobe.

My own personal take on the “Java is dead” type stuff is that Java is still going to be around for a long time and is still the language of choice to build enterprise capable services with, or any other application where horizontal scaling, uptime, and a fast, rock solid platform are your primary concerns. I would however certainly look for a different technology to use to build the UI into such a beast.