Over the last two months I finished my first Java project since becoming a consultant a few years back. I haven't missed Java and it hasn't missed me. I can't tell you any details due to NDAs. But I know more that I ever wanted to about NTFS now. And I've extended my love/hate relationship with Eclipse.
The project made me think of this blog again. Due to lack of free time (and my waning interest in Java) it has atrophied. I think it's time to change the focus of this site and resurrect this blog.]]>
Stacks doesn’t offer the “fan” option when the dock is used on the side. Spaces is kinda cool in that linux-had-for-years-but-not-completely-kinda-way. I’m sure if the visual navigation used by spaces hasn’t been copied into most linux window managers yet, it will be shortly. Time machine is kinda fun. Making backups fun will hopefully get more people to backup their data regularly. Most everything works, except svnX despite downloading it’s leopard update. Command line svn works fine.
Then there is Java. When the list of 300+ features included ~5 talking about iChat’s tabs and 0 about Java I knew it didn’t make the release. And you know what, I don’t care. I have a confession to make as a Java Developer and a Mac User: I hate Java desktop applications. IF they are done correctly, you may not realize your using a Java app, but 99% of the time you will. File dialogs that don’t jump to a file when you type a letter. Wrong fonts. Text fields that can’t spell-check. Drag-and-drop doesn’t usually work. No working “Services” of any sort. Cut-and-paste is hit or miss. Then there is the memory usage. I mostly use Java as a way to write programs on the OS I like for people who use another OS.
As a Java developer, the only Java programs I use are the ones I write, an IDE, and some tools for database management. Since I switched to mainly consulting, I use Java less. I don’t miss it. When Java 5 came out, I was impatient for Apple to port Sun’s JVM. Java 5 had a lot of language features I wanted to use. When Java 6 was released, I was still writing Java code daily, but the feature list wasn’t impressive. I decided I could wait. I can still wait.
Java 5 on leopard is rough. Leopard, in general, still has sharp edges. These will be fixed. Java will probably take longer than the rest of it.
Please no email regarding Java. I don’t care how upset you are and I already know I’m arrogant, so stuff it.]]>
What's wrong with the Pepper Pad? First and foremost, boot/wake time. The device takes a good 2-3 minutes to boot up and over 60 seconds to wake from sleep. Battery life is about what you would expect from a average laptop -- around 2 hours on the highest brightness setting and 4 hours on the lowest. So why even pretend to use this device as remote control if it takes 60+ seconds to wake and only lasts 4 hours at a shot?
Next on the list, the WiFi receiver is dodgy at best. In the same spots my PowerBook has no trouble, the Pad will randomly drop it's connection. Also I've had the device lock-up a few times when disabling or enabling the WiFi -- which you need to do a lot since sometimes the damn refuses to get an IP address.
Third, it looks like an overgrown PDA or an undersized laptop and has weaknesses of both and the strengths of neither. It's too bulky to carry around and lacks some basic PIM features even if you did. No syncing of documents or photos beyond email. Doesn't have a system wide onscreen keyboard or handwriting recognition. It lacks a usable physical keyboard (my LG enV has a better keyboard). The spilt design keyboard is awkward to use, doubly so if your using the stylus as well.
Then there is the camera. WTF? It is mounted on the front to left of the screen. There isn't a video-conferencing app, but even if there was, the camera is mounted in the wrong place. People would see about a quarter of your head. You can't take pictures on anything in front of you since the display is your only feedback and it must point toward the subject. It's hard to even take a decent self portrait with the device.
The Pepper Pad is basically meant for home use, that is, in the home. Comparing the size to by 17in PowerBook G4: it is about as wide, a little thicker, and more the half as deep. You can surf the net and the brower (FireFox modded for the pad) supports Flash. You can check and write email. There's an ebook reader I didn't try, and a photo organizer. That is not much function from a device that is more expensive that some laptops. If you want to surf the net from the couch, get Opera for the Wii or pull out a laptop. If you want to surf the net and email from other rooms (or maybe actually go mobile) get an iPhone (or other smart-phone if your primarily concerned with email). Wii and iPhone are both cheaper than the Pepper Pad. The only market the thing actually serves is people who buy things because they run Linux.
When I received the first unit a few months back, it was before Apple released the iPhone. After seeing the Pepper Pad, more than one person asked "I wonder what it would be like if Apple made it?". At first, I thought iPhone was the answer, but the Pepper Pad is a different class of device. The Pepper-Pad is like Microsoft's UMPC and Surface or hydrogen fuel cell vehicles; they are ill conceived devices whose only purpose is too distract people from focusing on other technologies.
After thinking about it for a few months, I don't think Apple would create a device like the Pepper Pad or a tablet Mac because they know form follows function, and function follows form. Apple creates three classes of device: those that can create content, those that consume content, those that provide service. Macs can create content (or at least provide the means the people who create content). Apple TV and the various iPods (iPhone included) primarily consume consume content. Sure, you can write an email, take a photo, or use a web-app with iPhone but you're not going to write a novel, cut a movie, compose a song, or write a program using it. Xserves and AirPorts provide services and infrastructure.
Why would Apple create device that can't create content and doesn't fit it your pocket or connect to your TV. I don't care how many ads you create of a guy holding UMPC or tablet PC on top of mountain or in the park or on a subway, there isn't a market for these devices that isn't better served by some other device: smart-phone or laptop.
A lot of people think the way to solve the browser-only UMPC problem is with voice control. Sure it looks all nice and sci-fi. If you watched the linked youtube video, did you notice everyone was alone when they talked to their UMPC. Try using a voice interface in a noisy place like a bar or cube-farm. Now try using text-to-speech on any three emails in inbox, how long before you go nuts? I can read faster than it talk and I can type faster than I can talk and with more clarity (seriously, If you think I'm are hard to understand in type, never talk to me).
What I would expect to see from Apple at some point is a regular 12-15" MacBook with normal keyboard and trackpad and a regular MacBook price, but you somehow flip the screen to cover and hide the keyboard and use a multi-touch interface on the screen. Probably something iPhone-like with easy access to email, iTunes, iPhoto, and Safari. I'm not trying to start rumors, just saying it seems logical.
h2. What About Development?
When you hear "runs Linux" and "Java-based SDK" you'd think the Pepper Pad would be a developer's dream, right? Wrong, or at least partly wrong. First, it is not a real full Java install, it's the pseudo-Java that comes on a lot of Linux distros by default. Secondly the "SDK" is really a toolkit for writing hybrid web-apps where the server runs on the device. Except no-one would write a web-app this way.
The "Pages" or tabs are written using XSL stylesheets and the datastore is XML. There didn't seem to be any relational quantity to the datastore. Java-based actions serve as controller. You can opt to create your GUI in Java but have to do your own data porting and not everything will work correctly because it's not real Java. XML config files glue everything together. A file whose structure resembles JNLP informs the launcher (called "Keeper") of the name, icon, and code for the application. Applications written using the SDK are subject to the same restrictions as an unsigned WebStart application, but without the prompt for clipboard or file access API. You can opt to sign the application for more permissions but the application has to be signed by Pepper Inc. or you have to hack a cert into the keystore. If you already have a cert for signing WebStart applications it would be of no use here.
The SDK API is horribly designed. For example you can toggle fullscreen mode, but you can't set fullscreen as a boolean value nor can you test if fullscreen is active. The data access API is only good for keeping lists of things. Due to security lock-downs and odd application renaming practices, data entered into your application can't be shared or synced with another computer or application. So I guess I should say the API is only good for storing lists of things you don't mind losing. I'm hard pressed to think of any suitable application for the SDK. You'd be better served writing a real web application unless, of course, your application needs to be used offline and store data. All signs point to the Pepper team working on pointless bells and whistles and less on fixing problems.
The "runs Linux" part at least keeps the party from being a total drag. The device uses X11 which, I feel, is a questionable choice. But that doesn't mean use can slap any old X app on the device and expect it to be usable. After all, the Pepper Pad can only simulate a right click by holding the stylus down for a few seconds and completely lacks a middle mouse button or an "Alt" and shift-lock key. But, because it runs Linux, you can get any number of command-line programs or servers to work on the device.
The application my client wanted needed to work offline and be able to upload data and download updates. They also wanted extraneous applications removed from the device. Due to the openness of the device, OS, and API and the lack of signing on a application's "design" files, I was able to get around the restriction against deleting system provided applications and stripped the keeper's interface to the bare minimum. For the actual application, the SDK proved too restrictive/inadequate even when signed. So I installed apache and PHP on the devices and wrote the application as web app and opted to use a var_extract/eval combo as a lighter alternative to MySQL. We then create a thin shell around the web app using the SDK primarily to show the web app in a browser fullscreen without firefox's kiosk UI. Wrote a shell scripts to do system stuff that were in turn launched by PHP. Add duct-tape, hot-glue, and glitter when we finished the project.
The Pepper-Pad has so much potential and triggers geek tech-lust even in people that aren't geeks and don't lust after gadgets, but its high-price, bad design choices, and bone-headed software keep the device from being anything other than a curiosity to owned by Linux fan-boys. I hope OpenMoko fairs better, but the youtube videos I found are extremely disappointing.]]>
Consulting is nothing new for us; we’ve done it in the past, and given our results, we’ll certainly continue doing it. I’ve more or less finished a prototype of a medium sized website with a lot of complex features built in PHP, IT mandates that the finished site be built in dot-NET (Doubt I’ll be involved in that). I’ve got a few upcoming sites that are going to be PHP based. I’m working on a Ruby-on-Rails based site. I’ve tinkered with NASA’s World Wind Java SDK for a part of project. And I developed a prototype application for the PepperPad 3. Oh, and we’ve load tested, and did code reviews for a few applications we didn’t write (much better than being on the receiving end).
In other words it’s been a busy few months.
Our product is built in Java, it’s a three-tier, rich-client, Web Start distributed enterprise system for insurance companies. If you can believe the articles at JavaDesktop this sorta thing has been coming into vogue has the last few months. We when started this thing five years ago, no-one was doing Web Start enterprise clients. I still don’t think that many people are doing them.
Guess what, Web Start rich-clients are hard to sell. Maybe it’s just in the insurance industry, which people always say is 20 years behind the technology curve, we have to spend a lot of time convincing people that our product isn’t client-server. We tell them you can run it from anywhere. We patiently explain to IT that there aren’t any upgrade headaches, everyone is always on the latest version just like a web-app. We tell them that our software can do more (and in more productive ways) than most web-apps, but AJAX is making that less true. Most customers don’t care that maintaining one code path for Java means more solid software that doesn’t depend on the whims of browser vendors. Basically, you spend a lot of time/energy selling web-start just to have people go “Yeah, I don’t know. It looks client-server.”
Occasionally, you’ll come across refugees from web-apps. They love you because you’re transmitting only the data (mostly) over the wire in a binary format instead of bloated plain-text with markup. They love the power of rich-clients. They know that running mission critical applications as a script in the same in same program you use to access every other service is begging for security exploits or other headaches. They know HTML wasn’t made for applications. Then they get overruled by someone higher in the corporate structure.
So now, we’re focusing on consulting, that means I don’t play with Swing as much these days. Sure, World Wind uses some Swing (but mostly JOGL). The Pepper Pad doesn’t use much Swing but it can. But mostly we’ve using web technologies. They work well enough for “casual use” applications. What’s “casual use” for some people, is mission critical for others. That said, I still think adobe is crazy for working on a web version of Photoshop.
Anyway, on to silly comments about server software only the most bored geeks would read.
I really like PHP. Sure, PHP has got it’s issues and quirks, but when you don’t want to be limited by a framework and you need it done quick PHP is the way to go. The biggest benefit of PHP is that no matter what sort of hosting solution you have, it has a 99% chance of supporting PHP. If you’re using Java, dot-NET, or even Rails, your hosting options are more limited. Yes, if app/site gets very popular you will need dedicated or co-located hosting. But, when you are small, a shared-hosting plan can serve you just as well, in most cases, while you are still feeling out your audience and working on your offering.
I have a love/hate relationship with Rails. Once you commit to learning the framework, Rails is a joy to use. Ruby is a great language. The hate comes when you deploy your app. Rails isn’t fast and if you deploy to shared-hosting, even a “dedicated” box that serves a few other sites using other server software, then Rails can’t have it optimal configuration. I hope Ruby get faster at launch time and at runtime and that Rails gets faster and easier to deploy (webserver/Rails integration) because I’d REALLY like to use them more. Just to clarify: it’s the setup of a production environment that I don’t like. Once the environment is setup, actual deployment is pretty painless. Except, sometimes your production environment doesn’t automatically pull in the same modules as your development environment. While some shared-hosting providers allow Rails hosting, it’s not really fast enough to do more than providing clients with a sneak preview during development.
In case you are wondering how I can do code reviews and security reviews in a language/platform I don’t use: It’s simple. Most web-apps have a similar structure, they have mostly the same issues and limitations, and they use the same protocols regardless of language and platform. If you take unfiltered user input and slap it in a SQL statement or on a web page, you will have security issues. Logic works the same way in most languages, it is only the syntax that changes. Understanding control flow and edge cases is far more important for reviews and debugging than knowing the language inside and out.
As consultants, we haven’t had much call for server-side Java yet. I think, it’s because mostly Java is used in IT shops for much larger projects/teams than we’ve been getting. Start-ups and small companies prefer PHP, Rails, or something else. Java isn’t sexy anymore but it’s still very functional and delivers good resource utilization on the server. It’s all about using the right tool for the job. IT departments tend have the “I have a hammer, everything is a nail” mentality — so if they have Java programmers, everything is Java; if they have dot-NET people, everything is dot-NET. I still think Java is the best solution for a large project but it would be hard to recommend for medium or small sized projects.]]>
Over the last month I’ve been looking at Ruby and Objective-C. After looking at Ruby for a week, I came to a couple of realizations. First, a lot of Ruby’s “relaxed” syntax could easily be fit into Java via an upgraded/alternative parser. Secondly, I can see how enclosures provide for some interesting options but I’m not really convinced they make code more readable as some people assert. Third, a lot of Ruby’s syntax is because Ruby, unlike Java, allows programmers to override operators. Forth, I realized that this is another language that will have server-side and command-line success but will likely never move beyond that. I know there are binding that allow Ruby to use some graphical toolkits, but I don’t see the move happening. Fifth, I realized that, knowing “the lay of the land”, I’ll probably never get a job or contract using Ruby.
The Objective-C book I ordered arrived today. I know I’ll probably never get a job or contract using Objective-C, but I can make shareware using it. I’ve written some shareware games in Java. Unlike a few Java games that recently received a lot of attention on JavaDesktop, mine are written in pure Java — no JNI libraries needed, no OpenGL, but they use pre-compiled native launchers. Even in the good reviews, I get beaten up for slow startup times. The Windows launcher has a native startup slash screen and I hate to tell the Mustang guys, but users do not find it be acceptable. Most of the third party Java game API lag behind or don’t exist on the Mac and since the Mac is my primary platform, I find this unacceptable. To take this games to the next level, I have to learn Objective-C to use either for the complete game or to make my own launchers and JNI. I used to program in C/C++ for Windows and Linux for 5 years before switching to Java. Objective-C and Cocoa should be pretty easy to learn. I look forward to experimenting with Cocoa but not to dealing with pointers and manual resource handling.
2005 has been a pretty good year for Java on the desktop, but for Java to really shine the “Virtual Machine” need to upgraded to something beyond the Windows 95 style interface that Java aims for. Between OS X, Windows Vista, and Windows XP with Google Desktop Search and Google Toolbar I think the path is pretty clear. Java needs APIs to integrate with the system’s search functionality. Java needs APIs to integrate with Bonjour/Zeroconf (Apple has an API, and check out Howl for a cross-platform native library). Imagine adding Zeroconf setup info to your app server and have your rich-clients easily find the server (or switch test and production servers). Java needs to integrate the system’s spellchecker into the Swing text components (I’ve had enterprise rich-client customers request this many times, but never had anyone request system-tray integration) and provide APIs for the spellchecker to be used in custom components or server-side tools. Java needs a much faster startup time for Swing clients and not just splash screens. A smaller memory foot-print and the ability to create objects on the stack could hurt either.]]>