Archive for May, 2008

Eclipse on an ASUS Eee PC?

Monday, 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

Monday, 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 coobird.net, such as Thumbnailatator and Dvaspi is developed in Eclipse. Eclipse is open-source software that can be downloaded for free from eclipse.org.

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

Saturday, 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 coobird.net.

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

Thursday, 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

Saturday, May 3rd, 2008

Coobird's Blocks imageCoobird’s Blocks has been released. The applet is available to play on the coobird.net 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 http://projects.coobird.net/Blocks.