Using Eclipse on an Asus Eee PC

December 10th, 2008

Image of Eee PC screenIt has been four months since I purchased a Eee PC 901. I’ve been almost exclusively working on my Eee PC and I must say I am having a really great time with it.

Back in May, I worked out a little simulation of using Eclipse on an Eee PC, so I will revisit that post, now that I have been working with this set up for a good amount of time.

In this entry, I’ll take a look at how the Eee PC 901 is able to stand up against development using Eclipse. This entry will be looking at the performance, usability aspects, along with some tips on getting the most of the Eee PC as a Eclipse development platform.


In terms of performance, the Eee PC 901 is adequate to handle the Eclipse IDE. The system is equipped with an Intel Atom N270 processor running at 1.6 GHz. (In reality, the processor has a variable clock speed feature, which allows it to run at several clock rates between 600 MHz to 1680 MHz depending on the power settings and workload.) The processor seems a little bit on the slow side for a modern processor, however, that it seems to be able to handle the tasks of compiling and running relatively small Java projects that I work with under Eclipse without too much trouble.

However, there is an issue when it comes to the disk access. For most disk I/O operations such as booting up the system or launching and using applications, the Eee PC’s solid state drive is quite fast, however, the drive can come to a crawl when writing many small files. This may be problematic when compiling large projects with many source files, as the compiler reads and writes many source and object files, respectively. Tasks that exhibit similar read/write patterns seems to cause system slowdowns.

Keyboard and Mouse

Image of Eee PC keyboardThe keyboard and mouse may take a little bit of getting used to. In terms of the keyboard, it is a little bit on the small side of things. In my case, it took a couple days to get used to the keyboard’s layout and size, but after using it for a week, I felt quite comfortable with the small keyboard.

As with other laptop keyboards, there is a function (“Fn”) key which is used to invoke certain keystrokes. For example, the Page Down, Page Up, Home and End keys are invoked by a combination of the Fn key along with one of the arrow keys. At first, this may seem like inconvenience, however, I’ve found it to be the opposite, as it means that I don’t have to move my hand around as much on the keyboard. (Some laptops have tiny Page Up and Page Down keys that are at the top row of the keyboard, which I found inconvenient.) Of course, this is a personal preference, so as they say, your mileage may vary.

The mouse on the Eee PC is a touchpad, which is a little bit small and may be a little bit dull in terms of sensitivity. One interesting feature of the Eee PC is that the touchpad supports multi-touch, allowing the invocation of the vertical scroll (like a mouse wheel) by sliding two fingers up and down on the touchpad. This is one feature I found quite useful when looking at long documents on the browser or scrolling through code in Eclipse.

Screen Resolution

Before purchasing my Eee PC, one of the biggest concerns for running Eclipse on the lightweight machine was whether the small screen would make it difficult for development. In the previous entry, I was assuming that I would purchase an Eee PC 700 series which has a 7 inch LCD display with a resolution of 800 x 480 pixels. However, the 901 model I purchased has a 8.9 inch screen with a resolution of 1024 x 600 pixels. The difference in the screen size results in an increase of 60% of screen real estate on the 900 series in comparison to the 700 series.

Eclipse on a 800 x 480 screen

Eclipse on a 800 x 480 screen. (Simulation of a Eee PC 700 series)

Eclipse on a 1024 x 600 screen

Eclipse on a 1024x 600 screen.

The increase in screen size is a very welcome feature of the Eee PC 901. In fact, the increase makes using Eclipse much more pleasant. One of the biggest factors is the 33% increase in the vertical resolution of the display.

The vertical resolution is important because it affects the number of lines of code which can be displayed on the screen at once. With less lines that can be displayed on the screen, it would mean that more scrolling would be required, which is time-consuming and can also be distracting and possibly lead to difficulty in understanding the code which is being viewed at the time.

