« May 2003 | Main | July 2003 »

June 2003 Archives

June 9, 2003

New Tungsten C

Today I got an early father's day present: a Tungsten C. In fact I am posting from it right now. Cool Beans! Now I just need that new j2me runtime

June 10, 2003

WiFinder for Tungsten C

I've been trying out a nifty little app called WiFinder from Bits 'n Bolts (It's still in beta, but quite nice). Basically it's NetStumbler for the PalmOS, and specifically for the new Tungsten C. It amazes me at how good the Wi-Fi on my Tungsten C is based on the sheer number of access points it was able to snoop on my way between home and work. I tried doing the NetStumbler thing with my Dell and the TrueMobile wirelless card it has, and before I detected maybe 5 to 7, my Tungsten detected about 15+.

One of the things that astonished me was the sheer number of "default" and "llinksys" nodes with no WEP on channel 6. Very few sites that did any configuration actually turned WEP on, the most suprising one being a nursing home (HIPPA anyone)? One that actually did turn on the security was the local Seventh Day Adventest church, along with some banks and stock brokers.

I didn't actually try to connect to any of them (it's hard to do at 35-55 MPH) so I couldn't get a real feel for connectivity. When I was scouting out the details of the C I did a lot of message board snooping and one of the anecdotal complaints I heard was the pitiful range of the C. Becasue of that I was a little cautious about un-doing too much of the packageing for my C. But when it outperformed my laptop I was supriesed.

Of course you got to wonder about some of those posts, because if you disconnect your antennas, place it atop a rack-mount server in a metal rack, close the cage door, and close the metal fire door in the server closet of course range is going to suck, it's not the wireless client's fault.

June 11, 2003

Palm Auto Install from Palm Web Browser

