Occasional Comment

I found a great book this weekend. It’s Cocoa® Programming Developer’s Handbook, Second Edition, by David Chisnall, published by Addison-Wesley Professional. It provides a very complete coverage of this broad subject but, unlike many of the other books I’ve read on the topic, it assumes that the reader is already a competent programmer. The author tells how Cocoa started life as NeXTStep on the NeXT computer and follows its evolution through a collaboration with Sun Microcomputers which resulted in OpenStep until Apple bought NeXT and adopted OpenStep as the heart of it’s development of OS X.

The book is wide, deep and fast paced. Don’t be frustrated if you find yourself having to read some sections more than once.  It includes an historical overview, a survey of the languages that have interfaces to Cocoa and why you might want to consider using each of them, an overview of the Developer Tools that Apple supplies to write applications with Cocoa, and of course, in depth discussions of how to use all of the various frameworks that comprise Cocoa (e.g. Core Framework, Core Graphics, Core Data, Core Audio, etc.) It also discusses the philosophy of Document-Driven Applications that was pioneered by Apple on the Mac. It frames these discussions with plenty of code examples that help place them in a practical context.

One of the philosophical principals underlying Ruby on Rails is that software should be opinionated. I have been thinking about what that means a lot lately and have decided that being opinionated is a good trait in general. I have decided that I will be opinionated and share my opinions with anyone who will listen. In particular, I will share my opinions here.

I have concluded that software engineering is at best a misnomer and at worst a detriment to the development of quality software. Engineering is a philosophy of creating physical artifacts that has been developed empirically for the last two or three centuries. Software is not a physical artifact.

When I have a physical artifact and I give it to you I no longer have the artifact. When I have a piece of software and I give it to you, I still have it. Your having it doesn’t reduce the utility of my having it. When I design a physical artifact, I want to get all the details right before I build it because materials are expensive. When I design software, the easiest way to figure out the details is to create a prototype and then iteratively improve it until it is right.

The point being that building multiple versions doesn’t incur large material costs. These are only two of many reasons that software development is very different from the process we know as engineering. Calling Software Development Software Engineering raises inappropriate expectation in those that don’t understand Software Development.

I’ll rant on this topic more later but I’m going to call it a night right now.

After watching several of Allison Randal’s videos yesterday (see Dynamism Clarified ), I started investigating Parrot. I was so impressed that I downloaded the latest version (2.0.0) and built it on my MacBook. I haven’t had time to do much more than start reading the documentation but I like what I see so far. I will probably play with Cardinal, an implementation of Ruby 1.9 in Parrot. I may see what kind of bench marks I can come up with.

I realized that my first several languages were all dynamic languages, i.e. Microsoft Basic (long before Visual Basic) and Forth. I always preferred dynamic languages because, in spite of whatever project I was working on for my employer, I was always intrigued by the prospect of artificial intelligence. My first static language was Pascal, quickly followed by C. I was going to say that I learned Lisp around this time but it took me a long time to really learn Lisp. I was able to write Lisp expressions in pretty short order but the whole process of building expressions up into programs that leveraged the unique strengths of Lisp took quite a while.

When I look back over my career it seems that I was always avidly studying dynamic languages. In fact, one of the reasons I was so enamored with Java was that it was more dynamic than C. When I discovered Java (the first day that Sun released the first public beta as a matter of fact) I immediately recognized it as a tool for convincing the static programming masses of the value of dynamism. Or as I put it at the time, it was a step in the right direction toward Lisp.

My current favorite language is Ruby, primarily because I can interface to more main stream software more easily with Ruby than just about any other platform. It is also sufficiently mature that I don’t worry much about it changing too drastically. I also share a lot of “opinions” about code with Ruby.

Today I watched a video of a presentation given by Allison Randal entitled Exploring Dynamism. It helped me put everything I know about dynamic languages in perspective. Allison is chief architect of the Parrot virtual Machine and employed by O’Reilly Media.

She made a point in the video that while theoretically, languages are either static or dynamic, in practice they exist somewhere on a spectrum between static and dynamic as extremes. She also discussed at length the various dimensions of dynamism including dynamic typing, dynamic dispatch, dynamic compilation and dynamic loading to name a few.