Finally, in terms of overall quality of the screen, I must say that it is very good. The screen itself is very crisp and clear; it gives an impression of a very high resolution screen. In contrast to larger laptop displays with similar screen resolutions, the Eee PC is much clearer and is a pleasure to look at. However, one downside may be that the backlight may be a little bit weak to use in very bright light conditions, but that is a general problem with most laptop LCD screens anyway.


There are a few changes to the configuration of Windows and Eclipse which can make development on the Eee PC more pleasant, in my opinion. Most of these tips involve strategies to increase the amount of space Eclipse takes up on the screen, therefore making editing code in Eclipse easier by being able to view more lines of source code at once.

Tip 1: Set the theme to Windows Classic mode.

Using the default Windows XP theme makes the title bar of each window take up more vertical space.

Comparison of Windows XP theme and Classic theme

As the image above demonstrates, the title bar for window using the Classic theme (shown on the left) is 22 pixel, while the XP theme (shown on the right) is 30 pixels. The difference is a mere 8 pixels, but it does translate to about half-a-line difference in terms of being able to display more information.

The loss of vertical screen real estate should be avoided, as the wide screen of the Eee PC means that there are fewer pixels in the horizontal direction.

Tip 2: Reduce the rows of buttons and toolbars in Eclipse.

Comparison of two rows or one row in Eclipse toolbarBy default, there are at least two rows of buttons that are displayed at the top of the Eclipse IDE. There are quite a few buttons that are displayed by default, but having all those buttons can be wasting valuable space which could otherwise be used to display source code instead. Reducing the toolbar to one row can lead to quite a bit of vertical space savings.

To customize the buttons that are displayed in the toolbar, right-click and choose “Customize Perspective…” From the Customize Perspective dialog, you can configure the buttons to be displayed on the toolbar.

By choosing to display only buttons that are frequently used, you may be able to save a few vertical pixels. The image on the left shows that there’s a 22 pixel savings by reducing a row from the toolbar. This can translate to about one to two lines of source code which can be displayed on the screen.

Tip 3: Use the auto-hide feature of the taskbar.

Using the autohide feature of the taskbar would also contribute 30 pixels under the Classic theme. This translates to an additional line or two of vertical screen real estate. Personally, I like to have the taskbar visible at the bottom of the screen, so I don’t use this tip.


Running Eclipse on the Eee PC 901 is quite possible. Performance-wise, the netbook is not very powerful, but it should be adequate for most purposes. With a few changes in the configuration of Eclipse and the operating system, the Eee PC 901 can be a nice portable platform for light development.

See also: My response on Stack Overflow to the question “EEE PC for Programming?

Revisiting QuickBASIC

October 9th, 2008

I started out programming back in elementary school on a fairly well-known language called QBasic. It was a programming language and development environment developed by Microsoft which came bundled with MS-DOS. Back then, when I first started writing programs, making the computer print things on the screen and accepting user input was so exciting, that I would come home from school and be coding for hours on end. (Albeit, programs were a mess of GOTOs; a wonderful example of spaghetti code.)

As I went on to middle school, I continued to write programs in BASIC, including Visual Basic 3.0 which could produce programs for Windows 3.1, and QuickBASIC 4.5 which could compile executable programs for DOS. Back then, the school I went to had IBM PCs with 386s. Yes, it was the mid 90s, and systems with Pentium processors were out, but back then, most computers weren’t exactly cheap, as most systems started around $2,000. How times have changed.

Getting back on track, one of the types of programs that I always enjoyed making were menu programs. In fact, I had so much fun making menu programs, that the verison number of the last menu program I wrote was the version 8. The program was appropriately called Menu 8.

Menu 8 may have been one of the rare programs which I actually wrote to the point that it was usable and (relatively) stable. Oh, and I got permission to install it as the dedicated DOS menu program on the one standalone “multimedia” computer (i.e. not connected to the network) at the computer lab. That was exciting indeed.

