Windows Application Spying

Windows sports an interesting implementation of a Proxy.

This can be easily accomplished by creating a proxy DLL, which contains a stub for each of the functions exported from the Winsock library. If the proxy DLL is named exactly like the original Winsock library (i.e. wsock32.dll) and placed in the same directory where the target email application resides, then the interception occurs automatically. When the target application attempts to load the original Winsock library, the proxy DLL is loaded instead. All the calls made to Winsock's functions are routed to the exported stubs in the proxy. After performing the necessary processing, the proxy DLL simply routes the calls to Winsock and returns control back to its caller. --Yariv Kaplan

Allegro CL 8.0 with AllegroCache Now Available

Here's the deal:

• Allegro CL 8.0 addresses computationally hard problems.

Here's the confusion:

• Most computing problems are hard, but 80% of the money is being spend on computations that are inherently easy. An accounting system is inherently easy. Scaling it for enterprise use at WallMart is not easy. Oracle, IBM, SAP are good at scaling -- they have good tools for scaling.

Because of the heard mentality among VCs, CEOs, etc., most companies try to use the tools that scale easy problems to solve hard computationally problems.

[Gemstone and DB40 also have offerings which address (some of) the types of problems addressed by Allegro CL.]

For a conceptual overview of these issues, Franz has an excellent, if visually uninspiring, presentation. In all honesty, its the best summary of these issues I've encountered in 15 years of dealing with OODBs.

OK. The fact is some hard problems need to scale as well.

Allegro CL won't address every concievably problem, but it is designed to play well with others. This design has been honed over many years, many releases. [The 8.0 version number is an honest version number.] 8.0 includes important SOAP updates and their relational database integration is excellent.

Coders should check out their 24 minute demonstation.

I had the good luck to be exposed to some world class FORTH programmers at the beginning of my career. They placed a lot of emphasis on the notion that simple problems should be easy and hard problems should be possible.

Advanced Java and LAMP tools, such as Eclipse, Ruby on Rails, and OODBs like DB40, make solutions to a wide range of simple problems simple. They should be exploited because of their wide distribtion and adoption until they start to show their limitations. When they do, Allegro CL 8.0 may well provide a good next step. Because of the excellent SOAP and RDB support, advanced solutions can be part of enterprise work and a sudden, disruptive transition is not required.

Zeldman Considers 2.0 Hype

A List Apart's Zeldman has some unkind words. However enamored one might be with Ruby on Rails, Zeldman's view is worth considering -- especially if you are about to launch an RoR or Web 2.0 project.

One issue for me is the "...if all you have is a hammer..." thing.

Many of us need rich clients. Its well to consider where Ajax fits the bill and where something like eclipse RCP (eRCP) fits the bill. Speaking of eRCP, there is some cool stuff coming out in the eclipse GMF and eclipse Forms.

RoR and eRCP are radically different ways of approaching rich clients. Simple projects can (and should) use a simple bag of tricks. Are all projects simple?

Mashup Camp

The Ward and Bjorn are headed for Mashup Camp.

Me too.

The loosely coupled systems made possible by adoption of web services and open APIs (the technology and especially the new business models) are taking off.

Google Earth + SketchUp

Check it out.

How could you find a better example of a platform based upon open APIs?
Is the platform Google Earth or SketchUp ?

I hear its especially amazing on the new Macs.

It is worth looking at the end user instructions for using the Google Earth and SketchUp together. They may seem a bit complex to non-developers, but even skimming over them, most people can probably see that integration of a SketchUp based building into google earth is not a multi-month project. It requires far less skill and knowledge than most power users possess.

POJOs

Plain Old Java Objects, a term coined by M. Fowler. He can explain the original inspiration best:

“I've come to the conclusion that people forget about regular Java objects because they haven't got a fancy name - so while preparing for a talk Rebecca Parsons, Josh Mackenzie and I gave them one: POJO (Plain Old Java Object). A POJO domain model is easier to put together, quick to build, can run and test outside of an EJB container, and isn't dependent on EJB (maybe that's why EJB vendors don't encourage you to use them.)” ~ Martin Fowler

On the plus side...
I'm not sure I use the term as he intended, so reader beware. Here are a few things I like:

• I like to think of my domain as a graph of active objects. Think of the Actor model in a distributed system rather than a bunch of static schema which are populated by access to a relational data base.
• I like to think I can pickel my graph and send it somewhere w/out losing the state of my computation.
• I like to make sure all external (file, db, etc) access takes care of their own cleanup -- especially exception handling. If exception handling needs to percolate accross major system boundaries, it should be done logically, not physically.
  
• Was the source of my object graph a web service? xml file? relational db? object db? word document? My clients should never know these deep, and often dark, secrets.
• I claim that EJB thinking is hard to eradicate. We need to raise the concept of Objects which send each other messages and behave in real time to the top level of the system.

Concerns
Many systems need to be ugly in their implementation because they need to support efficient transactions, lots of information, too many objects, etc. At some point, the core design of many systems must take these things into account; they cannot always be left to 'implementation'.
However, in many systems and system components, these issues are not serious.
For example, 8 gigs of ram on commoditiy servers is cheap. 2 gigs on a laptop is cheap. That is a lot of information. If my application has more information than that, perhaps my real problem is getting relevent information.
Techniques for using AOP to separate the concerns mentioned above is an area of active research and development. If these concerns are not pressing today, someone may solve them for me tomorrow.
Search
Search is an issue which is not straightforward if POJOs are cleanly separated from underlying database connections.

• RDBs do a lot of search well.
  
• RDBs make a lot of search effectivly impossible.
  

A useful implementation of a domain will probably contain serious infrastructure for search, sort, filter. Of course there is no need to start from scratch. Prevaylor and db40 are both useful starting points. Extensions to Java (Groovy) or languages which support closures directly (Ruby, Smalltalk, Lisp) are worth considering.