The Third Bit

This from James Shore, via Mike Gunderloy’s ever-entertaining Larkware News.

Uncategorized

Annoyed by people conducting 80-decibel conversations on their cellphones in public places? Just wait—according to New Scientist, Motorola is about to inflict guitar phones on the world. Yes, you heard me: the cellphone display will show the fret board, and as the Santana wannabe next to you fingers it, the phone will play.

Sartre was wrong. Hell isn’t other people; it’s other people’s toys.

Uncategorized

The first lecture of two on software development process is now up. I know a lot of people have very strong opinions on this, so feedback would be very welcome.

Uncategorized

These stats on the development of Eclipse 3.1 (via Prof. Dave Wortman at the University of Toronto) show what it takes to get something that size out the door:

• Days in the Eclipse 3.1 development period: 365
• Decrease in size of the SDK installed footprint (from 3.0, 32KB block size): 6,688 KB
• Committers: 133
• Lines of Java source code: 2,425,709
• Java source files: 11,548
• Lines of XML source code: 57,533
• Builds delayed by fire (Oregon): 1
• Builds broken by lightning strike (Beirut and Ottawa): 2
• Most tests for a single component (JDT Core): 17,764
• Bugzilla bug or enhancement reports entered: 21,831
• Bugzilla reports resolved (fixed, wontfix, duplicate, etc): 20,789
• Bugzilla reports fixed: 9,871
• Number of bug reports written entirely in verse (#100918 and #100924): 2

Learning

Part 1 of an article on data crunching is now up on the StickyMinds web site. Part 2 should follow in a couple of weeks.

Writing

The lecture on databases (actually an introduction to SQL) is now up. Comments and corrections welcome.

Software Carpentry

The second lecture on testing is now online. As always, comments and corrections are appreciated.

Software Carpentry

A few days ago, Brendan Eich wrote a thoughtful
post on incorporating a few ideas from Python into JS 2.0
(specifically iterators, generators, and comprehensions, but that’s
beside the point for the moment). I replied:

t would be tremendously helpful if JS2 could standardize plugin APIs
in both C and C++ (and do the latter in a template-smart way). Having
simple C APIs accelerated the growth of Python and Ruby tremendously,
and (I believe) is crucial to getting JS accepted as a “traditional”
scripting and glue language. Standardizing “one way to do it” for C++
(esp. templated C++) would avoid a lot of the grief P&R have gone
through.

Brendan’s response was:

…for Mozilla, XPIDL and XPCOM (http://www.mozilla.org/scriptable/)
are the way to interface to “plugins” (generally construed)
implemented in other languages, not just C++ but also Python (a C
XPCOM binding could be done, and one was started, but there hasn’t
been much interest). A truly painless C or C++ binding should work as
with OCaml — that is,

ocamlc foo.c

This is a fine goal, but not something for ECMA TG1 to standardize
just yet. I would welcome a prototype for SpiderMonkey, if volunteers
capable of pulling it off are motivated.

Plugins loaded from the net are a different animal, requiring lots of
trust as well as highly compatible, stable APIs on both plugin and
browser sides of the fence.

I’ve argued elsewhere
that Javascript could be the dominant scripting language five years
from now: it’s sexy, it’s (relatively) simple, and it’s one of the two
languages every programmer has to learn (the other being C). An easy
way to wrap and call legacy C/C++ code—one that handles C++ objects
and templates, rather than requiring programmers to pretend they’re
C functions—would be a big step toward this. Boost.Python
is the closest thing I’ve seen yet to a usable solution; if anyone out
there wants to be rich, famous, and popular, Boost.Javascript is just
begging to be created.

Uncategorized

In the wake of at DemoCamp 3 last night, we had another on-line meeting this morning about the state of DrProject. Our original aim was to release it at the end of January; we’re now looking at the first week of March, and it may slip again. Here’s the current to-do list:

1. Our Kid templates are too slow: 2-3 seconds per page. This is only partly Kid’s fault—as Chris Lenz pointed out, our current wiki formatter is creating HTML, which Kid then tries to validate. We hope to fix this with a two-pronged attack: writing a new wiki formatting engine (which we really want to do anyway), and getting Kid’s maintainers to add a “don’t bother to validate” flag.
2. The mail subsystem still isn’t hooked up. Exim vs. Sendmail is part of the problem, but so is the code that was written last summer.
3. We still don’t have any screencasts (which have quickly become one of the things that separates the pros from the amateurs). Pat Smith has tried various tools, but none of the free ones generate Flash and record audio at the same time. The latest beta of Wink is next on his list; if that doesn’t work by week’s end, we’ll spring for Camtasia.
4. We haven’t figured out what to do about RSS authentication (but then, neither has anyone else). We must use the user accounts on the underlying Unix system, rather than doing our own provisioning, so we either figure out a secure way to get a dozen different blog readers to pass user IDs and passwords to us (unlikely), or place a bet on one of the open source identity management “standards” being bruited about. You can probably hear the lack of enthusiasm in my voice…
5. Documentation. The user guide isn’t done, the installation notes are incomplete, the scripting examples don’t exist—in short, we’re looking like a typical open source project.
6. Finally, there are a bunch of smaller issues: modifying the CSS style sheets so that pages printed from Firefox aren’t squeezed into a two-centimeter column, making the logo display properly in IE, and so on.

None of this detracts from the fact that we’ve come a long way in a very short time: DrProject is very usable, and impressed a lot of people last night who aren’t particularly easy to impress.

Onward!

DrProject

16 lectures are now in place (more or less), which means I have 8 more to do. The syllabus shows what I’ve covered already; my current plans include:

• unit testing
• XML
• SQL
• more SQL
• small-team development process

What do you think the other three should cover (keeping in mind that this is supposed to be a course on basic software engineering, rather than scientific programming)? Options include:

1. Basic web programming, with much-revised versions of:
   • http://www.third-bit.com/swc1/www/client.html
   • http://www.third-bit.com/swc1/www/server.html
   • http://www.third-bit.com/swc1/www/security.html
2. Integration, including:
   • wrapping C code so that it can be called from Python
   • using popen() and its ilk to run external programs
   • (probably) something on refactoring to make code more testable (as per Feathers’ excellent Working Effectively with Legacy Code
3. Three lecture-length examples, building very simple versions of core tools that haven’t been covered elsewhere:
   • data lineage
   • continuous integration
   • data consistency checking
4. Give in, and do the scientific programming stuff anyway:
   • floating-point arithmetic
   • Python’s Numeric package
   • data visualization
5. Scrap the single lecture on development process, and put in four full lectures on the subject
   • XP
   • UML-based processes (probably ICONIX)
   • something else (not entirely sure what)
6. Something else entirely — suggestions would be very welcome.

Please let me know what you think.

Software Carpentry