JavaScript

Best known for it use in client side web application, it was touted as a language that was supposed to be easier to learn than Java for non programmers. It has seen many ups and downs over the last 13 years since it was released, but it has never shown more promise than today. With almost every website becoming “Web 2.0ified”, the language is finally showing it’s strengths. Developers who think that JavaScript is simply a presentation layer language are going to miss out the ability to create really great applications.

Python

This language has been around for 17 years and has a tremendous following and deploy base. Though, for some reason, it always seems to be a language that takes a back seat to other more ‘enterprisey’ languages. It is one of two official languages used at Google and it does power a lot of their most profitable products. It’s also going thru a major point release that I am convinced is going to bring it to the front of dynamic language queue. 3.0 is guaranteed to break backwards computability but it’s doing so in order to dramatically clean up the language. It’s getting more DRY and obvious.

Erlang

After developing and becoming proficient with Object Oriented Languages for the last 10 years, I can’t express strongly enough how much joy it can be to develop with a functional language. Your mind is forced to think in different more creative ways. In Erlang, there is no looping construct (for, do-while, etc), but there is tail-recursion. There are no Objects, so how do you maintain state? There are no variables, only single assigned values. No such things as threads, but it’s a language that allows you to create highly concurrent and scalable systems.

Mandarin Cantonese, Hindi, Russian - Pick one

They are not programming languages, but they are important for two reasons:

1. With the economic slow down, countries with emerging technology sectors and talented, well educated developers will be getting a second look as a means of cutting applicationd development costs. Don’t think major outsourcing, think one-off employment opportunities and telecommuting. You’re next pair-programmer just might be an ocean away discussing data structures over iChat.
2. This is by far the most important reason to learn a second language - You’re doing something that is different that developing application. For the love of all things Holy, get off your ass and do something else!

It still amazes me to this day that managers refuse to see that developers, or more specifically coders, have requirements that go above and beyond their typical ‘office’ coworkers. Here’s a short list of items that piss me off on a daily basis  

Speaker phones for everyone

For the love of God, why do people in a cubical farm need to use speaker phones? Get rid of them, and the inconsiderate employees that think it doesn’t disturb anyone. That goes for the managers that have windowed offices but refuse to shut their doors. Speaker phones should be restricted to meeting rooms.

Sitting near walk ways

I need to focus on code. My code is on my monitor. My monitor is at eye level. If anyone walks within my near 180 degree field of view, I get distracted.

Monitor Policies

At my current place of employment, everyone has two options, you can have a single 22″ LCD or two 17″ LCDs. For developers, both options are unproductive. 17″ monitors just don’t have adequate resolution, and the single 22″ has me alt-tabbing between applications if I am on Windows or switching spaces on my Mac. Two widescreen LCDs might seem like a luxury to someone in Accounting, but it actually makes my job more efecient.

IT Homogenization

It’s not good enough to have me sitting in “the IT” department, I need to sit with other coders. It’s not that I don’t like to be around other people in the department, but we just tend to have different philosophies on how to work effeciently. Architecture and Planning work best when they have adhoc meetings at their cubicle, but I need silence. Human Resources like to talk about the weekend, but I need silence. IT support staff need to be one the phones all the time, but I need silence. There is an obvious pattern here.  

Over the last few months I seem to have spent considerable time discussing, or more accurately arguing which dynamic language should be the choice of Java shops. The argument is really about which is a better framework, Rails or Grails and their respective languages Ruby and Groovy. I’d like to point out a few logical fallacies that seem to creep into the conversation.

Groovy is more like Java, so Java developers will transition to the language more easily.

There are really two problems with this argument:

1. Do you really want a language with similar syntax to that of Java? Mandatory parentheses and curly braces are for compilers, not humans.
2. If your developers need the crutch of “similar syntax” to transition to the new language, how are they possibly going to handle closures or blocks or meta-programming? These are the features of dynamic languages that make them so powerful.  This shift in paradigm that will baffle many programmers, way more than syntax that doesn’t “look” like Java.

Groovy can make full use of Java very mature libraries.

