Book Review: Introducing HTML5 by Bruce Lawson and Remy Sharp

The buzz in the development world these days has changed. Cloud Computing? That’s so 2010. Multi-core CPU’s? Ho-hum. Tablet computing? Whatever.

But when Microsoft announced that the next version of Windows would allow for development in HTML5 and JavaScript, the world took notice, and a lot of us are scrambling to get up to speed. Okay, so some developers have been playing with HTML5 for a while now, and JavaScript has been around for years. I’ve worked in HTML4 for quite a while, and JavaScript has never really floated my boat. I’m a traditionalist. Code compiles. Scripts are what I use to run back in college before I had a real IDE.

I say that with only a little bit of sarcasm. I’ve never liked Web UI coding. Working with the infinite number of browsers and their individual peculiarities frustrated the crap out of me. The web was for signing people up for things, watching videos and browsing news and sports. You would never write a real application in this environment. Would you? What masochistic developer would want to build a core business system in something you could never truly test, and would behave differently on every computer? What sadistic system designer would expect users who have jobs to do to wait for a page to refresh every time they wanted to know if their data was valid?

When I heard about Microsoft’s intentions, my initial reaction was to think it was a joke. After hearing it a few times, and learning it really was true, my heart skipped a beat. I was worried that I was about to be left behind again technically, and in a few years, I’d be one of those back-end developers that couldn’t change with the time. I’d be branded as a ‘.NET Developer’, something akin to the 2011 version of a COBOL programmer. It didn’t take long for that fear to turn to anger. I’d just invested the last five years working my way deep into the Microsoft .NET Stack, building my skills and my reputation, and… and it just wasn’t fair! This whole process was very similar to the seven stages of grief. I went through the depression of realizing that I was again going to have to rebrand myself and rebuild my skills, and then the realization that doing it the last time really hadn’t been that bad. I started to look at the opportunities this would present – things that I had never before been able to do, that I could now do. I started to research what HTML5 really was, and what it was that made the world so sure this was the way to go.

After doing some piecemeal research on the web, I realized I needed a book. I’m a book learning. Reading a book primes my brain. Books are generally better organized than the snippets you might find on line. I wanted to start with the basics, and form a solid base with which I could talk intelligently with my coworkers and my bosses. I wanted a book that would explain it from the beginning.

Introducing HTML5 (First Edition) by Bruce Lawson and Remy Sharp was the book I chose to get me there, and I highly recommend it. It starts by covering the Structural Elements of HTML5, how pages are organized, the new elements and the expanded role of JavaScript in HTML5 applications. It then dives into some of the more advanced features of HTML, including Audio and Video, Canvas, Data Storage, Offline mode, Drag and Drop, Geo-Location and Messaging. I skimmed the Audio and Video and the Canvas sections since I am usually designing business apps, and haven’t had the need to build an app that draws lines since I was in college. I did, however, build a Silverlight Video player on Windows Azure for Microsoft Demo Showcase back in 2009/2010, so I expect that sooner or later, I’ll be doing something similar to that in HTML5. It’s good to know it’s there.

I was fascinated by the offline storage possibilities and the future of messaging and sockets. I can see a day coming very soon where I build an HTML5 app with messaging tied to the service bus on Windows Azure that handles Windows Workflow Processes and notifies users that some long running, multiple streamed process has completed. There’s power there. A lot of it.

I do find it a little bit funny that this is the second technical book in a row I’ve read where the authors are constantly taking shots at Microsoft and Internet Explorer. I guess I’ve been buried so deep in the mother-ship for so long, that I don’t have the same level of animosity. Of course, I have worked my career around not having to do a lot of browser work. Perhaps that has insulated me far more than I thought.

This book is short and to the point, and a great introduction to HTML5. You won’t come out a world class expert on HTML5, but you will understand the basic concepts, enough to be able to talk about it, and to begin the honest discussion of whether or not that next project you are starting should target HTML5. I’m at least willing to consider it at this point, as long as we don’t implement any features that can’t be made backwards compatible by implementing modernizr.js which is covered by Scott Guthrie here.