Fast forward 10 years. After going in and out of programming several times, I’ve dabbled in multiple programming languages. Having spent the past few years programming in C-style languages such as Java and C, I thought it might be fun to go back to QuickBASIC to write a perennial favorite: a menu program.

Since Menu 8, I have attempted to make another menu program, but I never got around to it. Most of them turned into demonstration programs for moving windows around or tinkering with graphics. This week, I decided to take another shot at building a menu program. This time, it will be called Menu 10.

The decision was made to design a menu program that would be done in text mode and navigated only by the keyboard. After all, I figured I’ll try to differentiate myself from others by limiting myself to a certain subset of functionality that are available. (For those who are curious, performing a Google search for QBASIC and GUI results in many graphical user interfaces, many of which have support for mouse input and output graphics in SVGA.)

My goal for the windowing interface was to build a generalized system. I don’t intend to use the windowing interface for anything other than Menu 10, but keeping it generalized will be a departure from the times when I was programming in QuickBASIC; back then, I would have interfaces which were tied specifically to the menu and nothing else. Also another common staple was the copious use of GOTO statements.

Menu 10 first screenshot

The generalized windowing interface was designed with the following goals: allow on-the-fly addition and removal of the windows, and also allow the user to resize, reposition and switch between windows. Within a couple of hours, I was able to write a simple version of the windowing system.

Menu 10 second screenshotDisplaying windows on the screen is nice and all, but it isn’t very interesting nor useful without the windowing being able to display information for the user. This was achieved by providing hooks within the window drawing routines so external code could be called to display the contents of the windows.

As the over-arching theme to this menu program is to develop a generalized windowing system that doesn’t couple too much menu-specific code into the windowing system, a window content display mechanism called a display handler was implemented. A display handlers is a piece of code which is activated on drawing of the window onto the screen. The appropriate handler for an window is decided by the ID number of window.

Menu 10 third screenshotAfter implementing several window handlers, the menu program began to look more and more like a usable menu.

It took about three days to get to this point. The next few days involved tweaking the windowing, reassigning keyboard shortcuts to activate the events, and refactoring the code to separate the windowing system from the handlers.

By day six, the menu system became more usable with the addition of a menu component which allows the display of menu items which could be selected and executed by the user. At this point, the menu only allows invoking specific window system tasks such as saving and loading the states of windows on the screen and exiting the menu program.

Perhaps what this revisiting of QuickBASIC showed was that there were many features of the language that I wasn’t taking full advantage of. For example, I didn’t know the exact difference between a SUB and FUNCTION until recently. I had always assumed that a SUB was simply a void function, but it turns out that a SUB allows the “returning of multiple variables” and can’t be used in expressions where a FUNCTION returns a single value which can be used in expressions. Arguments passed to SUB and FUNCTION in QuickBASIC are pass-by-reference, therefore, the value in the arguments can be directly altered within subroutines and functions.

Also to note is that QuickBASIC allows separating code into multiple source files called modules.  This is not a feature that is supported in QBASIC (if I recall correctly), but is a feature in QuickBASIC which allows for more heavy-duty development over its brother which came bundled with MS-DOS. Using modules came handy when using a module like a header file to include definitions for user-defined types in multiple source files. (Using the $INCLUDE metacommand.)

Overall, it was a good exercise in learning a language that I haven’t used heavily in years, and it was fun to revisit an environment that I first started programming with.

Review of Asus Eee PC 901

September 5th, 2008

I finally took the plunge and purchased a Japanese version of the Asus Eee PC 901. it has been a full month and In short, I must say that I really am very satisfied with my purchase. At 59,800 yen (approximately $570), I can’t exactly say that the 901 is inexpensive, but it has been worth its price. It should also be noted that the prices for the Eee PC 4G-X (the 700 series model in Japan) has come down in price, going under the 40,000 yen mark.


