« July 27, 2004 | Main | July 29, 2004 »
July 28, 2004
OSCON 2004: Groovy
Maybe the coolest thing I heard about today is a language called Groovy. Groovy is a dynamic scripting language that compiles to JVM bytecode. The result is that it can use the entire J2SE/J2EE API. That's leverage. Groovy would be a good candidate for a scripting language for integrating lots of Java code. The code is dense and fairly elegant.
05:41 PM | Recommend This | Print This
OSCON 2004: Dana Moore on Jabber Messaging
Jabber is not just for IM anymore. Conversational interfaces are less structured, more flexible and can be ambiguous. They can support S2S (system to system) as well as they support P2P (person to person). Applications need presence, fault-tolerance, identity, and mobility the same way people do.
XMPP is the eXtensible Messaging and Presence Protocol, the basis for Jabber. Jabber streams XML messages. Conversations open and close with <stream> tags. The server works as a switch and doesn't maintain much state on users.
Pervasive services follow you wherever you go. The service knows that you're subscribed to them. Dana builds sensor systems and wraps Jabber communication code around them so they understand presence messages and can send status messages over XMPP. He describes an alarm system (briefly) built on XMPP. He uses the term "constellation of services."
The protocol is dirt simple. XMPP has three element types <presence>, <message> and <iq>. The <presence> and <message> elements are relatively self-explanatory. The <iq> message is for communicating with the server. The <iq> message, for example, can be used to tell the server that you have a service to offer. This allows services to be published to the server and other users to discover them.
Dana is working on the DARPA UltraLog project which is attempting to create extremely survivable software systems. The agent architecture for the system is built upon Jabber. The network is dynamically reconfigurable and can simulate attacks. This was made possible by using agile languages (Ruby) and Jabber. One benefit was that IM clients served as the ready-built user interface to the system.
Dana's bumper sticker summary of the talk is "Jabber enables Web services without the baggage."
12:16 PM | Recommend This | Print This
OSCON 2004: O'Reilly Radar
Tim O'Reilly, in his annual O'Reilly Radar talk, made some interesting observations about the current state of application development:
- Internet, not the PC is the platform
- Apps are built on top of open source, but not themselves open source
- Doc Searl's "DIY-IT" is a key to success
- Sevices, not packaed applications
- Source code + comilation != application
- Exploring how to becone platform players via Web services APIs
The take-aways:
- FOSS doesn't guarantee freedom when applications depend on network effects and data lock-in more than on software secrets.
- Invite your used to build your services and your data, not just your code.
- if you're committed to openness, set bold standards for user control of data.
- Architect for participation via a web of smaall advantages.
11:32 AM | Recommend This | Print This
OSCON 2004: Paul Graham on Great Hackers
What follows are some thoughts from Paul Graham's talk last night.
Variation in wealth is a sign of variation in productivity. Low-tech societies don't have variations in connectivity.
We need to understand especially productive people. How do you recognize them? How do you become one? How do you get them to come to work for you?
Like all craftsmen, hackers like good tools. They refuse to work on projects that use the "wrong" tools.
When you decide what infrastructure to use on a project, you're not just making a technical decision. You're making a social decision. The quality of the people who work on your project will depend on the tools you choose.
Programming languages are mediums of expressions. They are more than standards.
Good hackers insist on control. That's why they prefer open source.
After software, the most important tool to a hacker is the office. Offices are places to think in. Making hackers work in a noisy environment is like having a paint factory where the air is filled with grit and dirt.
What tools do hackers choose when they can choose freely? Open source operating systems and languages like Perl and Python.
People like to work with people with high standards. Buts its not enough just to be exacting. If you're not a hacker, you can't tell who the good hackers are. To drive design, the manager must be the most demanding user of the company's product.
Solving a lot of nasty little problems is not nearly as interesting as solving a few big problems. Solving nasty little problems doesn't teach you anything. Big problems have patterns. Solving nasty little problems makes you stupid.
Great hackers like other great hackers. Good hackers clump.
Having great hackers is not in itself enough to ensure success. A company that can attract great hackers has a definite advantage.
How do you know when you meet a great hacker? It seems the only way to tell is to work with them. This is why Universities are at the center of high tech areas. They serve as intellectual dating services.
How do you become a great hacker? The key to being a good hacker may be to work on things they like. To do something well, you have to love it. If you're worried that your current job is rotting your brain, it probably is. Curiosity is listed as the number one property of great hackers given by many people. The ability to concentrate is also frequently mentioned. If may not be possible to cultivate these qualities, but it is possible to repress them.