The Kodu game building system got some coverage in today’s Edmonton Journal. In a piece titled Kudos for Kodu, the Language of Kids, they cover the story of how St. Mary Catholic Elementary School is using Kodu to teach not just programming, but parts of the science curriculum as well. The kids are building a Kodu world that simulates a wetland ecosystem, filled with creatures that explain their roles. It sounds more fun than my grade school science classes and echoes my own philosophy of “don’t learn to build, but build to learn”.
Want to learn more about Kodu? You can get a quick introduction by watching me and Junior on Developer Junior:
…after which, you can look at Hello, Kodu!, my article that walks you through the process of programming Kodu the robot to respond to the gamepad controls. It also provides links to more Kodu tutorials.
Here’s the first of my notes from the Science 2.0 conference, a conference for scientists who want to know how software and the web is changing the way they work. It was held on the afternoon of Wednesday, July 29th at the MaRS Centre in downtown Toronto and attended by 102 people. It was a little different from most of the conferences I attend, where the primary focus is on writing software for its own sake; this one was about writing or using software in the course of doing scientific work.
This entry contains my notes from C. Titus Brown’s presentation, Choosing Infrastructure and Testing Tools for Scientific Software Projects. Here’s the abstract:
The explosion of free and open source development and testing tools offers a wide choice of tools and approaches to scientific programmers. The increasing diversity of free and fully hosted development sites (providing version control, wiki, issue tracking, etc.) means that most scientific projects no longer need to self-host. I will explore how three different projects (VTK/ITK; Avida; and pygr) have chosen hosting, development, and testing approaches, and discuss the tradeoffs of those choices. I will particularly focus on issues of reliability and reusability juxtaposed with the mission of the software.
Here’s a quick bio for Titus:
C. Titus Brown studies development biology, bioinformatics and software engineering at Michigan State University, and he has worked in the fields of digital evolution and physical meteorology. A cross-cutting theme of much of his work has been software development for computational science, which has led him to software testing and agile software development practices. He is also a member of Python Software Foundation and the author of several widely-used Python testing toolkits.
Should you do open source science?
Ideological reason: Reproducibility and open communication are supposed to be at the heart of good science
Idealistic reason: It’s harder to change the world when you’re trying to do good science and keep your methods secret
Pragmatic reason: Maybe having more eyes on your project will help!
When releasing the code for your scientific project to the public, don’t worry about which open source licence to use – the important thing is to release it!
If you’re providing a contact address for your code, provide a mailing list address rather than your own
It makes it look less “Mickey Mouse” – you don’t seem like one person, but a group
It makes it easy to hand off the project
Mailing lists are indexed by search engines, making your project more findable
Take advantage of free open source project hosting
Distributed version control
“You all use version control, right?” (Lots of hands)
For me, distributed version control was awesome and life-changing
It decouples the developer from the master repository
It’s great when you’re working away from an internet connection, such as if you decide to do some coding on airplanes
The distributed nature is a mixed mixed blessing
One downside is "code bombs", which are effective forks of the project, created when people don’t check in changes often enough
Code bombs lead to complicated merges
Personal observation: the more junior the developer, the more they feel that their code isn’t “worthy” and they hoard changes until it’s just right. They end up checking in something that’s very hard to merge
Distributed version control frees you from permission decisions – you can simply say to people who check out your code "Do what you want. If I like it, I’ll merge it."
Open source vs. open development
Do you want to simply just release the source code, or do you want participation?
I think participation is the better of the two
Participation comes at a cost, in both support time and attitude
There’s always that feeling of loss of control when you make your code open to use and modification by other people
Some professors hate it when someone takes their code and does "something wrong" with it
You’ll have to answer “annoying questions” about your design decisions
Frank ("insulting") discussion of bugs
Dealing with code contributions is time-consuming – it takes time to review them
Participation is one of the hallmarks of a good open source project
From the New York Times: “Despite an improved economy, many Japanese are feeling a sense of insecurity about the nation’s schools, which once turned out students who consistently ranked at the top of international tests. That is no longer true, which is why many people here are looking for lessons from India, the country the Japanese see as the world’s ascendant education superpower.”