Caffeinated Coder

I’ve spent much of my free time over the last few weeks learning Ruby on Rails and thought I would record a few first impressions for anyone else who is thinking of dipping their toes in the RoR waters any time soon.

First…My Motivations

1. Curiosity – I’ve made a few snide remarks about Ruby over the past year in response to what I felt was the overuse of hyperbolic and cultish language by prominent Rubyists. After a while, I decided the only way to know for certain whether the buzz was more hype or more reality was to experience it for myself.
2. Project - I promised my wife I’d get a simple PayPal integration e-commerce site up and running for her soon. Since my hosting site only supports PHP or RoR and I’ve already played with PHP enough through WordPress tweaks for my blog, I decided to go the Rails route. This gives me a vested interest in giving it a fair shot because if I can’t get it to work, then the wife won’t be happy. Everyone knows that if the wife ain’t happy, then nobody’s happy.

Learning Curve Milestone

1. Over the Motivation Hump: In the beginning, I languished for several weeks in a state of motivational limbo. The pure Ruby language stuff wasn’t that interesting to me and I hadn’t quite invested enough time in Rails to understand what was going on yet. The “Aha” moments finally came once I got all the CRUD operations working for one of the pages of my eCommerce app (sample apps only get you so far) and then got it deployed to my hosting site. Every since getting past that hurdle, I’ve noticed that the time I’ve spent reading my Ruby book has increased dramatically along with my reading speed because I am suddenly much more interested in it now that I am starting to grok the potential.

Concepts I’m Sold On

1. Convention Over Configuration – As a .NET developer, I’ve written my share of data access code and SQL over the years and feel perfectly comfortable with it. But I have to admit that it was a nice feeling to have ActiveRecord (the ORM package for Rails) be able to glean the table structure based on my naming conventions and dynamically generate the SQL and plumbing code behind the scenes for me. I didn’t even have to look at a bunch of ugly generated code in a code-behind page. It just worked. I haven’t had any experience with Hibernate\NHibernate mapping XML files, but I imagine that it is still much more laborious than the Rails approach.
2. MVC structure - When I first tried debugging into CruiseControl.NET, which uses its own home-grown MVC style architecture, I was discombobulated because the url didn’t directly map to a code file. It seemed like an unnecessarily complex way to structure a web site. However, after experiencing how the url maps to a Controller/Action/Parameter in Rails, Django, and the .NET MVC framework, I am finally becoming a fan of this approach. Once I got used to where to look for everything, code suddenly seemed like it was much more organized and manageable than before.
3. Having Development Lifecycle Built Into Project Structure - The fact that Rails creats a Dev\Test\Prod folder and configuration files, thus embedding the natural development lifecycle into the project structure from the very start, is such an obvious improvement that I’m surprised that not everybody does this.

What I’m Excited To Try

1. Migrations – I’ve heard about this for a while, but only read about its full capabilities today. Managing database schemas and data across environments is one of the biggest pain points where I currently work. Having a tool that can manage incremental changes to databases and then automatically roll versions back sounds too good to be true.
2. RAKE – This is the Ruby version of Nant/MsBuild but it uses code syntax instead of XML. I’m not as much of an XML-hater as some people, but if given a choice I always prefer code because it usually means much better debugger support.
3. RSpec – This is the testing tool that encourages Behavior Driven Development by enforcing certain naming standards and the transforming executable tests into human readable documentation. I saw the .NET port of this last fall at the ALT.NET conference in Houston and finally saw this demonstrated at the last KC Ruby User Group Meeting. I’m still not convinced that it can simply be handed to users in lieu of documentation as many claim, but it is still the best effort to merge the world of tech specs and executable tests that I’ve seen yet.

What I Haven’t Made up my Mind on Yet

