Eclipse Java Pearls

Posted on October 10, 2010 by ellisbjohns

If you’ve been around academic M.D.s you know about “Clinical Pearls of Knowledge.”  In essence, a Pearl is really just a tid-bit of knowledge that may be anecdotal but is probably worth sharing.   For the past 4 years I’ve been programming JAVA HIT tools using the Eclipse IDE and there are a few “Pearls” I’ve learned along the way

  1. Spend less than a hour reading through the Eclipse documentation for your programming language of interest (see: ref link).  It amazes me how often fellow programmers arrogantly ignore their most important tool’s documentation.  Reading through this documentation will not only familiarize you with the Eclipse platform, but also give you some context into what the Eclipse foundation considers good programming work-flow.
  2. If you want to see an identical file structure to your HDD’s file structure (e.g. view .class files in Eclipse) within Eclipse use the “Navigator” View and not the “Package Explorer” View.  Both can be accessed from the Window–>Show View menus.
  3. Learn and love Maven, and then learn to love m2Eclipse.  Maven helps you establish a best practice file structure for your project, and this in turn makes your development work-flow less cumbersome (called the “development cycle” in Maven speak.  See: Maven Philosophy).  Tasks like compiling, deploying, packaging, testing…are natively included in the Maven architecture.  Best of all, it has good integration with the Eclipse IDE via Sonatype’s m2Eclipse plug-in.
  4. If you’re planning on using tomcat with eclipse, learn how Eclipse deploys your projects (e.g. where your web service files are deployed to) and also what deployment options you have (see http://wiki.eclipse.org/WTP_Tomcat_FAQ for more info).  The only true way to ensure that your deployment file structure matches your project file structure is to compare the file structures after deployment.
  5. Try not to rely on Eclipse’s built-in build scripts (i.e. .classpath & .project files).  It is always tempting to build your project/application solely using Eclipse’s built in tools.  This works, but it makes your project very difficult to modify in another IDE (yes, there are other Java IDEs).  Using Ant is a great solution, but as I mentioned above, Maven seems to be a better solution.
  6. If you are converting an eclipse project into a maven project.  First place all source files under a common “src” folder.  Then right click the src folder and select “make this my source folder.”
  7. If you have more than one monitor, set new perspectives to open in their own window.  If you’re like me, you like the idea of having a single editing environment that persists even when you’re debugging your application.  Going to Window > Preferences > General > Perspectives and selecting the “open a new perspective in a new window” radio button allows for a single editing environment on each monitor.  Eclipse was one of the first IDEs to offer dual-monitor support and perspective managment  is one of the reasons Eclipse continues to be such a great development tool.
  8. More to come.
Posted in Eclipse, Java | 1 Comment

URL Redirects

Posted on September 28, 2010 by ellisbjohns

I’m losing count of the number of ways URL redirection can be accomplished, but I thought I’d share my experience related to one method in particular:  Apaches’ rewrite_mod: (enabled using the command: a2enmod rewrite)

Below are two example rewrite rules I use to perform the redirects used on this site.  The rules utilize regular expressions  and are both derived from the apache2 documentation pages. 

#This rule sends all urls that don’t specify a file name (i.e. end in “/”) to this blog located in the blog directory
RewriteRule ^/$ /blog/index.php [R]

#This rule redirects all URLs ending in /Wiki or /wiki (NC=case insensitive) to the NotesWiki directory
RewriteRule Wiki$ /NotesWiki/index.php [R,NC]

Both of the above rules are placed in our site’s configuration file (e.g. ../apache2/etc/sites-available/”your site’s name” on a linux machine).  After you restart apache (i.e. /etc/init.d/apache2 restart on a linux machine) all uri’s pointing to www.medengineers.com redirect to www.medengineers.com/blog and  www.medengineers.com/wiki redirect to www.medengineers.com/NotesWiki.

You can also accomplish redirects by including custom .htaccess files in each directory you want to redirect, but most Apache aficionados frown on this practice b/c it adds an un-needed layer of complexity for the next Apache admin (i.e. it is usually better to have your configuration centralized, or else you end up spending hours chasing down all the .htaccess files).  However, if you don’t have full directory access, this is one of your only options (The other option is to use a java script redirect html page)

Hopefully, this saves someone some time.


Posted in Apache, Programming | 1 Comment

Duke Desk

Posted on September 14, 2010 by admin

If you’re reading this post you are probably wondering why I’m posting about my desk. Well, the short answer is that every programmer should love their desk, and I really like mine. Programmers spend way too much time at their desks, and if their desks aren’t designed properly they can end up with some pretty serious medical conditions (I’m losing count of how many programmers I know who have carpal tunnel symptoms). Also, since I’m an engineer by training, I frequently redesign my desk, and with each new design I learn something new about functional desks  (notice the use of the word “functional” and not pretty or aesthetic)

For me, a desk should meet a few simple criteria:

  1. It should fit your anatomic characteristics. This means the desk should be highly adjustable. My current desk has a fully adjustable keyboard tray (I’m partial to the Knape & Vogt SD series), and an adjustable height surface (I use motorized electric telescoping legs made by ConSet (see tablelegsonline.com ConSet type 501-15 or IKEA’s Bekant). Also, having adjustable shelving allows you to custom tailor your shelving height to your specific needs. I keep an AV receiver and laptop docking station on my desk shelving (see image below), and it has been really nice to set the shelving height according to these items (i.e. no wasted space). It’s also nice to be able to change the shelving height from time to time as the desk is re-purposed for other roles/uses.
  2. The desk should be mobile. I’m a big fan of LAN desks (see Kendall Howard’s site if you don’t know what a LAN desk is), but because my desk holds a lot of electronics, I’m constantly tweaking component connections and changing configurations. A desk which is hard to move limits your ability to access its components, and thus limits its configuration possibilities. I’ve made my desk mobile by placing it on casters. This same principal is used in operating rooms, and enables a single operating room to serve as a theater for countless different surgical procedures.
  3. A desk should be modular. If you’ve worked on a large coding project you appreciate the principals of encapsulation and modularity. A desk should be no different. Just because a desk has a computer on it doesn’t mean it shouldn’t also be a good drafting station, or soldering station, or reading surface, etc. My desk is made up of discrete units that are only loosely coupled. For instance, the desk surface/base can be completely separated from the monitor/shelving sections of my desk.  This enables the surface to be used for countless other purposes, many of which require the desk to be completely separate from the shelving.
  4. A desk should take advantage of room height and provide lots of storage/shelving so that your work surface is as big as possible. Clutter is the enemy of any desk, and any desk should encourage organization. This was always an issue for my earlier desk designs. From these earlier designs I learned that adding height to a desk often leads to instabilities, and most shelving arrangements can’t handle the weight of dense electronics. I’ve addressed this issue by using steel wire-shelving. This idea was also taken from operating rooms (ORs). In an OR most of the instruments and medical devices are extremely heavy, and wire shelving handles these devices with ease. Additionally, wire shelving doesn’t collect dust easily, and provides ample air flow for the cooling of electronics. I’m also partial to a particular brand of wire shelving (precisionTools.com /omega) that adds extra reinforcement to their shelving units, sells online, and charges less then most retail stores.
  5. A good desk shouldn’t break the bank. Since I’ve been a student for so long (you’ve got to love medical school), I’ve been poor, and I’m still poor. The desk I built cost about $940 with all the attachments (see completed pic below for more info), or about $710 for the base desk. If you can do without the telescoping base the desk is only about $360.

If you’re interested in building something similar my sketchup CAD drawings can be downloaded using this link: DukeDeskSketchup.   Of note: I’m posting my drawings under a creative commons license (See bottom of post)

The completed desk is pictured below:

I’ve also pulled the desk apart and raised the surface to show how one might use the desk standing up (i.e. similar to the geekdesk.com).   Of note: Con-Set is the same manufacturer used for the GeekDesk’s table base.

Creative Commons License
Duke Desk by Ellis B. Johns is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License

Posted in Drafting, Engineering, Furniture | 6 Comments