The system is fairly powerful for its size. It is powered by an Intel Atom N270 processor running at 1.6 GHz, 1 GB of DDR2 SDRAM, and two solid-state drives (SSD), one with a capacity of 4GB which has the Windows XP operating system installed and the second 8 GB SSD which can be used to store data and applications. The screen is a 8.9 inch TFT LCD with a native resolution of 1024 x 600. According to the specs, the system weighs in at about 1.1 kg or about 2.4 pounds. The weight and size of the 901 truly makes it a portable system.

Operating System and Storage

The Eee PC 901-X model that I purchased came with the Japanese version of the Microsoft Windows XP operating system with Service Pack 3 installed. In the factory installed condition, the primary SSD had 1.4 GB of free space, while the secondary had about 7 GB free.  It should be noted that the system comes in a fairly “stripped down” configuration compared to laptops and desktops that are available from other manufacturers, so it is somewhat difficult to try to increase available disk space by uninstalling unnecessary applications. Disk swapping has been disabled by default for the system, so there is no way to increase available disk space by removing the page file. (This should not be a big problem as the system comes with 1 GB of RAM; so far I have had enough free memory to run all the programs that I usually run — No problems running Eclipse Ganymede which likes to gobble up 200 MB of memory.)


At first the 8.9 inch screen seemed fairly small, but after using it for a few hours, it has been more than adequate. In fact, because the screen is small but has a high resolution, the text appears very crisp and clear, making it very easy to read. The resolution can be adjusted to 800 x 600, 1024 x 600, 1024 x 768 with scrolling and 1024 x 768 with vertical compression of the screen. I have been using the native resolution of 1024 x 600, and the horizontal resolution is more than good enough to view most websites and for editing documents. Even when running Eclipse, there is enough screen real estate to comfortably write programs with some minor modifications to the layout to allow maximum display of the code editing area.

Battery Life / Power

In terms of battery life, I must say that it does run for a good length of time. The Eee PC 901 comes with a power management software called the “Super Hybrid Engine” which allows the user to pick a power mode from one of four choices: Super Performance Mode, High Performance Mode, Power Saving Mode and Auto Mode. When the setting is on the Auto Mode, the power management software will choose either to use the High Performance Mode when the AC adapter is connected or the Power Saving Mode when running off of battery power.

The system is advertised to run for over 8 hours on one charge, it should be noted that under real conditions, the numbers will probably a bit lower. For example, when using the system on battery power with Wi-Fi or Bluetooth wireless turned off, and using the Power Saving Mode, I could run the system for a few hours before the batteries would drop too low to make the system go automatically into standby. When at full charge, Windows generally reports that the run time of  the system is about 7 hours, although I haven’t used the system for that long in one sitting to be able to tell if that estimate is accurate or not.

The only downside is that charging the battery seems to take a very long time. I remember the first time I charged the system up, it took at least 2 to 3 hours before the battery was fully charged. Also, the power adaptor becomes very, very hot from use. This is especially true while the battery is charging. It becomes less hot when the battery is not charging and the system is running off of AC power.

Keyboard and Mice

The keyboard can be a little bit difficult to get used to. However, I did get used to using it after about a day of use. The bigger problem is with the touchpad. As the touchpad is located directly in front of the keyboard, and also lacks a recession into the case, it is very easy to mistakenly tap it while typing on the keyboard. This of course leads to the annoying effect of suddenly having the cursor jump to a new location and you’ll end up typing something where you don’t want to, which already has happened a few times while typing up this post. However, overcoming this problem isn’t too difficult, as all it takes is to keep your hand well clear of the touchpad.

The Japanese model of the Eee PC 901 is bundled with an optical mouse, probably to compensate for the touchpad. I haven’t used the optical mouse much, but it seems to be good enough considering it’s a goodie that came with the computer. I must say that it may be a little small for some, but it probably is fitting when comparing it with the size of the system.