1. Documentation: I’ve read several complaints that the English documentation for Ruby, which originated in Japan, is lacking when compared to other languages like Perl or Python. As a beginner, this hasn’t been an issue for me yet because there are plenty of books and web-based tutorials available, but this is something I’ll watch out for down the road.
2. Complex data models: I’m curious how ActiveRecord will handle the traditional problem of impedance mismatch that all ORM systems face when trying to reconcile conceptual differences between how information is represented in a relational database versus an object model (it’s what prompted Ted Neward to call ORM the Vietnam of Computer Science). So far I have been impressed with Active Record, but the approach in all the Rails tutorials so far has been to start with the database tables, which seems to be the opposite approach of what noted architecture gurus like Rockford Lhotka have been recommending for years. I also saw a few references to things like composite keys not being supported by ActiveRecord, which makes me wonder how it will handle large, complex data models from legacy systems. Once again, I’ll just have to wait and see how this turns out.
3. Ruby & Rails vs Django & Python – I’ve seen some excellent debates, like the ones in this Bitwise article or this blog post, on which of these two popular web frameworks is better. Both frameworks rely on the MVC pattern, dynamic languages, and ORM magic to reduce boiler plate data access code. Django boasts faster speed, a more popular and widely applicable language, a more plugable architecture, and some extra administrative interfaces that help out for content management sites. However, since my hosting site doesn’t currently support Django, I’m going to have to wait and do a comparison for myself later this year.
4. Speed & Scalability - I don’t even want to open up the can of worms that Rob Conery did by suggesting Ruby is slow and has scalability issues. However, the general consensus is that Ruby is indeed slower than Python and both are much slower than most static languages like Java or C#. Rubyists contend that Rails is fast enough for most scenarios and that you can always drop down to C when performance is needed. I agree that performance isn’t something that most apps need to worry about these days, but I am more skeptical about the viability and ROI of dropping down to C for most development shops when performance is an issue. On the other hand, Rails is still pretty young, so I can only assume that future versions will improve in this respect.
5. Tools – The general consensus seems to be that tool support for Rails is lagging behind the powerhouse IDEs used in the Java and .NET worlds. Although I do think that Visual Studio is a bit bloated these days, I see Intellisense and visual debuggers as major productivity boosters and see it as a significant downside to doing development in Ruby. So far the attitude I’ve run into from Rubyists has been the equivalent of “real programmers don’t use tools”, which I’ve never agreed with. I did see an article about Ruby In Steel that has both intellisense and a visual debugger, so I plan to try that out. For the time being, Notepad2 will work.
6. Beauty? – Call me a cynic, but I’m afraid I side with Jeff Atwood here when I say that I just don’t feel comfortable using the word beautiful in reference to code syntax. I definitely have aesthetic preferences when it comes to code, but they seem a little too subjective to be able to definitively say that one language clearly reigns supreme over all others in this respect. To be honest, from what I’ve seen so far, I like about half of the syntax in Ruby better than C# and half of it worse. For example, all those end keywords that litter Ruby code give me nasty VB.NET flashbacks, so I’m not partial to them. I am willing to believe that my sense of aesthetics will change over time and that I might suddenly find Ruby syntax more appealing a year from now. However, I am also suspicious that there is an emperor’s new clothes phenomena at play here. This means that a few smart and influential people proclaiming that they see beauty can suddenly cause everyone to convince themselves that they also see beauty, not because it is really there, but because they don’t want to look stupid or feel left out.

Please remember that I am very new to Ruby on Rails, so I welcome any corrections or helpful insights that readers who have more experience in this area can offer.

As for the rest of you, I wisely chose to clip my section on “Tips for People Just Starting Out” because this post was so long, so tune in next time for some tips on how to avoid stumbling blocks early on in the Ruby learning path.

Popularity: 19% [?]

In case this post rides a reddit or Dzone wave, let me start out by saying that I am both from the United States and a .NET developer. Now on to my regularly scheduled point…

I’m fairly certain that most people would agree that Microsoft as a company is despised by a sizable segment of the software industry.

Since corporate politics bore me, I’m going to skip the part about why this is the case or whether this view is justified. Instead, I’m going to focus on the following corollary:

The same segment of the software industry that dislikes Microsoft also views developers who use Microsoft tools and languages as inherently less skilled and less capable.

That is a nice way of saying that when the typical Java\Python\Ruby developer conjures up an image of a .NET developer, it probably looks something like my esteemed blog sponsor on the right sidebar. In other words, I believe that the prevailing stereotype about .NET developers is that we wouldn’t know a software best practice or sound computer science principle if it recursively bit us in the arse.

Why does this stereotype exist and is it deserved?

Some harsh reddit feedback on one of my recent blog posts prompted me to seriously ponder this question and after going through various phases of anger, denial, and rationalization, I finally settled on the following theory.