Great, so can JRuby. Oh, and so can Jython for that matter. Next argument.

Grails uses best of breed technologies to provide similar Rails functionality.

And Rails does too. It just so happens that the best of breed technologies are developed specifically for the Rails stack. This does not mean you have to use them, but you can be sure that they are going to work nicely together. Grails uses Spring, SiteMesh and Hibernate. Great technologies to be sure, but developed mostly independent of each other. Grails has done a great job of bringing these technologies together and in true “Rails” fashion, shielded the developer by encouraging convention over configuration. I’m just saying that if I drive a Porsche, I’m not going to replace the transmission from a Lexus.

Groovy is an official JSR (Java Specification Request).

So what? The JSR process is a committee driven process that in natoriously slow and generally broad in its results and catering to the lowest common denominator.

Look, I’m not against Grails or Groovy. We’re using Grails on my current project and I don’t mind it. What I do mind are the inane arguments listed above that are continually thrown around. Please, sell the technologies on their merrits, not on uninformed opinion.

With this week’s release of the new iPod Touch with its apparent ability to support sound input, it seems rather clear to me that this is the SECOND step Apple is taking to create and provide VoIP based telco services to the world. The FIRST step, of course, was to release the iPhone.

Step one (the iPhone) was to simply provide a test bed for feeling out the appetite users had for using an iPod as a voice based communication device; effectively to see how well it would work. Of course, as we know, it has worked surprisingly well. It not only worked well, users were more than willing to pay through the nose directly to the telcos for the luxury of having the sweetest ’smart phone’ on the market. People will pay.

Now, while we all (or most of us) love Apple, it is still just a business that wants to generate large revenue. In order to get the iPhone successfully in the market, it needed to partner with the Telcos. Apple cut a deal with AT&T that saw Apple receive a monthly cut of each new contract it signed up. This was huge. When iPhone 3G was released, that contract was no longer in effect, but the telcos subsidised the phone because the opportunity to sign up subscribers was so big that it became cost effective. In both deals with the Telcos, Apple promised not to allow VoIP applications to provide service over their data plans. But, why would anyone use VoIP when they have a more stable cellular connection instead? This seemed like a win to the telcos…but of course, it was a win for Apple.

Shortly after Apple released the iPhone, they introduced the iPod Touch. A simple extension to their iPod line that would certainly not pose a threat to the telcos stranglehold on the iPhone…or would it? You see, when the telcos decided to subsidize the iPhone, bringing the price down by half that of the Touch the prognosticators claimed that it would ‘cannibalize’ the iPod line and Apple would have to drop their prices. Apple did drop the prices, but the iPhone is still cheaper. Why would anyone buy an iPod Touch when an iPhone is cheaper and it can make calls?

Why? Because Apple wants iTunes to provide VoIP services, and the Touch is its preferred means of placing voice calls. Right now, cellular subscribers pay about $100 per month for voice service and a data plan. Apple wants that reoccurring revenue stream and knows it can do it. It’s easy to imagine reloading your minutes through iTunes and getting billed by the second, with Touch-to-Touch(-to-Android?) calls which cost nothing.

OK, I know that some of you think I am crazy. Obviously you need a WiFi connection to place VoIP calls, so it’s not reasonable to expect people to buy into this idea. Well that is true for now. But if I think about my Touch useage habits, I am almost always near an open WiFi signal. I might be at home, at a friend’s house, or at work. It’s there. And if not, I am close to a phone. I know this is a limitation, and one I would be willing to live with for now. WiFi, in whatever form, will become more and more pervasive and openly available.

Steve Jobs started the home computing revolution in the early 80’s, dominated the MP3 player market and forever changed how we purchase and experience music (and soon movies) in the new millenium. The iPhone of course revolutionized smart phones. I don’t think it’s much of a stretch to think iTelco is already in the works.

