Start Simple, Then Build “Call of Duty”

My son is taking a course in computer programming at his high school. As is the case for many (most?) high school students in Ontario, they’re using a programming language named Turing.

I initially hated the Turing programming language. That hate was a bit irrational, as–like many of my peers–I have great respect for Alan Turing and find it more than a bit audacious for someone to dare name any programming language after the man that is responsible for much of what we take for granted.

After spending the weekend helping my son with an assignment, I still don’t particularly like the programming language: I find it unnecessarily verbose and cumbersome; its libraries lack important features; the development environment is sluggish; and it only runs on Windows (though it seems to work reasonably well using the wine emulator on Ubuntu 11). But, I’m starting to warm to it as a pedagogical tool.

When I was just learning about programming, the coolest game available was Lode Runner. This is the game that my high school peers and I strived to emulate on four beat up Apple ][ plus computers. The teaching staff wasn’t very much help with regard to learning how to write software; there wasn’t even a formal course on computers. They did provide one big bit of help, however: they only let us play video games that we wrote ourselves; no store-bought games were allowed in the lab. Through trial and error, with help from Nibble magazine, Beagle Bros., other students, and an occasional visit from one of the professors from Royal Roads Military College we learned to program. I produced many great games like Airwolf, a top-down shooter based on the television programme; Corridors of the Inquisition, a 3D maze game; and Kitty Munch–my most popular contribution–another 3D game in which the user drops bricks on cats from the top of a tall building.

By “great”, I of course mean “totally lame”. Nothing that we ever built compared to Lode Runner. But the important part in this little trip down memory lane is that there was a fighting chance that any one of us–or perhaps some small number of us–could write something like Lode Runner, and sell enough copies to make a decent bit of money.

Fast forward to today. “Call of Duty: Modern Warfare 2″ cost between $40 and $50 million to produce. A big boatload of people where involved in the creation of this masterpiece of mayhem and violence. I worry a bit that today’s student programmers can’t possible look at games like this and draw inspiration. I can’t see how any reasonable person can look at Call of Duty and say “I could build this” like we did with Lode Runner?

So what does any of this have to do with Turing?

I’ve tried a few times to teach my son how to program in Java. Maybe with more time and effort, that could work. But it was difficult to get to a point were we could do anything meaningful or interesting. In a couple of hours, I managed to get an working version of Kitty Munch (actually the third version) implemented in Java and running on Android, but this just left my son’s head spinning. Three decades of growing with the industry has equipped me with what I need to get that job done, but teaching all of the moving parts to a teenager is pretty difficult. Jumping into the middle of this is a great way to discourage people from even getting started

This is where Turing comes in. It’s a simple language that shares many concepts with Pascal. Like the Applesoft Basic and, later, Turbo Pascal, that I cut my teeth on, it’s possible to write a working program without understanding functions, objects, or structures. You can get by with a very basic understanding of a couple of data types, and grow from there. My son and his classmates have all, in a matter of a few days, managed to build working games. My son’s “Kitty Munch 4″ is almost as functional as the original after only about two days worth of effort; more functional if you count the use of colour as functionality. Yesterday, I taught him about using double buffering to eliminate flickering, which should give him a leg up on his classmates. Tomorrow night (he has baseball tonight), I’ll show him how to use image masks.

I’m still not a big fan of the Turing programming language. But I do appreciate the ability to get something running very quickly, and then incrementally introduce concepts without having to worry about all the nitty-gritty things that real programmers have to think about. For students who are just learning to program, I don’t necessarily recommend Turing. What I do recommend, however, is that you start simple. Don’t try to build Call of Duty. Start with Lode Runner. Or Pong. Learn the basics. Get something working. Then make it better.

Do this first. Then go get a degree in Computer Science.

Posted in Cranky Old Programmer | Leave a comment

Understanding Layouts in SWT

An unrelated problem drew my attention to the Understanding Layouts in SWT article. It’s always bugged me that the many screenshots in this article are represented in JPEG format. JPEG is a lossy format that, in my humble opinion, is inappropriate for screenshots as the images end up with odd dithering that just plain bugs my eyes. So I decided to rebuild the screenshots in PNG format.

When I updated this article in 2008, rather than build and shot each image manually, I wrote a little Java program that builds and shoots all of the images automatically in one fell swoop. At the time, I couldn’t figure out where to store the code; it didn’t belong to any Eclipse project, and the way that Eclipse Corner is set up in CVS makes it an inappropriate place for Java code. At the time, I stuffed it into a private CVS server and forgot about it.

I pulled that code out today, tweaked it a bit, and regenerated the images. I think they look a lot better in PNG format.

I’ve put the code into a repository on GitHub if you’re interested. I’m not sure if it’s a great example of how to bend SWT to your will, but there is a little trickery in there that gets the job done.

Oh… and some food for the trolls: SWT is way better than Swing. FWIW, I haven’t looked at Swing in years; what do I know?

Posted in Eclipse 101 | 6 Comments

The Eclipse that Everybody is Looking For…

Our dependence on search technology grows.

A while back, I posted the Top Ten Ways to Say Eclipse. It seems like every few days, I get a new one to add to my list. I get asked about Eclipse cables, Eclipse wire strippers, Eclipse massages, and more. The variety is inspirational.

Most of the people who contact me are pleasant enough. Some acknowledge that they’ve probably contacted the wrong person. Some people are downright nasty. Again, the variety is inspirational.

I’d wager that all of these misdirected missives, are the result of the sender simply typing the name of whatever it is that’s itching them into their favourite browser, clicking the first thing in the list, and navigating our contact links until they find the most promising email address. The eclipse.org pages do pretty well in terms of page ranking on Google, so we’re probably the first hit for anything “eclipse”, and once you get that first hook, it’s only two clicks to the “General inquiries” (EMO) email address.

Oh well… I guess that it only takes a few seconds for me to explain that we’re not the eclipse they’re looking for

Posted in Cranky Old Programmer | Leave a comment

Transparent and Open

The term “open and transparent” rolls off your tongue. While somewhat more cumbersome to say, I tend to prefer reversing the order: “transparent and open”. I prefer this because I believe that transparent precedes open; and far more open source projects are transparent than are open.

In my experience most people seem to understand transparent. “Transparent” means that you do things in a way that others can watch. Making source code available to anybody who wants a copy is one way of being transparent. Holding project-related discussions in a mailing list with an archive that’s accessible to anybody with an Internet connection is another way of being transparent. There are many more examples, like making your issue tracker available, hosting public discussion forums, and more.

Transparent does not mean open.

Open is a little harder. “Open” means that you do things in a way that others can participate. It means that you provide a level playing field: everybody participates using the same set of rules. Being transparent is easy; being open is hard.

Being open is more than just accepting code patches, and permitting outsiders to create bug reports.

Being open and having a true level playing field is hard because it requires that you give up absolute control. In an open project, control is shared. When the playing field is truly level–with the same set of rules applies to everybody–it’s possible that somebody can arrive at your project and change the way that you do things. This is not to say that anybody can show up and start making arbitrary changes to the code. Rather, it means that there exists a set of rules and conditions by which anybody can earn the right to participate as an equal member.

The rules need not be explicit or quantitative. Though, it does help if they are.

Take a look at the developers on your project. Do they all work for the same employer? When was the last time you added a new developer to the project? Do you accept contributions from “outside” contributors? How hard do you work to convert those “outside” contributors into full participants and decision makers on your project?

Operating in an open manner, actively courting participation to turn outsiders into insiders increases the diversity in the project and in so doing increases its strength and durability.

Transparent is good. Transparent and open is better.

Posted in Community, Cranky Old Programmer, Project Management | Leave a comment

The Eclipse Common Build Infrastructure

Creating an Common Build Infrastructure (CBI) at Eclipse has been one of our holy grail pursuits over the years. My main goal in this effort has been to get Eclipse committers out of the build business so that more time and energy can be focused on actually writing software (which is what most software developers would rather spend their time doing).

When we talk about “build”, we mean the process of taking source code and turning it into a form that adopters and users can download and consume. Building software in general–and building Eclipse plug-ins/OSGi bundles in particular–is a relatively hard problem. The original CBI at Eclipse used a combination of PDE Build, black magic, cron, and manual intervention in the form of pulled hairs.

Our first attempt at trying to make this easier for Eclipse projects resulted in the Athena Common Build. Athena added a layer on top of PDE Build that made it quite a lot easier to build Eclipse plug-ins, features, and update sites. The community owes a debt of gratitude to Nick Boldt for all the hard work he did to implement Athena, and his tireless efforts help projects to adopt it.

Around the same time that Athena came into being, we brought Hudson into the picture to provide proper build orchestration.

Builds at Eclipse continued to evolve. The Buckminster project, which focuses on assembling artefacts, waded into the build space. The B3 project, a third-generation build based on Modeling technology, was created. At one point, a new project at Eclipse had lots of different choices for build.

Then the push to Maven started. For years many vocal members of the community complained that Maven couldn’t be used to build Eclipse bundles. It was Eclipse’s fault. It was Maven’s fault. There were a many false starts. But everything changed with Tycho. Tycho makes Maven understand how to build Eclipse plug-ins. Tycho facilitates a couple of useful things: first, it allows you to do “manifest-first” builds in which your Maven pom leverages the OSGi dependencies specified by an Eclipse bundle; second, it enables Maven to resolve dependencies found in p2 repositories. It does more than this, but these are the big ones.

Unfortunately, we haven’t found a good way to track the rate of migration. But in my estimation, Eclipse projects and many others in the adopter community are flocking to it.

The combination of Hudson, Maven, and Tycho seems to be delivering the holy grail. I managed to get up and running on Maven/Tycho in a matter of minutes and haven’t thought about the build since. For projects delivering a handful of features and bundles, it’s dirt-easy to get started and maintain the build. There are a still few rather large corner cases that need to be addressed. For example, we have a team working on moving the Eclipse project’s build over to the CBI. The Eclipse project’s build is about as hard as it gets.

The CBI has evolved and will continue to evolve. Our noble Webmaster recently added a new interface for signing build artefacts with the Eclipse certificate. We have ongoing work to develop a standard “parent pom” for Eclipse projects, and even a Maven repository where Eclipse projects to push their build results for dissemination to the general public.

So the CBI at Eclipse seems to be stabilizing around these technologies. But, I have no doubt that it will continue to evolve, especially as more and more projects start to consider implementing continuous build strategies combining Gerrit and Hudson.

Posted in ALM, Eclipse 101, EDP, Project Management | 5 Comments

Google Summer of Code 2012 Students announced!

The Google Summer of Code 2012 students have been announced, and I’m very happy to report that Google selected twelve exceptional student project proposals for the Eclipse Community.

  • The Eclipse Communication Framework (ECF) project picked up two student projects: Future enhancements for Salvo Newsreader, and OSGi Remote Services Testing framework for ECF;
  • Three student projects were selected for eTrice – Real-Time Modeling Tools: Diagram Layout in eTrice with KIELER, Extended Model Validation and State Graph Proposal Generation, and Generic Action Code Language;
  • Only one project was selected for JGit: Extending the CLI (command line interface) in JGit;
  • Two for Mylyn: Activity tracing for Mylyn, and Enriching Mylyn’s Task Context with Breakpoints;
  • Two for Orion: Eclipse Orion Chrome DevTools Extension, and Orion – Cooperation with Contributors;
  • The Parallel Tools Platform (PTP) gets one: Parallel Tools Platform Graphical Explorer of CUDA Programs; and
  • One for Code Recommenders: Merge SnipMatch into Eclipse Code Recommenders.

I’m pleased with the results so far. The bonding period officially begins tomorrow, and the official start of coding begins near the end of May.

Congratulations to the accepted students!

Posted in Community, GSoC | Leave a comment

Application Lifecycle Management at Eclipse

The Eclipse Foundation has evolved a pretty impressive application lifecycle management story. Based on what I’ve observed over the years, I believe that it’s completely reasonable to say that our ALM story is one of the best in the world: the envy of hundreds of open source projects and closed source development shops around the world.

I believe that our success comes from a combination of great people, well-defined process, and a powerful stack of open-source tools.

We started from humble beginnings: issue tracking with Bugzilla, CVS for source code management, PDE Build and Ant scripts for build, cron for orchestration, and the Eclipse Development Process for guidance. Over time, all the the pieces have evolved resulting in the world-class whole that we have today.

Process

The Eclipse Development Process describes the structure of projects and teams at Eclipse. It provides guidance to help projects run in an open, transparent, and vendor-neutral manner. It provides a framework for processes around releases and other important stages in project lifecycle (e.g. creation, graduation, and termination). From a process point of view, it’s a pretty high-level document that provides a framework for day-to-day work; individual projects, however, are given flexibility to decide how they run their day-to-day development.

Eclipse projects have the benefit of the most comprehensive IP management and due diligence process available to open source projects. In fact–based on my experience working with many dozens of companies over the years–it is one of the most comprehensive IP management processes available to anybody.

IP Management is important when you care about adoption of your open source project. Adopters need to know that they can safely use the output of your open source project in their own projects and products.

Tools

The tools story has evolved considerably since those humble beginnings.

We still use Bugzilla for issue tracking. We have a second Bugzilla instance, called IPZilla, that we use for tracking intellectual property contributions and use of third-party libraries.

And we’ve added a few new pieces:

Subversion (SVN) was added as an alternative to CVS for source code management, but both are now being phased out in favour of Git. In fact, CVS is meeting its end-of-life at Eclipse on December 21/2012 and Subversion is no longer an option for new Eclipse projects. Moving forward, it’s Git or nothing.

Hudson provides build orchestration. As of EclipseCon 2012, we have 337 build jobs that have run a total of 86,000 times on Hudson: ninety-eight run daily, and 218 have run in the last month.

Gerrit was recently implemented by our noble Webmaster team to provide code review for projects that opt to use it. Using Gerrit streamlines the contribution workflow: contributors can push their commits directly to Gerrit where project committers can quickly and easily process them. Gerrit has a lot of very cool tricks including the ability to invoke Hudson builds to confirm that new contributions will actually compile (Hudson, in effect, gets a vote on whether or not a contribution should be accepted).

With the introduction and subsequent development of Tycho–technology that lets Maven understand and build Eclipse plug-ins and OSGi bundles–Maven-based builds are quickly becoming the gold standard for Eclipse projects.

Tying it all together is, of course, Eclipse. The Mylyn project provides integration from Eclipse to Bugzilla (along with many dozens of other issue trackers), Hudson, and Gerrit. The EGit project provides integration with Git, and the m2e project provides support for maintaining Maven build artifacts.

People

None of this would be possible, of course, without people. The implementation of Git at Eclipse was not a trivial matter. We had a lot of questions that needed to be be answered, and the Eclipse Committer community stepped up to help us answer those questions. There are similar stories for the other technologies that have been adopted at Eclipse.

We’re still working on our Maven story. Like everything else at Eclipse, this isn’t being driven from the top-down, but rather it is being driven by the developer community.

One of the most important things that keeps all this technology and process moving forward is communication. We have a strong ethic of transparent communication and open discussion across all 250+ Eclipse projects.

Of course people drive both the evolution of technology and process. The Eclipse Architecture Council–a group of old and grizzled veterans of open source development–provides assistance to projects who are just learning the process, and are responsible for evolving the process as necessary. The Eclipse Development Process is considered a living document and so is subject to change. We tweak and adapt our processes and practices on an ongoing basis.

No discussion of the Eclipse ALM story is complete without discussing the simultaneous release. The simultaneous release, which is coordinated by the Eclipse Planning Council, is as much about people as it is technology. Every year, many of projects join together to coordinate their development schedules and combine their releases into a single mega-event. This year’s Juno release includes 71 separate Eclipse projects and (total SWAG) 60 million lines of code.

The size of the simultaneous release has been growing over the years. Something as massive as the simultaneous release can only happen with free-flowing lines of communication among developers working together with common goals.

Evolution

Are we there yet?

No. There is no “there”. The ALM story at Eclipse continues to evolve. It will always evolve. We still need to solve the Maven question, and projects are pushing us into the continuous integration space. And there may be more changes ahead.

Who knows what the future will bring?

Posted in ALM, Community, EDP | Leave a comment