Developers who don’t earn their living from Redmond-based technologies dislike Microsoft developers for some of the same reasons that people from other countries dislike Americans.

For any of my fellow countryman who are surprised by this, it is true. Most people in the world don’t like you. I’m sure books could be written on all of the social, political, economic, and cultural offenses that we unknowingly dole out on a daily basis, but I’m just going to focus on the one psychological offense that I’ve observed first hand numerous times in my travels.

Americans are inherently annoying because we rarely invest any effort into learning anything about the external world.

For example, If you are an American and meet someone who is well educated from another country, then statistically speaking the chances are good that:

1. You will not speak their language even though they will probably speak English.
2. You will not be able to locate their country on a map even though they could probably name all 50 states.
3. You won’t know who their national leader is even though they will not only tell you the name of our President, but also give you a nice summary of his foreign policy exploits over his last two terms in office.

You don’t have to have a political science degree to understand the psychological effects of this interaction. How did you feel the last time someone completely blew you off because you know they didn’t think you were important enough to bother with? Needless to say, it doesn’t help much on the diplomacy front.

I think a similar dynamic occurs with .NET developers who are so busy drinking from the firehose at Microsoft that they forget about the rest of the development world entirely.

The reddit comments that drove this home the most for me was the one said my opinion should be discounted because I “break the programming languages world into “languages by Microsoft” and “other languages”. Not a bad point.

Then there was my favorite wickedly sarcastic comment from Lepton3 (…come on reddit…you really need to de-anonymize this process a little). In response to my stated desire to learn finally learn Python, he quips… “Steady on there tiger! You wouldn’t want to rush in too soon.” A damn good point considering how long Python has been popular.

They both made me realize that despite my great efforts to study software best practices and learn no less than a dozen new Microsoft technologies in the last few years, I was still being pretty myopic in my approach to software development.

So, I hereby relinquish any guilt that I may feel for not keeping up with every new technology coming out of Redmond in the next several years. Instead, I’m going to do the programmer’s equivalent to a little world traveling so I can get better clued into what the rest of the software world has to offer.

I’m sure all the other kids will still make fun of me for feeding at the Microsoft teat, but at least I won’t stand out like a typical American tourist anymore.

Oh, and for all you .NET readers who may get inundated with posts on Ruby, Rails, Python, Django, and MySQL in the near future (at least that’s what I’ve been spending all my free time on in the last few weeks), hang in there. A little foreign culture is good for the programming soul. Also, since there’s no place like home, I’m sure I’ll continue to churn out .NET content as well.

Popularity: 100% [?]

I recently came across an excellent blog post via Dzone from Ben Watson called 5 Attributes of Highly Effective Developers.

He lists humility, love of learning, detail-orientedness, adaptability, and passion as the most important traits that a developer can have in order to be effective at their job and provides some well written insight into what he believes each of the different traits really means. For example, he has this to say about humility:

…humility isn’t pretending to be worse than you are and it’s not timidity. So what is it?

Simply put, humility is an understanding that the world doesn’t begin and end with you. It’s accepting that you don’t know everything there is to know about WPF, or Perl, or Linux. It’s an acknowledgment of the fact that, even if you’re an expert in some particular area, there is still much to learn. In fact, there is far more to learn than you could possibly do in a lifetime, and that’s ok.

Once you start assuming you’re the expert and final word on something, you’ve stopped growing, stopped learning, and stopped progressing. Pride can make you obsolete faster than you can say “Java”.

His thoughts inspired me to come up with a few corollaries of my own. I refer to them as corollaries because some of them are related to humility and passion, which are Ben’s attributes.

Ensure the Right Problems are being Solved

One of the fastest and most talented developers I’ve ever worked with also turned out to be the least productive member of the team because he continually had to rewrite his code since it never matched what the stakeholders envisioned. I’ll be the first to admit that stakeholders are a fickle bunch, but other developers on the team, who were not nearly as fast or smart, turned out to be much more effective in the long run simply because they constantly asked clarifying questions and sought regular feedback on their work. That led me to one of my most important maxims: It’s not how fast you can churn out code that matters, but how long it takes you to get an acceptable product to your stakeholders.

Creatively Reformulate Problems

