Thoughts on Systems

Emil Sit

Jan 14, 2011 - 3 minute read - Technology configuration git hudson tools

Store Hudson configuration in Git

For any kind of server, it’s a good idea to keep its configuration in some sort of version control system. Hudson is a pluggable continuous integration system. Recently, I was trying to set one up and was wondering the best way to store Hudson’s configuration in version control (StackOverflow summary). The most complete answer is a post on the Hudson blog about how to keep Hudson’s configuration in Subversion; there are also plugins like a nascent SCM Sync configuration plugin. But, the former is very Subversion specific and the latter does not seem particularly mature. So, to understand how to do it in your workflow, there are two things to consider.

First, which files are relevant? Hudson puts configuration, run-time state, source code and build output all in the same sub-directory (called HUDSON_HOME). Second, relatedly, since normally you edit Hudson’s configuration through the GUI, when should you commit changes? Should it be automated (e.g., nightly at midnight) or manual (e.g., ssh into the server and manually commit)? I’ll answer those questions with an implementation in Git but you can translate the information easily to your preferred VCS.

Identify relevant files by using the following .gitignore file:

This ignores the uninteresting files and will allow git status to show you interesting new files. Note that I prefer to actually commit the binaries of plugins since I don’t want to rely on outside sources (namely, the mirror network) having the particular version of the plugin that I was using for the given configuration files. To use this if you are installing a new Hudson server, you can just

cd $HUDSON_HOME/.. # Default is /var/lib
rm -r hudson
git clone git:// hudson
# Don't forget to chown hudson hudson as appropriate for your environment

before starting Hudson for the first time. Then once it has started, run git commit to track the default config that Hudson creates.

The second question is when. The Hudson blog’s recommendation is to create a Hudson job that runs nightly at midnight to check for differences and automatically commit them. I prefer manually committing the changes on the server and then pushing it. This allows me to identify specific functional changes (using git add -p) and commit them individually. If you want to do it automatically, simply write a script or add a job that will

git commit -a -m "Automated commit of Hudson configuration"
git push

once you set up an appropriate origin.

Once you have this set up, you can even use something like Chef to automatically pull down updated configuration that you manage and test elsewhere and restart the Hudson server when necessary. Then you can re-create your Hudson server in case of failure at any time!

Nov 16, 2010 - 2 minute read - Technology agile gbcacm gil broza programming selfimprovement tdd

Programming without fear

This past weekend, I attended Gil Broza’s seminar on Programming Without Fear, organized by the Greater Boston Chapter of the ACM’s Journeyman Programmer initiative. The seminar was as advertised, and covered:

For anyone with more than a passing interest in agile, the material Gil presented (covered in the links above) will not be new.

The benefits of the seminar came from two things. First, Gil presented the information in a somewhat “formal” framework: a taxonomy of code smells, a set of refactoring patterns, a pair of mnemonics (PRICELESS unit tests and TRUST your refactoring process) to help remember basic techniques. This gives someone new to the material an organized set of knowledge to internalize. Second, Gil has prepared a series of exercises, interspersed with the lecture-y sections, that seminar participants work through in pairs, designed to reinforce the theoretical frameworks with practical experience. Even as someone moderately experienced with these concepts, the exercises are useful in that they focus on the fundamentals and force you to actively strengthen those fundamentals. (The weakest section, I thought, was the one on mocking which received insufficient exposition and dropped the class directly into jMock, which was a bit opaque.)

Gil is not the most exciting or funny teacher but he kept the attendees engaged by teaching with a Socratic flavor—he presented examples and solicited audience evaluations, allowing the audience to interact to reach conclusions. The practical exercises were followed by group de-briefs. This encouraged the audience to stay engaged and better absorb the material.

My main worry about the techniques is the overall reliance on Eclipse (or other IDE) as a developer’s assistant: while certainly the tooling is convenient, they make me worry about Java and whether the use of tools and wizards weaken developers who may never learn how to do things themselves.

