yonkeltron

A recent blog post on TechCrunch discusses their plans to try for the construction of a $200 tablet for light browsing with a modified Firefox 3 (in a special kiosk mode) and VOIP thanks to Skype. Now, we’ve heard rumblings of low-cost, touch-based computing devices before. Remember concept stuff from the XO-2 which was supposed to be the second OLPC? The idea was to have it be an ebook-style device with dual touchscreens and a sub-$100 price tag. Shortly following the announcement by the OLPC guys, some researchers from Maryland and Berkeley showed of a prototype ebook reader that responded to hand-generated movement like opening and closing the leaves to advance the displayed pages.

While the dream of a lightweight, $200 tablet seems a little far-fetched, the blog post does show that some serious thought went into this. They are very insistent that the proposed device run a stripped down version of Linux that will boot right into Firefox instead of a traditional desktop. From there, the plan is to have a special start page with “large buttons for bookmarked services” linking to sites of great interest and/or utility.

With this in mind, it stands to reason that SproutCore would be an excellent way to build this start page. By designing the startup page as a SproutCore application, the whole experience can be constructed in a completely customized way while still maintaining whatever parts of the traditional application experience are desired. Furthermore, SproutCore apps can be cached can be automagically and transparently upgraded as well as cached on the client so that basic functionality can be maintained even in the absence of a WiFi link.

After a little bit of thought, I think that the main interface (with the big buttons) should be a draggable grid of icons so that a user may reposition applications according to their preferences and usage patterns. Additionally, there should be a basic configuration interface allowing users to add or remove sites from the startup page. After that, anything else seems like an added complication even if it’s really, really interesting.

Though I haven’t taken that much time to learn about type systems, I have read up a little bit. I devoured Chris Smith’s essay on What To Know Before Debating Type Systems and briefly tinkered around with a typed lambda calculus before trying to really get into some of the heavier stuff that my program covered in a seminar earlier this year. All of this, combined with my personal experiences using dynamically and statically typed languages, gave me just enough of a background to get by when learning or comparing various programming languages.

While I favor dynamically-typed languages (like Lisp, Ruby and Python) as a matter of personal preference, I have tremendous respect for statically-typed languages (like C and Java). In my humble opinion, some of the most interesting languages are those which allow one to switch between the paradigms as need or desire dictates. Take for example, Haskell’s type annotations or Common Lisp’s type specifiers (particularly declare). The former allows one to annotate Haskell function definitions with type information to enforce type constraints while the latter can be used to turn off Lisp’s dynamic typing system when trying to do something special like optimize certain functions.

After I discovered all of this and determined that I think it’s pretty neat but not something I have the time to pursue right now, my interest has been rekindled by a recently delivered presentation entitled Types Considered Harmful. Perhaps it’s also time for me to re-read another famous type-system paper, Java is not type-safe.

I’ve messed about with Processing a couple of years ago but haven’t done much with it since. I saw this post from Lambda the Ultimate detailing how the gentleman behind the jQuery JavaScript toolkit ported almost all of Processing from Java to JavaScript. Now, the whole thing will run directly in your browser thanks to the canvas element. The demos (ported from the original Processing examples page) are very impressive.

Anyone who frequents programming-related IRC channels will already have an appreciation for online pastebins, originally termed nopastes. For those who might be unfamiliar the basic idea is that pastebins provide a quick and convenient way to display text on the web and share it with others. The canonical usage of a pastebin is a situation where an individual must share a snippet of source code with other programmers to illustrate a concept or seek advice. The most famous of pastebins:

• The original pastebin.com
• General pastebin, pastebin.ca
• paste.lisp.org primarily for pasting Lisp and Scheme code but capable of highlighting the syntax of a few other languages
• RAFB nopaste, rafb.net/paste
• gnopaste over at nopaste.info

Most interesting is the recent increase in pastebin spam. The open nature of pastebins make them ripe for abuse by spammers and that has led to numerous discussions of the problem and use of CAPTCHAs to try and combat the issue. I had no idea this was even an issue though it makes a lot of sense now that I think about it…

Everyone has written slow code so let me make an important distinction and say that code can be slow for two main reasons:

1. The operations being performed are, by nature, intensive in the form of being either computationally-heavy or I/O-dependent.
2. The code is poorly written or designed such that it is sufficiently sub-optimal that it’s inefficiency becomes noticeable.

Though code slow for the first reason is often code that cannot be improved much, code slow due the second reason can often be improved through various optimization techniques like algorithmic refinement, complete reimplementation or, less frequently, refactoring. Tracking down the slow parts and to determine the best way to proceed is not always easy in large or complicated programs.

