December 2006 Archives
I continue to be extremely impressed with the Parallels VM. However, I just spent an undue amount of time wrestling with Window's and Parallel's network configurations in order to achieve a relatively simple result. In the hope of sparing someone else out there some wrestling, here's the scoop:
Goal
Set up a Parallels VM with Windows XP so that it is isolated from the outside world but network addressable from my mac via a fixed address (192.168.2.100) and the name 'parallels.'
Solution- Set up your parallels VM
- In your VM's Network Adapter configuration, choose 'Host-only Networking' for the emulation mode
- Go to the DHCP tab of the Parallels application preferences. Set the DHCP scope to include the desired address. (I chose start of 192.168.2.1, end 192.168.2.254, subnet mask 255.255.255.0).
- Start the VM
- In Windows, turn off the firewall. (Control Panel | Windows Firewall)
- In Windows, set the local connection to use a static IP. (Control Panel | Network Connections | Local Area Connection | Properties... | Internet Protocol | Properties... | Use the following IP Address: 192.168.2.100)
- In OS X, open a Terminal. Type 'ping 192.168.2.100' and make sure you're getting a response.
- In OS X, etc/hosts isn't recognized. In order to put a name on that IP, you have to...
- Open Applications/Utilities/NetInfo Manager. Go to 'machines.' Create a duplicate of 'localhost'. Rename it to 'parallels'. Set 'ip_address' to 192.168.2.100. Save and quit NetInfo Manager.
- Back in Terminal, make sure you can 'ping parallels'.
- Fin!
Just stumbled across Charva. I love it. I just wish I could think of a reason to use it.
Scary, huh? It's you on the internet! Well, not really - its just looping back locally. But still. I blatantly stole this cool trick from this guy.
(For those not on an iSight equipped Mac: the above box shows the video feed from the Mac's built-in webcam).
But seriously, I am a little concerned about the iSight. It's fun and has the geek factor and everything, but there also are security and privacy issues that I think Apple seems to have pretty much ignored.
This morning, I was on a WebEx. The WebEx software and the iSight both decided that video of me should be transmitted. The WebEx software provides no way to disable this. Apple provides no way to disable the camera. A control panel? A shutter? Better yet, a removable camera? A BTO option to skip it entirely? Something? Please?
And yes, I do know I could fix this with a 1 sq cm of electrical tape. But then how am I going to get that consulting gig at NORAD if they won't let me through the 20-foot-thick door with my machine?
There have been a million blog postings this year weighing the pros and cons of the various web frameworks now available. It's a bit overwhelming to wade through it all, so I'm going to try to provide a nutshell summary of my take on the three that I've evaluated recently: Seam, GWT, and Echo.
I chose these because they seem to be the projects which have the most momentum. (I'm not proud - it pays to follow the herd in this kind of thing). I can't claim to have written 'real' applications with any of these yet, but in each case I at least got so far as prototype that presents master-detail views that update a database.
A quick note about me: I've been a longtime skeptic of the whole Ajax thing. My experience writing the early console for WebLogic server left me traumatized by javascript. The latest generation of tools may be changing my mind.
So, without further adieu, the nutshells:
JBoss Seam |
|
| What It Is | A few annotations, a library of JSP tags, and some interceptor/injection runtime magic that provide an unobtrusive glue layer between EJB 3.0 and JSF. |
| The Good | Seam feels very clean and well-designed. You don't actually use that much Seam stuff in withing a Seam app, which is always a good sign. Seam seems to be informed by an underlying pragmatism about what most real world apps are like and how they are developed. It's not quite JSF on Rails but it's in the ballpark. |
| The Bad | The docs are a bit haphazard and the tutorials are schizophrenic. |
| The Ugly | I would have killed for a framework like this six or seven years ago. Unfortunately, it does seem like much of the world is moving in a different direction now. If Ajax figures prominently in your future, you might do well to look elsewhere. There are some scattered efforts to Ajax-ify Seam but nothing I've read about them seems very compelling. |
| The Bottom line | If you are committed to a traditional page-centric application with JSF, Seam will make your life a lot easier. But nowadays you probably need to carefully consider the depth of that commitment. |
Google Web Toolkit | |
| What it Is | A compiler that translates java source code directly into javascript, a library of AWT-like widgets, and a 'hosted mode' container for simplifying the edit-compile-deploy-debug cycle. |
| The Good |
The sheer audacity of GWT's much-hyped approach really is astounding. Actually,
I'm not sure that part is good. The good part is that it really does
seem to work; I didn't encounter any cross-browser issues. You write java code and you get Ajax magic without having to
touch the hated javascript. The approach allows you to maximize the
amount of application processing that is offloaded to the browser, which
in theory could help you scale an application more easily.
Much has been made about potential security holes with putting logic in javascript in the browser, but this strikes me as a red herring. I fail to see how it's any different from shipping an applet jar out to the browser. Moreover, GWT all but forces you to keep your business logic on the serverside (more on this in The Ugly). |
| The Bad | I ran into some possible performance concerns
even on relatively simple pages (on the order of a dozens of listeners and
fields, things became very slow). The license is worrisome: it paints
itself as open source, but they keep the compiler proprietary binary
(and the compiler is where all the value is). The documentation is excellent in some respects but poor to non-existent in others, especially WRT project structure. In particular, GWT modules have a specific structure that is not documented anywhere. Naming your subpackages 'public' and 'client' and 'server' is not a matter of convention - they have meanings to the compiler but this is not described anywhere AFAICT. They seem to expect you to run their little bootstrap tool to set everything up for you and not ask questions - that approach always drives me absolutely nuts. English is my friend. Also, I hope you love CSS as much as I hate it because you will be using it a lot. You pretty much have to define a style for every little widget you use. The constant context switching between Java and CSS quickly becomes a pain when all you want to do is myButton.setWidth(100).
|
| The Ugly | In some ways, GWT presents a worst-of-both-worlds scenario in terms of how it abstracts away the client/server divide. You still have to define remote interfaces, and using them is awkward because of the inherent limitations of the java->javascript translation. It basically forces you to build a stripped down DAO layer for the javascript to talk to via XML, and for me that quickly became extremely tedious. |
| The Bottom Line | If you are writing a quote-unquote Web 2.0 type app that has to scale for millions of users, GWT could be the way to go. It does a great job of keeping javascript out of your hair, but prepare for busywork if you need to talk to an EJB. |
Echo2 | |
| What It Is | Take Swing. Rewrite the peer layer so that instead of talking to native GUI widgets on the local machine, it talks to a javascript agent in a remote browser that renders DHTML widgets. That's Echo2. |
| The Good | It's just like writing a swing app. The API is almost identical. It completely abstracts away the remoteness of the client - you can have an ActionListener that invokes a session bean directly if that's what you want to do. There are no restrictions on what you can do because all of the action is on the server - the javascript simply provides a reflection of what the server tells it is happening. It has a truly amazing demo app. |
| The Bad | It's just like writing a swing app. The API is almost identical. Doing relatively simple things often requires more code than it should. You will suffer greatly if you are allergic to anonymous inner classes (I'm not, some are). |
| The Ugly | It's just like writing a swing app, except it isn't. The peers are all on the other side of possibly high-latency link, but the API makes it easy for you to forget this. The runtime tries to do some smart things with batching up client/server comunication, but it's not always clear what the rules are. If your UI has to respond to lots of fine-grained events (e.g., keystrokes in a textfield), you might have trouble. If your UI needs to support hundreds or thousands of concurrent users, you might be in trouble. (I don't have hard data on that, only the intuition that Echo's approach is inherently more chatty and therefore less scalable for some kinds of apps). |
| The Bottom Line | If you're writing a traditional J(2)EE app with forms and tables that talk to a database and it doesn't have to scale to thousands of users, Echo seems like the way to go. The beauty of it really isn't even so much about Ajax. Rather, it's about a client/server programming model that feels like a fat client model 98% of the time. You do have to be a little careful not to let things become overly chatty, but for many kinds of apps that isn't likely to be a problem. |
At the end of the day, the answer is the same as it almost always is: it depends on the app. Seam if you have to do traditional pages, GWT if you're building GoogleMaps, and Echo if you're doing mid-size/J2EE apps.
At the moment, I'm mostly in the last category, so my choice is clear: Echo all the way
