Posted by Jeremy Voorhis
Tue, 03 Oct 2006 23:51:00 GMT
As a followup to my last post, here are some brief musings on other recent language experiences I have had that have challenged my comprehension of programming languages. If you have any experiences to share of your own, by all means do!
Common Lisp
Lisp is among the earliest families of high-level programming languages, and it has many incarnations, from the semantically pure Scheme to the pragmatic Common Lisp. Lisp looks daunting, at first, because of its mandatory use of parenthesis for expressing nesting - if you squint, it all looks the same.
One feature that sets Lisp apart from other languages is its ability to treat code as data. Since Lisp functions and Lisp data structures are represented the same way, Lisp's macro system allows you to manipulate Lisp programs at compile time as if they were simple data structures. This allows Lispers to write custom dialects to concisely express common abstractions.
While Lisp is often written about as being esoteric and difficult to grasp for non-Lispers, Practical Common Lisp takes you through a whirlwind tour of vital Lisp techniques and makes them easy to understand; the reader should have a good grasp of macros and where they fit into the development cycle by the end of the book, as well as packaging lisp code as modules and other techniques for programming-in-the-large. Find it at your bookstore or read it online.
Text: http://www.gigamonkeys.com/book/
Language: Common Lisp - try SBCL
Important Concepts
- Code as data
- Rapid prototyping
- Meta-programming
- List processing - destructuring, et. al.
C++ Template Meta-Programming
If you're like me, you may have learned the basics of C++ at your university and left it at that. What my college didn't tell me about was how the language was re-invented within the last decade by important works such as Andrei Alexandrescu's Modern C++ Design and the Boost community.
The latest C++ techniques have led to highly flexible generic implementation of design patterns and interesting libraries for functional programming and parser generation. I was particularly surprised when I discovered relatively sane implementations for multiple dispatch over value types (think archetypal multi implementations of factorial and fibonacci functions). I implore you to go ahead and explore - you might be surprised at what you find.
Resources
Language: C++ - if you're reading my blog, it's highly likely that g++ is already installed on your system.
Important Concepts
- Generic programming
- Template meta-programming
2 comments
Posted by Jeremy Voorhis
Wed, 27 Sep 2006 17:55:00 GMT
As a professional programmer I am devoted to my ongoing education, and sometimes this leads me to learn new languages. My criteria for learning languages does not hinge on their practicality for my everyday use – in fact, it is likely that I will only use one of the following languages for profit – but new languages can arm me with new problem solving skills and deepen my understanding of programming in general.
Each of the experiences I am setting forth here are accessible. That does not mean they are easy, but language implementations and tutorials I will reference are all freely available online.
Ruby – The (Poignant) Guide
I won’t repeat here how I learned Ruby, but I will give some credit to Why’s (Poignant) Guide to Ruby. The guide is presented in a surreal comic book world with talking foxes and man-eating goats, but highlights many crucial aspects of Ruby including blocks and meta-programming. If you are learning Ruby, have a playful attitude and want to learn Ruby quickly, spend a few hours with the Guide – and don’t say I didn’t warn you!
Text: Why’s (Poignant) Guide to Ruby
Language: Ruby
Important Concepts:
- Fundamentals of Ruby
- Blocks
- Meta-programming
Erlang
I was vaguely aware of Erlang as a functional language for some time, but my curiosity was aroused after a discussion with Jason Watkins about object-orientation in Erlang. Erlang’s distinguishing feature is its process model (Erlang processes, not operating system processes). Once established, Erlang processes can then communicate with each other via message passing, and closely resemble the Actors Model. Each process can maintain some state through recursion and communicate with outside processes by passing them messages, making them very similar to objects in common OO languages.
The Erlang tutorial is well-written, although it helps to have some prior knowledge of functional programming. If you are interested in challenging your understanding of object-oriented programming, take a look at Erlang.
Note: Ian Bicking wrote a good article about Erlang processes.
Text: Getting Started With Erlang
Language: Erlang
Important Concepts:
- Concurrency, actors model
- Object-orientation
- Functional programming
Prolog
I’ve known about Prolog for a long time and understood some of its principles, but trying it out was completely different. After googling one day, I found a good tutorial that introduced me to the language. I learned about constraint programming, programming with goals rather than statements and expressions, and running the program “backwards” to find the parameter-space for a given solution. The tutorial also challenged my knowledge of destructuring and recursion.
The example programs in the tutorial are good, and include such problems as coloring regions on a planar map and identifying animals by their attributes. It also explains how Prolog does what it does and includes more advanced topics, such as prototyping and processing a grammar that resembles the English-language.
Note: for an interesting constraint programming example in Ruby see Jim Weirich’s solution to Ruby Quiz #70.
Text: prolog :- tutorial
Language: Prolog – SWI-Prolog worked well for me.
Important Concepts:
- Logic programming
- Constraint programing
- Destructuring and recursion
Posted in Languages | 5 comments
Posted by Jeremy Voorhis
Thu, 21 Sep 2006 23:33:00 GMT
Feature ecology is a collection of concepts I am developing in an attempt to frame my work as a technology producer. The term feature ecology pays homage to media ecology from which I draw some inspiration. While feature ecology intersects with media ecology, it focuses on product utility and aesthetics.
In my last post, I introduced the term feature ecology. The discussion that took place in the comments, however, digressed from the meaning I intended to share. In an effort to clarify the already-overloaded terms I have chosen, here are some operating definitions.
- Feature
-
A unit of behavior and perceptual attributes. For practical reasons, a feature may be defined recursively, as a set of other features1.
- Product
-
An environment consisting of features which a user may interact with.
Features provide an arena for human behavior. Features also have an agenda – their capabilities inform the user of what is important, and through ommision, what is not important2. A product will contain features that reflect the values of its producers, and – hopefully – the values of its users as well. Interactions also take place between features, as I have mentioned in my last post. Depending on the product, the addition of a feature may change the way users interact with features. A new feature may also make prior features more or less valuable to their users.
In response to the original post, Brian Ford wrote,
I’m cool with the zen-ish “products are features” but “features collected are not products” if I’m just being contemplative. But I’m wondering how does this help me think about software?
How can feature ecology assist us in creating better products? It reminds us to be aware of the behaviors we wish to evoke in our users. It also requires an awareness of the interactions between features within a given context; when adding a feature, we must consider to what extent we are redefining the product, and how consistent its messages are with neighboring features.
1 This definition is purposely vague on some levels. I work in the domain of web applications, but I think similarly about desktop software, my iPod, the newspaper, and anything else I call “technology”.
2 Marshall McLuhan stated this more succinctly when he said, “The medium is the message”.
3 comments
Posted by Jeremy Voorhis
Tue, 19 Sep 2006 20:35:00 GMT
Throughout my years as a software developer, I have come to recognize that it is silly to think a product can be improved by adding features. A product is its features. More specifically, it is the union of its features within a given context. When a feature is added to a product, the nature of that product has changed. Can you imagine a product with no features? I doubt it. Can you describe a product without mentioning any of its features? Can you compare two products while ignoring their features? Try it.
Features are not additive; they alter the environment of all other features. I recall when 37signals added Writeboards to Basecamp. When posting to Basecamp, I decided whether I was posting a living document which would be best handled by Writeboard, or a temporal message, which was best handled by the messages feature of Basecamp. Messages also excelled at fostering discussion, but Writeboards did not; they were more wiki-like, and over time the identity of the original author matters less and less. Later, 37s integrated Campfire with Basecamp. Since then, Basecamp users who want to initiate a discussion can use the cooler messages option or the warmer Campfire group chat.
After these two features were added to Basecamp, its messages weren’t used in quite the same way. If you are reading this blog, it is very likely you are participating in creating a product of some sort. Do you have compartmentalized ideas of a product and its feature list? Do you implement features in isolation, or can you find the interactions between features within your product’s environment?
13 comments
Posted by Jeremy Voorhis
Sat, 16 Sep 2006 23:04:00 GMT
To clear up some confusion, I unfortunately had to withdraw from the speakers list for the European Railsconf. While life on my own has been great, traveling to Europe and not working for a week is more than I am able to pay for the privilege of speaking.
For those of you who are in the great Pacific Northwest and would like to hear me speak, I am offering a workshop titled Understanding Web Architecture Through Ruby on Rails on 9-10 November for an affordable price. If you want to sharpen your application design skills and bridge the gap between the principles of web architecture and running code, this workshop is for you.
2 comments
Posted by Jeremy Voorhis
Sun, 10 Sep 2006 00:06:00 GMT
By now, I’m sure you have read that Sun is serious about JRuby. I have no practical reason to use JRuby myself, but I decided to kick the tires anyway. Here is a screenshot of a session where I am playing with JRuby’s high-level Java integration.
3 comments
Posted by Jeremy Voorhis
Fri, 08 Sep 2006 21:25:00 GMT
A common complaint against Ruby is its lack of tooling support for developers. Amidst the influx of new and potential Ruby and Rails developers, there is a demand for something more. For those of you still putting your development environment together I’ll describe the tools that I am currently using that have proven themselves indispensable.
Automation
Learn Rake. Learn everything there is to know about it. Learn to make your own task libraries. You’ll be ready for anything. This article by Martin Fowler was useful to me.
Likewise, learn Capistrano for deployment. You should implement your deployment recipe before any of the core functionality of your application. Doing so gives you the advantage of writing code that is easy to deploy.
Testing
Take Rcov – Ruby’s coverage tool – for a spin. A good coverage tool provides you with detailed information about the kind of exercise your code is getting. You should strive for 100% test coverage, but also keep in mind that Rcov has no opinion about the quality of your tests.
There is a Rails plugin for Rcov, but I begin by dropping the following into
lib/tasks/testing.rake:
begin
require 'rcov/rcovtask'
Rcov::RcovTask.new do |t|
t.libs << 'test'
t.test_files = FileList['test/{unit,integration,functional}/*_test.rb']
t.verbose = true
end
rescue LoadError
puts 'Rcov is not available. Proceeding without...'
end
You run the task with
rake rcov. This works for most scenarios and I can fine-tune the task as I go.
Learn to use mocks and stubs. I use Mocha for a mocking library. When used properly, mocks and stubs eliminate external dependencies from your tests – including the database. Eliminating external dependencies makes your test suite more robust to change, easier to understand and as a side-effect, it will run much faster. Here is an example of how to use Mocha to stub a web service client.
def test_get_avatar_from_flickr
flickr_user = Flickr::User.new()
flickr_user.stubs(:id).returns("30798076@N00")
flickr.any_instance.stubs(:users).with("jeremy@jvoorhis.com").returns(flickr_user)
assert_equal "http://www.flickr.com/buddyicons/30798076@N00.jpg", @user.avatar
end
Editor/IDE
When I first began programming Ruby for profit, I was a devoted emacs user. Its keyboard shortcuts came natural to me – maybe something to do with my classical training on the piano. The basic emacs commands also work almost everywhere on OS X. Safari has a kill ring; while you can copy and paste normally, you can also use -k to kill highlighted text and -y to yank it back. The killed text doesn’t go to the clipboard either. Try it!
After using OS X for a while, I gave TextMate a try. It renders fonts beautifully and had many of the commands I commonly used in emacs, such as recordable macros. It is also very easy to automate – I even had a TextMate bundle for automating my book.
Since resigning from Planet Argon, I’ve had to turn in my shiny company PowerBook and have fallen back to involuntary ubuntu. I’ve tried going back to emacs, but couldn’t adjust to the jaggy fonts. I also tried compiling emacs with the Xft library for font anti-aliasing, but succumbed to the mysterious segfault. After deciding that it wasn’t worth spending any more time setting up a work environment on my home workstation, I decided to tackle the problem from the other direction and give Eclipse a chance.
For the past month, I have been using Eclipse with the Ruby Development Tools , RadRails and Subclipse plugins. It’s proven itself to be a reasonable platform.
Pros
- The test runner gives me a visual representation of all passing and failing tests that is far easier to scan than console output.
- Double clicking on the stack trace of a failed test moves my editor to the offending line of code, when applicable.
- Subclipse’s diff browser is among the best.
- The built-in RI browser is nothing to write home about, but is far easier to get in and out of than the html docs for Ruby’s core and standard libraries.
- Subclipse displays the current revision of each file in the filesystem tree view.
- I hate to admit it, but the outline view is just plain useful in large files.
Cons
- Eclipse doesn’t have recordable keyboard macros.
- My Subclipse installation chokes while committing to
svn+ssh:// repositories.
There are other Ruby IDEs available as well, such as FreeRIDE and Komodo. It is also interesting that sun has hired the JRuby team and given them a mandate to think about developer tools. The refactoring support of Java IDEs may some day extend to Ruby. Of course, you, the savvy reader, will find something that works best for you.
5 comments
Posted by Jeremy Voorhis
Wed, 30 Aug 2006 16:08:00 GMT
To begin, I will share an email conversation that Joe O’Brien and I traded this morning:
Joe,
You made a wise purchase ;) About Face 2.0 isn't bad; it's full of some
great advice. My biggest gripes with it are the follows:
* It declares that programmers are just unfit for interaction design.
* It advocates for waterfall development.
* Cooper has a defensive tone whenever discussing his beloved discipline
of interaction design.
* The web chapter is dated.
If you can get over all of those things, it is full of great ideas,
specifically about working with personas, and data entry and retrieval.
You might also like Rapid Contextual Design - it is a book that builds
on some of Cooper's ideas and presents them in an agile-friendly way.
What I like about Design of Everyday Things is that it creates a
framework for thinking about usability problems, rather than handing out
specific advice. I think this allows for much more creativity, and gives
you more depth when supporting your design decisions.
Cheers
On Wed, 2006-08-30 at 09:35 -0400, Joe OBrien wrote:
> The Design of Everyday Things just arrived last night. You're right,
> it's been great so far. I'm really stoked about it.
>
>
> I also went ahead and purchased About Face, I know it's not all
> great, but I'm still looking forward to it.
>
>
> Thanks again,
> -Joe
>
>
>
> =======================
> are you living on the edge?
> theedgecase.com
This got me thinking: as developers, we invest a great deal of time and money in technical books. I value good recommendations that I receive, and I also enjoy passing them on. I also enjoy a good discussion about the content with other readers.
In order to foster this type of dialog, I have created a new Google group: The Agile Book Club. The group is public, and we would really like to have your input!
9 comments