To assist in such performance analysis, there are numerous profilers available (but, as usual, Mac users should beware of foul play). For Ruby, there is the profiler module which enables automatic profile reports to be generated at the conclusion of a program’s run. When running quick analyses, you can enable profiling by telling the interpreter to require the profiler module at load-time with the -r command-line flag. If your program is contained in a file called program.rb, then you’d want to run ruby -r profiler program.rb while being conscious that the report is written to standard error. You can add a require 'profiler' to those files which you would like profiled all the time.

Seeing as how classes have been canceled today, it would seem that I have completed the Fall 2007 academic quarter. While this is most certainly something to get excited about, I have a few more obligations until I can walk away. For the next few days, these are my projects:

1. Finish my thesis proposal. It’s cool and I promise to post the completed copy)
2. Complete work on my final exam. I have the permission simulator written and it can actually store data. I still need to write test cases and debug the thing though. Additionally, once I have it working, it might be worth seeing how much of it I can refactor and tighten up. Like anyone, my code isn’t always great but it should at least be written well.
3. Clean up and finish the draft for the current tech report I am working on. Two tech reports in one academic quarter seems like a pretty good pace.
4. Cook for Shabbos dinner at the home of my beloved, revered and venerated faculty. Her clutch of dedicated students are planning a large dish involving many sautéed vegetables and rice. Perhaps I’ll post our methodologies if it turns out well.
5. Pack to go home on. I fly home early on Tuesday, 2007-12-11 so I need to have certain items like clothes, my tefillin, chargers for my various media devices, personal grooming equipment (razor, etc), books and assorted other required equipment.

I have been keeping a little list of good ideas which are either ideas which I would like to point out or ideas which I would like to see implemented/used more often. It has always been interesting to watch the development of the world around me and from this I have gained an appreciation for good ideas and generally neato stuff.

• Metalink - Have you ever tried to download a large file which is available from multiple locations and may even be retrievable using a variety of methods? Well, I have and I know it’s a real frustration that I can’t get the file faster by leveraging all of my potential options. Enter Metalink! Metalink is an open standard which provides a specification for a little XML file that lists all of the ways one can retrieve a file. For example, for a file available from multiple mirrors the Metalink file would list the available mirrors. If the file was additionally made available through rsync or BitTorrent, it would make note of that as well. This file can then be parsed by a Metalink-aware download client which will seek to initiate a download by grabbing chunks for the various sources and then piecing them together. Apparently (according to the Wikipedia article), the Metalinks spec allows for enumerating a multitude of download sources including HTTP, FTP, rsync, BitTorrent, ed2k and magnet links. I’d like to see this used by more distributors of large files and supported by more download clients (though I heard KGet supports Metalink beginning in KDE4…wahoo KDE4!).
• Eee PC -As everything seems to be moving to web-based apps these days, it often seems silly for a person to be lugging around an expensive and overpowered computing device which they’ll generally only use to surf the web. In fact, it makes sense that many desktop users are most likely spending too much money for a computer with capabilities they’ll never use! In any case, for those looking for a lighter and cheaper alternative for network-centric computing on the go, check out the Eee PC by Acer. Runs a customized simple-GUI with Linux under the hood though I’ve heard it also comes in a less-good Windows variant. It’s light, small and cheap.
• Jabber - I’ve said for ages now that more people should be looking to Jabber-based technologies for instant messaging and more. Having one Jabber account on one server allows me to communicate with any user on any Jabber server out there. It also allows me to use any service being offered by any Jabber server. These services could be everything from conferences and data services to gateway transports to other chat networks. It gets even better! Once an organization or community has a Jabber deployment running, the door is open to use that as connective tissue for other services and individuals to connect. This is especially true given the availability of solid XMPP (Jabber’s underlying protocol) libraries for every language you’d want to use.
• Using Java-the-platform without Java-the-language. Now, it’s been ages since jwz published his famous “java sucks” essay, but I firmly believe that non-client Java (save neat stuff like Web Start) can be a very powerful platform. Much of the server-side Java scene is not so bad. For example, JSP is a very cool templating language which also allows for convenient development using MVC (the Right Thing™). The real pain seems to be in developing the back-end stuff in Java-the-language. Now, thanks to projects like Jython and, more notably, JRuby, things are getting better. I’ve heard about people developing whole servlets and other web-apps in Ruby and then compiling them to Java classes and deploying them as they please. The power of Java without the Java!

So, in case anyone was wondering what I’ll be doing this year in college, I’m taking this year-long program called Student Originated Software (commonly abbreviated SOS). It has four components which are:

