Wednesday, December 31, 2008

Happy New Orbit!

As we approach to within 5 million kilometers of the arbitrary point at which we've declared one orbit of the Earth around the Sun to end and the new one to begin, I wanted to wish everyone a happy new orbit!

This year, the Sun has traveled about 0.00000144 degrees around the center of our galaxy, the Milky Way. This means we on Earth have followed our sun 6,591,881,796 kilometers through space relative to the center of our galaxy. If that starts to seem like a long way, remember that's only about 0.0007 light years.

The Earth itself has traveled about 939,955,097 km in its orbit around the Sun.

And we here on the surface of the Earth, living at about 38 degrees north of the equator, will have spun around 365.242 times since the start of the present orbit. This means that we've travelled about 11,534,832 km relative to the center of the Earth.

So, to see how much you've gotten around this last orbit, get the following:
About how far you walk in a day, times 366 and the mileage off your car's odometer, then add it to the distances above (given in miles below, since my car's odometer is calibrated in miles.)

Solar orbital travel about galactic center: 4,096,030,281 mi.
Earth orbital travel around Sun: 587,471,955.8 mi.
Earth surface travel about Earth center: 7,209,279.2 mi.

Cumulative distances (all added up) are:
4,690,711,519 miles, or,
7,505,138,430 km.
plus whatever miles you travelled personally on the surface of the Earth. Figure about 0.00078 light years. As they say, it's not the years, it's the mileage.

In the past orbit we've improved our view of the Andromeda galaxy by coming about 8,678,149,920 km closer to it. That's an improvement of about .0009 light years out of about 3 million. Our views of the Magellanic clouds has gotten worse, however, with them getting about 8.5 billion km farther away for the Large Magellanic Cloud and about 5.3 billion km farther for the Small Magellanic Cloud. The compensation is that the Triangulum galaxy, M33, is now about 6 billion km closer. So views of objects in the Local Group of galaxies gets better and better for us here in the northern hemisphere.

Happy New Orbit, everyone!

Thursday, December 25, 2008

Merry Christmas!

Here's wishing everyone a wonderful holiday. I hope you got some great computers, free OSes, preinstalled software development packages, and clean compiles with no errors and no warnings worth mentioning.

While you're preparing for the new year, you're going to need a way to keep track of the date. You could do a lot worse than to pick up a Traveller calendar. It's got great science fiction art contributed by amateurs. Not that you can tell by the quality of the art. I've seen worse--far worse--in many professional publications. I've got one hanging next to me here at my post, I'm looking at the ship Azhanti High Lightning by Andrew Boulton now.

It's been a great holiday for us, and it's not even over yet.

The last couple of classes I had my Middle School computer class playing a MUD in the classroom. We had a good time, and the kids didn't even realize they were getting educated in the process.

My high school class was finishing up their proposals for video games, it looks like we're going to have some great ideas to work with. Even some of the really simple game ideas have some interesting twists to them. When school starts up again they'll be giving their presentations (assuming they still remember what they were doing ;) and we'll be selecting the games we'll be developing once we get through some Greenfoot tutorials and some Java basics. But the high schoolers found out the middle schoolers have been playing the MUD, so I've promised them a few classes of MUD before we start programming. After we've done some Greenfoot, though, I wonder if they'll regret it. :)

Saturday, December 6, 2008

Preparing for Programming (with Greenfoot)

In my high school computer class we're starting to look forward toward next semester when we begin programming. I like to have an assignment in the first semester of class where the students prepare a document with images, tables, and such. If possible I like to make it something they're actually interested in writing. And I have them tie the paper to a presentation to the class.