What I really enjoyed was the experience of actually developing and refactoring with the protection of a unit test suite and learning techniques to perform refactoring without more than a moment or two of compiler errors. This was in sharp contrast to my normal refactoring experience of making a top-level change and then following all the compiler warnings until the work is done. Now if only every codebase I worked on came with such a set of tests…

Sep 3, 2010 - 2 minute read - Hacking Technology gina trapani howto thinkup

How to install ThinkUp on NearlyFreeSpeech

Gina Trapani and ExpertLabs have put ThinkUp, a cool tool for tracking replies to your posts on Twitter. As of September 2010, ThinkUp has a nifty drop-in web-based installer, much like WordPress. Simply grab ThinkUp 0.007 or later, unzip it somewhere that your PHP/MySQL-enabled web server can get at and it’ll prompt you through the installation.

In response to Gina’s post asking for help testing/hacking this long-weekend, I ran through this in about 10 minutes on NearlyFreeSpeech. Here are some quick tips where NFSN’s set-up is a bit different than what is expected by the default installer:

  • After you unzip the ThinkUp dist, run chgrp -R web _lib/view/compiled_view and chmod -R g+w _lib/view/compiled_view so that the templating engine can cache its views.
  • Make sure you have a MySQL process enabled in your NearlyFreeSpeech control panel. A basic MySQL process costs $0.02/day but you can share the process with your WordPress database. Spin up phpMyAdmin in the right-hand sidebar and create a user called thinkup and make sure to check off the option to create a database with the same name and grant all rights to that user. Generate a random password, and copy that password.
  • In the ThinkUp database configuration section, enter thinkup as the user name and database name and paste your generated password. Open the advanced section and change the database host from localhost to your database host name. It’ll be something like username.db; mine, for example, is sit.db.
  • ThinkUp will fail to write the configuration file due to perms but helpfully offers the ability to copy and paste a file. Select the text in the config text box and go back to the terminal where you unzipped the dist. In the thinkup directory, cat >, paste and then Ctrl-D to save the file.

Check your e-mail for the activation link and configure your account. You’ll need to register your installation as a Twitter application and paste in the consumer key and consumer secret. The config page will send you to the Twitter registration page and tell you the callback URL to provide. Leave ThinkUp as a read-only application and leave the ‘Use Twitter for login’ unchecked.

That should do it!

For more details, check out the ThinkUp wiki for more up-to-date instructions.

Jun 1, 2010 - 5 minute read - Technology dependency-injection j2ee java jee programming spring spring-framework springsource

Understanding SpringSource and the Spring Framework

In light of recent announcements like vmForce or the SpringSource/Google App Engine integration, you may be wondering, what the Spring Framework is, precisely. What does the SpringSource company provide?

According to their homepage, SpringSource is in the business of “eliminating enterprise Java complexity” and is a leader in Java application infrastructure and management. That’s not very concrete, and so I don’t feel it is particularly helpful, particularly if you are not an J2EE/JEE (Java Enterprise Edition) developer. In this post, I’ll talk about SpringSource in general and focus on the Spring Framework. Note that while I work for VMware (which owns SpringSource) and use the Spring Framework (commonly referred to as Spring) at work, I am not part of our SpringSource division nor do I have any particularly special access to the innards of SpringSource. I did get to take the Core Spring training for free, but it is only after 5 months of programming with Spring that I’ve started to understand the SpringSource philosophy.

SpringSource products let you write code that is as focused as possible on the needs of your application, and as little as possible on the boilerplate or hassle of dealing with different underlying environments (e.g., dev, test, production may have different database backends) or infrastructures (e.g., GAE, vCloud). This is the core value that underlies SpringSource, but it is only explored indirectly via its various instantiations in the SpringSource literature and product line.

