Archive for the ‘Development’ Category

Using Eclipse on an Asus Eee PC

Wednesday, 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.

Performance

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.

Tips

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.

Conclusion

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

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

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.