This year and last year I have had that paper be a design document or design proposal for a video game. This year we're going to actually use the proposals. The students will be presenting their video game concepts to the class, they'll get feedback and an opportunity to touch up their presentations then present them again. After that we'll vote to choose which games we'll actually work on developing next semester, and form small development teams to work on them (students with less of an interest in programming and more of an interest in art will be put to work producing visual resources for the programs they're interested in working on.)

In spring semester, we're going to be programming with Java, and this year I'm adding Greenfoot to the curriculum. In the past we've only managed to do a little bit of graphics in the time we have. I'm hoping that with Greenfoot we can make graphics and sound a much more integral part of our work. I've already got the students familiarizing themselves with what Greenfoot can do, so that they don't expect to develop full 3D first person shooters in one semester of introductory programming.

I've had them visit the Greenfoot Gallery to see what others have done with Greenfoot, and we've talked about how ambitious it would be for them to develop different types of programs. I've asked them to organize their design documents to have a core functionality described in the body of the document, with possible extensions described in an appendix. So hopefully the proposals will be developed enough to be interesting without being overly ambitious.

Since I first looked at Greenfoot the materials for learning how to use it have grown. There are a number of videos added to the video library they maintain. Likewise, the other documentation has grown, and the Greenfoot mailing list is quite active.

One of my middle school students has decided to take on Greenfoot on his own outside class. He saw the link on my class website, got interested and downloaded it for himself. He needed a hand getting the Java SE JDK installed on his home system, but with some basic instructions and the loan of a disk to save him the download time he's got that running now, it seems. He's worked through a few of the tutorials, it'll be interesting to see what he produces.

At this point I intend to teach only the most basic elements of running and compiling Java programs at the command line before we jump into the Greenfoot tutorials in class. It will be interesting to see how things go. Will Greenfoot drive an interest in learning how Java works to obtain desired results in the students' programs, with learning of Java smoothly interleaving with the work in Greenfoot? Or will we hit a plateau where we have to backfill with more formalized teaching of Java before we move forward? It will be interesting to see how things work out.

Either way, we'll certainly keep it fun.

Monday, December 1, 2008

Fun with the "Sharpie Test"

Among my various hobbies is telescope-making. I'm in the process of making a Gregorian telescope right now. My daughters are also making telescopes. The older one is making her second mirror, an 8 inch f/7 for a Newtonian. The younger one is making her first mirror, a 6 inch f/8, also for a Newtonian telescope.

One of the parts of making a telescope mirror is what's called the "Sharpie Test", where you draw all over the mirror with a permanent marker (you can guess what brand usually gets used) to make sure you're working the entire surface of your mirror well as you grind it. They describe the test in detail on one of their tutorials over on

Well, I like to have some fun with my Sharpie tests, I get tired of just drawing plain old grid patterns. So I like to draw other things. Pizzas are a favorite. I also draw all sorts of cartoons on the mirror. They only last a few minutes, so it's very ephemeral as art goes.

My wife suggested I take some pictures, and after reminding me of the idea enough times I finally took pictures of a couple of my Sharpie test patterns, and now I've finally posted them. Here you go.


Cat gripping planet.

Cat on alien world.

Not all my drawing have cats, I just got more pressure into taking pictures when they had cats.

Wednesday, November 5, 2008

Improving the Atmel STK500

Atmel STK-500 in an attractive case
One of my new STK-500 boards inside the case I modded for it.

I recently bought two new STK-500 development boards from Atmel. I've had one for years, and it's been very useful to me when working with AVR microcontrollers. There are a few faults with the STK-500 however. One is that it doesn't provide for mounting in a case. There are no mounting holes, and the components on the board run out to within a millimeter or so of the edge, so there's not even room to put the board on rails.

STK-500 board with rails along edge, showing the components are too close to the edge for the rails.
The components don't provide enough clearance at the edge of the board for mounting rails, and there are no mounting holes on the STK-500 board.

My old STK-500 lives in a cardboard box for a 5-1/4" hard disk drive. It's worked out well, even if it's not very attractive. It lets me keep dust off the board, and it keeps people's fingers away when I take it out in the living room to program chips while I'm in my easy chair. It also lets me put it on a shelf safely when I'm not using it.

Cardboard case for the STK-500. Stylish permanent marker on the side keeps it from looking like trash.
My old STK-500 inside its box. The markings on the side keep me from thinking it's an empty box that belongs in the trash.

The connector cutouts at the end of the old cardboard box.
Here are the cutouts at the end of the box to let me get at the connectors on the STK-500.

My old STK-500 inside its box with the lid open.
The STK-500 inside the box.

I have to open up the box to turn the STK-500 on and off, but that hasn't been a problem. It usually only happens a couple of times a session.

When I got two new STK-500s recently, I originally figured I'd do the same thing with them. When I went looking for boxes, though, I couldn't find anything of the correct size. I haven't bought any hard disks this large for long enough that I've either used or thrown out the boxes of this size.

A trip to the local thrift store turned up a travelling backgammon game set that was just the right size. The plastic moldings for the game pieces and the metallic game boards came out easily. If the STK-500 had fit in alongside the game piece holders I probably would have left them as storage space for cables, but they were a bit too wide.

The new STK-500 case with one of the backgammon board pieces that was originally in it.
The case started life as a backgammon set.

The adhesive on the vinyl covering was pretty dried out, so it wasn't hard to pull it up and away from the wood underneath. I set the STK-500 inside and marked the power and RS-232 connector locations on the wood with a pencil. A couple of sessions with a Dremel milling bit and test-fits later, I had the connector cutouts where I wanted them in the wood. The next step was fitting the vinyl to the new shape of the wood.

The new case with connector cutouts.
The connector cutouts.

I started by cutting the vinyl for the big cutout first, with yielded a sizable scrap of left over vinyl to use to cover up gaps and mistakes elsewhere. To attach the vinyl back to the box, I used the tail end of a can of spray-on contact cement that was sitting on the shelf going to waste. Brush-on contact cement would have worked just as well. I cut and folded the vinyl pretty much the same way as I would gift wrap around the wood. The results aren't perfect, but they're good enough for someone who's looking for something more classy than a cardboard box.

A closer look at the end of the new case.
The business end of the case. If I plug cables into the connectors I can cover up any flaws in my work before the guests arrive.

To support the board inside the case, I used some self-adhesive closed-cell weatherstripping. The closed-cell variety is stiff enough to hold the board and to hold its shape. I used 3/8" weather strip, two layers high. There are strips on both sides of the board to hold it in place, and a strip across the other side to hold it up against the side with the cutouts. The strips only need to be one layer high to hold the board. However, I want to be able to store jumper cables in the box without having them rattle around across the board when I move the box. So I stacked sections of weather strip on both the base and the lid of the box to fully enclose the board inside the box when the box is closed. The standard STK-500 jumper cables fit nicely in the extra space along one side and the end of the box.

The STK-500 held and enclosed by closed cell foam strips with space for jumper cables outside the strips.
The board safely held by the foam strips, with extra jumper cables stored safely along the sides.

Now I'm going to have to hit some more thrift stores. I've still got one more board to house, and I think my old one will get jealous if I don't find it a nicer home, too.

The finished case.
The finished case. Too stylish for the laboratory?

Saturday, November 1, 2008

Class Web Projects

My high school class wrapped up their team web projects last Thursday, we'll be doing a postmortem on them in class next Tuesday. A few of my students had prior experience with HTML, but not much. These pages represent about 8-9 hours of class time of work in development by newbies.

We had about 3 hours of instruction in the most basic HTML and CSS prior to the start of these projects. I've learned it's better to keep the structured instruction to a minimum. Then we split the class into 3 teams, I gave them some working parameters, and off we went. I was kept busy answering questions and pointing people in the right direction. I also needed to make sure all the class members stayed engaged, that nobody sat back and let their team members do the work.

The biggest problem for the class was the requirement I placed that they only use material in ways that was appropriate for the intellectual property rights granted. They wanted so badly to just grab images off of a Google image search and post it on their page. They also wanted to scrape images off other websites--it's not a usage violation if they're not copying it, right? Wrong. I insisted that they demonstrate to me that all materials on their site be within their rights to use, with severe grade implications for inappropriate usage.

Finally I provided them with some links to sites with content they could use--free image sites, stuff they could use for noncommercial purposes, and so on. They didn't seem to have much luck finding it on their own, particularly since they seemed to be unable to tear themselves away from groaning over all the stuff they couldn't use in Google image search results...

Friday, October 31, 2008

Atmel STK-500 Starter Kit for AVR: Now with Death-bots

I've been programming the Atmel AVR microcontrollers for some time, I got started with the old AT90S1200 a long time ago, and I've been enjoying programming them ever since. Shortly after I started using them, new chips came out that I couldn't program with my Xeltek SuperPro/L programmer. So I picked up an STK-500 starter kit to use as a programmer and for light prototyping of AVR circuits.

My old STK-500 has gotten quite a workout. I've used it with a lot of different AVRs and built a bunch of other prototyping hardware around it. Unfortunately, I usually have more than one project going at a time and often I'd like to use the STK-500 for more than one. It's also a pain to change the configuration of the board to and from some chips, like the ATTiny26, one of my favorites.

When I ordered some of a new model of AVR the other day (ATTiny13A, a big upgrade from another of my favorites, the ATTiny12), I decided to pick up two more STK-500s (I wish I'd decided to get them back when they were only $50, but oh well.)

The STK-500 itself is pretty much the same, except that it's lost the serial memory IC that they had on-board (which I never use.) But the packaging has changed significantly:

STK-500, Now with spear-throwing cybernetic Odin kill-bot.

STK-500 boxes. Old on right, bigger new box on the left.

The old box is nice enough. It's got that "Wonders of Science" look to the art that reminds you of the stuff they tried to dress up at school to make it seem interesting when in fact it was a drab treatment of something that could have been interesting before the educational system sucked all the life out of it.

The new box is something else again. When I got it, I wondered if the increased size and the new art meant something. Like maybe a spear-throwing one-eyed Odin kill-bot inside? With cyborg Hugin and Munin?

Unfortunately, no. If I want an AVR-powered kill-bot I'll still have to build it myself. The increased size of the box just provides more room for the STK and its cables inside. The preprogrammed board demo still just uses switches to make an ATMega8515 flash LEDs. No Doom-Spears or all-seeing crows to report back to you what you've been missing in the neighbor's yard.

I was a little disappointed that they didn't throw in an extra IC this time. My first set included a sample ATMega163 as well as the AT90S8515 that ran the demo program. It also had a hardcopy parametric list of AVR devices that were available at the time. The set still includes a fairly current CD with software and family data on it, but no additional chip samples. A free ATMega644P would have been really nice. ;)

Still, I got the main thing I wanted. New STK-500s. Now I can work on three things at once without having one project wait on another to finish. And I've got cool pictures of a Norse microcontroller robo-dude. I think I'll take one into my classroom to hang up on the wall.

Edit: One thing the new STK500 comes with that the old one didn't is a handy little JTAG adapter. That's got more long term utility than a hardcopy user's guide, I guess, but I still miss getting the guide with its listing of the LED blinker demo program in the back.

Wednesday, October 22, 2008

New Bookshelves for the Computer Room

I went shopping for a couple of bookcases for my computer/electronics room this week. I wanted a pair of sturdy six foot tall shelves to replace some four foot stacks of cardboard boxes along one wall. I wanted to pay about $100 per shelf, but was prepared to pay up to $140 apiece for decent shelves. My requirements included a depth of no more than 14 inches if possible with a hard limit of 16 inches to avoid cutting into a walkway, sturdy construction and a reasonably professional appearance. If at all possible I wanted something on feet to allow vacuuming underneath and behind, and 2 or 3 drawers in the bottom would be awfully nice.

Sturdy is important to me. I'm a practiced abuser of bookcases, with more than a few exploded cases and collapsed shelves to my credit (so to speak.) I'm a packrat of data books, journals on glossy stock, and I top-stack and double stack when unsupervised. I try to fight the worst of these habits, if nothing else because they work against my using my books.

When I looked in at our local oak furniture store I found that seven-foot shelves of the sort I bought for our living room last year had jumped over $100 in price. The six footers that came closest to what I wanted were priced at $210 apiece. Even if the store had been willing to dicker, the shelves sat with the bottom shelf on the floor so they weren't really what I wanted even if we could get closer to my price.

I then stopped at our only other dedicated furniture store in the area. It's a nice, friendly discount place in a sort of quonset hut warehouse. Most of their stock is in living room furniture--over half the floorspace is covered with sofas--but they carry a few nice pieces of office furniture so figured I'd give them a look.

Unfortunately, all they had was either cases like those at the oak store (in a wider range of finishes), and large deep heavy pieces like display cabinets for living rooms. The prices on the straight bookcases were the same as at the oak store.

I walked out sarting to assemble a list of lumber, fasteners, and finishes to buy at the hardware store. I really didn't want to make my own, especially when I considered how much time it'd take away from other current work. But I sure wasn't going to pay double for something that wasn't even what I wanted.

More to kill time while I thought than with any expectation of finding something, I stopped in at our nearest Target store. I figured I could think through my budget again, and plan out where else I might go looking further afield. When I got to the furniture section I saw a couple of different shelves along the lines of what I was looking for. One was at the top end of my planned price range, the other on sale at my preferred price. Neither had drawers in the bottom, but otherwise they met my requirements and desires.

I ended up getting a pair of the cheaper ones. Six foot "honey" colored (sort of a maple finish) bookcases. Unlike the ones from the furniture stores they're assemble-yourself, but that's better than design-and-fabricate-yourself as far as time and effort is concerned.

They went together easily, about ninety minutes each. The stain job isn't perfect, but it's good enough for working furniture. Good enough that I didn't bother touching it up. There's a fixed shelf in the middle that adds a lot of strength and stability, I'd have a hard time exploding these. Also, the carcase--the structural parts of the case--is made of hardwood, not pressboard. This makes the case stronger, lighter, and more dimensionally stable.

The shelves are pressboard, but they're reinforced with hardwood to prevent warping and sagging.

Assembly was easy, even easier because I didnt follow the order given in the instructions. I installed the lintel ornament before putting on the top, and the top before the back panels. In both cases I had better light and access to the work than if I'd followed the given order.

The shelves also came with restraint cables to attach them to the wall. I didn't realize this. So I stopped at the hardware store and bought two kits on the way home from Target. Oh, well. I've got one other shelf at home that I'd like to change out the restraint on, then I'll take the other kit back.

The bookcases are in place and loaded up. They look great and they're proving to be as strong as I hoped. They'll also save me from worrying about cardboard box collapses this winter, and let me focus on my various electronic projects.

Monday, September 29, 2008

Trying Out Free OSes & Giving Back

My high school computer class got a start trying out free OSes on the school's computer systems about two weeks ago. I brought in a stack of CDs and DVDs with free OSes on them like Linux, FreeBSD and OpenSolaris. I passed them out to teams of two or three students apiece and had them start testing them on our different systems.

Almost none of the students had never booted an operating system other than the one a computer came with. Few of them had ever worked on an OS other than Windows, except perhaps for a short session with Mac OS on one of the Macs we have in the lab. Likewise, almost none of them had ever interacted with the system BIOS.

This activity was a success on so many different levels:
  • We had a lot of fun. The classroom was in a state of productive chaos throughout.
  • The distinction between hardware and software was demonstrated. That is, that there is a division between the operating system and the hardware it runs on.
  • Students were able to see and interact with new operating systems.
  • Students discovered that a different operating system was not so alien. They were able to find the applications they wanted and do at least basic tasks.
  • Things don't always work, and that's OK. There are ways of dealing with it.
  • You don't have to rely on any one OS. If one isn't working out for you, try another.
  • Different OSes and different applications give you lots of options for doing things your way.
As a conclusion to the activity, we took the next step--giving back to the community. To start with, we discussed how all these OSes came to be, and why they are free. We reviewed the history of Linux and BSD in particular. How large things have happened as a result of the contributions of many, many people, each giving what they can, from detailed bug reports to programming. Then I let them know that they could make a contribution to the community by reporting their test results.

I had the class post their final results on the Linux Compatibility Database.

Afterward, I did a quick informal survey. About 80% of the class is interested in trying out some of our new OSes on their home systems to use as an alternative to what they have now. The holdouts are apparently not sure what their parents would think. We're going to have a future activity where we duplicate some disks for use in class and for the students to take home.

This activity turned out really well. It accomplished my goals for the class admirably. I wanted to give the students something in the way of a hands-on activity that would really make them feel a sense of control over the computer systems, and break through any remaining shyness. I also wanted to instill a sense of confidence beyond that, confidence that they can handle new programs and ways of doing things. Even experienced users have shown some resistance to trying something new to them at times. Further, I wanted to broaden their horizons a bit.

We've achieved all these things, and the fun that came with the activity has left the class hungry for more. It's a great base from which to continue our learning.

Tuesday, September 16, 2008

Trying Out Free OSes

As a class activity I had my high school students try out several different free operating system distributions on the school's different computers in the lab. I brought seven different Live CDs, and we have five different computer types in the lab. I had the class break up into teams of two or three and go round-robin to the different types of systems and test each OS.

The computers we have include two desktop PCs, one a Dell, the other a generic PC (perhaps assembled by our tech, I'm not sure.) We have some Fujitsu laptops for student use, and two models of iMac. I didn't pull all the system stats today, I'll do that next class on Thursday for when I publish the completed test results.

The partial test results can be found here. This document will be updated with further results as we get them.

Today we tried out iLoog 8.02, Edubuntu 7.10 (the last Edubuntu on a LiveCD--it still frosts me that it takes a second disk under 8.x), Belenix 0.7, Ubuntu 8.04, and OpenSolaris 2008.05. If time permits, we can also test Sabayon 3.4e and Mandriva 2008 Spring. These are on DVD, and only about half the lab's systems can read DVDs, so that limits their value to us.

This turned out to be a good class activity for all the students at different skill levels. Some of the students had no experience trying to boot to some operating system other than one preinstalled on the computer. For them, we got to learn about modifying BIOS settings to change the boot priority on the drives on PCs, and using the Option key to select a boot device on the Macs. I'm sure I'll have to review this during out lecture period in our next class to make sure it sticks.

For others, it was good for them to get a chance to try to boot an OS with no idea of what results they were going to get. Getting to see failures during boot and having a sense of what was going on, why the boot failed, and learning when to give up was informative for them.

I tried to hand out OS disks to the teams based on my assessment of their skill level. I gave the OSes I expected to be more compatible and to have the least problems to those teams that were probably less skilled. This turned out to work well for a couple of the teams, but it didn't matter much otherwise. As it turned out, the skill levels had a greater effect on the speed at which a team could try out an OS and move from system to system than it did on how they could deal with the compatibility problems. Just about all teams needed the same level of oversight. Only one team got caught up in games enough to need a comment.

This testing was not only educational for the students, in some cases giving them their first exposure to an OS other than Windows, it was also very helpful for me. Once we do some more testing I'll be able to see which OSes I should duplicate to use with my middle school class on the basis of what works where, and what apps are installed. For that class, it would be nice to have one OS that works on all lab systems, but splitting between two different ones with the same apps would work, as well.

I'll also be offering copies of the disks to students when we complete this activity. In fact, I'll probably make an activity of copying the disks on those systems that can do so. Then the students can try the same thing on their home systems.

Tuesday, September 9, 2008

Reliable Website? Ask the Conscious Burritos

Today I had my high school class do a second assignment on finding reliable information on the web. I used part of the excellent ICYouSee: T is for Thinking guide to critical thinking about what's on the web.

Specifically, I had the students group in pairs then go out to look at sites on the Mayan Calendar and The Sixties. The selection of sites given is excellent. They cover the range of reliability well, and different sites draw in different students. The result was that no two teams did full evaluations on the same sites, but there was enough overlap to make things interesting.

While I asked the students to evaluate how reliable the information was on the websites they chose for deeper evaluation, I did little to define reliability for them beforehand. We had one prior exercise in web research during which I covered the idea. In the course of the class I had the question raised, as one group struggled with the distinction between honest but misinformed and reliable.

This triggered a short conversation about the distinction between belief and demonstrable, or at least supportable, truths.

When the groups finished their evaluations we did round robin reports of our findings.

The link to Conscious Burritos on the Dreamspell site pretty well sealed that site's degree of authority with the class.

The evaluations opened up a number of conversations about reasonable measures of authority. We agreed that the appearance of a website definitely affects the perception of its authority. If, for example, a science website has images of little pink ponies dancing across the screen it'll be hard to take seriously, even if it's written by an authority in the field with excellent supporting links. On the other hand, sites that have a spartan design say less in a direct fashion about reliability one way or the other.

The subject of quantity arose, as well. One of the student groups felt that the volume of data on a site added to its authority. In another case, a large volume of information on a wide variety of loosely related subjects was felt to detract from the site's reliability. After I provided some possible counter-examples in each case, it seems like the class pretty well agreed that volume of content had no direct bearing on the reliability of information on the website. However, in each case I think the students were expressing feelings concerning the approach to organization of the website, and how that reflected the thinking of the creators.

We also had a discussion about supporting material. We talked about sites that link to like-minded sites while ignoring divergent points of view, as well a the idea of "sock-puppets" and other techniques for creating a false appearance of supporting data. We also discussed potential conflicts of interest and how these might color the information that people post on the web, as well as the fact that a single conflict of this sort may affect a large number of people, having a similar effect on them, creating what appears to be a large body of consensus, when actually we're seeing a small community that's heavily cross-linked.

I saw more lights going on in people's heads today than after our prior exercise. It turned out really well, and the feedback I've gotten from the students so far has been positive. Time constraints kept us from covering things as well as I would have liked. For example, I would have liked to have the class study some websites with very authoritative appearances and find the "gotchas" that undermine their reliability as sources of information.

I may yet do this in a future class. The number of sites on subjects such as health and ethics that maintain a very authoritative appearance while having a decided slant and underlying purpose are many, and I would like to give my students an introduction into applying their critical facilities to these sites.

Wednesday, August 27, 2008

Ubuntu Works!

Classes start next week. Between meetings today I had time to slip into the computer lab and spin up the Ubuntu Live CD for Hardy Heron. It works great with the PCs in the school's lab. Networking works fine, video is good, apps run, and so on.

I'm really pleased about this, even if it's not an Edubuntu Live CD as I've mentioned elsewhere. I'll be able to use this disk in class even if it doesn't include some of the Edubuntu apps I'd like to have. I'm not in a position to intall Ubuntu so that I can apply the Edubuntu stuff to it. I need everything on one Live CD.

In addition, I may download the older v.7 distro of Edubuntu Live CD image to get the Edubuntu apps. After all, that's what I was told I was getting when I ordered the CD. The upgrade to Hardy Heron where Edubuntu no longer fits on the same CD as the core Ubuntu is what I got. The fact that Hardy Heron works fine on the school's hardware means that it's reasonable to hope the prior version will do the same (we're not talking cutting edge hardware here.)

I was hoping to spin up some other free OS Live CDs, but my time went into making a copy of Ubuntu for a former student who happened to be in the school center instead. She has a computer at home that's a close cousin to our lab PCs that has some problems that a switch to Linux might fix.

The joy of free software. All I had to do is pull out a blank CD and make a copy for her. No fuss, no muss, no shrink-wrap licenses or fees.

And knowing that I've got at least one Live CD that just ups and runs on the school's computers feels really good.

Saturday, August 23, 2008

Four Things I Would Like My Students to Get

It's the start of a new school year. Every year it's very exciting to look forward to the new classes and plan where we'll be going between now and next summer. Not only am I planning out the classes I teach, but I'm working with my daughters on putting the final touches on their plans, and my oldest is preparing to apply to universities for next fall.

This year I'm teaching computer classes at the high school and middle school levels, as well as a cartooning class. The computer classes are elective classes with no specific requirements, which is nice since it means I can do a lot of things with these classes without being bound by the restrictions of an established curriculum. This also means more planning and work for me than if we were just going front to back through a text, but I'd much rather have it this way.

The cartooning class seems like a frivolous class, but I use the fun aspect of it as a hook for the students to make it into more of a class in communication. Alongside lessons on drawing characters I teach the plot skeleton, storytelling techniques, and so on.

No matter what the subject, there are four things I would like my students to get from my class:
  • Confidence
  • Ability
  • Results
  • Patience
Let's look at these from the perspective of my computer classes.

I want them to develop the confidence to use the computer as a personal tool for self-expression and communication. I want that confidence to lead them to try new things, and feel that they can teach themselves new things. I want them to perceive the computer as a medium for their use, not as an antagonist.

I want them to have some basic ability to use the computer, some actual knowledge upon which to base their confidence. The specific abilities will vary by the student's age, and by the individual. But they should actually be able to use the facilities of the computer to produce something they've thought of, and to extend their abilities beyond what we're able to cover in class.

They should have some tangible results from their effort. Some finished pieces of work, in whatever form, to demonstrate to themselves and others the abilities they've developed. The products of their work should be impressive within a limited scope of effort, rather than incomplete overambitious efforts. They should be the result of a complete "life cycle" of producing a work, from concept to completion, including the incorporation of some incremental improvement.

Possibly one of the toughest things to give a student is the patience to stick with something. My experience is that having some prior results is one of the best ways to get there. Once they've got something to show that they have an ability, they can come back and apply that ability again on something more ambitious. With the knowledge they've developed of the process of producing something, it's easier for them to commit themselves more fully to their work.

Without something tangible to give them a sense that their time is well spent, they won't have the patience to deal with niggling syntax rules, strange vocabulary, and unfamiliar concepts. So there needs to be an early payoff. This can then be followed by further demands on their time and attention.

Thus, patience is developed. At some point the cross-over is made to the student seeking more knowledge and involvement on their own. When they're working for themselves on a project of personal interest patience becomes practically limitless. They enter the joyful iterative cycle of improvement, both for themselves and their programs, so well known to so many programmers.

Tuesday, August 19, 2008

Busy, Busy, Busy

Preparing for the start of school has had me busy lately, as has a personal project.

I've just about finished a rebuild of my class site, the new version should be posted within the next two days (as I write this the new version exists only on my local disk.) I'm also preparing the early handouts and organizing my class notes.

Also, my daughters and I are making some telescope mirrors. We've just transitioned from polishing to figuring. So a lot of my spare time has been spent hanging over a Foucault tester looking at shadows.

So the blog is neither dead nor forgotten, just off to one side for a bit. Stay tuned!

Monday, August 11, 2008

Increase Your Depth as a Programmer by Spelunking

Once upon a time I had a sort of game I used to play. It was fostered in part by "downtime" at work, where I had nothing to do immediately, but I couldn't look idle, either. I called it "spelunking." I'd dig into the computer systems that I had access to, trying to find everything on the system that I didn't already know or know about and learn what it was and how to use it.

Unix systems were particularly fun in this regard. I found games I didn't know, and learned how to use utilities that were already on the system that my coworkers were often not even aware were there. I saved my employers a fair amount of money several times by letting them know they already owned the solution to some problem.

Up until the mid 1990s I knew what every program was on several commercial Unix base installations. Then it got beyond me, but I still kept at the game. Now a lot of the game is seeing how many of the old, still useful, tools are still there. The fact that a basic C compiler is typically not part of a normal install of Unix any more bugs me. In my mind it makes as much sense as shipping it without a shell. Nevertheless...

I've also done the same thing with languages. Find some library, some function, some use of a function (or method) that I haven't used before. Then I try to do something useful with it in a program, or apply it to a problem that I've solved in some other way before.

I'll usually start with a specification to find something, but then I'll move to my books. What I often find is that the coverage is awfully homogeneous. I usually find a bit more diversity online in the coverage of any specific item, but often the items covered are fewer than those that appear in books or the original documentation. Sometimes it's clear what sort of problems a feature is meant to solve, other times it's less obvious.

This doesn't usually result in any big revelations or new ways to rework my current project. Occasionally it solves a problem that comes along some time later. More frequently, it gives me a better understanding of the parts of the language I'm already using. I get a better idea of why things are done the way they are, or of ways to divide a coding problem differently to make more effective use of the language.

I'd say spelunking through specifications is second only to reading other people's code as a means of improving my depth in a language. It gets me into things that aren't in my books or that I haven't turned up when looking up something I need to solve a specific problem.

Thursday, August 7, 2008

Mini-Review: Beginning to Program in Java for Dummies by Barry Burd

I've posted a mini-review of the book Beginning to Program in Java for Dummies on my Java beginners' blog A Beginning Programmer's Guide to Java.

Learn Another Language

There are a lot of computer languages out there. Each one has vocal adherents. They often sound like the folks who used to battle over whether the Commodore 64 was better than the Atari 800. The fact is that computer languages are created for a reason, they're created to solve a problem. Each one has its own features, and its own approach to dealing with specific problems that the implementors saw with existing languages.

Learning a computer language is an involved process. Learning modern object-oriented languages well enough to be well rounded in all their features is a time-consuming process. I'd say it takes two years to become competent, longer to become really good at solving any arbitrary problem with the language. With this kind of a time investment, why dilute your efforts by learning more than one language?

I took English classes all the way through elementary school. I got good at spelling, and developed a pretty good vocabulary. But most of the grammar went right over my head. In 7th grade I started taking a class in German. Suddenly all this stuff about subjects, objects, and indirect objects started to make sense. It was enough to make me wonder why I'd never gotten it before, it seemed so simple.

The same sort of revelation can occur when learning a new computer language. Concepts that were muddy before can suddenly be illuminated by the new language. This is especially true when learning a language that's been designed for an entirely different class of programs than your first language.

The "big" languages today are far more flexible and more generally applicable to a wide range of problems and programming approaches than the simpler languages of 30 years ago. This is part of why it takes longer to learn them thoroughly. They've adopted the good parts of many earlier languages, usually building on a base of a strong prior language. The result is that it can make each language look like it's the be-all and end-all of languages. They fill a lot of checkboxes, and even where they don't have a specific feature, they have some other fairly direct way to get the same results.

This doesn't mean they're all the same, however.

Why Spend the Time?

Still, there's only so much time and energy. With learning a language being such a substantial undertaking, why divert effort into a new language rather than delving deeper into the one you already know?

First, diversification is not only educational, it's a survival skill. Overcommitment to one language means that when the need to shift finally comes, it'll be that much harder to change one's thinking to adopt a new language effectively. Languages will change, new languages will appear that will overshadow current languages. Current languages aren't likely to go away--code tends to hang around--but new languages will dominate. Even if you still work with an older language, understanding newer languages and what they do will be valuable to you. Chances are your language will change and adapt, too. A prior understanding of the new concepts will make it that much easier to take advantage of these changes. Either way, you'll be a more valuable programmer.

And it will be easier to learn the new languages if you are already familiar with several. Those new languages are going to come from somewhere, and if you've already got a regular approach for picking up new languages, you'll just be applying it to yet another.

Educationally, there's more to learn by picking up new languages than the new syntax and programming constructs. Learning a new language often means learning to work in a new development environment, and possibly with a very different workflow. You'll have a chance to see what other programmers use, and see the advantages. Perhaps the same features are already there in the IDE you use with your own language, you've just never been motivated to try it out since you didn't perceive the advantage. Each different language tends to have a preferred set of tools for version control and project management, too. Even if you only ever program professionally in one language knowing more than one toolset for everything from editing to distribution is of tremendous value.

There's nothing worse than knowing the language that everyone is advertising for then get passed over for job after job because you don't have experience with the employer's environment.

If you're a lone wolf developer, or part of a small team, knowing more than one thing is even more important. It's essential to get as much productivity as possible out of the few work hours available. You can't afford to spend your time carrying water from the well in buckets, you've got to put in plumbing to be productive. If you don't get out of your groove and look around at what other languages and other toolsets have to offer, chances are you're carrying buckets and complaining about how there's no time to put down the buckets to learn plumbing.

Picking a Second Language

Choosing the language to learn is important, too. It shouldn't be over-thought, however. It's not like it's the last language you'll ever learn. You can also break off and change choices at any time, though it's best to stick with one long enough to get well enough in to understand why it does things the way it does.

For your new language, you may want to pick a second language close to the one you already know. This can be both good and bad. It can introduce you to some new things without requiring as much of a change of pace as a totally unrelated language. The problem is that you're not getting as far out of your groove as you would with something else, and the syntaxes of two similar languages might just get jumbled in your head making it even harder to use your primary language.

Picking a language that's out of left field for you will require more effort to learn and understand, but it avoids the problems of picking a closely related language.

One way to diversify is to select a language that's of a different scope than your current language. If you're programming in one of the more "full-up" languages OO like C++ or Java, you may want to pick up one of the "scripting" languages like python or ruby. Or you can take a step even lower to the actual scripting languages like one of the Unix shell languages (ksh, bash, csh, etc.) If you already know one of the simpler languages (whether simpler in features or in syntax--I don't mean any of these comparisons as value judgements) you should probably give a try to something more involved.

There's also diversification in terms of language type. This relates to the approach the language takes to solving problems, and the mindset used with the language. If you know a procedural language, try a functional programming language, perhaps. If you're not doing object oriented programming, try one of the OO languages--particularly one of the OO scripting languages.

If you want to limit your efforts, there are a lot of languages that you can learn without too much effort--at least well enough to get a feel for the language's approach. Clearly the syntax-light "scripting" languages fulfill this requirement. But other languages, such as LISP and LOGO are also very easy to learn, and they're often well off track for most programmers relative to their usual language, making them a great learning experience. I know that LISP and its related languages are going through a bit of a vogue right now, my recommendation has nothing to do with that. I've been recommending LISP since I first learned it in a single quarter's class in 1981. And though LOGO is often considered a "kid's language," I personally consider it more of a LISP with a lot of the historical cruft taken out. Either way, the current vogue of LISP-y languages is a good thing. It means there are many good, modern implementations and tool sets for them.

Forth is also easy to learn, and playing with its guts is both fun and educational. You don't necessarily have to join the religion. ;)

Assembly programming is not as straightforward as it once was, interactions with modern OSes make it more involved. However, learning assembly using a virtual machine of some sort, solves this problem. There are free, downloadable development and simulation environments for many microcontrollers. This can be a good way to get started with assembly.

If you only know one language, get out and learn another. It'll be fun, it will stretch your brain a bit, and it'll make you a better programmer, even in your first language.

Monday, August 4, 2008

The Anti-Java Professor: Still Off-Base

When we first heard from "the Anti-Java Professor" it created quite a stir. This made it inevitable that we'd hear from him again.

I disagreed with his points earlier, and I disagree with his points and his reasons now. I think I stand in a pretty good position to do so. As an instructor, I'm not in a position comparable to his, I'm just a part-time high and middle school instructor. Otherwise, however, I am an aerospace engineer. My work covers a wide range of systems for aircraft, launch vehicles, satellites and probes. I've done design work for nuclear systems and man-rated systems. I've been doing safety-critical design work for about 28 years now. My work includes mechanical, electronic, and software design--usually more than one at a time on any given project.

So let's take a look at what the "Anti-Java Professor," Dr. Robert Dewar, is saying this time around.

On a high level, the presentation suggests that universities are turning out what are in essence incompetent script-kiddies by using Java in the core curriculum classes for Computer Science. The claimed cause is all those libraries that Java has, insulating the student from "real" programming.

He states that Java programmers aren't employable because their function is too easily outsourced. Without the ability to create "complex systems" their skills aren't up to snuff. His concept of what makes for a "complex system" seems to be circumscribed by an aerospace/defense mindset, as he says that Java does not appear in complex systems, only in "trivial" applications, using the example of code used in aircraft as the place that Java doesn't appear. C and Ada are called out as being the "suitable" languages.

I've been around long enough to remember when C was the latest hazard to our aircrafts' software. I remember when our poor students were being under served by that poor language, Pascal. When the only thing you found in "real" applications was languages like JOVIAL, PL/I, machine and assembly language. The fuss he makes about Java sounds like the fuss over barbed wire to me. That awful, poorly structured, type-unsafe language C was the end of the world to some. You didn't find it in aircraft, 25 years ago. It had all these library functions--how could the programmer know what lurked inside them? How could you validate code written on top of them?

Well, it's been managed. There are compilers and libraries for C that are validated and well documented. Now there's C code flying.

Does that make C a better language? No. There are plenty of other uses for C, from writing entertainment software to system code, that don't require the same level of code validation as an aircraft's instrumentation, communication, and control systems. C came to aircraft because it was an effective language to code in and for writing maintainable code, and because there was a huge base of labor to draw on.

Java has those advantages, too. Maybe it's time to get a JVM validated for use with safety-critical code? That's all it would take to get Java in the air. In fact, it would seem to me that a validated runtime environment like a JVM with the appropriate low level reliability features could be a safer software environment than one based on C, or even ADA. In most systems that have the space and processing time available (which is many now) a base environment with applications running on top of it is typical. In some cases this is a high reliability RTOS, in others it's a specially-written core system. There's no reason it couldn't just as well be a hi-rel JVM.

There's also the matter of limiting one's perception of "complex systems" to aircraft code. Distributed database systems and transaction processing systems don't count as "complex"? Why, because the programmers don't necessarily have to code every algorithm from scratch? Java has been most successful on the server, in some cases acting as a translation layer between an underlying application and the web presentation (what I'm presuming Dr. Dewar considers "trivial"), in other cases it is far more than that. Enough to be called "complex" in my book. Does anyone die when this code goes down? Not necessarily, but that's not a measure of complexity.

Does Java make programmers incompetent?

Dr. Dewar claims so. He lists some questions he'd use to screen applicants. What's interesting about these questions to me is that I think the average BSCS grad would have had just as much trouble with these questions 30 years ago as they would today. I also consider these questions to be just as narrowly focused as his view of complex systems. Paraphrased, the questions are:

How would you find an error caused by improper compilation by the compiler?

How would you identify and deal with a bug in your processor's implementation?

For as long as I can remember, the undergrad CS program has only required two classes that even address these areas. One class in hardware, one in assembly language. Both are brief introductions to their subject. There isn't time in a one-quarter or one-semester class to get beyond this, particularly when it's first exposure for the majority of students. Operating systems classes are no longer about system level code, and haven't been for a long time. There's far more to talk about in an operating systems class than implementation of program loaders and I/O drivers these days.

The first question could be covered to some degree through the use of a plain debugger. I think the solution he'd look for would be to go a step further, and look at the object code. Usually a student will have gone through these steps at some point in their education, but they aren't, and haven't been, something that is routinely performed in most programming classes at the undergraduate level, no matter what language is used.

Hardware classes at the undergraduate level spend a lot of time on flip flops and gates. The better ones talk about processor and system architectures. Identifying bugs in silicon is usually well out of scope.

There's also this thing called the "internet." Seldom do we have to be pioneers when it comes to using compilers and processors any more. Before, there were long delays in information transfer. Likewise, if you're writing code for aircraft, you're not going to be an early adopter. Looking up known issues is likely to be a far more useful skill than finding them yourself the hard way. And if you're coding for ASICs, well, expect some OJT and experience between the time they hand you your sheepskin and the time you lay hands on code.

When I went through college, we did have some undergraduates who knew this stuff. Not one of them learned it in school. When you came into any class, you could quickly pick out the enthusiasts who made a hobby of computers and electronics. And this group mostly didn't wait until they had a degree to go out and get a job using what they knew.

There are study programs that encourage a lot of hands-on work. And that get students out into internships in a real working environment. These are great, but a student can do the same thing on their own as well. By the time I went to college I had held a job as a programmer, a job as an electronic technician, and had run my own company selling electronic and computer systems of my own design. In the case of universities and colleges, my own feeling is that waiting for a "senior project" to do practical work is waiting too long. The problem is that the curriculum is so filled with classes of low value that it prevents a student from both getting a good GPA and holding down a job relevant to their major. It's possible, but it's a good way to burn out a promising programmer, too. Unfortunately, accreditation boards don't seem to reward institutions for getting students into real work, but they seem to support lots of non-major classes.

An attack on the Java programming language as the source of the job market's ills is misplaced at best. Java isn't the problem. It doesn't make headlines to say that the problem is the same as it always has been: non-major requirements for degrees prevent any depth in a four-year program. The other half of this is a problem that's really no problem at all: Only a fraction of in-major graduates are ever going to be drawn to work that goes beyond creating applications, mash-ups, or other high level code. This is both because of personal preferences and because of the market itself.

The place where a tragedy occurs here is when a student goes through a program, gets a degree, and thinks that makes them prepared for any programming job. The answer to this is the same as it always has been. Students need to get their heads out of the school zone. They need to stop relying on the university as a primary source of education. The resources for self-education are better than they have ever been before. The opportunities for doing real work with either hardware or software outside of school are the best they've ever been. Either as a hobby or in an entry-level job.

This is where the real education happens. It also makes the university education more valuable. Students come prepared to learn, and with a desire to learn, when they already have some background. They get the full advantage of the broadening aspects of college. They can interact with their professors at a much higher level, because they aren't having to learn the language first and have at least a general grasp of the basics. The elements that fit into theoretical frameworks are familiar to them--they aren't memorizing them by rote and hoping that it'll all make sense somewhere down the road.

Among the solutions Dr. Dewar calls for to the problem of unprepared programmers is one on one mentoring. This isn't realistically available for most undergraduates. At least not in school. It is available to interns, however. It's also available to hobbyists who are able to find a group of fellow enthusiasts.

One of the biggest lessons I've learned in my many years of working, interviewing, and managing projects is that specific technical skills are far less important than outlook and character. Technical skills are the easiest skills to teach. They're also the skills that must be updated and replaced regularly.

Actual on the job work that's going to be handed to a new hire is typically going to be work that already has an established procedure. That means it's going to be relatively easy to teach, and that the situations that arise in the performance of that work are pretty well known. That includes the identification of compiler and hardware bugs. What becomes of paramount importance is the team itself and its willingness to share information, and the character of the new worker and their willingness to partake of the information and shared lore of the rest of the group.

This isn't to say that one would want to hire someone to program C or assembly who doesn't have any relevant experience. But it also doesn't mean that using Java makes them a bad candidate.

It may be time consuming to interview candidates, but turning away candidates is an educational process. If candidates are turned away without getting a sense of where they failed in the interview, then it is just a waste. But if they come away knowing that they couldn't answer a battery of questions on handling registers in C, then they have information they can act on.

They may come away with the knowledge that the job was not for them. Or they can buck up, go home, and download a C compiler and some resources, and get cracking. They may end up delivering pizzas for a few weeks, but chances are that'll give them even more incentive to press on with their own studies. In less than a semester, they can acquire the skills to manipulate registers in C, debug object code, and familiarize themselves with the practices of writing hi-rel code. No matter what language they studied in school.

If a student comes out of a university not knowing how to expand their education in this way, then the university has done them a far greater disservice than the use of any language you care to name.

Debating over Java's use in education is a sure headline-grabber these days. It's a cheap and easy ploy, and its intellectually dishonest. Java is not the problem, any more than Pascal was when it replaced Fortran, or C was when it replaced Pascal in the educational curriculum. In each case the universities were making the change to serve their students.

The problem is the wall between education and reality. Some institutions do a lot to get past this, but not many, and even that's no guarantee that a student is going to get any advantage. If students are using Java to write "trivial" web apps, then at least they are on the web. They're getting far more exposure to reality than any student who spent the same time writing a bubble-sort in Fortran, or Pascal, or C. For them the ideas of networking, clients, and servers are like air; it's just there. They start with a lot of knowledge they don't even realize they know. Sure, they can't debug a bad instruction in a processor, but how many CS graduates of the past 30 years could? The ones with an EE minor, maybe.

And if you want to limit your time on interview, put a section in the application for hobbies and magazines read. If you don't see something like electronics, robotics, or microcontrollers in the hobbies or something like Circuit Cellar Ink, Embedded Development, or other trade journals in the magazines they probably shouldn't be on your 'A' list if you want someone who can debug assembly and processors.

I've updated this article to use the proper form of address for Dr. Dewar. At the time I wrote this article I failed to find a reference for this. Since then a reader, "aquerman" has provided me with the appropriate information. No disrespect toward Dr. Dewar was intended through the failure to use his proper title earlier, regardless of our divergent views on the role of Java with respect to programmer incompetence.

Friday, August 1, 2008

Class Objective: Going from Consumer to Creator

Teaching a computer class in high school is a lot like teaching a class in the fine arts. You want to teach the students to express themselves. You provide them with basic information on tools and techniques. Most of all, you try to help them overcome the mental barriers that keep them from believing that they can produce something worthwhile.

These barriers are many. Just like a student who hesitates to pick up a brush because they "know" they can't paint well, the computer student will resist trying their hand at some skill. The resistance takes a different form, usually, than refusing to try. Computers are the perfect tool for passive-aggressive behavior. There's always an obstacle for someone who doesn't want to try.

The problem starts long before students enter the class. Students are conditioned to believe that it's not safe for them to mess with the computer. They adopt a belief that the things they enjoy on the computer have been created by teams of professionals who are smarter than they. In some cases, they have an attitude that they can't be bothered to learn it since this will look like a crack in their "I already know it all" veneer.

The expectations of parents are often limited, too. For many, computer class is a typing class. Certainly it's a good place to get some time in on a keyboard, but typing is learned far better when there's a purpose driving the fingers on the keys. So treating the course as a mind-numbingly dull typing class would defeat that. Not to say there aren't students who like dull rote classes for an easy 'A' without engaging the brain.

Another problem is expectations that are too high. Some students want to write a full A-class computer game in a single semester. Interest wanes when they find out that that's not likely. They want to run before they can walk. Then the conviction that they can't do what the pros do comes in again.

The most effective attack on negative mental attitudes is to have exercises that result in visually stimulating results. The problem is that the range of skill levels coming into the class is so wide that some students may need to be told what "left-click" and "right-click" means, and they may be totally unfamiliar with the keyboard. Others may already be fast typists and fast readers.

My own way of dealing with this has been to have open-ended in-class exercises. There is a basic level of achievement that is expected. Beyond that, extra credit is given for creative effort beyond what's required. Multiple avenues for extension of the basic assignment are provided. Usually they all require some degree of research on the part of the student. This gives more advanced students an opportunity to use their time constructively while I assist others with bootstrapping themselves on the basics.

I also allow collaboration and sharing of information on class exercises. This removes me as an information bottleneck in class, and it gives the students a social incentive to research solutions to problems.

As to the types of problems, I start with creating a rich document in a word processor. It seems like a banal exercise, particularly when so many high school computer classes are nothing more than an introduction to horizontal applications. But rather than focusing on the use of the application itself, I focus on the product.

I don't assign a specific document to write. Rather, I work with the class to identify something that would be fun to write. Last year we came up with a specification for a computer video game. It could as well have been a guide to online art of a specific genre, or any of a number of other subjects that interest the students. I place requirements for what needs to be in the document on the basis of what would make a good document of that type, not on the basis of the mechanics of the programs we use to create its content.

As we progress from word processing to using basic basic tools for text editing, file management, system monitoring, and so on I use the same approach. With a goal in mind that interests the students, we can focus on that and learn the technical mechanics along the way.

The result is that the students get an opportunity to create something of their own, not just another copy of a document given as an assignment. They get to learn what they learn for a reason, not as an end in itself to fill grading checkboxes.

I allow the students to express themselves with their assignments. We keep things within the bounds of propriety, of course. At first they're tentative, but by the time we're doing web pages they've usually gotten to by outspoken. I don't grade them on what they say on their web pages, but on how they say it. What features of HTML have they applied, how does the page appear as a whole, and so on.

Then, after each unit in class I have a little surprise. I take some time to list for them all the technical skills they've acquired. All that stuff that goes on resumes or that gets listed as a class subject on the syllabus. The lists are long, and full of all sorts of scary polysyllabic words. We go through each scary word, and they learn that that scary word is something they know and can handle. We review their work, I comment on it, and their peers do, too.

They discover something. It's something we keep discovering it over and over in class. A message that bears repeating, over and over.

They can create.

Tuesday, July 29, 2008

Greenfoot: Further Examination

Greenfoot is a Java framework and IDE designed for introducing high school students to programming. Since I teach just such a course, it's of considerable interest to me. As I mentioned in an earlier article I have started trying it out. I have a pair of summer students who have been using it for the past 3 days, and I have been working with it myself.

I approached Greenfoot with some ambivalence. It looks like more than I could hope for, teaching OO concepts through graphics, allowing easy first-day programming, while teaching a real language and not heading the student into a dead end teaching language.

However, the concern that nagged me was whether Greenfoot was too "candy coated." Would students use it only at its lowest levels and not want to move from treating it as a game console to using it as a development system? Would there be a gap between the demo materials and further progress?

I've worked with several other systems in the past where this has been exactly the case. They do something very limited very well, then require a big jump in knowledge to advance that ends up taking more effort than learning without the system would have.

There's also the matter of how well any knowledge earned within an artificial system translates into skills outside the system. All too frequently students end up knowing the classroom system, but not able to translate that into something useful outside of class.

I work very hard to avoid this. There are a plethora of packaged systems that make the teacher's job easier, but do nothing for the students, or worse, waste their time and energy and leave them discouraged. I prefer using real world materials in class. There are seldom good classroom materials available for these, so it takes more work. Also, I have to be careful about the scope of what we do in class. It would be easy to overwhelm the students and end up doing as much harm as a poorly made pedagogical system.

But I would rather have a class of limited scope that teaches practical methods than one that just fills checkboxes.

Enter Greenfoot. It's made by the same folks who made BlueJ, an educational IDE that I really like a lot. Its mechanisms for interacting with classes, objects, and methods looks like a perfect solution for visually demonstrating these concepts in class. It provides a development framework that lets students jump right in on graphics programming. The developers have stated they want to make learning to program as fun and straightforward as it was in the days of BASIC. If I didn't know better, I'd think they got their specification by reading my mind.

Reality check. I've made mistakes before. I've gotten overenthusiastic about something, and missed obvious flaws. I've got a scar for every point I made about flawed pedagogical systems above. There are gaps between intention and result, between desire and ability. My own judgment is flawed. I'm an experienced programmer, and though I've developed an artificially-derived beginner's viewpoint as an experienced instructor, it's not an actual beginner's viewpoint.

That's where testing with real students comes in.

I've got two students, ages 13 and 16, who have spent three class sessions with Greenfoot now. I haven't been running things the way I would in a normal class. Rather, I've been seeing how much Greenfoot can do for them with the least involvement on my own part.

Both students had made a start in Java before I introduced them to Greenfoot. The younger one had done exercises from a textbook using a graphical editor and command line tools. She had also done some minor programs of her own design, but generally hadn't shown any inclination to develop her own programs even though she has expressed interest in becoming a professional programmer.

The older student has a familiarity with using command line tools, but prefers to work in a simple IDE, either BlueJ or Arachnophilia depending on what she's doing. She hasn't developed as extensive a knowledge of Java and programming, but she's done more with what she knows. She writes her own simple command line applications.

The differences are normal for different ages and dispositions.

Neither student really understood classes, objects, methods, and so on. The younger one has been introduced to them, the older one had heard of them but not studied them formally. In both cases I have been concentrating on getting them through the mechanics of programming to the point where they start having questions about larger issues before we really get deeply into OO. I mention OO concepts frequently as we go, but don't stress them. We use good OO practices right out of the gate, however.

I decided to interrupt our summer session to give Greenfoot a try. They've both been enthusiastic about it. Not only because it looks like getting class credit for playing games. They both have a real desire to write their own programs.

For our first session I let them play with Greenfoot after we watched a presentation on Greenfoot. That was as far as we had gotten as of my last post on Greenfoot. I was hopeful, but my doubts were still intact.

We've since had two more sessions, and I've had more opportunity to assess what the students have learned and get a better sense of where things are likely to go.

Both students started using Greenfoot as a sort of game system. Good enough. As a game system its simplicity invites the student to come up with their own ideas. My experience is that if you sit a student down with a Halo, Mario Carts, Zelda, or other A-grade games there's little or no desire to produce something of their own aside from a bit of daydreaming. If you set them down in front of a 1970s Pong, Pac-Man, or Space Invaders they start developing their own game ideas spontaneously. They'll grab some paper and start drawing out their ideas, or start developing involved game concepts verbally with their peers. What's interesting to me is that these concepts are not derivative ideas. They'll start with the concept of playfield and sprites and start developing ideas completely tangential to whatever games they've been exposed to.

Greenfoot possesses that same quality. Greenfoot's provided scenarios both in the original download and on the web provide the same jumping off point for creative thought as old video games. The integration of scenario downloads into Greenfoot's menus is an excellent little feature. The students don't have to leave Greenfoot to get new scenarios.

A few of the scenarios are somewhat frustrating to play as provided. At first, this can lead to frustration. It also provides an opportunity for the instructor to ask, "Why don't you change it to make it work better?"

The 16 year old began making code changes without prompting in the second session. The younger one showed some mild resistance to shifting gears from playing through the catalog of games to doing something more than changing images. Once over the hurdle, however, she did fine.

This set my mind at ease about whether Greenfoot would become a source of contention in class if I introduced it. If any student were going to turn sullen and resistant toward moving on to programming from pure play, this one would be the one. So, I think I'll be able to steer a full class into using Greenfoot as more than a video game system.

The older student's ideas soon outran her abilities, causing frustration. We reviewed the specific features she wanted to implement, and identified existing scenarios she could look at for examples. Now she has managed to implement some of her ideas, and the confidence she's gained is keeping her from getting frustrated while implementing others.

Once the younger student started modifying scenario logic, she came up with complicated ideas for reworking the ant simulation. She got hung up, then we talked. Now she is progressing with incremental changes of far less scope, and using what she learns to guide her ideas.

My doubts are beginning to be put to rest. I'm still concerned about taking things from within Greenfoot to outside of it. I'm in no hurry, but it's the next major hurdle I see. Meanwhile, I'll be using Greenfoot for more formal learning--teaching with flow control, iteration, and so on.

I'm also interested to see whether either of the students takes what we learn in Greenfoot back to their prior working environment on their own. The older student has a text game of her own she was working on, and it'll be interesting to see if she goes back to it with lessons from Greenfoot.

The students have a firmer idea of the relationships between classes, objects, methods, and fields than before. The younger one was still unclear when we started talking, but Greenfoot gave us a basis for discussion. In just a few minutes, she understood the purpose of a class versus an object, the relationship between the two, how to identify a method, and a had general idea of constructor methods. We're still working on fields.

The older student now has these pretty well down. She understands the relationship between subclasses and their parents well enough to introduce superclass and overridden methods. She said "I know how to create subclasses in Greenfoot, but I don't know how to do that in my programs I write from scratch." A few minutes later, we'd worked through two examples of subclassing using extends and she has it. Magic!

So far I'm extremely pleased with Greenfoot. I'm hoping to get a third student to give it a try. She's a friend of my two present students, and out of classes for the summer. The other two are going to show her Greenfoot and see if she's interested in trying it out outside of class. They're both already using it on their systems outside of class. Another point of view is always welcome, and this other student is very introspective and very outspoken.

I'll post more as we continue. I need to make more time to review the available materials for Greenfoot, and start planning how it'll fit into my class. At this point, I think it's safe to say I'll be using it.

Monday, July 28, 2008

Cuil: Color Me Unimpressed

OK, I had to go give Cuil a try. I should have known that something with a kewlio name like "cool" misspelled would be anything but.

I ran some searches that I'm familiar with the Google results, so I would have a point of comparison. Specifically, I tried the searches that most often hit my Atari 7800 site and other more common searches that I often use in class to demonstrate search engines for my students.

First, I came up with a "No Results Found" page. I'm afraid I laughed pretty loud when that popped up. Then I used the same terms in a different order.

"Want to find XX YY ZZ? We've got it!" "We're your source for XX YY ZZ! Buy Now!" jumped out at me. The first page of results had two people asking questions related to my subject, two pages that were relevant, three totally irrelevant pages, and four spam ads like the ones above (both on the first line.)

The second page was two relevant hits, three completely irrelevant hits, one more "how do I?" question with no answer, and five more spam ads. "Celebrity photos featuring XX YY ZZ!" Gee, I wonder where they fit the cables?

I did a number of other searches, but the results were about the same. Finding the one or two relevant results per page was tedious. The addition of irrelevant graphics to almost every hit didn't do anything to make finding the needle in the haystack any easier.

Scanning back and forth across three columns didn't help, either. Different doesn't mean better. It also made it harder to find results when going back to a page previously viewed. The odd, unbalanced layout resulted in empty space at the bottom right of the page that made it look like the results had been exhausted, when there were additional pages to view.

Google Killer?

The high incidence of spam results on my searches suggests that Cuil suffers from the same disease that drove me to Google in the first place. The last time I used one now-defunct search engine I closed the window on "We have got all your Hittite cuneiform right here!"

As much as the buzz makes out that this outfit is headed by some sort of search engine dream team, I find it hard to believe when I see results that look like something that was a PITA for me ten years ago. Not everybody with a successful company on their resume contributed to that company's success. Cuil looks like the QED to that.

I'd like to have another search engine that gives me relevant results without animated ads of imbeciles in chiaroscuro offending my sensibilities. Maybe Cuil can still pull it together. But dang, if this is the best they can manage for their grand unveiling, I'm not going to be hurrying back.

Greenfoot: Killer Intro to OO or Just a Toy?

I'm checking out Greenfoot, a Java framework + IDE for high school students. The IDE extends BlueJ. The framework provides right-now graphics to students, a favorite object of mine.

Greenfoot lets students jump right in and start playing with objects and classes. The concepts of object and class are very hard to teach. They're my biggest hurdle in teaching programming. Greenfoot looks like it may be the perfect tool for clearing that hurdle.

It simplifies the relationships between classes, objects, and methods without concealing the useful information. It ties actions like instantiation and method calls to visible manual activities with visual results. You can say, "I'm going to instantiate a wombat," then do it. The Wombat class has a menu item creates a new wombat object. Similarly, subclassing and inheritance can be demonstrated from simple menu actions.

Greenfoot isn't just for the teacher's projector. On the student's computer it runs framework programs called scenarios that are basically tile and sprite programs. They are fun and easy to tweak and run. The system invites exploration.

The underlying code is real Java
, not a canned version of an OO language. Theoretically this means the programs produced with Greenfoot can be as extensive as Java itself. It generates stand-alone applications and applets. The question is whether students will willingly grow out of using Greenfoot as a simple sprite game generator to develop ideas that Greenfoot doesn't implement as easily.

I'm trying out Greenfoot with a couple of live students now, aged 13 and 16. Both have been exposed to Java, neither really got classes or objects. We spent about 40 minutes watching a demo of Greenfoot by Michael K├Âlling. The demo wasn't targeted to students, but by the time we reached the Q&A session they were both aching to get their hands on Greenfoot. I set them loose, with no further instruction, just making myself available for questions (while I played with it myself.)

Both definitely had fun. Neither wanted to quit when time was up. There wasn't any time for a debrief to see what was learned aside from the fact that Greenfoot can do a pleasant job of filling an afternoon. That by itself has value if it shows you can control a machine without being an otaku egghead.

For myself, I found it to have some rough edges that would make it tough for non-programmer teachers to use in class. This isn't a problem for me, but I had hoped this might be something I could present to others whose skills largely restrict their classes to typing, MS Office, simple painting apps, and the occasional session of Minefield or Solitaire. I don't think it's ready for them to use on their own. But I'll see about sitting a non-programming instructor down with it and see what they make of it.

It might work for an instructor with the right mindset:
  • don't sweat what you don't get,

  • if something doesn't work then don't do that--do something else,

  • let the students research their own solutions online,

  • and share among themselves,

  • then grade results and progress, not code.

There are questions I have about Greenfoot that I'll be looking for answers to before I recommend it. Does its use really translate into programming? Or will students resist going beyond menu-driven image replacements and simple changes of constants? Will they go into shock at the sight of code in the editor window? How much of my time will it take to set up scenarios to introduce and illustrate new concepts and constructs? Will attempts to shift gears from unstructured play to directed learning cause a revolt?

Where does it fit with other instruction? After a few command line exercises or as a light intro? Is there a point when a more conventional IDE should replace it? Will it be necessary to repeat concepts both in and out of Greenfoot so that they still make sense without Greenfoot's presentation?

More on my Greenfoot experiment soon. At this point, I'd say a teacher with programming skills could make excellent use of it to illustrate many basic OO concepts that are serious problems to non-programmer students.

And it's a heck of a lot of fun.

Friday, July 25, 2008

IDEs for Class: Arachnophilia

Arachnophilia is a simple IDE that works with a variety of programming languages. It's got a simple, but highly configurable, interface.

Arachnophilia is the primary IDE that I use in my classes. After starting my students at the command line, and after introducing them to other IDEs, about 80% of my students use Arachnophilia by choice, and are very productive with it. The other 20% usually choose to use the command line as their primary development environment, though they will usually use Arachnophilia as an adjunct, for example as a code beautifier.

I teach in a multi-platform computer lab. While this is a challenge, I mostly consider it an excellent opportunity for making a point to the students. The real world is a multi-platform environment. Since Arachnophilia is written in Java, it runs on all the lab's systems and behaves the same way on all of them. Arachnophilia includes a special install for Windows that makes getting it going on that OS easy. It even includes a nice icon. (To get an icon on OS X and other Unix systems, I get the favicon.ico file from Arachnophilia's web site and make that the program's icon.)

Arachnophilia is syntax-aware for many programming languages, including HTML/CSS (its original purpose), C, C++, python, PHP, JavaScript, and Java. In a class where multiple programming languages are introduced (like mine) it's nice to have one IDE that works with all of them. I usually introduce Arachnophilia about halfway through our HTML/CSS unit, and continue using it in the Java programming portion of the class.

While I don't teach that Arachnophilia's interface is configurable, about one third of the class usually discovers this on their own and figures it out. They rapidly share this with the rest of the class, configuring their own build settings, customizing toolbars, and so on.

Arachnophilia behaves exactly the same on all platforms. This is a plus when you're calling out keystrokes in class, but it can be a problem for Mac users who are used to keyboard shortcuts that employ the Apple/Command key rather than the Control key. Moving back and forth between Arachnophilia and other apps on the Mac in the same session can be a bit disorienting as a result.

The interface the program provides is clean and easily accessible. I usually spend only about 10-15 minutes of class time getting students started with it, and another 10 minutes or so going into more advanced features later. Arachnophilia doesn't require any configuration to use before class (other than installation), unlike more advanced IDEs like Eclipse or Netbeans. Unlike Amaya, which is a nice IDE focused on HTML/CSS, we can keep using it when we move on to Java programming.

While I also like BlueJ a lot for class use, it is Java-specific, so I don't have an opportunity to introduce it during the HTML/CSS unit that I use as an introduction to programming concepts.

For my class, the ease of use and flexibility of Arachnophilia has made it the winner among a strong contingent of IDEs available.

Thursday, July 24, 2008

IDEs for Class: BlueJ

BlueJ Logo

BlueJ is an integrated development environment (IDE) for Java development specifically created for educational use. It is an outgrowth of the Blue programming language project. Blue was created as an educational programming language, like Pascal, but with an object-oriented focus. Part of the project was the creation of a programming environment for beginning programmers.

BlueJ does the same for Java. It gives a graphical representation of classes and objects in the student's program. It also allows editing and interaction with the program constructs through both graphics and text.

The IDE is clean and straightforward. It's possible to get right to work without spending a lot of class time on the IDE itself, or spending time outside of class configuring the IDE (which is my experience in trying to use Eclipse and NetBeans. They're great for more experienced programmers, but not so great for beginners, especially in the classroom, unless heavily configured first.)

BlueJ's graphical mapping features are fantastic. They make it very easy to visualize subjects of discussion in class, and they make the whole object paradigm make more sense to beginners. I was concerned that they would form a crutch that would keep the students from being able to work with objects and classes without the graphics. This hasn't been a problem for me in actual use, however.

My only complaint about BlueJ is that it's tied to Java. I would like to be able to use it on the parts of my class that don't use Java, particularly with HTML/CSS. However, it's easy to change from another simple IDE that does handle HTML/CSS (like Arachnophilia) to BlueJ.

Among the things I particularly like about BlueJ is how nicely it ties documentation into the development process. Getting new students to take advantage of Java's documentation is frequently a hurdle. BlueJ ties in documentation, both the standard documentation and the use of documentation within program comments, from the very start. Having students write their own documentation as they go, and seeing how it ties upward into the standard documentation makes this all very easy.

I haven't used the Objects First book for BlueJ in my class, I have only used BlueJ with other texts, including Beginning Programming in Java for the Absolute Beginner. This hasn't been a problem at all, though. I also haven't made much use of the resources available through the BlueJ site, but since I am considering teaching without a text, using only my own material and material available online in this upcoming year, that will probably change.

BlueJ is simple, clean, and magnificently tuned. It's a joy to use in class, particularly in a mixed platform lab. If you teach introductory programming courses, I highly recommend it.