The Spring Framework (aka Spring) provides glue. Spring provides glue in a relatively uniform manner, so that once you understand the basic approach(es), you can apply it to interfacing with different components. From the documentation, Spring seems to do everything, but at the same time, when you try to use it, you may feel that it seems to do almost nothing. It may be useful to compare the Spring Framework to the Debian Linux distribution: Debian provides a nice out-of-the-box experience with a uniform mechanism for managing software, and in particular, alternative software packages that can provide a common service. But to get at the power of the underlying packages, you must learn how to configure and use them. Likewise, Spring does not actually provide many services on its own. It does not free you from having to learn how to write a unit test, access a database, manage a messaging system, or implement security. Instead, it makes it possible for you to write code to do these things in a somewhat generic manner, so that your code can be as generic as possible.

Understanding these two key points will help you make sense of the variety of things written about Spring.

The core glue provided by Spring is its dependency injection support, also known as the “inversion of control” or IoC container. This means that, instead of class Foo explicitly instantiating an object implementing interface Bar, Foo will have a constructor argument or setter that accepts a Bar. The inversion of control container lets you specify the right kind of Bar for Foo in a given environment and handles constructing that Bar, and injecting it by calling the setter. This makes code less fragile because it no longer needs special-casing for testing (e.g., a stub Bar) or anything else. The mapping of a particular Bar to Foo becomes part of a configuration file that also captures all of Foo’s other dependencies.

Spring also provides more special-purpose glue; the Spring Framework page writes: > Spring provides the ultimate programming model for modern enterprise Java applications by insulating business objects from the complexities of platform services for application component management, Web services, transactions, security, remoting, messaging, data access, aspect-oriented programming and more.

For example, your application can use the Spring Framework with straight JDBC, or with generic object-relational mappers (ORMs) like JPA through to highly specific ones like iBatis or Hibernate. You can configure your application to then talk to a variety of database back-ends, with minimal changes in the actual configuration files, and write minimal code related to setting up database connections and processing error cases. Spring provides wrappers and translators to help unify service-specific method names, such as the one that causes an ORM system to generate database tables, and exceptions into more generic expressions of those concepts. This means you might be able to switch between JPA providers, for example, without changing too much configuration. However, you still have to configure your JPA provider correctly.

In line with allowing you flexibility from the infrastructure, Spring also provides flexibility of mechanism, so that the code and configuration that you write to integrate with Spring’s services are at a level that you are comfortable with. You can configure the IoC with XML or with Java; you can use annotations or you can use explicit configuration. To specify which of your business methods should be in a database transaction, you can annotate with @Transactional in your source code, or you can use an aspect-oriented programming filter to tag the relevant methods in an external configuration file.

All of this glue and the flexibility of mechanism contribute to making Spring hard to understand; however, their presence emphasizes the idea that Spring wants to get out of your way so that you can focus on application development. Other SpringSource tools such as Roo and Insight work similarly: they simplify development and debugging (respectively) without requiring that you make extensive changes to your source, and respecting current best-practices.

I’ve left out various components of Spring to focus on the core philosophy of SpringSource, but this background should help you make sense of resources like the Wikipedia article on Spring, the Spring Framework documentation, and books like Spring in Action. If you’re running into problems, however, the best place to get concrete questions about Spring answered is Stack Overflow.

May 2, 2010 - 4 minute read - Hacking Technology creativity go Photography programming style

Examining your personal programming style

When I was growing up, we would listen to classical music stations in the car and try to figure out the composer and sometimes even the performer. Both musicians and composers often have their own distinctive style: you can hear the mathematical precision of Gould, or the clarity of Horowitz, whether they are interpreting Bach or Mozart. My last post started me thinking about a musician or composer’s style and drawing a parallel in the context of computer programming.

When thinking about music, one’s style is a matter of personal expression, but if you say “coding style” to a programmer (or really, to Google), you’ll find rules about whitespace, variable naming, plus some proverbs about how to write maintainable code (e.g., “avoid global variables”). Overall, I don’t think these are particularly relevant to the art of programming.