The biggest advantage I see to HTML5 is that in the ideal world going forward, we can build an app once, and as long as it is HTML5 compliant, it should just work on all browsers. I really like that. I want to do the work once, and move on the next project. HTML5 brings the Web UI development out of the dark ages, and makes it a real possibility for someone like me. This is a good book to get up and running inside of a week, and I’ve already recommended it to my team.

Book Review: jQuery in Action

A few years ago, when I first got into ASP.NET development, I worked on a project that used the Ajax Controls Toolkit. I was not a JavaScript person, and my experience with the Toolkit and all its idiosyncrasies left a very bitter taste in my mouth for ‘client-side’ web development. For many of the projects after that, I worked on the back end of the system – the database, data model and business logic, and eventually the controllers and web services. We had a UI guy who tackled the JavaScript stuff and worked ‘magic’ there.

A couple of months ago, I got involved in a project which had a very large existing code base, with a lot of jQuery and my UI guy was nowhere to be found. Before I knew it, I was neck deep in it, and drowning fast. I muddled through the project and got it out the door, but I realized that I could no longer have this gap in my education. I also realized, by working on that existing code base, that jQuery was nothing like the JavaScript and Toolkit I once struggled with, and it was really freaking powerful.

It turns out that back in early 2010, I had ordered jQuery In Action by Bear Bibeault and Yehuda Katz during some book buying binge, but never read it. It got loaned out to a couple of people at work, and I didn’t see it for the longest time. It wasn’t until I finished working on that big jQuery project that I even remembered that I still had it. I tracked it down, and it flew to the top of my reading list.

I wish I had read this book a three years ago. jQuery is really powerful. And it’s really big.  jQuery in Action did a great job of introducing me to the core concepts, and giving me a refresher on basic JavaScript. Ok, not a refresher – an introduction. The unfortunate part is that I ordered this book in early 2010, which meant the version I have is the first edition published in 2008. The second edition came out in May 2010. The first edition covered up to jQuery 1.2. The second edition covers jQuery 1.4.  As I recall, there are some fairly major differences in jQuery between 1.2 and 1.4, but more importantly, there have been major changes in browsers. Internet Explorer was just on Version 7 when the book was written, and a lot of time had to be spent by developers to account for the way IE6 worked, and to a slightly lesser extent, IE7. With IE9 now out and promising “It just works”, I would like to think that jQuery will have gotten even easier in the last few years. The first edition of jQuery in Action has quite a few asides that detail the frustrations developers had with IE6 & 7, and I get the impression that the authors would have little good to say about Internet Explorer in conversation.

The book is well organized and the coverage of the core concepts appropriate for a beginning jQuery developer as long as you have a solid background in web development. It even has a very good appendix on JavaScript, which was invaluable to someone like me with a large gap in their knowledge of the subject. They build a large number of exercises into the book as well. Since I was reading the book whilst commuting, I didn’t get a chance to try them, but I think I understood them well enough from the written copy. At the very least, I know they are out there and I can download them when I get a chance to give them a try.

What I find amazing about this book (and jQuery), is how many times I thought back to projects I already have in production, and said “Wow, the UI could be so much better”, or “If I had only known about jQuery, the whole architecture would have changed.” The former makes me happy that I can now say “Yes, we can do that.” more often to clients. The latter makes me question my skills as a software architect. I had never even considered some of the approaches presented in the book, and not only would the UI have been more user friendly, it would have been faster and more reliable. I’m disappointed in myself for not taking the time to learn about jQuery before now. I can rationalize all I want about being busy with other things (like learning Windows Azure, MVC, WPF, writing 4 books, etc.) but the truth is that I considered the UI side to be the ‘poofy’ stuff and let other people handle it. The UI, I thought, was just for displaying the results of all the ‘hard work’ done on the back end.