It’s difficult to insert and remove cards into the SDHC slot. The good part is that the SD card is flush to the case, however, that flushness makes it difficult to insert the card into the slot and even more difficult to remove the card.


In terms of performance, it has been above my expectations. (Then again, I didn’t expect a whole lot to begin with.) From the time the system is turned on until the Windows desktop appearing is less than 30 seconds. In terms of the processor speed, it definitely is not blazing fast, but it does seem powerful enough to browser the web, watch some video clips, and do light software development work.

However, there is one thing that will bring the system to its knees: heavy disk access. This is probably due to the very slow write speeds of the solid-state drive in the Eee PC. As with other flash memory based storage such as USB flash drives, read speeds are much faster than write speeds. From sources on the web, the primary 4 GB SSD is a single-layer cell (SLC) SSD which is high performance, allowing for fast read/write speeds, while the secondary 8 GB SSD is a multi-layer cell SSD which is slower than SLC SSDs. This means that read/write access to the D: makes it a little bit slower than accessing the C:, resulting in slow downs.

This has particularly been a problem when using Firefox, where the browser will come to a halt and the disk access indicator will be constantly on. This may in fact be an issue with Firefox, as it has been noted that since Firefox 3, the newly introduced database system has been accessing the hard disk more intensively than the previous methods.


Overall, I have been quite satisfied with my Eee PC 901. Asus has more or less introduced the “netbook” category, as it is called now, and they’re second generation model seems to be pretty good. With new netbooks being introduced from Acer, MSI, Dell and others, this category of PCs are going to become more interesting in the times to come.

Eclipse on an ASUS Eee PC?

May 19th, 2008

Update: I’ve posted my experiences and some tips on using Eclipse on my Eee PC 901 in Using Eclipse on an Asus Eee PC.

The Eee PC is a a cool, new, subnotebook manufactured by ASUS. The Eee PC 700 series sports a 7″ LCD, a solid state disk and weighs less than 1 kg (approximately 2 pounds). All of these come at a price of less than $500. The thought that came to my mind was, “wouldn’t it be awesome to get a subnotebook to run Eclipse and develop Java applications on the go?” So, let’s examine how feasible this is.

There are a couple of concerns that I have with running Eclipse on the Eee PC in order to do Java development. First, would the small Eee PC be able to handle the Eclipse IDE, which by no means is a small development environment? Second, would the small 7″ screen with a 800 x 480 resolution be sufficient to display the feature rich environment? Third, would the keyboard be good enough in terms of quality and size in order to type code?

Eclipse IDEFirst, does the Eee PC have enough processing power to run the Eclipse IDE? Just as a reference, when I fire it up on a Windows XP laptop, it usually takes about 15-20 seconds to load and consumes around 100 MB of memory. (Right now, it has 128 MB allocated, sitting in the background as I type this post.) Would a small machine with a Celeron-M processor running at 630 MHz be able to handle the heavy-weight Eclipse development environment?

In terms of the system memory, the Eee PC 700 series can be expanded to 2 GB, so that is not a particular concern when I am (arguably) comfortably on this system which only has 768 MB of RAM. Also, the Eee PC uses a solid state drive, or SSD, which is basically a cluster of flash memory in a ATA interface drive enclosure, instead of a hard drive, so the read performance is probably better than a laptop hard drive spinning at 4200 rpm.

Second concern is the screen. Considering the size of the screen is only 7″ and the resolution is 800 x 480, which by today’s standard is quite small, would the Eclipse IDE have enough screen real estate to be usable? In order to find out, I’ve simulated what Eclipse looks like when it is sized in 800 x 480.

Eclipse in 800 x 450 sizeTo the right is a simulation of how Eclipse may look on a screen resolution of 800 x 480. Since I can’t resize the desktop on this machine to 800 x 480, I resized Eclipse to 800 x 450. (The taskbar takes up 30 pixels in Classic mode.) I did remove some of the tabs and tool bars to allow maximum space for displaying the source code and the outlines on the left. It seems like using Eclipse would be manageable under these conditions. It appears that about 17 lines can be displayed at once, so it’s definitely less than one would have seen in a text-mode DOS terminal, but definitely tolerable.

