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.