What Ever Happened to Dojo?


I was listening to one of the JavaScript podcasts I listen to—Adventures in Angular, I think—where the conversation had turned to ES6, transpiling and the tools around that process. Apparently webpack is the new shiny. Rolling my eyes at still one more tool to try and come up to speed on, I went to the web site to check it out. As I read over the introduction page in the docs, I thought, "This reminds me a lot of Dojo's build process. This is hardly new. Whatever happened to Dojo anyway?"

Back in 2010, I was hired to be the primary developer for small on-line university start up. I hadn't really worked on a project of that scale before. One of the first questions I asked myself was, "How am I going to manage the jQuery code?" I started googling strategies for architecting and managing large numbers of third party and custom jQuery plugins. Generally, all I found was "Well...". There were a few suggestions, but they felt a bit forced and didn't really give me the warm fuzzies.

The more I searched for a solution that spoke to me, the more I found people saying, "If this is really a concern, you should consider using Dojo Toolkit." So I did consider it. Backbone had just barely been released. People didn't have opinions about it, so it wasn't something I wanted to take a risk on. There was no such thing as Angular (2014) or Ember (2013). In then end I went with Dojo and I really enjoyed working with it. One of the features I really liked was the ability to build modules and only load what I needed for any given page. However, as often happens with start ups the money ran dry and I was looking for a job again in 2012.

I haven't touched Dojo since. My next job was happy with jQuery. Nowadays, no one talks about it. Whenever someone talks about JavaScript frameworks, the canonical list is Backbone, Angular, and Ember. Not necessarily in that order. Maybe I'm reading the wrong web sites. Maybe I'm listening to the wrong podcasts. I don't know. Dojo never was on the tip of everyone's tongue. I don't think they have ever tried to be the new shiny. They first released in 2007, so that ship has kind of sailed anyway. They do talk a lot about wanting to be a rock solid platform that large undertakings can build on. So if stability and longevity are a primary concern for a project you are currently planning, Dojo might be worth a look.

ES6 & Black Magic


So I've been dipping my toes in ES6 and have come across this bit of code:

((diameter) => diameter * 3.14159265)(2)

Part of me thinks that's kinda cool. Part of me thinks, "What crazy black magic is this?!? Burn the witch!!"

I seem to remember a trend where the goal was to make programming languages more like human languange. So have we given up in favor of something more succinct? Let's be honest. Human language is a mess. How many prepositions does one need, really? I suppose it ends up depending on context. We also have code libraries that look like this:


Some of it undoubtedly has to do with advances in technology. How well do you think Angular would have run on a 486? Some of it has to relate to the level of sophistication of today's web developer. I don't have a degree in computer science. I took some CS classes in high school and college and that's about it. On the other hand, I have been tinkering with programming since I was a kid. (Anyone else remember the TRS-80?) ES6 is not your father's JavaScript. (Yes, I'm old enough to say crap like that. Refer to previous reference to TRS-80.) We've come a long way from DHTML and I think the changes coming in ES6 reflect that.

The Endless Debate: Mac vs Windows


Let me start out by saying I develop on Windows. No, I'm not a .NET developer. I started out in Java, did LAMP for a while and have been working on becoming more proficient on the frontend of late. I've been around long enough that there were no laptops when I started developing. No Ubuntu. No Mint. Unix was a server platform. Period. Mac was still Macintosh was rarely used outside of graphic design/desktop publishing and video editing. I seem to remember the odd person writing code on a Macintosh that didn't have something to do with Adobe or Avid, but they were extreme outliers. I don't remember anyone developing web sites on a Unix platform, but I'm sure they were out there. The only Unix guys I knew were either dev ops guys writing shell scripts or C++ developers writing desktop applications for Solaris or Irix.

Here we are 15+ years later. Laptops are ubiquitous. Macintosh is now Mac and is actually a fairly common web development platform. You see job postings all the time where one of the perks of employment is being provided with a Mac. Because obviously everyone wants to be working a Mac, right?

I work for a consultancy these days. My first day at my current gig, I was handed a Mac and told, "We use Macs here." Uhhh. OK. Six months later what is my opinion of the Mac as a development platform? Meh. There's no magic sauce that makes Mac some wonderous user experience. Indeed after a few weeks working on a Mac, I was griping about my frustrations to one of the die hard Mac guys I used to work with. His response: "You're not drinking enough koolaid." Six months later, I'm still not in love. In the end, it boils down to this: It's all about what you're used to and how invested your are in making a change. I'm used to Windows and I'm not invested at all in changing to a Mac. I'll limp along when I'm required to and will breathe a sigh of relief when I can go back to my comfort zone.

Don't get me wrong. Windows has it's problems. You'll never hear me say otherwise. The thing is, so does the Mac. So does Linux. There is no perfect operating system. A Macbook does look sexy. I'll give you that, but that doesn't justify the premium price tag for me. I was listening to an episode on The Web Ahead today about the impact of the Apple watch. What struck me was the conversation about technology as fashion. They talked about how Apple is marketing the watch, not as a smart device, but as a fashion accessory. Because that's what watches are. Jenn's guest, Josh Clark, also talked about how kids are just as fashion conscious today as they were in his day, but today's kids care less about the logo on their shirt than they do the logo on their phone. Maybe that's Apple's secret. They've figured out that today technology is fashion and it's all about having the "right" logo on your laptop/phone/watch.

In some circles you're not a true developer unless you're on a Mac, particularly if you live primarily on the front end. Lately the guys on the Shop Talk Show have been pushing back against this monoculture that is developing. It's nice someone with a larger voice in the community is. At my last job we were all over the map. There were three guys on Ubuntu, one using Mint, two on Macs, and the rest of us were on Windows. Honestly, I think that is how it should be. Developers should be allowed to work on whatever platform makes them most efficient. If your tooling is platform dependent, you're doing it wrong.

Migrating Generic IMAP to Gmail Hell


I have a friend who is an attorney who keeps tons of email. He's been having issues with reliablilty on the shared hosting account he is on so I suggested we move him to Google Apps. Then I discovered he has nearly 15,000 email messages stored. A bit of a shocker, but it's Google. They have made migrating to Google Apps a breeze, right?


It has been a complete nightmare. We tried just dragging and dropping folders using his Apple Mail client. It was moving one message every three to five minutes. At that rate it would have taken just about one month to migrate all 15,000 messages.

So we tried Google's tools. Big mistake. The migration tool available on the apps dashboard pretends like it's working, but it doesn't. After 2.5 days, it reported having moved all his email except it didn't. It moved two out of eight folders and only about 8,000 of the 15,000 messages. Nice job, Google.

I called Google support—one of the perks of being a paying apps customer. They suggested I use a Windows desktop tool that is supposed to be better, but I couldn't make it work. It refused to accept his secret key and would bail without doing anything. Once, apparently randomly, it actually got past the secret key check, but then couldn't create any of the necessary labels and quit. I read and re-read all the support docs I could find, but could not find anything that explained why the secret key was being rejected. I tried calling support back, only to have the support rep read back to me the support pages I had already read through.

Next I tried talking to these guys on the advice of the one of the IT guys at work. Apparently we're using them for a big domain migration we're undergoing right now. Supposedly they are the best 3rd-party migration service out there. There's just one catch. Their software is licensed on a per person basis and you have to buy a minimum of 10 licenses. I contacted them and asked if their free trial would work to get one person migrated. They responded that I could buy a license for one person. Except that you can't. The web site won't let you buy fewer than 10. I tried chatting with someone on their web site to see if I was missing something. He told me the minimum was 25. Do they not even know how their own site operates? I contacted them by email again saying I couldn't see how to order just one license. I explained that I was happy to pay for one person, but I didn't want to pay for 10 if I only needed one. Their response? Nothing. So, if you're small potatoes, don't waste your time.

I had some PHP code lying around from a time in the past when I needed to migrate email from one server to another. I didn't use it then, but decided that was my next best option. Problem: it was apparently some seat-of-the-pants coding. It was mostly broken and got some things flat out wrong. So after several hours and much trial and error, I finally got it working. Seemed to work like a charm. The folder I was testing with had about 1200 messages in it and moved to Gmail in just a few minutes. New problem: in the message list view, all the dates were being displayed based on the date the messages were moved, not the date of the last message in the conversation. Even though you can specify an "internal date" in the PHP funciton call—which some seemed to think should do the trick—it wasn't working. Even with the date parameter set and properly formatted, Gmail kept right on displaying the date of the copy, not the date of the last message. To be clear, the actual dates on the message were not affected. You could open the message and see the correct date, but that's just annoying.

This morning, I started Googling for a solution to the date problem...ironic isn't it? Apparently this has been an issue for years. This thread was started in 2009. TL;DR: use Thunderbird. So after weeks of fussing with Google's migration tools, several support calls to Google, and a failed attempt to engage with a third party, I fired up Thunderbird, pointed it at both accounts and in less than a day I have all 15,000 messages moved to Gmail. Apparently not all IMAP clients are created equal. For whatever reason Thunderbird plays nicely with Gmail.

What really bugs me about this whole thing was the long, painful process. It wasn't until I tried to write my own code, ran into an issue with my code and started looking for a solution to that specific problem that I finally found a workable solution. Why, when I spoke to the first support rep at Google about migrating this enormous quanity of email, didn't he just say, "Hey, our tools suck. Just use Thunderbird. You'll be much happier."

Hopefully, some day in the future, someone else will be trying to migrate to Gmail and will find this post sooner rather than later in his or her process.

Blast From the Past


LiveScript, Silicon Graphics, IRIX, Solaris, NCSA Mosaic, IE3… It was kinda fun listening to Brendan Eich talk about the evolution of JavaScript. Lots of names I hadn't heard in a long time. I found it quite interesting to hear all the political machinations that surrounded the creation and development of JavaScript. It's worth a listen: for historical edification if you're a young developer, or for a bit of nostalgia if you've been around for a while.

JSJ The Origin of JavaScript with Brendan Eich