No longer. Reading jQuery in Action has opened my eyes to the fact that I have to know all the layers, at least well enough to know what is possible. I have no doubt that there will be aspects (especially in CSS) that require an artist’s touch (which no amount of reading is going to give me), but I will now treat jQuery as a first class language in solving client problems. I still have qualms about jQuery, mainly from the testability standpoint, but I do like the idea of unobtrusive JavaScript which will allow me to keep a separation of concerns and allow me to build up a personal collection of functions that I trust just work.

I will, at some point, go out and get the second edition of this book to see what has changed in the last few years, and to reinforce my basic knowledge of JavaScript and jQuery. With HTML 5 and JavaScript coming at developers like an out of control freight train, jQuery in Action is a great way to get started and to get up to speed.

Using etc/Hosts to Assist in Testing

A coworker and I were in the process of migrating a client’s web server from old hardware to new hardware last week, and we needed to be able to test the system before turning it on to live traffic. The web applications called web services, and the configuration of the web app included the URL for the web services.

We needed to be careful what we were doing here, because the web services were also migrating to a new server, and on this new server, were pointing to a new database server as well. We didn’t want to change all the configuration settings on the new servers, and we couldn’t change the public DNS entry.

I’ve done this before, but not everyone knows about the following trick, so here it is:

On Windows, if you go into your %WinDir%\System32\drivers\etc directory, you’ll find a file called hosts, often referred to as “etc\hosts” or “Etsy Hosts”. Open this file with notepad running as administrator on your machine. The instructions for changing this file are right in there, and it’s pretty easy. We added a new line to file on the new server, (and on the test client) like:

127.0.0.1       www.palador.com

We saved our changes, and then restarted IIS on the box. And presto…

But it didn’t work.

We reset IIS again, and did an ipconfig /flushdns from the command prompt.

And it still pointed to the old domain.

We went back to the Hosts file and everything looked fine. I scratched my head. Then I realized that we had forgotten to put a carriage return after the new line. We added the hard-return, restarted IIS and flushed DNS, and now everything worked.

I’m pretty sure I had run into this exact same issue a few years ago, and that’s why I knew to look for it. Hopefully this will help someone else avoid this issue.

Book Review: The Nomadic Developer by Aaron Erickson

I don’t actually remember how I found this book. It somehow got onto my Amazon wish list one day, and it was one of those things I bought because I needed to top up an order above $25 to qualify for free shipping. I don’t remember what it was that I bought with this book, but I doubt it was as impressive as The Nomadic Developer.

It’s funny, because I tell people that I got into the consulting world back in 2008. After reading this book, I realized that I actually started in consulting back in 1994. My very first job in IT was technically at a consulting firm, albeit a very large one, (the one started by Ross Perot back in the sixties and famous for making everyone wear blue suits everywhere they went). I worked on a couple of very large accounts, so it seemed like I was just a developer in Corporate IT, but in reality, I was a consultant. I left that company in 1999, and moved on to real Corporate IT, working for an airline maintaining their revenue management systems, and later on to building and maintaining the fight operations systems. We owned those systems from cradle to grave, twenty four hours a day, seven days a week. They were horribly difficult to change. There was a tremendous amount of tribal knowledge in every subsystem, and many were already five or six years old when I started, and rewrites were impossible. By the end of my 8.5 years there, my technological skills were atrophied to the point where another year or two, and I would have been completely unmarketable outside of that industry vertical.

I jumped (back) into consulting in 2008 with little idea of what true consulting was. I wish I had had this book at my disposal back then. Not that I would change my decision – the leap into consulting has done wonders for my skills and my career. I have no doubt that making the move, when I did, was absolutely the right decision for both me and my family, and I’d like to think it was the right decision for the company I work for as well.

But in The Nomadic Developer, Aaron Erickson goes into wonderful detail of what to really expect from technology consulting, how to identify good (and bad) companies, how to survive, and how to thrive in the consulting world. He talks about how to maintain both your position and your passion during both good and bad times in the economy, and how to avoid career limiting moves. At the very least, had I read this book while still working for the airline, I could have avoided a couple of interviews that would have led to positions that I was not right for. My trouble-radar kicked in on those before I accepted, and I count myself lucky. By the time I had finished chapter two of The Nomadic Developer, I had already identified those firms as being one of the ‘Seven Deadly Firms’, and hiring on there likely would have tainted my consulting experience for the rest of my career.