1. Agile Toolkit Podcast
2. Apple Quick Tips
3. BBC History Magazine
4. Best of Youtube
5. Big Ideas
6. commandN
7. Cranky Geeks
8. BBC World Series Documentaries
9. FLOSS Weekly
10. The Gillmor Gang
11. Google Developer Podcast
12. Great Speeches in History
13. I, Cringely
14. IT Conversations
15. The Mac Observer’s Mac Geek Gab
16. MacBreak Weekly
17. The Naked Scientists
18. net@night
19. Pragmatic Podcasts
20. Rails Envy Podcast
21. RailsCasts
22. Real Time with Bill Maher
23. Ruby on Rails Podcast
24. Security Now!
25. The Skeptic’s Guide to the Universe
26. Systm
27. TEDTalks
28. This Week in Law
29. This Week in Tech
30. Windows Weekly
31. You Look Nice Today
32. 60 Minutes Podcast

Fluid is a site specific browser for OS X. It allows you to make desktop applications out of web pages. For example, GMail, GCal and GDocs are generally the first applications people tend to “Fluidize”. Indeed, I have created a single Fluid application for my company’s office applications.

But Fluid provides another benefit that I think gets less coverage than it deserves; security. By creating a site specific instance of your web application you minimize some of the common web attacks that are in the wild such as Cross Site Scripting (XSS) and Cross Zone Scripting.  By limiting your fluidized web application to a very narrow domain path you can prevent any nefarious web pages from opening within that application.

Links that point to pages (or scripts) from a different domain will open in your default browser, not in your Fluidized application. Beyond your “office applications” you might want to consider using Fluid for your banking applications.

One of the preloaded applications in Mac OS X is Stickies, a virtual scratch-pad where you can quickly dump thoughts on virtual post-it notes. I use this on a daily basis to help keep track of issues, thoughts, or concerns that I have while developing my application. It allows me to quickly jot down notes and address them at a more appropriate time (i.e. when I am not developing!).

Why not just use TextEdit, you say?

Stickies can be placed anywhere on your screen and arranged in ways that make sense to you. Better yet, they can be colour-coded to reinforce the importance of the items they list.

The above sticky layout and colour scheme is how I typically throw down my thoughts during the day.

• Red stickies indicate items with a high priority and should be address quickly
• Yellow stickies are items that need to be dealt with but can wait until a better time
• Gray stickies (I usually just have one big one) are my scratch pads. A convenient place to put configuration information, code snippets, or just general thoughts.
• Green stickies (I only use one) list any outstanding task that needs to be completed when I get back from whatever pulled me away from coding.  I look at my green sticky as soon as I sit down at my computer with the intent to code (first thing in the morning, after lunch or after a meeting).

Stickies are a great way to give context to your development thoughts and process throughout the day.

Not likely to win any awards, but a basic overview of the origins of Erlang. Judging by the size of the developer’s glasses (it’s harder to determine date by nerd-clothing alone), I’d say this movie was made in the late eighties.

Joel’s latest blog post on NOT disabling menu items is very bad advice. If I have an operational link in a  web page or a button in a rich client application that is clickable, the last thing I want is a popup indicating why this action isn’t going to work for me. For as long as I can remember a greyed out menu item/button/link means it isn’t going to work. Wrong or right, the metaphor has been established.

Ideally (and if possible) grey out the disabled widget indicating that it isn’t going to work in the way you expect but still make it respond to an action that indicates why it can’t be completed.

• Normal link/button/item == You can click on me and I will do the action you expect.
• Disabled link/button/item == You can click on me and I will show you why I am disabled.

Easy.

In her presentation “Memes and Temes” at Ted, Susan Blackmore proclaimed that technology is in effect itself a meme (coined term, teme) and that humans will soon have “all kinds of implants” to assist in a technological symbiotic relationship. When I first heard this I scoffed aloud. Seriously, how many times do I have to hear that we’re going to embed microchips in our bodies?

But after some careful thought I believe she is spot on. The implants ear buds are the mechanism for information conveyance is my iPod touch. I subscribe to over 30 podcasts and there is barely a waking hour where information is not being passively pumped into my ears. Through its WIFI connection, I have instant access to a world of knowledge. Granted, the interface is slow and cumbersome when compared to the ideal microchip-on-brain implant, but at least this way, I can disconnect whenever I choose…..or so I keep telling myself.