For example, formatting and naming conventions are important in a codebase only that a properly followed convention becomes invisible—just like your nose becomes acclimated to a smell, your brain quickly learns to recognize a formatting convention and ignore it. Having a convention (any convention!) allows you to focus on what the source code is really doing. Following a convention is good for everyone reading your code, even you. Automate your coding conventions and forget about it. (In the extreme, check out what the Go Language formatter can do.)

Similarly, coding style proverbs, like “write tests before code” or “keep code in a function at one level of abstraction”, are like any other proverb: these statements capture an element of experience from programmers past, but are often blindly followed by people new to the practice. It takes significant time before a programmer can truly internalize the reasons for and nuance behind any proverb. (Incidentally, if you are interested in studying proverbs, I highly recommend you examine the game of Go.)

What I am interested in exploring is personal expression and style in programming, outside of language/library/tools, proverbs or code formatting. Having a personal style is not a concept that we as computer programmers are generally exposed to. School focuses almost exclusively on the technical, ignoring both the practice (i.e., the stuff of proverbs) and the art (the subject of this post). Indeed, I am only beginning to be able to express what my personal style might be.

So, how do you express yourself in code? To begin exploring our artistic programming style, let’s continue to draw an analogy from the arts—instead of music, let’s look at the process of establishing a personal photographic style. The author talks about the importance of the choices—the choice of equipment (camera), subject matter, the approach to making a picture. You come upon a way of doing things that you believe is right, that supports your personal values. When looking at myself:

  • Equipment: Linux/Vim/Mutt/Xmonad/Git.
  • Subject matter: I care strongly about the process with which you build programs, and so I wind up working a lot on tools and scripting, but I’m also interested in distributed systems problems.
  • Approach: I like (re)using what is present; I strive for consistency, simplicity, elegance. I am somewhat inclined towards using functional constructs in imperative languages (though I never did like OCaml’s syntax). I always look at a diff of my code to ensure it is minimal before committing it, and I like to write verbose log messages.
  • Examples: Some things I’ve worked on that you can look at include of course Chord, and some contributions to Gina Trapani’s todo.txt tool.

I’m not entirely happy with this “approach” because it feels like mostly a list of platitudes. But some of my difficulty, I think is in not having thought about this specifically as I look at other people’s code, not even having the words that I can use to compare and contrast my approach with that of others. So, I’d like this post be a start for each of us to explore our own style.

Spend a few minutes thinking about what you value in your own code, and how you define yourself as an artistic programmer and write about it in a comment, perhaps using the template I’ve set for myself above. I hope we’ll each learn something!

Apr 24, 2010 - 3 minute read - Technology art computer science education

Music education versus computer science education

My mother recently forwarded me this interview of the pianist Glenn Gould:

I encourage you to watch this (and all 6 parts), even if you know nothing about classical music.

What stood out to me in viewing this series of videos was the fluidity with which Gould is able to discuss a piece of music, in its historical context, and to simply jump in to play a phrase from a different piece to call out a point for discussion. This demonstrates an incredible mastery of the subject matter, unifying history and context, theory, and practical implementation.

From my experience at the Manhattan School of Music, musical training seeks precisely to bring this unification into its students. As you study, you learn to play a variety of pieces or styles, from different time period. You are taught some history, to be able to understand the evolution of styles; you are taught the underlying theory, to be able to discuss this evolution using precise terms; and then you practice the mechanics needed to actually play the pieces.

How does this compare to computer programming? Computer “science”, as you may know, has a fair amount of artistry to it.

We are simply not trained to have these kinds of discussions. How many people do you know who, during a code or design discussion, might say, “Oh, this is very similar to System X, in contrast to how System Y did things,” and then pull up the source code (or architecture diagram) for System X and Y and compare them with the relevant pieces under discussion?

