It took quite some time, but I have finally started to find value in twitter. It’s short messages, sent and delivered in near-realtime with less of the mechanical feel of RSS. It’s great…but it won’t last.

Twitter as a tool, WILL grow beyond Twitter the company. It’s quickly becoming a communication mechanism that won’t be controlled or owned by any one entity. The Twitter protocol, while not formalized, will eventually evolve in the way email did in the 60s, 70s, and 80s.

If Twitter has really been offered anywhere between $500M - $700M dollars, they are foolish not to sell.

DHH delivers a great talk about legacy software and why you should be happy when you see it.

http://itc.conversationsnetwork.org/shows/detail3987.html

Late last week Monster.com admitted that its database was “illegally accessed” and that its member’s names and passwords were likely stolen. Monster.com the smallest amount of advice it could, “Please change your password”. But they should have included the following in their press release:

Since our organization does not encrypt our members’ passwords, the individual(s) who perpetrated this illegal act now know both your E-mail address AND your password. Please take a few minutes and ask yourself, “Which other websites to which I belong, use both my email address and the same password?”.

Contrary to all the advice, most people still use the same password for multiple websites. Changing your Monster.com password might stop the criminals from getting to your resume, but how much other personal information is now ready for the taking?

PS: What screwed up company doesn’t encrypt their users’ passwords?!?! Amateurs.

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.