Helping your kids (and ourselves) building and controlling their own devices

During Christmas dinner yesterday, I was talking with Craig McNeil about preparing myself for helping Henry & Owen to explore building and controlling their own devices. Part of Craig's research is building scientific instruments and so he is well along the hardware path whereas I am further along the software path. Here is a list of resources that came out of the conversation.

Modern Device has a Arduino microcontroller kit originally designed by Paul Badger for his RISD students's art projects. It is very reasonably priced and easy to construct and program using Processing.

Picaxe is another microcontroller with lots of sensor accessories. Craig uses this in his instruments.

Squeak is a modern development of the SmallTalk (textual) programming language. The most significant development in this for kids is EToys. Squeak by Example is a good place to start learning Squeak.

EToys is a kid orientated (graphical) programming language. The One Laptop Per Child EToys site has a good collection of information about EToys beyond how to use it on the OLPC.

Logo was the first software language designed for children. I think this is still the language used in Lego Mindstorms. This is today overseen by the Logo Foundation.

NetLogo is a simulation orientated variation of Logo.

FIRST is an organization that promotes interest in the sciences. I know about them because at the last Providence Geeks gathering there was a presentation about RI's involvement with FIRST.

Getting Started with Rails

I have just finished reading the free online book Getting Started with Grails. Grails is a "Ruby on Rails" competitor that uses the Groovy scripting language. Grails follows the convention over configuration approach to application development and it seems to do a fantastic job. The advantage of using Groovy over Ruby is that Groovy srun in the Java VM and so you have access to the best of class tools available in Java.

I have not yet experimented with Grails and so I do not know how much practice differs from preaching. I have a small project based on Galley that I would like to use to test out alternative frameworks. I had intended to build this first with Rails but I think I will use Grails instead.

Rosa's Testing Tools

I asked Francisco Rosa, CTO at Tizra and author of WebTst, what web application testing tools he uses and recommends. Here is his response:

"I am currently using Selenium [1] ... it really rocks since it allows you to do real UI testing ... You can pretty much do all your system integration testing that way and even test your site's JavaScript code ... pretty nice ...

"That covers at least part of the testing, other parts I cover with TestNG [2] for unit testing (have no idea how you can live with JUnit without the decent test classification TestNG provides) and with WebTst (still) for monitoring testing ...

"I also do continuous integration with cruise control [3], coverage reporting with Cobertura [4] (AgilePDF is up to 64% code coverage :-) ) ... all in all pretty cool (IMHO) ...

"I can no longer imagine development without all these tools/practices: system integration testing, UI testing, unit testing, monitoring testing, continuous integration and code coverage reporting.


"Hope this helps!"

Yes it does. And do I have a lot to learn!

Working below one's means

"You must always work not just within but below your means. If you can handle three elements, handle only two. If you can handle ten, then handle five. In that way the ones you do handle, you handle with more ease, more mastery and you create a feeling of strength in reserve." -- Picasso

Maximizing PageRank via outlinks

Leigh Dodds's blog has a link to the paper Maximizing PageRank via outlinks about optimizing the Google page rank of a site. The basic strategy is to have a sequence of pages where each page links to the next page in the sequence, each page links back to all previous pages in the sequence, and the final page is the only page with outlinks. The paper illustrates this I am sorry to say that I have not read the paper as the proof looks like more than I can handle.

Interaction problems with Yahoo! Video

I have seen the beginning of Bill Scott's Yahoo! Video presentation several times today! The reason for this is that there is no way to know which interaction widgets are in-page interactions and which are cross-page interactions. Given that the presentation is about UI the problems on the page are all the more prominent. For example, "Share by email" is a cross-page interaction while "Save to" is in-page interaction (actually a pop-up window interaction) and yet they have the same visual design; the "+Add" is an in-page interaction even though it looks like a button which normally affords cross-page interaction; the rating stars are a cross-page interaction when generally this is an in-page interaction (especially when logged in).

Bill Scott's rich user interface design for web applications presentation

Bill Scott (again of Yahoo!) gives a great presentation about rich user interface design for web applications. (It has been a slow day at Andrew Gilmartin & Associates!)

The presentation also mentions the new Yahoo! Teachers "Gobbler." Gobbler is a tool panel that sits over web pages and allows you to clip content from the page for placing on a "project" page. Project are web pages that organizes web content for one or more lessons. I used it a little today and it does work. I need to use it more to see how it compares to the idea of "binders" that we tried to incorporate into AccessScience several years ago when it was built and hosted by Ingenta.

Steve Souders's web page performance best practices

Steve Souders (Yahoo!) gives a great presentation about web page performance. The 14 best practices are
  1. Make fewer HTTP requests
  2. Use a CDN (Content Delivery Network)
  3. Add an Expires header
  4. Gzip components
  5. Put stylesheets at the top
  6. Move scripts to the bottom
  7. Avoid CSS expressions
  8. Make JHS and CSS external
  9. Reduce DNS lookups
  10. Minify JS
  11. Avoid redirects
  12. Remove duplicate scripts
  13. Configure ETags
  14. Make AJAX cacheable
Many of these seem obvious at a gut level and the presentation gives detail about why at a technical level they are so.

The need for a richer and integrated data environment

I wrote this in a comment to David Ascher's posting about SOGo: Thunderbird-inspired and Thunderbird-compatible Groupware.

One of the great advances of the desktop rich applications was the compound document. Mixing text, images, interactive charts, active diagrams, busy/free displays with a simple drag and drop. The machines of the time were a little underpowered for this task but that should not take away from the advance. The compound document frameworks were also very difficult to program to. Mostly the power software houses like IBM, Microsoft, Borland, Lotus, Claris, Taligent, etc did it. The underpowered houses could not and so created data and display islands.

Another of the great advances was the expandable shell. The first one was OS/2's Presentation Manager. Then came Windows 95's Explorer. Linux had Nautilus. It is a very compelling idea to have a single tool that integrates browsing and searching hierarchical collections of data. The shell frameworks were also very difficult to program to. Mostly the power software houses like IBM, Microsoft, Borland, Lotus, Claris, etc did it. The underpowered houses could not and instead presented other independent hierarchical displays.

We need to go back to these ideas and implement them now with the more powerful machines and high level languages and toolkits. I really don't want Thunderbird to be so deep so as to enclose these tools and data repositories. I want a lighter touch. I want Thunderbird to provide interactiveness that is not currently available via the browser. Thunderbird needs to be a super-browser. I want it to show the way to where browsers need to go.

Comments on "The Slow Death of the Technical Specification"

The "The Slow Death of the Technical Specification" is another reason why so much slipshod work is passed off as finished work. Preparing the technical specification is an initial and thorough implementation of the work on paper. The coded implementation is the second implementation based on the strengths and weaknesses of the first paper implementation. As Fred Brooks says, plan to throw one away; you will, anyhow.

A work needs to be reviewed. The customer needs to know that they are getting what they asked for. How do you review a working implementation -- a web site, a desktop application, or an infrastructure? How do you review a paper implementation? People have been developing the skills and using the tools necessary to review a linear presentation of a work since secondary school. A very rare few people have the skills or tools to review a working implementation. Not having the written specification is short changing both the customer and the supplier. The customer gets something they are not in the position to review and the supplier is in the position of not knowing if the implementation is what the customer wanted.

The weakness of the paper implementation is that it does not define the coded implementation. The construction industries have "as built" blueprints. These are the original blueprints with annotations detailing the differences from the design and the construction (i.e. implementation). Software needs these too. We just don't have them yet.

Unfortunately, I have supplied much software without initial or even afterward technical specifications. Hardly great moments in a software development career.