At MIT, the classes are (were?) organized around ideas and then around technical implementation (leading, hopefully, to understanding). Little emphasis is placed on how to be a programmer, such as prototyping, testing, revision control, or code-review; that is, these things rarely factor significantly into your grade. Even less emphasis is given to the ability to discuss ideas in context, even at the graduate level. Undergraduate classes at most schools seem to focus on learning best practices for a particular programming language. As graduate students, only the extremely motivated would explore beyond the papers presented in the course syllabus, or the immediate related work for a given project; tracking down the source code of other systems is almost never done (perhaps simply because it is not often available).

In the professional world, no one teaches you how to do code or design reviews at this level either. Just like in school, professional programmers are constantly subject to deadlines which override just about any extra-curricular work. Reviews are often focused on mechanics or on vague, unsubstantiated worries. Again, extreme personal motivation is required to move beyond this.

How can we improve this situation? Is there room at the undergraduate level for more capstone projects that unify the theory, the history, and the mechanics with the craft of programming? What about at the graduate level? How about in a professional environment? What has been your experience?

I’d like to find programmers that work this way, that are excited and passionate about the craft of programming. Are you one? Get in touch.

Apr 20, 2010 - 1 minute read - Research Technology reproducibility science

Repeated and Reproducible Systems Research

Daniel Lemire (@lemire) recently posted on the Mythical Reproducibility of Science, noting that sharing code also makes it easier to spread your ideas:

The reproducibility that matters is getting people to use your ideas. Merely proving you are honest falls short of your potential!

He’s also written on this in the past with statistics on downloads of his software.

Here are some more writings on reproducibility:

At PDOS, Frans Kaashoek and Robert Morris definitely encourage us to build real systems and make the system available. I definitely like this approach and never found that publishing the full source to Chord, including our work-in-progress/submission, caused any problems. It has also meant that a lot of people still play with Chord, even if I no longer actively maintain it.

Apr 18, 2010 - 2 minute read - Technology interview question techniques

Interview non-questions

Once you get a job at a company, you move from one side of the interview table to the other. My ideal candidate for just about any engineering position:

  • has the ability to present technical ideas on the fly;
  • has practical Unix knowledge;
  • can write clearly and concisely in English and in code;
  • has a strong technical background.

Knowledge of particular technologies or programming languages is generally not interesting. Rather, the candidate should be smart and passionate.

One way I’ve started looking for passion is to see if the candidate has been involved in any volunteer work or open source projects. But it can be hard to assess the other qualities, even in an hour long interview. Typically, an interview assesses your ability to solve a particular problem, possibly in code, but not much about how it would be actually work with you.

As we hire some more people for MVP, I’m considering changing up our standard “bring in candidate for a series of 45m one on ones” to include some ways to probe for my desired qualities before the interview. I’d like to have candidates perhaps:

  • Send in a dot-file of some sort (e.g., .bashrc, .vimrc, .emacs, httpd.conf, etc.) That is: does the candidate use Unix and customize it? Does the candidate comment dot-files?
  • Prepare and deliver for the interview panel, a 5m presentation on some (any!) technical topic. Ensures the ability to communicate ideas clearly and answer questions.
  • Provide some samples of bug reports the candidate has filed or technical discussions that the candidate has had on a mailing list. (Say, 3 from the past 3 years, ideally from an open source project.) Alternately, provide a pointer to the candidate’s blog. That is, can this person write cogently? “Excellent communication skills” anyone?
  • Provide a code sample, something the candidate has had primary responsibility for developing, on the order of 100–500 lines of code. Two interviewers will review the code with the candidate.
  • Provide a commit, i.e., a diff to existing code (perhaps the code sample provided) and a commit message. This would demonstrate the ability to provide a clean functional change and document it for the team.

Most companies I interviewed with (at the PhD level) required a presentation, but only one asked for code samples. I’ve not seen any requests personally for anything else. Have you?

Incidentally, the Mobile Virtualization Platform team at VMware is hiring (mostly for our Cambridge office). Get in touch if you’re interested.