One of the cooler thing I have found about my palm is the auto handeling of automated install of the apps. For eample I found a PalmOS port of a VNC client (buggy, can't recommend it yet). If you click on the link in the built in browser it will automatically install it. That was incredibly cool when I first saw it.

However, it isn't without it's limitations: it must get an uncompressed .prc file. So if it is distributed in a zip it won't do it. So with this in mind why are Palm's software upgrades all in zip files? That would be the easiest way to upgrade your Tungsten C but currently they are missing the boat.

June 14, 2003

Swiss Army IDE Problem

The approriately names BileBlog was spewing some bile about IDEs lately...

There's also the gui editor issue. I despise it, and will gleefully delete it from my plugins dir once it shows up there. It's such a shame that market forces demand junk like this. To be fair though, I have some sympathy to it being added as a lot of big companies demand bloated shite like this, so it makes sense from a business perspective. Although it's particularly amusing seeing the various comments that have been made about it. A whole bunch of 'well I never use swing but I tried it and blahblah' rubbish. Serious swing developers I suspect are likely to scoff and stick to using their own hand rolled magic. Still, I'm sure java needs yet more ignorant mediocre inexperienced developers dabbling in swing eh? [The BileBlog ]

There's a couple of things I want to address in this little bit. But Wow, in four short days he's spewed a lot of bile that really chaps his hide about java in gerenal. I've probobly got enough for three posts off of this.

Issue #1 : IDE Bloat. Yea, I've noticed this alot lately. All the IDEs need to have some fangleled spangeled tool to do the latest programming fad. Well based on what was said at JavaOne I'de say it's only going to get worse. The 20% that can do without it are probobly using Emacs or TextPad anyway. But if sun wants that other 80% to come over (you know: those other 7 Million developers they want coding in Java instead of VB) They live and breate by and IDEs slick add on tools. And they want it all in the same program.

The type of slick progams they want are stuff like the new Project Rave (and hardcore developers will yawn, principally because it's not for them). Be ready becuase if Sun is serious about those developers they will have to cater to their whims. We're talking about the corperate IT guys who only write software for their department and other such "internal use only" tools that extist because of VB. What's going to happen is that if developing something is not easy they'll put it back on their never ending stadk of stuff to do and work on something else or (more likely) use some other tool.

It's like dating: You'll generally go for what's available and (given a choice) you avoid stuff that's difficult to deal with (or go without). And if it dosen't fulfull your needs you're likely to move on. Sun wants Java to appeal to the lowest common denominator by being flexible, without attachment, and easy!

June 16, 2003

The Follies of IDE Selection by Checklist

Back on the issue of IDE bloat. Sometimes corperations pick IDEs by commitee. And that leads to the check list syndrome. Group A requires Feature A and Groups B, C, D ad infinatum. Add in another common feature of "corperate standards" where development "needs" to standardize on one IDE. So what usually winds up getting picked is the IDE that can meet the biggest check list. In the interest of not losing revenue the IDE developers try to fill all of thoese check list items as is inhumanely possible. But the problem is that the IDEs become a Jack of all Trades, and are sadly the master of none. More often than not what winds up getting picking is an IDE that no one is happy with. But it was done in a very egalitarian fashion, meaning that everyone's equally screwed in that case.

Situations like these remind me of the early days at my current job. We initally had some big fuzzy discussions about coding practices and build environments and one of the things that came up was IDEs. One person with alot of clout (that immediatly eliminates me) insisted we all use Visual Cafe because it integrated with WebLogic. At the job I had just before this one I tried to use what was a current copy of Cafe for a week. I had liked it before, but then again this was after not using it for two years while I was experementing with Linux in College (don't we all experement with stuff in college? Since I didn't experement with drugs I had to experement with something...). Anyway, I quit rather quickly because of it's horrible JDK 1.2 integration. That, and it crashed alot. I voluntered that information but it was freely ignored. Weblogic Integration was the most importaint thing (perforce integration was second) and thus the standard was Cafe (I didn't use it, I stuck with NetBeans).

This was before WebGain crashed and burned. In the year since I had abandonded it Cafe hadn't seen any major changes (despite the new major version number since WebGain bought it). A year and half later I walk into a phone confrenece where he's whining about Cafe crashing again and about what a piece of crap it was. I had to have a chuckle to myself because that's exactly what I had told him over a year earlier. It was still a piece of crap, but the piece of crap integrated with WLS.

Moral of the story? Trust experience over a marketing checklist.

June 17, 2003

GUI Design Tools are Not Just for the Weak

Now on issue #2 that I see with monsuier BileBlog's rant on IDEs. The most relevent poriton of that previous quote is as follows.

Serious swing developers I suspect are likely to scoff [at IDEA's GUI designer tool] and stick to using their own hand rolled magic. Still, I'm sure java needs yet more ignorant mediocre inexperienced developers dabbling in swing eh? [The BileBlog ]

I suspect that he's never done serious Swing development, I also suspect that a serious OSS developer would use an an OSS version control system as well (and by suspect I mean "I'm speaking out of my ass here"). There is no doubting that hand-rolled magic is sometimes the only difference between a sophomore CS project and a shrink-wrapped product. But if I were going to write a GUI in nothing but hand-rolled magic I would need at least two to three times the schedule to accomplish it.

Why? Well, as I blogged nearly eight months ago productivity matters. There are times that you want to spend a lot of time tweaking the little tidbits, and there are lots of times you could honestly care less. That's why I like start out in the GUI designer rather than blank java class. Yea, I could do all the GridBagLayouts by hand. I could also make the vertical FlowLayouts line up nicely inside multiple BoxLayouts by hand, and I could even write my own layout manager to deal with my personal nits if I wished (in fact that was one of the first things I did with Java GUIs more than seven years ago). But why should I visualize the insets, gridwidths, and weightxs in my mind when I can visualize them with my eyes? GUI designers also speed up the tweak/compile/run loop we all get in just to see if you got a titled border on the right component or to see if you fill propertu on a component needs to be GridBagConstraints.HORIZONTAL or GridBagConstraints.BOTH or whether that box layout looks silly with an alignmentX of .96.

GUI designers are not just about layout stuff either (something the reviews indicate the IDEA designer focuses on exclusively). It's about basic wire-work as well. Do I really want to write the boilerplate code to attach some method to a actionPerformed listener added to a JButton or would I rather jump right into the code preping the data for the SOAP call? (the latter, because it's gonna have to be written anyway). When code is truly boilerplate (like button presses and menu selections) and can be automated it should be, wether it's as a language feature, an API convienece, or as a feature of the development tool.

Believe me, there are many times where hand-rolled magic is the way to go. But that time is not when you are saying "JTree here, JButton there."

June 18, 2003

FontBitch Irony

I find it kind of ironic that in the post where The FuzzyBlog complains about font bitches the post is, inadvertently, an example of font bitching. From Mozilla screenshots at 200% and 75% respectivly:

fb_big.GIF

fb_small.GIF

June 23, 2003

Yahoo Using Google News Tricks?

Found this on My Yahoo, but Get a load of this juxtaposition:

jackson.PNG

No, the photo on the left is not the Late Mayor, but Jacko! Too bad for the late Mayor Jackson he's upstaged by some wierdo. The real question I have though is who's to blame? Yahoo? Reuters? Was there no human associating those photos?

June 25, 2003

Know Your Role! (But Fill in Where You're Needed)

Some discussion has been happening recently about programmers and GUI design. One particular thread had to do witht he bifurcation between what I will loosley call Graphics People and Coding People. Two overly broad generalizations I know, but when you are looking at the perspective of creating a UI for an application subtleties like database/build/swing coders and artists/layout/graphic designers. Sometimes it's good and sometimes it's bad. Jon Tirsen had a bit to say about this. What I want to blog about is specilization in the development process.

But first I'm going to start talking about some of the small details about the US Army. The Army has about a bajillion job assignments called MOSes. These range from combat roles like eliete special ops and calvary scout to support roles like MP, cook, and decontamination specialist. But despite all of these specialization all must go through the same basic training even though their advanced training is much different. One of the reasons for this is so you can expect some basic skills out of anyone wearing an army uniform, namly you can give them an M16 rifle and expect them to be able to use it with some basic proficiency. At the same time you aren't going to expect an Army Ranger to beable to act as an advocate at a court-marshal and you woudn't want an MP providing cover fire from an Apache LongBow. But when a defensive line falls and headquarters is under attack you want to be able to hand everyone in sight a rifle and have them defend the camp.

So how does this relate to GUI work? Code types and Graphic Types represent two broad specializations when it comes to making an application. Unfortionatly this can lead to what Jon wrote about where the specializations become a class segregation. Situations like that are definatly bad. However I don't think the world of total equivilence is a good realm to live in. There needs to be some form of specilization if for no other reason then some people are better at some things (through training or talent) than others. The people who know how to make a graphic design look essentialy the same across 4 different browsers probobly aren't the same people who know how to ensure the cache consistency of the data behind the page and how to prevent double posting of forms.

This generalization is a two edged sword however, you may need the graphics people and the data people to do stuff others specialize in occationally. Perhaps they are on vacation and a new icon needs to be made, or an HTML page needs to be re-done for new data. A coder type could do it if needed but given the choice a graphics type would be better. Perhaps a field on a form needs to accept a phone number with dashes in it but strip it to just numbers for the database before submission. A coder type may be perfect for that but perhaps he has some nasty synchronization bug he's dealing with so the graphics person has to do some text processing and data tricks.

More and more projects now a days are much to big for one person to possibly do everything even if time wasn't a factor. That's why we work in teams. Nearly all teams have specilized roles, but it is the effective team that knows when to live within those roles and when to step outside of them.

June 28, 2003

Use Resource Files for GUI Text

This may seem like an obvious statement for people who do a lot of GUI work, but I will say this because it simply cannot be said enough. Don't hardcode strings! That falls into the good old "no magic constants rule" (unless that constant is the 32-bit signed int -1258207934). How do you go about it?

  • Take all your strings and save them in some file that is not part of your main code. There are several options: you could put them all in a code file full of constant values, you could put them in a properties file, or (my favorite) you could put them in an internationalzied resource bundle.
  • Use meaningful names. SC_EN_000854 may be just the same to a compiler as LOGIN_DIALOG_LABEL_USER_NAME, in fact it's shorter and probobly compiles just a millisecond faster. But take my advice: use the human readable form
  • Use some consistent strategy to create these names. Ther are at least three things it should include: what part of the application it's in, what particualr GUI element it applies to, and some indication of what it says. The order doesn't matter and you can even use short varients or (for location and type) encoded varients. But be consistent! The previous exampel could just as easily be LB_D_LOGIN_UID if you are coding it as type/location/meaning.

So why are these importiant? You mean I can't say "that's just the way you shold do it?" Ok, ok. There is a point to this blog entry rather than random rules. Why do I consider this importaint? Any guesses? Umm... you there, yea the one waving his hand up and down and shouting out "internationalization," you can sit down and calm down because you're wrong. Yes it is a very nice side effects but I think there are better reasons. You there, on the front row. "Maintainable code?" Well, it is maintanable code, but that's not the only reason we do it. Anyone else? How about you. Yes, the cynical one sitting in the back corner. "Management!" Ok, close enough, I'll take it.

It's not just management; it's tech writers, QA, marketing folks, and even other coders with better grammer and speling skills then you. To be more precice it's everyone else who wants to put their fingers in the GUI that isn't actually writing the GUI code. If you mis-spel a word and the strings are all over the code good luck finding the string. You could just search on the mis-speling and fix all occurances of that one. But in those cases people only catch the problems they can see, so the biggest stinkers may get over looked because they don't come up that often (for error dialogs they may never come up). With a centralized set of string files you can run a spel checker over it, but don't try this with java code bacuse signal to noise goes down. You can even hand it off to someone with linguistic skills who can fix all the bad grammer as well. Oh yea, I almost forgot. It's easier to internationalize as well, but you'll probobly have the other problems sooner if you are in anything but the smallest development teams.

Even though my reasons for this are entierly prgamatic it won't end all the problems. While some people care about colons v.s. hyphens for separator cues others care about what shade of grey the background is. Should it be windows grey, swing grey, or bike shed grey?

About June 2003

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in June 2003. They are listed from oldest to newest.

May 2003 is the previous archive.

July 2003 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33