Some of the most productive moments I’ve had in my career have resulted from taking a step back from a difficult problem and critically thinking about each of the problem’s underlying assumptions. Many times the assumptions proved to be erroneous or incomplete, thus making way for a much simpler solution. I can think of a few instances where I was able to get around the problem by creatively tweaking the user interface or workflow.

Other times I’ve been able to eliminate the problem entirely by honestly communicating the cost of the feature to the stakeholders, who then removed it from the project list because it didn’t provide enough value to justify the cost. There are definitely times when the brute force technical approach will be required, but I think a developer who is willing to try finessing a complicated problem first will almost always come out ahead.

Use Questioning As a Learning Tool

Sometimes it is not a matter of knowing what question to ask, but rather knowing when to ask it. I recently caught myself squandering perfect learning opportunities because I was afraid that asking my questions would make me look stupid. Conversely, I routinely witness developers pass up similar learning opportunities because they view another person’s skills or platform as vastly inferior to their own and thus erroneously assume that there are no valuable lessons to be gleaned.

On the opposite end of the extreme, it is common to waste learning opportunities by too quickly asking to be spoon-fed an answer without first applying any effort to solving the problem. It is justifiable to occasionally take shortcuts when the project is under a tight deadline or you are in a true collaborative mode (i.e. pair programming), but I think that truly effective programmers value the research and problem solving skills more than one single answer and will thus tend to discipline themselves to be a little self-reliant whenever possible in this area.

Temper Passion with Pragmatism

I agree with Ben that passion is a key trait to look for in a developer, but I’ve also seen otherwise brilliant developers reduced to utter ineffectiveness because they expressed their passion in negative ways one too many times and consequently alienated their co-workers and destroyed their own credibility. Unless you’re spiking the workplace coffee with mind control drugs, you’re likely to only have a limited amount of persuasive currency to spend on convincing your co-workers to switch to the latest and greatest language, tool, framework, or process. Truly effective developers are good at prioritizing the changes they want to help bring about and will consequently let the little things go (without so much as even a snide comments).

The other thing I notice in effective developers is that their passion is grounded in some form of objective criteria so that they are able to calmly provide both pros and cons of a technology that are situational based. That means that they can immediately identify situations where their favorite technology would be inappropriate. Passionate developers who are ineffective don’t often make such a distinction, which usually leads me to conclude that what they are really need is a religious cult or social club to fulfill whatever void that their current language, framework, or platform of choice is filling for them.

In conclusion, it takes more than raw mensa level brain power and passion to be effective at your job. If you want to be or find someone who is both Smart AND Get Things Done, then you have to focus on a few non-intellectual qualities like emotional IQ and self-awareness as well.

Popularity: 15% [?]

I’ve been noticing my interest in non-Microsoft languages has been on the rise lately. I’ve been actively playing with Ruby and PHP and have been blog surfing for information on functional languages like Lisp and Erlang.

I guess that’s why I suddenly became curious about the current popularity ratings of programming languages and started to search for some hard data. The most comprehensive rating system that I found so far is the Programming Community Index published by Tiobe Software.

Here’s an excerpt from their February 2008 results:

Position Feb 2008	Position Feb 2007	Delta in Position	Programming Language	Ratings Feb 2008	Delta Feb 2007	Status
1	1		Java	21.483%	+2.50%	A
2	2		C	14.859%	-1.24%	A
3	5		(Visual) Basic	11.604%	+3.24%	A
4	4		PHP	9.890%	+1.04%	A
5	3		C++	9.274%	-1.49%	A
6	6		Perl	6.205%	+0.13%	A
7	7		Python	4.763%	+1.20%	A
8	8		C#	4.510%	+1.32%	A
9	12		Delphi	2.798%	+0.72%	A
10	9		JavaScript	2.334%	-0.65%	A
11	10		Ruby	1.862%	-0.67%	A

The list led me to a few surprising conclusions:

1. .NET isn’t as popular as I thought – It’s easy to lose perspective when you are surrounded by a single technology. For some reason I had assumed that C# and Java were equally popular. Although Java has declined about 5% on this survey over the last six years, it is still almost 5 times more popular than C#. In fact, C# is 8th on list behind C, C++, Perl, and even Visual Basic (oh the scandal!).
2. Ruby didn’t make the top 10 – Although there has been somewhat of a backlash against Ruby in the blogosphere over the last few months, I still assumed it was popular enough to be in the top 10. I suppose I should have guessed as much after the last recruiter I talked to told me that she never heard of the language.
3. COBOL refuses to die – I was saddened to see that COBOL is still 15th on the list. Some languages just don’t know when to quit. This shouldn’t surprise me since the bank I used to work at was at least 3-5 years from retiring their last COBOL program when I left and they were further ahead of the game than the vast majority of other financial institutions (they adopted .NET when it was still in Beta).
4. Python was language of the year for 2008 – Apparently Tiobe awarded Python this status at the end of last year due to its surging popularity. I noticed this right after I got an impassioned endorsement of the language from someone whose opinion I respect. I guess it’s time to check it out.
5. Functional languages are still on the fringe – DotNetRocks has had about a dozen shows on various functional programming in the last several months, so I thought that was a sure sign that the paradigm had gone main stream after a mere 50 years of relative obscurity. However, Functional Languages as a whole come in at a paltry 1.4% compared to the whopping 98% dominance of Object-Oriented and Procedural languages combined. LISP tops out the list at number 20, while Haskell is 36th, Erlang is 46th, and Scala barely made the top 100. Given the fact that we have hit the wall on processor speed and are well on our way to scaling out to a gajillion cores, I’m surprised that functional languages haven’t achieved a Ruby like cult status yet. Do you really want to spend your golden years debugging multi-threaded programs in Java or .NET? I didn’t think so. On a brighter note, Functional language searches rate quite high on reddit as indicated by this other poll. Perhaps there is still hope.
   

   Category	Ratings February 2008	Delta February 2007
   Object-Oriented Languages	54.8%	+3.1%
   Procedural Languages	42.9%	-1.9%
   Functional Languages	1.4%	-0.4%
   Logical Languages	0.9%	-0.8%

6. Dynamic languages are coming on strong - Rails has definitely proven the value that dynamic languages can bring to the table in terms of meta-programming magic and generally making life easier for the programmer, but I was surprised to see that dynamic languages were already almost as popular as static languages in overall usage. I obviously forgot about the prevalence of PHP, Python, and Perl.
   

   Category	Ratings February 2008	Delta February 2007
   Statically Typed Languages	57.2%	-0.2%
   Dynamically Typed Languages	42.8%	+0.2%

As an interesting side note, there were some languages that didn’t show up on the list because of the “Turing Complete” requirements that the site used.

A language is considered a programming language if it is Turing complete. As a consequence, HTML and XML are not considered programming languages. This also holds for data query language SQL. SQL is not a programming language because it is, for instance, impossible to write an infinite loop in it. On the other hand, SQL extensions PL/SQL and Transact-SQL are programming languages. ASP and ASP.NET are also not programming languages because they make use of other languages such as JavaScript and VBScript or .NET compatible languages. The same is true for frameworks such as Ruby on Rails, Cocoa, and AJAX. Finally, we have also excluded assembly languages, although Turing complete, because they have a very different nature.

No matter how you look at it, there are a lot of options out there that are being taken seriously these days and the number seems to only be growing.

It reminds me of a quote that I recently heard from Steven Forte. He stated in an interview that he won’t hire candidates if they have too much experience in any one language. He suggested only spending about 2 years on a language before moving on to something else. I was skeptical of his career advice at first, but now I’m starting to think that he had a point.

We are clearly entering the era of the polyglot programmer, which means that diversification is becoming more and more of a career asset.

Popularity: 45% [?]

Every since I learned that the most important characteristic of people who become experts is that they continue to learn throughout their careers at the same pace they did when they were beginners, I have found it helpful to do regular mental inventories of new things I’ve recently learned as a way to keep myself honest.

Here are some of the productivity tips that I’ve picked up in the last 3-4 months that have worked out well and saved me quite a few wasted keystrokes and mouse movements:

1. Launcher Program Parameters – In my recent post Friends Don’t Let Friends Use the Start Menu, I described my newfound addiction to SlickRun as a way to launch programs. Since then a few people have suggested that I try Launchy instead because it automatically detects programs without any keyword setup. I still intend to give it a fair chance, but I have to admit that so far I’ve been too distracted by experimenting with using SlickRun parameters so that I am not just opening a program but also accomplishing the first task or two that I normally would perform. For example, instead of just opening Firefox I now have different “magic words” configured to open one or more web sites at the same time. I also have different keywords set up for opening up each of my Visual Studio solutions as well as connecting to each of my different database servers with SQL Management Studio.
2. UltraMon Window Switching Hotkey – I’ve been hooked on UltraMon as a way to quickly switch windows back and forth between monitors for a while, but I’ve only recently thought to set up a hotkey(there is a HotKey tab in the UltraMon properties window). Now I switch the active window to my other monitor by just hitting Ctl + Right Arrow Key.
3. Adding NotePad2 to Context Menu – Life is too short to open random source files with Visual Studio. That’s why I prefer using Notepad2, which offers syntax highlighting but opens instantly. I recently ran across this blog entry that shows how to hack the registry so that this handy utility shows up in the context menu. Now when I want to open source files outside of Visual Studio, I simply right click on the file and choose NotePad2.
4. Address Bar Hotkey (Alt-D) – I picked this tip from a recent Jeff Atwood post and have since used it about a thousand times a day since it works both with the browser and Windows Explorer.
5. Lighter Weight ToDo List – Adding to the “ridding my life of tools that take too long to load” theme, I’ve recently stopped using Microsoft Word to track my To Do list and instead started using a lightweight utility that comes with SlickRun (Jot). Now when I need to jot down a task or thought, I hit Ctl-J and a little green window pops up within in milliseconds rather than the 3-6 seconds it takes Microsoft Word to load. It doesn’t sound like much, but it really adds up over the course of a day. Also, given my ADD tendencies, I have trained myself to immediately jot down random tasks or thoughts immediately as they occur to me or else I tend to lose track of them. However, if I can’t do this in one swift, fluent motion, then I lose all the momentum I had built up on my prior task so this is a big boost me personally in that respect.
6. Unlocking Files with Unlocker – If I get impatient loading up Visual Studio and Microsoft Word, then you can imagine how reluctant I am to reboot my laptop or a development server. Rather than rebooting to solve a file locking related issue, I used to fumble around with Process Explorer in order to figure out which program or service needed to be shut down rather than rebooting like I’ve observed other people doing. Now that I have the Unlocker utility installed, all I do is right click on the locked file and select ‘Unlocker’. The utility displays a list of all the open file handles along with the option to simply unlock the file or else kill the locking process.
7. Configuring VSS to use BeyondCompare for File Comparisons – Every piece of code gets reviewed where I work now, which means that version comparison becomes a pretty critical feature. God help us that we still haven’t managed to find the time to migrate to a real source control tool yet, but one saving grace is that we all have BeyondCompare2 configured as default comparison tool. The VSS comparison functionality just highlights the line that has changed, but BeyondCompare2 highlights the exact characters that have changed. This doesn’t sound like a big deal, but the savings in time and eye-strain add up quickly if your shop is strict about code reviews.

I picked up many of these tips by simply observing my co-workers or following suggestions I read in a blog posts. Other improvements came about as a result of trying to pay attention to any actions I did frequently that seemed to take more steps than they should and then creatively thinking about how to reduce the number of steps.

No matter how you end up picking up these kinds of tips, the trick is that you have to be willing to invest energy in changing your workflow habits.

Which tricks have you picked up recently?

Popularity: 14% [?]

Congratulations to Peter Christensen for winning my first-ever Battle of the Technorati-Challenged contest with his excellent post Lisp: The Golden Age Isn’t Coming Back, Let’s Welcome a Bright Future.

Without the support of Rory’s minions, the voting turnout was about what you would expect for Municipal elections for the Assistant Sanitation Engineer (a.k.a Janitor in Training), but nevertheless I am glad to be able to pass along an excellent prize for a fine blogging effort.

I’ll be contacting Peter later today to hook him up with his prize.

Popularity: 9% [?]

Keeping track of my passwords has been a nagging problem for me for a long time, but I only recently got around to doing something about it.

I’m ashamed to admit it, but up until now I’ve relied on a few popular but extremely insecure strategies to manage my various online identities.