Mar 18, 2010 - 2 minute read - Technology git howto tools

Getting started with Git

Because of our work with the Linux kernel and with Android, we have started using Git more extensively at work, and my colleagues often have questions about how to get things done with Git. While the every-day command lists are helpful, most of the time, people would benefit more from getting a fundamental understanding of how git works. Here is a brief list of useful resources to help achieve that:

For me, the core difficulty is that people have to explicitly think about the history of their code and how they would like to share it with others. Git gives you many options whereas tools like Subversion and Perforce don’t; this plethora of options can make things confusing. In fact, it can lead to very philosophically different approaches for all aspects of your development process, ranging from shared-repository vs integrator to whether or not to merge frequently (yes? or no!). Here are a few useful readings on how people actually can use git:

Once you’re ready for more “tips”, be sure to follow:

For more regularly updated and possibly esoteric resources, check out my git bookmarks on delicious. Do you have some useful resources for getting people started with Git? Leave them in the comments.

Update: Added a link to the Visual Git Reference.

Oct 12, 2009 - 7 minute read - Technology conferences devdays javascript John Resig Miguel De Icaza mono stackoverflow

StackOverflow DevDays Boston 2009, Afternoon

The afternoon of Boston DevDays 2009 was, in my opinion, not as broadly appealing as the morning sessions (see my writeup of the morning here). However, there was still a lot of interesting material presented.

Joel welcomed us back from lunch by plugging StackExchange and how it’ll mean the end of “crappy old copies of Usenet” (by which he meant phpBB). He showed a pretty graph of StackOverflow edging out ExpertsExchange in traffic. He also announced a new job search site called that charges job seekers some money and asks you what your favorite editor is. There was also a video ad for the FogCreek training videos. This man knows how to monetize.

Patrick Hynds and Chris Bowen

The first technical session of the afternoon was on ASP.NET MVC. Patrick started the session with an explanation of ASP.NET MVC’s history relative to ASP Classic and ASP.NET, and why one might want to use a model-view-controller (MVC) architecture for a website: for example, much finer control over generated HTML compared to traditional ASP, test-driven development, and better URLs for SEO.

The rest of the talk was a demo of creating a hello world MVC application in Visual Studio. The presenters walked through updating models and view and controllers, setting up some basic routing. It seems that ASP.NET MVC is a fine re-implementation of Ruby on Rails or Django for the Microsoft world. One concrete tip I learned was that in Visual Studio, Control-. will offer you some completions or other shortcuts.

Reception to this talk was somewhat mixed, at least as far as I can tell from the blogs and Tweets about it. The talk itself could have been improved, of course; for example it would have helped for Patrick to have explained what MVC stood for (with a few architecture diagrams) before plugging its advantages for ten minutes. My take is that if you knew nothing about MVC, it was a straightforward talk that gave an introduction to the concepts and the implementation in .NET. If you were already familiar with MVC, I think you would have thought it pretty content-free as there wasn’t a tremendous amount of focus on the ASP.NET side of things.

John Resig

John Resig, the creator and lead developer of jQuery, a very popular JavaScript library, next took the stage to talk about JavaScript testing.

“Developing for JavaScript is a lot like whack-a-mole,” John reported. The large space of operating systems, browsers, browser versions, JavaScript engines, and browser plugins mean that typically if you fix one thing you’re more than likely to break something else. And so, in some informal studies, John found that people just don’t test. This is something John would like to change.

A unit test suite for JavaScript apparently isn’t that hard to write. John threw up a bunch of increasingly feature-rich test harnesses—with asserts, grouping by role, and a test runner web-page—using a few dozen lines of JavaScript. The hardest part of writing a test suite is likely to be adding support for asynchronous events (e.g. XMLHttpRequests). Fortunately, there are several pre-built suites such as QUnit, JSUnit, YUI Test, and Selenium. John spent a bit of time talking about the differences between these frameworks, and particularly plugged QUnit and YUITest.