I thought it was brilliant how she discussed the pros and cons of these features quite clearly without bogging the discussion down with examples from any particular languages. This allowed me to think about her points in the context of languages that I know. She demonstrated a deep familiarity with a wide range of dynamic languages throughout her presentation. I was also impressed by the fact that she used her expertise in natural language linguistics to inform her model of computer language linguistics

If you are a fan of Ruby, Lisp, Smalltalk, or even Java, I highly recommend you watch the video. It was certainly well worth my time.

This morning I was thinking about a project that I am doing in Ruby. I found myself thinking to myself  “I sure am looking forward to getting more intimately familiar with active-record.” Active-record is the Object-Relational-Mapping component of Ruby on Rails.

I love a package that makes you eager to learn more about it. Not to say that you have to be intimately familiar with active-record in order to use it. Rails is just so well thought out that studying the API is actually fun. And, Rdoc, the Ruby documentation package, makes writing extensive documentation of your code so easy that programmers usually do a pretty good job of documenting their code.

I have been using active-record in my Rails apps for several years now. The reason that I needed to delve deeper into active-record at this point is that I am getting data from an external source (I’m scraping it from a web page), parsing it using nokogiri, another fine Ruby package, and then caching it in a local database. Consequently, I am having to do some thinking about how to structure the data that I cache.

Let’s face it, I’m not really all that experienced at database architecture. I can hack a little SQL when I need to but I haven’t had to do a lot of data normalization since I studied databases in college. Rails makes it easy to play around with your schema until you get it just right. I don’t mean to gush or anything but Rails makes these things so easy that it feels like playing instead of work. In my case, I guess it is playing, at least to the extent that I am not being paid to do it. But that’s another story.

So, here’s my first post of 2010. A new decade dawns. What will it bring? I hope a renewed commitment to blogging. I guess that’s a bit optimistic given my track record to date and considering it’s January 12th and I’m only now writing my first post of the year.

I’ve been working on a Ruby project the past week or so. It is basically a script to scrape data from pre-formatted text on a web page, cache it to a local database, then use it to generate animated plots to visualize how it changes over time. It sounds kind of pedestrian but is actually quite fun and is giving me an opportunity to build my Ruby skills on a task that I more or less understand instead of trying to build them while inventing something entirely new.

If I would just write for ten minutes a day to start with I would be in the habit in no time. Sigh!

I’ve been reading a good book lately. It’s called RESTful Web Services and it’s by Leonard Richardson and Sam Ruby, O’Reilly Media, Inc, May 8, 2007, ISBN 0-596-52926-0. It got me past an old obstacle that I basically ignored when I initially encountered it, which is how to access the web through a proxy from Ruby. I updated my Rails homepage, a private affair intended to give me quick access to a number of links that I access frequently. While I was at it, I figured out how to display the RSS feed of this blog in the center column of the homepage.

So, how does this make me feel? Totally empowered and back on my game. I haven’t done any web development in so long that I was beginning to think I wouldn’t be able to catch up with all the new developments. I guess I knew better deep down but it was still exhilarating to finally update my homepage after literally years of not changing anything on it but the content.

I also started looking in to Amazon Web Services but that’s a topic for another post.

Powered by ScribeFire.

It all started innocently enough. I had $50 worth of Amazon gift certificates so I bought an Arduino Duemilanove from Hacktronics with part of the money. It came and I was thrilled to start blinking LEDs with it right out of the box. I wrote a little program that flashed “SOS” in Morse code. My wife said, “That’s kind of depressing.” So I changed it so that it sent “LOVE” in Morse code instead.

I don’t know why I am so surprised when things work the way they are supposed to. I think it probably goes back to all the times I built electronics kits and had to troubleshoot them for days to get them to work (if they ever worked at all). In any case, the bug had bit me. I started scouring the Internet for Arduino based projects.

One of the reasons that I was drawn to the Arduino in the first place was the concept of shields. Understand that this was not a new concept to me. The robots at work had been expanded through the addition of daughter cards that plugged into the motherboard. But the Arduino had dozens of shields that interfaced to all kinds of interesting hardware. And the best thing of all was that they were affordable on my next to non-existent budget.

I decided that I was going to build a robot from scratch. I had built a BOEbot and I still love to tinker with it but I had the urge to create a unique robot that was my design from the ground up. Oh, alright. I intended to assemble it from parts but I intended to build many of the boards as kits and assemble all the various pieces to make a unique final product. And what is really exciting is that it wasn’t just possible, it was down right easy.