1. Reusing passwords – The obvious danger here is that some script kiddie compromises a very insecure ‘mom and pop’ site that stores my password as plain text and then goes around to all the popular sites trying it out until he finds one that works. Even though I was foolish enough to take this risk for years, most sites have different password complexity rules. That meant that I still had to rely on several different userNames and passwords combinations, which made revisiting sites that I hadn’t been to in a while painful since I invariably had to try several times before hitting upon the right one.
2. Forgot Password Email Feature – I don’t know about you, but I don’t normally access my yahoo email over SSL and many sites simply resend the password in plain text. This means that my password is visible to anyone with a strategically placed packet sniffer, like WireShark. It’s also annoying to have to wait for the email to be sent each time.
3. Firefox Password Manager – I let Firefox remember passwords for me all the time and I recently discovered that this is hugely insecure. If you’ve never used the SIW (System Information for Windows) tool from gtopala.com, take 30 seconds to download it and then click on the secrets node under software. You will be greeted with all of your passwords in plain text from any site that you’ve allowed Firefox to remember for you. That means if anyone ever gets even momentary access to your computer, all of your online identities will be compromised. Not cool.
4. Password protected Excel worksheet – Let’s face it. Microsoft Office security is a joke. I’ve tried this tool with file based dictionaries from this site on Excel 2003 documents and it has cracked the passwords almost instantly. I’ve tried this other tool with Office 2007 documents, which uses stronger encryption. It was pretty slow, but it eventually figured out the password as well.

Whether I’ve legitimately scared you or else you’re just sick of jumping through the “Forgot Password” hoops, I highly recommend trying KeePass. It is a open source password management tool that lets you store passwords securely and safely copy credentials into web forms.

KeePass lets you logon using a password/file combination for extra security and has several clipboard security measures built-in to prevent clipboard monitoring hacker tools from stealing the password while you’re pasting it into a website.

As far as encryption is concerned, the site boasts that even if you would use all computers in the world to attack one database, decrypting it would take longer than the age of the universe. That seems pretty secure to me…

If you’re still being lazy and insecure like I was, why not do something about it?

It only takes a few minutes to download and you will dramatically decrease your security related browsing frustrations as well as reduce your risk of identity theft.

Popularity: 14% [?]

I mentioned at the end of my last post that I decided to take a slightly different approach for my contest that JetBrains was gracious enough to sponsor. I had originally planned on having readers vote for their favorite Caffeinated Codey award and then giving the prize license to the author of the post with the most votes.

Although I will continue to churn out the monthly Caffeinated Codey series and present my favorite posts each month with the usual healthy dose of sarcasm and humor, I wanted to take a slightly more serious approach when it came to doling out prizes for this contest. So, I decided to focus on recognizing solid technical writing from lesser known bloggers (as opposed to just the ones that are easy to make fun of from the more popular bloggers).

In order to accomplish this goal, I set an upper limit for myself with regards to a blog’s technorati score (less than 40) and chose 4 posts from January based on the merits of the technical writing. The post with the most votes by Friday (see poll at the bottom) will be awarded the free license from Jetbrains, the makers of ReSharper, IntelliJ, TeamCity, and DotTrace Profiler.

Here are the four that I’ve chosen for the month of January.

1. Lisp: The Golden Age Isn’t Coming Back, Let’s Welcome a Bright Future by Peter Christensen – With all the hype of a new language but 50 years history behind it, LISP presents unique challenges to a language newbie. Peter provides great details on the history of the language and the current landscape of the community as well as some interesting insights into what you can expect if you decide to jump in and learn it.
2. Programming languages in CS education by Chuck Hoffman – The direction and value of computer science degrees was a popular meme this month. Chuck disagrees with the popular stance that Java doesn’t have value as a starter language and offers some valid counter points regarding the value of library reuse and scripting languages.
3. On Blub by Horatio Alger. Horatio discusses blub theory, the driving force behind any good language debate. He offers a dizzying critical tour of languages along with sound criteria for how to evaluate the strengths and weaknesses of a language for a particular task.
4. Software Development in the Mines of Moria by Marc from Kickin’ in the Darkness – Marc attempts to counter-balance the “shiny new toy” syndrome in technology by reminding us that all the current legacy projects that make us cringe started out by using the latest and greatest technology. He points out that it logically follows that our our current favorite, life-changing framework will also eventually run out of steam and be looked upon with the similar disdain.

Vote here on the post you think is the best (NOTE: if you don’t see the embedded poll below, then your RSS Reader is blocking it and you’ll have to go to the website to vote).

Voting will close on Thursday night at midnight. I’ll announce the winner on Friday.

Happy reading.

Popularity: 10% [?]