I do not understand Microsoft and Nokia’s approach to marketing. While I don’t know the average consumer’s attention span for cool new devices is, but I would measure it in days, not weeks, and certainly not months. Why then do these companies insist on talking about the Lumia 920 and the Windows Slate months before they are available? All it does is get people excited for a few days to a few weeks at most, and there is still a couple months before it’s actually available for anyone to purchase. It also gives the competition plenty of time to announce their own cool new devices, and if they happen to be available sooner, you’ve lost a customer.

Apple has it figured out. If you were quick, you could buy a retina Macbook Pro the same day it was announced. You can buy the iPhone 5 less than two weeks after it was announced.  There was no way anyone could have offered a competing device to the Retina MBP since it was available the same day. Samsung has been able to put together a commercial targeting the iPhone 5 before general availability, but I don’t know how many people it would convert. The point is, when you go from a two week delay after announcement to a three month delay, there are even more opportunities for other products to disrupt your launch.

Today I do not own a Lumia 900 or an Asus Transformer Prime. Both are products I was extremely excited about and I would have bought them both the same week I heard about them, except neither one was available for months. I still want a Lumia 920 and a Windows Slate, but there are going to be plenty of opportunities for me to find another product, that I can actually buy, before these two become available.

I can’t help but wonder how much money these companies are throwing away by wasting excitement and goodwill towards their products.

As part of working with Node.js I have been using what seems to be the standard template engine Jade, and for the most part it works as expected, however I’m starting to develop a philosophical objection to this sort of technology. One of the promised benefits of using Node.JS is reducing the number of technologies being used on your stack. That means you have to be proficient in fewer technologies in order to built really great stuff. I see CoffeeScript and Jade as completely removing that benefit.

If you use them, you now have to be intimately familiar with their syntax and idiosyncrasies in addition to the underlying script / markup that they get transformed into. It’s not like you’re replacing Javascript with CoffeeScript. If you have to debug anything, you now have to understand both the Javascript and the CoffeeScript in order to try to figure out where things are going wrong. The same with Jade. If you see a problem in the html, it’s not a simple matter of changing the html. You have to mentally convert from html to Jade syntax in order to fix the problem. I see these frameworks as adding a lot of additional complexity when debugging problems for the very short term gain of typing fewer characters.

No one would use C# if you have to be an expert at CIL to debug it! The tools are good enough that you can happily write and debug C# for years without even knowing that there is a CIL and until Jade and CoffeeScript get to that point, they will be more trouble than they are worth.

So I survived my first presentation at SoCal Code Camp. I was definitely nervous starting a couple hours before my talk started. My hands started sweating, and I was regretting the big lunch at Which Wich. I settled down a little once I was actually at the podium, but started to freak out again when I realized I was half way through my before I was 15 minutes into the talk! Thankfully there were people with questions, and I was able to extend things a bit.

I did end up finishing my planned material about 15 minutes early, but I had another demo that I had been working on which I showed as well. This was a socket.io chat / mouse sharing demo which I cobbled together when I was first learning about socket.io myself. People seemed to  really like being able to go from  my contrived examples, to something semi-functional which members of the audience were able to actually interact with real-time. In the future, I will definitely add some more interactive examples and probable spend more time going over what you can do with node and socket.io instead of the whys.

Big thanks to everyone who encouraged me to talk! If anyone is even remotely interested in talking on a subject at a code camp or other event, I would highly recommend that they take the plunge and just go for it! The support and feedback you get from participants is amazing.

The Code

The code for the socket.io demos is available on GitHub now. I’ll move the relevant bits of the chat / mouse interaction app over soon.

https://github.com/tstrimple/codecampdemo

The Slides

No hikes this weekend, it’s all node.js all the time. Getting my presentation ready for code camp next weekend. As part of that process, I decided to check out Cloud9 again. I last looked at their online IDE around six month ago, and wasn’t too impressed with it. It felt awkward and left a lot to be desired. I can see myself using their latest version, if for no other reason than being able to write code on something like an Asus Transformer Prime. I cannot, however, justify spending $15 / month for an IDE just to have private repositories without a hosting solution and / or much better IDE features that are not available elsewhere.

 Cloud9: The good parts

There are some very nice parts of the Cloud9 environment. One of my favorite part is not having to keep switching between different applications to edit / run / view my application. Perhaps I was just spoiled with Visual Studio, but the integrated part of a good IDE can really improve your efficiency by reducing context switching.

Another very nice feature is GitHub integration. I just started getting into working on GitHub, but Cloud9 pulled a list of my github projects and gave me the option to clone them into Cloud9 for editing. Pushing the changes back to GitHub is as simple as running the commit and push commands in the integrated console.

Integrated Console

What needs work

Based on my still limited experience with node.js, it seems the preferred way of storing sensitive information that you don’t want in your public repo is to use environment variables. From what I could find, Cloud9 still doesn’t support them. So what are my options? Store my mongo / cloud connection string in a plain text file and not commit that back to GitHub? That would work on a local test, but anyone with a Cloud9 account can view your files as you edit them real-time. So as soon as you put in your test connection information, if someone else is looking for that, they will be able to find it. Maybe Public repositories are one thing, I can setup my git ignore file to prevent any sensitive files from being committed, but a public working copy of the project you’re testing is something else altogether. Maybe I’m just being paranoid…

This isn’t a criticism of Cloud9 alone, but no one has a great Javascript editor yet. The static analysis tools are lacking as well as the refactoring and code navigation tools. Surprisingly enough, Visual Studio with Resharper has the best Javascript editing capabilities of any editor I have used. Code completion which mostly works, go to definition which mostly works, and find references which mostly works. It’s still not great, but it’s a start. Cloud9 has some static analysis built in. They can tell me when a local variable is not being used, missing semi-colons, and they throw warnings on the legitimate use of some reserved words, but that is about it. Their refactor (rename) tool doesn’t seem to work at all.

Must be using jslint

In addition to that, you’re also limited to the version of node / npm that they happen to be using. This is true with most PaaS providers, so it’s another scnario where you have to weigh the pros and cons.

I really want to like their solution and I will likely continue to play with it to see how it evolves, but it’s definitely limited when compared to a traditional editor / console combination.