That English, No, Aussie, Accent
The passionate author tells the secrets of good presentations.
I don't know about you, but in the last five years, the technical presentations I've heard, some in person, most over podcasts, tend to be delivered by a guy with an accent, British, Australian, Russian, Hungarian, French, Indian, etc.
Well, the Create Passionate Users's Kathy Sierra noticed it too and listed the accent as one of the reasons Damian Conway's presentations are brilliant:
Kathy Sierra: So what's his secret?
I'll summarize a few points here, but for a deeper look, check out these blog notes someone took at Damian's Presentation Akido talk (teaching geeks to give presentations), which I haven't seen but hope to one day.
Damian is brilliant. One of those scary smart guys. So there's that.
And he's entertaining, has a wonderful voice, and that
English(oops) Aussie accent.
I learned my English with a pretty standard (I was told) London accent. However I gave it all away after decades of living in the United States. Maybe I should pick that British accent up and start getting into the technical presentations fields.
Howdjewdo?
Software Development: The Abstraction Dilemma
It's all about complexity.
A recent thread on TheServerSide.com about Framework Java Coders:
Yakov Fain: Today, one of my former clients asked me to interview a job applicant for a position of a senior enterprise Java developer. After the interview I realized that I was talking to a representative of some new breed, which can be called Framework Coder. The guy had on his resume all required components (JSP, Struts, EJB, databases, application servers) utilized in various projects. The scariest part was that he did not lie on the resume: he really worked on these projects without knowing almost anything about Java SE or Java EE.
reminded me about a couple of posts that I made more than two years ago:
Here is what I think is happening:
- This is happening mostly in the IT software world, where the need for "good enough to make money" systems is the greatest.
- The most efficient, and therefore the most profitable, way to build software is through the use of both architecture level and application level frameworks.
- These frameworks, even simple ones, are expensive to build. Therefore there is pressure to make such frameworks reusable.
- The skills needed to build such frameworks and to use such frameworks are vastly different, akin to the differences between the skills to build a C compiler and the skills to use a C compiler.
- What do you think the framework builders do day in and day out? Right, they build frameworks. Thus the proliferation of frameworks.
- And that creates pressure for the framework users to ever switching to the newer and better frameworks.
- Thus in the name of productivity, we have just created a situation where the framework users (that's the majority of us developers) have to waste our time to learn the new things that they (he who built Struts, etc.) keep on churning out that we are sure they'll call garbage two years from now.
- And productivity suffers, because the things that are going to simplify our lives are making it more complicated.
The cure:
- Learn what's essential: Being able to use the String class from your language to achieve your string manipulation goals is essential. Making your application dependent on Apache Strings package (and seventeen of its dependencies) just to use a couple of their convenience methods is not essential.
- Productivity is a false goal for software developers. It only benefits the company who are building the software, usually at the expense of software developers personal development. Nobody is looking out for you.
- Enrich your knowledge about how to build software systems from scratch. Patterns is your friend. Abstraction layers is your enemy.
- Listening to the technical press with eyes open. They have their own agenda. Be especially careful when they say "XYZ is dead." Chances are it's not dead, or they can simply ignore it. (E.g., JavaEE is not dead, or Bruce Tate wouldn't have to say it every time he has a chance. Likewise, CORBA is not dead, or competing vendors wouldn't have to publish lengthy articles to pronounce its death. Similarly COM is not dead. Don Box said it best: "It's done. It will always be there. And everybody who wants to use it can."
- Kai-Fu Lee (Google VP, former Microsoft VP) once talked about the goal of education this way: If you make everything that a student learned during the four years of collage obsolete, what remains in his brain is the true value of an education. Each project we do is a mini-education experience. The most valuable part of it is the stuff we learn that can be carried to the next project.
Joost: A Simple Networking Library
The Java implementation.
Justin Michel came to the OCI internal Java lunch today to present the Java version of his Joost networking library.
First person is Justin now.
I started to work on this C++ communications library four or five years ago. I worked on several projects that could use a better higher level communications library. I worked on and off on this library. In the last six months or so I got some momentum going for the library.
The library abstracts away the socket API. It uses TCP concepts, which are presumably lower level than the socket API. However by not using the socket API, the library also becomes high level and allows the writing of high performance applications.
I gave the same talk last month on the C++ version of the library. This month I'll show the Java version. The Java version is almost the exact copy of the C++ code, with the necessary changes from C++ to Java syntax and idioms.
public class HelloClient implements TcpEvents {
...
private void run() throws Exception {
IpAddress addr = IpAddress.getLoopback(5555);
MessageSizeDecoder nsMsd = null;
TcpConnection con - new TcpConnection(addr, nsMsd, this);
myCloser.registerForShutdown();
myCloser.add();
System.out.println("Sending 'Hello World' to " + addr);
OutMessage msg - ew OutMessage();
msg.appendAscii("Hello World");
con.send(msg);
myCloser.waitForShutdown();
}
public void onReady(TcpConnection con) {
System.out.println("Connected to " + con);
con.disconnect();
}
public void onDisconnect(TcpConnection con, DisconnectReason reason) {
if (reason.isFinishedSending()) {
System.out.println("Server finished sending.");
} else {
System.out.println("Disconnected.");
myCloser.shutdown();
}
}
public void onReceive(TcpConnection con, InMessage msg, int totalSize) {
System.out.println("Received " + msg.getLength() + " bytes.");
}
}
The rest of the talk is the same as the C++ version.
Design
- Event-driven interface
- Asynchronous only
- No blocking calls
- High level
- Platform and language portability
- Performance
Features
- Message support
- Delayed sends
- Delivery by thread pool
- Retry connects
- Flow control
- Auto tuning
Asynch non-blocking APIs usually don't do flow controls. Joost has flow control built in.
Uses
- Financial applications
- Games
- CORBA
- Web Services
- DDS
Classes (com.joost)
- ImMessage
- OutMessage
- IpAddress
- TcpConnection
- TcpEndpoint
- MessageSizeDecoder
Compared to NIO this interface is pretty simple. It is also safer. In NIO you can easily crash your application. NIO uses Sockets and Selects which have performance and portability issues.
There are four kinds of sample applications I want to write:
- Messages
- Large Messages
- Streaming
- Messages using separators
The ultimate goal is to have Joost be used by projects that might need it. My plan has been to contribute it out to the community. But I don't want it to go out too early because the design is still fluid. As the design matures my plan is to submit it to the standards bodies: boost on the C++ side and a similar body on the Java side.
First person is Weiqi now. The Q&A went on after the talk for a while.
Don't Let Programmers Do User Interfaces
They think too much like a machine, not humans.
I ordered a new laptop at the Office Depot online store 10 days ago. I have been tracking the progress of the order through their website.
There is something that just seems odd with the page:
What's up with the second item? It does have a valid looking SKU number but a product name of "None"?
I bet the developer of the webapp has a perfectly good explanation for it. But in this case, it doesn't matter how good your explanation is. What's shown in my browser is .
InfoQ---Technical Articles That Make Sense
It hits every nail on their heads, accurately and consistently.
I haven't read all the postings on the new (well, launched in June of this year) InfoQ website. However, of the articles I did read, I have found them to be quite informative and technically astute.
Give it a try. I'm considering making it part of my Firefox home pages.
Web Services Standards
It's getting close.
(I saw this on Panic From Fuzzy.)

I have a couple of these posters on my cube wall. This one looks somewhat complete. There are 62 little boxes that cover roughly what J2EE or CORBA covers. That sounds like a lot of stuff to learn. However, most of these stuff have a counterpart in previous generation, mature, technologies like CORBA:
| WS-* | CORBA | J2EE |
|---|---|---|
| XML | CDR | HTML |
| Schemas | IDL structs | Java type system |
| SOAP | GIOP | HTTP, JMS |
| WSDL | IDL | Java interfaces |
| WS-Transaction | OTS | JTA |
| UDDI | Naming, Trading Services | JNDI |
| WS-MS | ? | JMX |
| WS-BEPL | UML 2.0 | JBI |
| WS-Security | CORBA Security | J2EE Security |
| WS-Transfer | DDS | java.lang.Void |
| WS-Notification | Notification Service | JMS |