To get a better idea of getting Eclipse to run on the Eee PC, I did a quick Google search and that brought up a few other people who have tried it already. In fact, one person has a YouTube video of running Eclipse on the Eee PC running Linux. Watching the video, it seems like it’s quite possible to run Eclipse.

The third and final issue is the keyboard. As with any small computer keyboard, the small keys can be difficult to type on. When I stopped by a computer store which had an actual unit on display, the keyboard did feel a little bit on the small side, but as with any new keyboard, it would probably become more comfortable to use after getting used to using it.

In all, the ASUS Eee PC seems like a nice little notebook to do some Java development using Eclipse, but it’s still probably a little bit on the small side to do any serious, prolonged work. I’ll probably go ahead and wait for the newer 900 series model with the 8.9 inch display.

My Development Environment

May 19th, 2008

My current development environment is on a laptop running Microsoft Windows XP Home Edition. The specifications are: AMD Mobile Sempron 2800+ (1.6 GHz) with 768 MB of RAM, a 40 GB hard drive (4200 rpm) on a 15″ LCD display. 32 MB of the system memory is assigned as the shared video memory for the on-board video adapter.

Image of Eclipse runningMost of the development is in Java, so I use Eclipse as the primary integrated development environment (IDE). Eclipse is a development platform which has an plug-in system which allows it to support multiple languages such as C/C++ and PHP. Many of the projects at, such as Thumbnailatator and Dvaspi is developed in Eclipse. Eclipse is open-source software that can be downloaded for free from

Along with Eclipse, I also have been tinkering with Netbeans IDE as well, which also supports multiple languages through its plug-in package system. Netbeans is also an open-source IDE which can be downloaded for free. One of the features that I like in particular in Netbeans is the Java Profiler, a way to check how much time is spent in a certain part of a program. This is useful in finding out which part of the code is taking a long time to execute, so it gives an idea of which parts of a program should be improved in order to achieve better performance.

Small image of SciTEWhen a text editor is needed, I use SciTE. It has features such as tabs, syntax highlighting and other user configurable features. It’s a light-weight, simple text editor with ability to compile and run programs from the editor itself with the console output being displayed as well. This editor was used to develop the early versions of Thumbnailator and Dvaspi before I started to use Eclipse.

Cannons 2000 Revisited

May 10th, 2008

Cannons 2000 imageAs a Saturday morning project, I took the first serious look at Coobird’s Cannons 2000 for the first time since 2003. The program is listed as one of the programs I’ve worked on in the past in the Past Programs page at

Cannons 2000 was originally written back in 2000, as the title may suggest (and also is a testament to how “2000” was really a suggestive of how futuristic something is, at least back in the 20th century.) and it was written in QuickBASIC 4.5.

This morning and the early afternoon (a total of about 3 hours) was a session in cleaning up the source code a little bit. Looking back at work written back several years ago, it was quite embarrassing. It was plagued with:

  1. Unindented code — The entire codebase (only a thousand lines or so?) was unindented and very difficult to read.
  2. Lots of GOTOs and GOSUBs — although it appears that I was using subroutines and functions for certain aspects, it didn’t really look like I really knew what the heck I was doing. Although some parts used functions and their returns in meaningful ways and subroutines were written where they were called without using GOSUBs, some parts were littered with GOTOs and GOSUBs. Spaghetti code at its best.
  3. Poorly names variables (and functions and subroutines) — Variables like py%, setd, inv1, inv2 were all over the place. The functions and subroutines were just as bad with very descriptive names such as boom, boom2, splode, etc.
  4. No understanding of multi-dimensional arrays — There were some arrays being used, but when they required have two dimensions (e.g. a situation where each player requiring their own array for their inventory), they were using the variables inv1 and inv2, where it would have been best using a two-dimensional array.
  5. GOTOs being used for loops — Loops where keyboard input from the user is being polled were in GOTO loops, where a DO loop would suffice. Although there were some cases where I did notice how BASIC has its deficiencies. If BASIC had a facility to skip one iteration of a FOR loop, like the continue keyword in Java, it wouldn’t require a jump to a label next to the NEXT statement of a FOR loop.
  6. Copy-and-paste redundancy — Sections of code were copy-and-pasted in different parts of the program. One example was a section where two players buys weapons to use in the game. Each player had their own menu display along with keyboard input code. One of them was removed and one was kept with a FOR loop around it to run through each player. And subroutines with essentially the same content, but different magic numbers…

