Adaptive Software Solutions

In this blog, Guy Kawasaki writes about 10 (real world) things college students ought to learn. He has raised some very good points that are not taught in school but are extremely important at work. In point #4 he says: How to figure out anything on your own. Armed with Google, PDFs of manuals, and self-reliance, force yourself to learn how to figure out just about anything on your own. There are no office hours, no teaching assistants, and study groups in the real world. Actually, the real world is one long, often lonely independent study, so get with it. Here’s a question to test your research prowess. How do you update the calendar in a Motorola Q phone with appointments stored in Now-Up-To-Date? (I’ll send a copy of The Art of the Start to the first person with a good answer.) This brings to mind ideas that I have been trying to talk about for a while: self learning, informal learning, and continuous learning. I would again like to take this opportunity to remind you of the...

Docking Frames is an excellent Java docking framework. There are a few other docking frameworks out there also, like FlexDock , MyDoggy , and VLDockin g, but from all of them I found DockingFrames to be the best for my requirements. DockingFrames just works. I found very little inconsistency and bugs in it. Also it uses static variables very judiciously which was important for our use, since we might want to use docking in multiple places in the application, such that each of those do not know of each other. I also found the lead contributor to be very responsive. He was extremely prompt in answering questions and always gave good suggestions. DockingFrames uses the concept of themes for docking. A theme specifies things like icons, buttons, tabs, etc that appear in the panels that contain the docked components. In the beginning I used the BasicTheme and the FlatTheme. However, BasicTheme uses angular tabs (for selecting components that are docked in tabs), which I liked more than t...

It's been a long time since I have blogged here. I maintained a blog at http://www.adaptivelearningonline.net for almost 2 years. However, it was a hosted blog and I was unable to update it regularly. Consequently I have stopped that blog. I hope to restart sharing what I learn by posting here again.

The Asus EEEPC does allow locking the desktop using CTRL-ALT-L. However there is a bundled utility kdesktop_lock that allows just that. To lock the desktop type the following line in a terminal. kdesktop_lock --forcelock This will lock the desktop (with the taskbar still being displayed) Here's how you can add an icon to the EEEPC's SimpleUI, so that you do not have to type in the command every time. Add this to the /opt/xandros/share/AsusLauncher/simpleui.rc " icon="iptv_norm.png" selected_icon="iptv_hi.png"> Lock Desktop

Static imports have been around since Java 1.5, but they are a feature that I have rarely used, or even seen much in code. I guess that's because static imports is not a must have thing, but something that is nice to have . Using static imports takes some pain away from typing code. For example, instead of writing System.out.println("some message"); we could statically import System.out and write it as follows: static import  System.out; public class  HelloWorld  {    public static  void  main ( String args []) {      out.println ( "Hello World" ) ;    } } Well using static imports definetely takes the pain away from typing System.out every time. However sometimes using static imports can also reduce the readability of code, because we would have to look at the imports to know if a variable in code was declared within that class itself or imported statically. Hav...

Can you spot the mistake in this code? // BROKEN - throws NoSuchElementException! for (Iterator i = suits.iterator(); i.hasNext(); ) for (Iterator j = ranks.iterator(); j.hasNext(); ) sortedDeck.add(new Card(i.next(), j.next())); If not, check this article on the Java for...each loop. Note: This text was originally posted on my earlier blog at http://www.adaptivelearningonline.net

In the past few posts we have discussed how it can be dangerous to extend a class that we do not control, if it has not been designed for subclassing. We understood this concept with a specific example from Josh Bloch's book: Effective Java. In the example we subclassed the HashSet class in the JDK. Without repeating the material, I will simply reiterate what I said in my previous post: The real problem was the class AbstractCollection which was not designed properly for inheritance. It is a non-final class with a public method addAll(Collection c) which invokes another non-final public method add(Object o) . Here is a possible implementation of the HashSet class that does not break the DRY principle and is also safe for extending...