See the latest five blog entries below, or jump to a specific month:
- October 2011
- July 2011
- June 2011
- May 2011
- April 2011
- December 2010
- November 2010
- January 2010
- August 2009
- July 2009
- June 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
I sometimes forget one of the main reasons I like programming, and that's that programming is fun. People can talk all they want about problem solving and helping others to accomplish tasks, but for me it's all about realizing that I can do it, and that's always been a fun thing. Granted, there's some code to write because some user (somewhere) needs a new feature, or there's a bug to be tracked down and squished, but the main reason I like programming is that it's, well, fun.
Of course, what with everything else, I had forgotten this. Life is busy and I'd generally gotten to the point where any programming I did was to do with something that others were asking me to do: give a technical presentation, write an article, consult with a start-up, deliver a course, or start another book. I was programming, and it was OK, but I was doing it to get to some end-point, not necessarily to have fun. I wasn't programming for the sake of programming; I was programming because I had to.
And then something wonderful happened.
I came across Erlang. Or to be more precise, I was pointed at Erlang by one of my past-students who wrote an intriguing article about an Erlang CMS called Zotonic for Linux Journal magazine. The author of the article, Michael Connors, then sent me an email together with a "you've gotta take a look at this!" plea. Based on this, I thought Erlang interesting enough to explore it more and I've been learning Erlang for a number of months now.
In fact, I've been programming in Erlang just for the heck of it!
I'd forgotten what this was like: writing code, realizing that I can do it, and then getting it to work can be so much fun! Nobody is asking me to write Erlang code. I'm also not writing the next-best killer Erlang application. And, I've not got some darn-hard problem that needs solving in Erlang. I'm simply programming in Erlang in my spare time and it's fun. What a lovely feeling.
Of course - me being me - I couldn't resist the opportunity to tell others about my latest language "find". So, when O'Reilly Media asked me if I wanted to do another webcast, I jumped at the chance. Feel free to check out my own personal take on Erlang. Enjoy, and have fun!
[Ed note: Are any of you HF readers programming in Erlang? Even if not, do you agree with Paul--if so, what is fun about programming for you?]
Well, iOS5 is out, and that means that Head First iPhone and iPad Development officially needs some tweaking to work with the latest tools!
First, a quick overview of the new features in iOS 5. For the OS itself, the biggest change is the addition of iCloud to the storage solutions for apps. Primarily Apple apps are leveraging this ability to support synching at this point, with Photo Stream, iMessage, and iTunes purchasing support, among others, but as time moves on that will expand. Newsstand support has the potential to change the publishing industry by providing a centralized place on the device and method of updating subscription type materials. You can find the Apple summary of these and other features here.
There are lots of other bells and whistles, the new Siri app is a personal assistant app that can parse meaning from verbal messages and find out information for you, but it only really works on the new iPhone 4S. Twitter integration is system wide now, and the new Reminders app is also really cool. It has geo-fencing for tasks, so you can set up a task that says "remember to take my shoes home from work" and when you leave that place, iOS will send you the reminder.
What does iOS5 mean for Xcode? Xcode has two major changes. First, there is now storyboarding support. That means that instead of creating each .xib file and manually linking them together and coding the transitions, you can create a big .storyboard file that contains all of the .xibs for your app and you can graphically edit the transitions between views.
The second big change is that Apple has added ARC (Automatic Reference Counting) to Xcode. A lot of the memory management work that we teach in the book has been automated. While it is stil important to understand what is going on, all the retain/releases that we have so painstakingly put in our code are now handled automatically.
What if you want to use the book with the new Xcode? Just a couple of things that you should know about. First, all the downloaded code here on headfirstlabs.com will still work, no problem. Second, when you create new projects, there are some new checkboxes to be aware of. When the project starts, there are boxes to "Use Storyboard" and "Use Automatic Reference Counting." In order to use our book as it is, you'll need to UNCHECK these two boxes. That's it. If you keep those two things in mind, all the examples in the book will still work without a problem.
One of the things that keeps technology exciting is constant change! Fortunately, these changes are relatively minor as long as you set up the project properly and you'll have happy coding. In the meantime, we're busily working on updating the book, which will be out early next year.
I'm often asked how I came to write for the Head First Series, specifically on their Python-related titles.
I'd been working with Perl for years and had written or co-written two Perl-related texts, and towards the mid-to-end of the 2000s had started working with Ruby quite a bit, no more so than as a result of all the (justified) hype surrounding Ruby on Rails. As a consequence, I'd read (and own) a lot of Ruby-related books.
Now, imagine my surprise when, one fine day, there I was sitting, re-reading some of the material in my well-worn copy of The Ruby Programming Language when - I kid you not - a big bolt of lightning shot out of the sky and buried itself in my beloved book. Take a look at the photographic evidence if you don't believe me.
I took this as a sign that my days of programming Ruby were numbered and that somebody, somewhere was trying to tell me something...
OK, I'll admit that some of that story is not totally true. Actually, the bit about the lightning isn't.
What actually happened was that it was my turn to cook dinner and, as Cooking for Geeks had yet to be written, I didn't yet understand how important it is to actually pay attention while cooking. You see, in one hand I had a pot which I popped on the stove-top to heat up. In the other hand, I had the Ruby book. When the pot got hot (or so I thought), I set the book down on the stove-top while I attended to the pot's contents.
It was then that I noticed a rather strange burning smell... then smoke... then (very nearly) fire. The Ruby book was smoking! Not paying attention, I'd switched on the wrong heat-ring on the stove-top and placed my book directly on top!
Needless to say, dinner was delayed that evening. But, I took this as a sign that my days of programming Ruby were numbered and that somebody, somewhere was trying to tell me something... and, anyway, the contract to co-write (with David Griffiths) Head First Programming (which uses Python) had just arrived.
Head First iPhone and iPad Development is shipping as we speak, which is very exciting! Updating Head First iPhone was a daunting task this time around, there have been lots of developments with iOS development since we printed the first time. Timing the release of the book around those updates was tricky, especially with the well-known Apple secrecy around new releases.
Going through and working on the update it was amazing to see all the changes that have taken place since the last version. The biggest changes are the introduction of the iPad, and iOS going from being the operating system for the iPhone to the OS for both. The result for developers is that the Objective-C hasn't changed, but what you're using it for is significantly different based on the device. We added two new iPad apps to the book and the last chapter has lots of good information about designing UI for the iPad instead of the iPhone.
The key difference in design for these two platforms is the time of interaction. iPhone users are almost always waiting for something. An appointment to start, somebody to meet them, the light to change. Interaction is quick and focused. iPad users are settling in for an extended interaction with the device. Sitting on the couch to shop, or read a book. The additional screen space is nice too, but just making an iPhone app bigger isn't going to cut it.
The second edition of the book uses Xcode 4, which is a vast improvement over Xcode 3. GUI layout with Interface Builder has been integrated into the main IDE, which is huge. You can graphically link outlets and actions with Xcode, code completion and documentation are vastly improved. It has an assistant editor that allows you to look at related code side by side as well. Debugging is in the main window as well. Xcode now really feels like a competitor to Eclipse or other more mature development environments. It does make development much easier.
Another big change to the iOS world is the maturity of the App store and the industry. When we published in 2009, the App store was just over a year old, and the Android Marketplace was just getting up and running, and App development was fairly immature. Since then, things have grown to the point that enterprises are getting into App development, because they need to be present on these app stores the way that they need a website. The first year the App Store made $50 - $100 million (from Business Insider). In 2010, Apps were a $5.2 billion business (from Gartner).
A quirk of this whole thing is that most enterprises, even if they have in-house developers, are PC shops. Since you can't develop for iOS on a PC, it means a fantastic opportunity for freelancers and developers who know iOS.
The book still features a cranky bartender, a bounty hunter, and a guy with relationship problems, but we fix their issues with iPhones and iPads this time. We really hope everyone enjoys the book and finishes with a good foundation to build their own apps!
I recently set my final year software engineering undergrads a task to take a simple Google App Engine webapp and add a login/registration system to it. I made a point of advising my students to RTFM (read the *full* manual), highlighting to them that there is lots of great functionality provided with App Engine "for free" and that its all just sitting there, waiting to be exploited by savvy developers.
When my students submitted their work, half of them had done half of what I'd asked. These students created the datastore descriptions required to store user-ids and passwords, created some UI forms to solicit login/registration information from the users of their webapp, and then tied it all together with lots and lots of code to make sure the logic worked as required, providing a fully functioning authentication system for their webapp. These students were quite pleased with themselves as they'd obviously done quite a bit of work here. After all, look at all the code they'd written!
The other half of the class did everything I asked, including taking my RTFM advice to heart, and - suitably enlightened - simply added the following line to their webapp's configuration file:
This directive - described in the App Engine online docs - switches on Google's own login/registration system for a webapp and provides a fully-working authentication system using the same technology that lets you into GMail, Google Docs and all those other Google cloud services. Take a moment to think about what's happening here: all that functionality from a simple configuration directive and not one line of new code in sight!
Of course you may not agree, but I'd suggest that the Google engineers have this problem pretty much solved by now and that any attempt to write a custom App Engine login/registration system is, at best, ill-advised and, at worst, unproductive. Although there's a case to be made that there's lots to learn from "rolling your own", there's also the point to be made that the savvy developer knows what to concentrate on, that is: build only the functionality that's specific to a webapp... then "beg, steal and borrow" the rest. Knowing when to and when not to write code is skill worth mastering.
Now, as readers of this blog know, I'm a big fan of the "Less Code Is Better" principle, but I'll take no code over less code any day. And I'm always amazed when a developer (not just a student) insists on writing everything from scratch. What explains this blind rush to write code? Is it inexperience? Arrogance? Madness? All of the above?
What do you think? I'd love to hear other developer's views on this.
Looking for source files, code, exercise answers, and other materials to go along with your Head First book? Go to this page, find your book on the list, and click on the title.
Head First C# is a complete learning experience for object-oriented programming, C#, and the Visual Studio IDE. By the time you're through, you'll be a proficient C# programmer, designing and coding large-scale applications.