I decided to build my robot around a chassis consisting of a Clementine tangerine crate that I had saved. I decided to use Google SketchUp to build a scale 3D drawing of the crate so that I could better visualize how I planned to transform it into a robotic vehicle. I managed to draw the crate itself fairly quickly but I’m still working on drawing the rest of the parts of the robot.

I drew up a prioritized list of parts that I thought I would need for the robot. At the top of the list was a Proto Shield. A Proto Shield is a board that has many uses but is often used as a place to mount a mini breadboard for experimenting with various hardware interfaces. The other major item on the list was a Motor Shield. The Motor Shield that I bought has connectors for 2 PWM servos and can control up to 4 bi-directional DC motors.

While I waited for my new hardware to come in, I decided to play with the hardware that I already had. I took one of the Infra-red receivers that came with my BOEbot and an old Sony CD player remote that I found laying around (the CD player had gone to hardware heaven years ago) and decided to see if I could get them to work together using the Arduino as the controller for the IR receiver. I got the circuit hooked up pretty quickly. Note: when building a circuit on a breadboard of one battery operated robot for control by another battery operated device, make sure you use a common ground. I eventually decided to just use the USB power from the Arduino.

Now I was ready for software. I Googled Arduino and IR and found RTFA‘s video on YouTube. I followed the link to his site and downloaded his code as a starting point. I hacked it to work with the particular remote that I was using and before my Proto Shield had even arrived I had created my first Arduino based hardware hack.

Then the hardware arrived. As I was soldering the power plug on the end of the wires coming out of the  9 volt battery holder with switch that I had bought, I decided that I was going to need a better soldering iron than the little pencil style iron that I had used for 30+ years.

The two criteria that I had were that it had to have a switch so that I didn’t have to bend over to plug it in and unplug it every time I used it and it had to have a shielded stand so that I could safely set it down while it was hot. The next day, I want to my friendly neighborhood Radio Shack and decided that the difference in price between the iron that met my minimal requirements and one that was variable digitally temperature controlled was small enough that I couldn’t justify not buying the fancy one.

It took me two evenings working about an hour an evening to assemble and test the Proto Shield. It took about 5 minutes to move the IR receiver circuit over to the Proto Shield and get it working.

Stay tuned. More mania is on the way.

I can’t remember exactly when I discovered Squeak but it was probably the late 90s. Even in it’s earliest releases, it was awesome. In case you haven’t heard of Squeak, it is a modern implementation of Smalltalk, based on Smalltalk 80. It was written by Dan Ingalls, Alan Kay, Ted Kaehler, and Scott Wallace at Apple in the 90s to explore Alan Kay’s idea of the Dynabook.

Smalltalk is the epitome of object oriented systems. It is, in fact, one of the most copied languages around. For example, the NextStep library was based to a large extent on the Smalltalk library. Objective C draws many of its OO concepts directly from Smalltalk. To someone like me, who has been doing OO programming for something like 20 years, Squeak is like coming home.

I’ll have to admit, Smalltalk is hard to get your mind around. I have been playing with Squeak off and on for years. Mostly, I’ve marveled at the rich applications that came bundled with the package. Each new distribution brought more nifty graphical applications that, more than just being examples of how to write applications in Squeak, were incredibly useful in their own right.

The thing that has changed recently for me is that I discovered the online book Squeak By Example. This has broken down all of the last mental barriers that were hindered me in developing Squeak applications on my own. It is an excellent tutorial for anyone with any knowledge of programming at all. I wonder if it isn’t a great book for people that have no knowledge of programming at all. But that’s a topic for another time.

Squeak has rekindled the utter joy of programming in me. I highly recommend that you download it and Squeak By Example, or SBE as it refers to itself, and have fun. Set aside a good chunk of time. You won’t want to put this one down.

I finally figured out how to configure PHP on my server. It was documented in my provider’s help desk pages. I guess I won’t move yet. I will probably wait until I can afford to buy a slice and keep this site. “Don’t fix something that’s not broken” I always say. I promise I’ll write a post that is about something more substantial than my web hosting configuration adventure real soon now. In the mean time, at least I’m posting more frequently.