The Nomadic Developer is not only for people who are thinking of becoming consultants. It’s also for consultants who are fairly new to the game, and will help you to stay out of trouble as the economy changes. I think it should also be read by owners/senior management of consulting firms, if only to avoid uncomfortable moments brought on during interviews by people who have read the book and are asking some of the hard questions Erickson suggests. Most of those questions I would be a little uncomfortable asking during a interview, but I see the value in at least trying to ask them. It’s not always the response that is important, it’s the way the response is said that will tell you if the employer is going to treat you as a partner / investment or a warm body / cost.

Here are some of the questions he suggests:

• What is your annual revenue?
• What is your (target) profit margin?
• What is your exit strategy?
• What’s the value of the sales pipeline?
• What is the sales process?

I’ve done a lot of interviews of candidates in the last few years, and even though I have been on the technical side, I’ve never been asked questions like that. I’m actually pretty horrible at technical interviews because I hate trivia questions. I prefer to ask about experiences and expectations and to evaluate the personality of the interviewee. If someone was to ask questions like that, and I hadn’t read Erickson’s book, I would perceive them as intelligent but aggressive. But after reading his book, I would think that the candidate truly is trying to find the right fit. If I’m a consulting company senior management, I’m reading this book to make sure I’ve got my crap together so I don’t lose out on good consultants because I look like an amateur. I’m also doing an honest assessment of my company to see if I am making any of the mistakes Erikson lists in the Deadly Firms chapter. Unless my goal is to build an unsuccessful company, I want to be active in fixing these situations, even if it is just an employee perception. I don’t think too many people want to be unsuccessful at running their own company.

Another point Erickson makes is about passion for work, and how to maintain that during hard times, especially when the client you are working for is not in an industry you find appealing. I spent three years working for a client that did direct marketing… sending out junk mail and running those annoying call centers that call you during dinner. I slept on my office floor multiple nights while doing system upgrades, and let me tell you, that was really hard to justify to myself after a while. That experience left me quite cynical when it comes to working on projects I don’t fully believe have societal value. In the long run, that cynicism can be a career killer in consulting. It can kill your passion for software development, and once you’ve lost that, it can be very difficult to get it back. Employers, and especially co-workers, notice when your passion withers. In tough markets, not every job will be life-fulfilling, but Erickson suggests that taking pride in the work you do on each project will preserve the passion, and from there, passion will generate positive results and better  opportunities in the future. It takes a while to build up the resume, and there is something to learn on just about every project.

I’m giving this book a big, big thumbs up, and making sure that my wife, who is a project management consultant, also reads  this book. Very little of the book is specific to programming, and those bits can be read and parallels drawn with most other industries and job types.

Do yourself a favor, and read this book, and then get your coworkers, and your boss to read it too. If the suggestion is negatively received, you may already be working at one of the ‘Seven Deadly Firms’, and its time to find your exit strategy.

Where did I go?

Judging by the activity on this blog (or lack thereof), you'd think I was either dead or retired. I am not dead.

I am still actively developing software, and am constantly hanging out on the bleeding edge.  To that end, I do occasionally post blog entries on the web site of the company I work for (www.Palador.com).  But most of the stuff I work on I cannot discuss in public, or is so well covered by other blogs that I don't see the need to cover.  In the best case I’d just be repeating what someone else has said, or in the worst case, I’d be plagiarizing it.

So if you have a question or a comment, feel free to leave it.  But I only swing by this blog once in a blue moon, so if you are in a hurry, you might want to try another search.

If you really need to get ahold of me, you can try my writing blog at www.joebeernink.com.  It’s not technical in the least, but it is monitored much more frequently.

Thanks for stopping by.