Selenium is of particular interest since, unlike the others, it is not just a unit test framework. It also has plugins to allow recording and scripting events to a browser, so you can do whole site testing. It even comes with Selenium Grid which will let you distribute and automate testing. This seems like a big win.

There are JavaScript engines like Rhino. To help test code in a browserless environment, John wrote env.js, which is a browser-like environment that runs in pure JavaScript. He talked about how this could be used for screen scraping.

{% img right 240 160 “John Resig plugs for distributed JavaScript testing.” %} Finally, John introduced This is a SETI@Home style site where anyone can visit the site, download some tests to run and report back the results. This should give very broad coverage and allow developers to get feedback from a wide range of real environments (e.g. mobile!).

Overall, John’s talk was a rapid-fire overview of JavaScript testing resources from a JavaScript ninja. It was very practical, easy to follow and probably great for anyone who does JavaScript development. However, it lacked the “Python is awesome!” feel of Ned Batchelder’s morning talk and so for a non-Javascript developer such as myself, it was not as appealing.

Miguel De Icaza

Miguel De Icaza closed out the day with a talk on Mono. Miguel explained that he wasn’t really sure what he should talk about—Mono is a giant universe and explaining “Mono” it is “kind of like explaining God”—and his informal survey didn’t really provide a mandate. He would up giving some nice technical demonstrations of some recent Mono developments, with a fair amount of personal flair to keep the audience engaged.

The core of Mono is an implementation of the Common Language Runtime for Linux. One of the goals of this project was to bring the best development tools to Linux.

The first demonstration Miguel gave was an impressive combination of tools. Using a plugin to Visual Studio, Miguel demonstrated that you could develop a Linux port of a .NET application entirely using Visual Studio on Windows, and seamlessly testing and packaging on a Linux machine (or VM), by walking through a live example of porting BlogEngine.NET. This made use of Bonjour to dynamically discover the Linux machines, pushing execution to the selected machine, and viewing the debugging results in Visual Studio.

Miguel then decided that a developer might want to publish their application as a software appliance, so he walked through a complete demonstration of using SUSE Studio. He seamlessly built an RPM on his Linux box from Visual Studio and pushed it into “the cloud” of SUSE Studio. From his browser, he configured an appliance with that RPM, baked it the way they do on cooking shows, booted the virtual machine in the cloud, accessed it using a Flash-based console in the web browser, and accessed the port of BlogEngine.NET that he had just booted.

For his second major demonstration, Miguel moved over to MonoTouch. This showed using MonoDevelop, an IDE for Mono developers, running on a Mac, to work with the iPhone interface builder application, to build a simple flashlight application (i.e., a giant white button) for the iPhone simulator. He talked a little also about the technical work involved here, which was to compile the developer’s Mono code into ARM assembly and link it into the Mono runtime, to create an iPhone application. This gets around Apple’s “no interpreters” rule.

Miguel’s talk was easily the most entertaining one of the day. It was perhaps most entertaining because, in addition to his wry humor (check out the pictures from Ian Robinson’s Tweet, for example), as he performed his live demonstrations, things would break, whereupon Miguel would think, realize what was wrong, pop open a Terminal and fix it. That’s not something you see in the usual carefully scripted demos at most shows. Of course, Miguel was also demonstrating some interesting technical features and giving an advertisement for a wide-range of Mono-related tools as well, so there was something for everyone.


After Miguel’s talk, Joel suggested that the audience break up into informal groups and get dinner, loosely organized around seven areas that he suggested. I hadn’t planned for that and had to get home; not sure how many people went.

Overall, I think DevDays was well worth attending. On the networking side, I got to meet a few local developers (of whom I’ve posted a few pictures on Flickr) and catch up briefly with some acquaintances from school. On the technical side, I got a broad overview of several popular technical areas from leading figures in those areas.