• Data Structures: A study of the various containers which are used by programs to store and organize information. Examples include arrays, matrices, stacks, hashes and trees. We’ll also be discussing and analyzing the algorithms used to manipulate data as we compare different methods of storage and sorting.
• Operating Systems: An in-depth look at various components of modern operating systems such as schedulers, processes and threads, memory management and filesystems. We’ll even be hacking some on the Linux kernel!
• Software Architecture: Not really sure where this thread is going but it seems to be about the organizations of large systems. Should be neat…
• Project: A personal (individual or group) development project of some sort.

Later on we’ll be doing some algorithmic analysis and having more project time. You can read the official description and visit the SOS website.

I’ve been hearing about Google Gears for awhile now and decided to give it a test drive with my new favorite web application, Google Reader. Basically, Google Gears is a framework for using web applications offline by providing a storage system (seems to be an SQLite database) which is integrated into the web browser. Installation was as simple as installing a Firefox extension (because it’s  actually packaged as an extension). Then, web apps which support GG integration have an option to go to “offline mode”. When using Google Reader, it goes ahead to populate the local cache with those headlines available at the time of mode change. Then, you can read the stories in the absence of an internet connection. Later, when you have regained connectivity, switching to online mode causes GG to re-sync everything (such as which headlines you read or which links you did something interesting with) bringing you back into step with the web.

I conducted a trial use of GG with reader to allow me to read my favorite news items and articles during my plane ride back to school earlier this week. It worked wonderfully and I have only one criticism of it. When going offline, Google Reader has to download a fairly huge amount of stories (often above 1500 items) and it takes forever. Other than that, I really liked having the functionality available to me.

I advise people to try both Google Reader and it’s integration with Google Gears because it’s really a winning combination. You can give it a spin for yourself by going to the Google Reader site and signing in with your Google account. Let’s face it, everyone should be using GMail unless you are super-happy with your current email setup for some reason (like running your own server or having a serious love affair with some one-of-a-kind feature).

Now, I just wish that more apps would use GG or have equivalent functionality…cough, GMail, Google Calendar and Wordpress, cough.

Amongst all my dabbling with Ruby, I have taken some time to compare the Ruby on Rails MVC stuff with the original Smalltalk implementation found in the Squeak VM. Now, I’m really not familiar enough with the Squeak MVC stuff to comment, but I did stumble across this well-though-out blog post entitled, “My Full-Circle Journey Back to Smalltalk“. In this post, the author (Ken Treis) tells the story of his experimentation with the many languages of web development and (as the title implies) his eventual return to the world of Smalltalk. He goes on to identify eights places where he feels that Ruby missed the boat. While all of these are really interesting points for consideration and discussion, the sixth point talks about how, in terms of live interaction, nothing beats Smalltalk workspaces.

Beyond the shadow of a doubt, I agree with that. I learned early-on with Python that it’s nice to have an interactive interpreter, but irb doesn’t provide anything near the features of workspaces. With a workspace, you can highlight any code fragment, snippet or statement and have it evaluated. Also, because the entire environment is Smalltalk-powered the code can meaningfully interact with anything and everything. Want details on a given object? Pop up a menu and the “inspect” option pulls up an object inspection window that lets you take a direct peek at the object’s internals. Need a different perspective? A browser offers an ideal way to take a more structured look at the environment and it’s contents (notice the similarity to RDoc generated documentation). Workspaces even integrate with the Refactoring Browser to help clean up your code!

In fact, I can’t think of any editing environment that offers the same level of flexibility as workspaces save for one editor: Emacs. Now, before I get flamed, I am a pretty big Emacs fan. Except for when I’m hacking with KDevelop, it’s really my default editor. That being said, I want to make a point by drawing a parallel: While the base of Emacs is written in C, eveything about the editing environment is written in Emacs Lisp. As a result Emacs is the best editor for Lisp and Lisp-like languages. The similarity I’m trying to point out is that the best development environments are those which are expressly aware of the language being developed within them. The easiest and best way to achieve such integration is to implement the environment in the language itself (i.e. Squeak in Smalltalk and Emacs in Lisp).

I imagine a new development environment, which I will refer to as “Rumble”. Rumble should be written entirely in Ruby and it should borrow the best elements in both design and features from Smalltalk workspaces. I imagine that the Rumble environment provide both the educational and exploratory opportunities that exist within the Squeak world. This way, just like extensions to Emacs are written in elisp, extensions and improvements to Rumble could be written in Ruby. If we had such a development environment, I feel that it would add tremendously to the appeal of Ruby as it makes it an even more compelling platform. Who’s with me?