Technovangelism

Here’s a fun javascript tidbit that can bite you if you aren’t careful:

>>> null >= 0
=> true
>>> null <= 0
=> true
>>> null > 0
=> false
>>> null < 0
=> false
>>> null == 0
=> false

I can’t think of any way to make this more inconsistent. In C# the expression will always evaluate to false (and you get a compiler warning, but let’s not get into that). In ruby, a NoMethodError is raised because the < operator is treated as a method on the nil object.

Unfortunately, due to the weakly-typed nature of javascript you are more likely to run into this problem than you might think. Because

>>> "0" == 0
=> true

there is a good chance you will find yourself comparing strings to integers, and eventually, null to integers.

No idea where the designer of javascript came up with this functionality, but now that I found it, I’ll be watching out for any potential null comparisons in the future.

At JavaOne, I attended a session given by David Pollak the creator of the Lift Web Framework. In his hour session David built, from scratch, a functional, comet-based chat application. Although short, and relatively simple, David’s talk was compelling enough for me to at least investigate Lift.

I purchased The Definitive Guide to Lift while at the conference and was able to read (note I didn’t say understand) through most of it on the plane ride home. One chapter deals specifically with adding AJAX and Comet to your application enabling push support. It covers almost everything needed to complete the Comet app but it is missing a few important lines, most notably the call to start in ClockMaster.scala.

I posted a fully working copy of the code on Github for anyone trying to use the code from the book. Hopefully it will help anyone else who got stuck in the same place I did.

In the first chapter of every beginner’s Java book, the reader is introduced to code like this:

public class MyClass {

    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

Its simplicity is important to not discourage the reader and its brevity allows for quick and continuous enhancement. But within the first line, it has started the reader down the wrong path in what is considerably more important long term.

Later, a code snippet like the following might be used to explain some features in greater detail:

MyClass myObject = new MyClass();
myObject.myMethod();

Again, the deterioration of good programming skills has started before those skills were allowed to develop.

Why are beginners taught these bad habits when it is just as easy to teach with proper programming styles? The use of the prefix “my” does not provide any insight to what that class/object/method actually does. Despite the difficulty of naming things, it is far better to demonstrate good programming practices and have a 90% intuitive name, than to have a name that is simple but meaningless.

Java is the most notorious for this, but other languages are equally guilty. If you are writing a tutorial somewhere, especially if it is for beginners, take extra care to ensure your code is portraying proper style, so first-time programmers will not have to dig themselves out of any deeper of a hole.

When developing a software project in a short amount of time (less than 6 months), demonstrating often that you are providing value to your customer is essential. Of course it is important for long-lasting projects, but if you only have three months to complete your project, you cannot afford to miss a demo.

I have learned this over the last two major software projects I have completed. On both projects, the team did not just “demo often,” but we demoed every week. (When you only work 2 hours a day, that is a bigger feat than it might seem.) We were not following the extreme programming methodology or specifically trying to program quickly, we simply found that we could provide enough value in one week’s time that it was worth presenting to the customer. These constant demos had some other beneficial side effects like keeping the build in an extremely stable state. Some people use an automated test suite for that kind of security, but having to demo the code once a week forced us to do more manual user testing that uncovers usability issues that an automated test suite is incapable of discovering.

Agile methodologies preach having shippable code at the end of each iteration/sprint, but how often is that the true outcome? When you demo your code to customers, you are essentially shipping your code. The customer has a chance to look at and try out the code and provide some instant feedback. In the most recent project, we actually did ship the code to the customer each week and they performed their own user testing on site. The amount of benefit gleaned from these each week was incredible and no doubt increased the success of the project. From now on, all projects I am apart of will have regularly scheduled demos in front of the customer or stakeholder. They are that important.

Several sources cite the importance of private offices for developers. But those are referring to full-time, professional programmers who are spending around eight hours a day in those offices. They do not ever speak to different situations in which developers might be working for only two hours a day. According to the same sources, two hours is hardly enough to ever enter “flow,” let alone do something with it. With flow being such an important reason to have a private office, if you can never reasonably enter flow in the first place, is a private office worth it?

A significant amount of my development experience comes from working on a team of five programmers who meet together for a total of ten hours a week and due to space limitations, all work in the same room. Because we typically work no more than two hours a day, I am willing to argue that private offices would not benefit us. I won’t go as far as to say an open area is beneficial, but I don’t think it is doing any damage to the team. The developers quickly learn how to focus and block out noise so that conversations between two members don’t become conversations between everyone. Private offices could disrupt communication between individuals because walking to another developer’s office takes time. Granted, it is not very much time, but when you have only two hours per day, saving a few extra minutes can be critical, especially over the span of weeks and months.

While I tend to agree with the authorities on private offices, I am not so sure they are always the right solution. When I enter the full-time workforce, I will expect an office, but for now I am satisfied with my small, open room.

After working for months on several different projects, I have learned it is far too easy to get burnt out. On any given day, I spend between 4 and 8 hours coding, and I don’t have a full-time job. I love coding. It is my hobby, my passion, and will be my career for as long as possible, but there are still days when I have had enough. It saddens me that there is ever a day when I simply do not feel like coding. Instead of coding, I am able to do productive things, but they are never as fun; one can be subscribed to only so many feeds.

Inspiration to the rescue. I listened to a talk today from Geoffrey Dagley, a developer at Relevance, Inc. He develops in Rails, uses git and github as source control, follows Agile methodologies with Mingle, does behavior driven development, has a continuous integration server (RunCodeRun), and contributes to open source projects. All of the coolest possible things you can do in the Rails world.

I, unfortunately, only have the time to do a few of these right now, but thanks to Geoff’s talk, I am more inspired to keep working. Listening to someone talk about how much he enjoys doing all of the same things you are doing, is an easy way to fight off the burnout. Heck, another speaker of two like Geoff, and I might just go to RailsConf after all.

In my quest to get users to stop deleting posts, I have spent a significant amount of time researching different rich text editors. I was hoping to find a visual editor that allowed users to write their posts exactly as they would see them once submitted. There are lots of editors out there: TinyMCE, WysiHat, FCKeditor, the YUI editor, etc. Each of these editors has its strong and weak points, but none stood so far above the rest that it was an obvious choice. I had a very limited and strict set of requirements that I wanted the editor to do: insert images and links, allow for basic heading and paragraph formatting, and the ability to drop into HTML mode so the savvy users could add whatever they wanted, like lists and tables. None of these editors gave me exactly what I wanted out of the box, so they would all have required some configuration.

I finally decided on tinyMCE. It didn’t take long to figure out where I needed to change things to get exactly what I wanted. My final configuration gave the user everything I needed plus a few extra basic formatting options.

I continued using tinyMCE for a while and posting trends didn’t change. Users now had a way to be reasonably sure they knew what their posts would look like, and yet they were still making and deleting unsatisfactory posts.

The problem clearly doesn’t have to do with knowing what your posts will look like, so I revisited the issue and tried to find what my the users were posting. I found over 90% of all posts were devoid of any formatting/HTML. They were just a few words of text and that was it. Having a custom tinyMCE editor didn’t make life any easier because the posts were so plain. Out of the remaining posts that did have formatting/HTML, the most common HTML to find was making clickable links. My latest solution is to remove the tinyMCE toolbar altogether and not use any kind of markup language besides HTML. Most users don’t know HTML at all, but it doesn’t matter. They weren’t using it when it was easy, so I took it out.

Now that tinyMCE is gone, I needed to make it easy for users to add clickable links to their posts. I thought about providing some help text next to the textarea that would teach a user how to correctly use <a> tags, but that’s a little bit of a pain for users who don’t want to learn any HTML. Even when tinyMCE was in use and users could easily add clickable links, they were still just pasting urls into their posts, hoping others would copy and paste the url into their address bars. While the extra copy and paste is not much of a pain point, if I could make those plain urls into clickable links, I would have the optimal solution. So a simple regular expressions to detect urls and now I can parse posts and automatically link urls.

The final solution ends up being very simple and provides all the functionality required by users. There is no unused toolbar, the most common posts are dead simple to make, urls are automatically linked, and one more side benefit, a reduction in total page size of about 50%. Success!

I recently asked a question and was pleased to receive an answer that was simple, concise, and worked perfectly.

I was asking about the best design pattern for handling several tiny, but separate scripts to run on page load. Most of these scripts were just providing focus for a specific input element. I didn’t want to write a new javascript file for each tiny chuck of onLoad code, but I also didn’t want to embed javascript directly into the HTML where it is obtrusive and easy to lose track of. An astute Stackoverflower presented me with an option that I consider to be about as perfect as it gets. Please excuse my Prototype, I am slowly working my way into the jQuery world.

Element.observe(window, 'load', function() {
    $$('.focusOnLoad').each(function(item) {
        item.focus();
    });

$$('.disableOnClick').each(function(item) {
    item.observe('click', function() {
        item.disable();
    });
});

});

Now most, if not all of my onLoad code that used to be scattered about my project, is nestled neatly into a single function, located in my project’s main javascript file. Doing this has also increased the usability of my app as before this solution, the amount of time it took to go through the painful task of writing duplicated code everywhere was great enough that not every page with an input had it auto-focusing. Now that I only have to add a single class name in each of those files, it is much easier to go through the project and make each page that much more usable.

Usability of programming languages is not something you think about all the time. I am not talking about the learning curve or whether or not it uses pointers usability, but the usability of a language for a variety of purposes. One such purpose is web programming, and specifically writing code embedded in HTML. Out of all the languages that are used to do it, I have not come across any better than Ruby. Compare these examples:

PHP

<?php foreach($array as $val) { ?>
    <li><?php echo $val ?></li>
<?php } ?>

C#

<% foreach(var val in array)
   { %>
       <li><%= val %></li>
<% } %>

Ruby

<% array.each do |val| %>
  <li><%= val %></li>
<% end %>

The PHP code is similar to ruby, but the curly braces always tend to get lost when they are surrounded by so much else. They are so skinny compared to other code, and they are usually not given any sort of syntax highlighting to help identify them.

The C# code is close to PHP, but Visual studio will adjust your code to fit C# coding style standards. Dropping the open curly brace to new line looks code in the C# editor, but not so much in the HTML editor. I have never been a fan of line-wrap in any code, and with the indent-happiness of HTML, line-wrap can quickly lead to code that doesn’t follow the visual hierarchy and becomes much less readable.

Finally, the Ruby code. While it does require fewer keystrokes to type the equivalent code in this case, Ruby has other benefits. Instead of curly braces, Ruby uses the keywords do and end. When writing this code in an editor, the keywords have syntax highlighting making them all the more easy to distinguish from the surrounding HTML.

Small differences in the design of a programming language can make big differences in its usability. The ease of embedding Ruby in HTML is just one of the many reasons why this language rocks.

One of the most used features of an IDE or a text editor, whether you realize you are using it or not, is the line numbers. When compiling, how do you know where to find the mistake you made when the compiler didn’t succeed? When debugging, how do you find exactly where an exception was thrown?

Line numbers are a valuable, time-saving feature of an IDE, yet, they are so rarely turned on by default. Remember the last time you installed Visual Studio, or any other text editor/IDE for that matter, and when coding your first project, you wanted to see which line you were on? Without cheating, what is the process for turning on line numbers? If the process isn’t, “Nothing. Line numbers are already turned on,” your editor is doing it wrong.

Why must developers, designers, anyone, go through so much work to see something that should be there by default? Some IDEs, like Netbeans, make it a little easier to turn on line numbers; the option is in the highest level of the View menu. But why does Visual Studio tuck this option away? It doesn’t just tuck it away, it makes you come back for each langauge you are writing in. Finally figured out how to turn on line numbers in C#? Now go figure out how to do it again when you open a XAML file.

Perhaps the only developers who don’t appreciate line numbers are the developers of IDEs. Or perhaps they haven’t learned to eat their own dog food.