Although not all of the problems has been addressed through the code clean up, such as poor variable names and some of the redundant code (especially the subroutines which were part of what I would describe as “spaghetti logic” due to the logic being designed like spaghetti), the code was indented and the subroutine and function names have been cleaned up. However, the GOTO and GOSUB spaghetti remains, as it would require quite a bit of effort (reorganizing the code) to clean up.

Overall, taking a look at work from the past made myself realize how awful I was writing code back a several years ago. But it’s also been a good refresher on BASIC and a good reflection on how I have been able to write better code today. (But then again, when I look at code from a year ago, there are quite a few places where I’d go “why the heck did I do that?” so programming definitely is a subject where growth happens everyday.)

Coobird’s Cannons 2000 is available for download for free, released under the terms of the open source, Modified BSD license. It should be noted that it is not a robust program and reflects how a beginner would write poor code, so it should not be used as a tool to learn programming.

Coobird’s Blocks release 0.2

May 8th, 2008

Blocks image Coobird’s Blocks 0.2 has been released. They include some minor changes such as:

  • Selectable background image.
  • Default image path changed.
  • Uses the AWT Toolkit instance for loading images.

The background image can be selected from the applet and application versions of Blocks. With the applet, the HTML file which hosts the applet can pass the “background” parameter with the image to load. The application can have its background image changed by using the “-background” switch with the path to the image when launching the application.

The default image name was changed to “background.jpg” from “blocks-background.jpg”.

When loading the background image in the application, the AWT Toolkit instance is used to load the image. The previous release used the Java Image I/O API, which is only available with Java 2 Platform, Standard Edition, v. 1.4.2 or higher. Using the AWT Toolkit should allow JRE 1.2 or higher, although it has not been tested.

First Release of Coobird’s Blocks

May 3rd, 2008

Coobird's Blocks imageCoobird’s Blocks has been released. The applet is available to play on the website, and the Coobird’s Blocks project page has the applet, application and source code available under the modified BSD license.

The Java-based block-breaking game has been in development for some time, and it is a third iteration of the block-breaking game. The history of the game along with more information is available at

Thumbnailator Update (4-29-08)

April 29th, 2008

Thumbnailator is currently being updated.

In the recent redesign, the basic design has been separated into four components:

  1. TGenerator – The thumbnail generating class.
  2. TImageParams – A container for parameters such as image size and source files which is the basic unit which is processed by TGenerator
  3. TRunner – A management class which holds and creates TImageParams objects to handoff to TGenerator.
  4. THelper – A helper class which provides convenience methods to generate thumbnails through TGenerator without using TRunner or TImageParams.

TGenerator continues to use the Java Image I/O API, and it is written for Java 2 SE Platform 1.4. Rather than using the ImageIO convenience methods for reading and writing images, the new Thumbnailator uses the ImageReader and ImageWriter classes which provide more flexible options for I/O, such as allowing the specification of compression quality.

Welcome to the devblog

April 22nd, 2008

Welcome to Coobird’s devblog. This blog will be focusing on recent events during software development. (Hence the name “devblog”)