Here Comes the Boss-man

I was part of a lucky group of employees who got invited to sit down with one of the big boss in my company. I worked for a massively huge company making enterprise software.

The big boss looks like a regular Joe but he doesn't act like one. He's calm, steady, straight-talking and completely in control of the situation. I guess it helped that he was talking to people about 4 levels under him, but he did have a commanding presence.

The session was an hour of q&a. I was surprised that he just came in, sit down, introduced himself, ask for a round table introduction, and went straight to q&a. No morale rousting speeches, no corporate propaganda. Just answering questions.

One thing to note is that unlike all the managers I've ever had, this guy actually listen. He waited until someone completely finish a question before even starts answering (he only cut off those folks can't seem to control themselves). Then he actually answered the question.

For example.
Q: Why is it so darn difficult to get IT to help us to get anything done? Like giving us a replacement for our broken workstations??

Big-boss-man answer: Yeah, they sit on a padestal trying to streamline IT while not giving us the service we need. I am doing my best to change that, however I have to pick my battle. I am working with my boss to get to the situation where IT will be providing services again instead of going about their own pet-projects.

My first-line-manager answer: You have a broken workstation? Did you call IT?

Another favorite of all managers I have worked with is to pick one word out of 20 that you said and skewered you with it.

Me: I'm not interested in taking Oracle DB Administration classes. I would like to focus my learning on server-side programming and get better at those side of the application.

Any of my managers: They are not just classes. They are excellent on-hands training program that will help you in your career.

So few things I take from listening to the Big-Boss-Man:
1. Listen listen listen.
2. Don't bullshit. It barely works at the low level (with people like me), and it most definitely won't work with the big boys (his level).
3. Pick your fights carefully. Apparently when you run a business division which are competing with other division for resources, you need to make sure you put your effort where you got the best return. It such common sense, yet some of us wants to fight all the time for all kinds of worthless thing.
4. Big-boss-man often has to go around appeasing people for all the screw-ups that all kinds of people under him do.
5. It is a better idea to pay conservatively and keep your employees during down-turn rather than pay extravagantly and lay off people when situation go worse.
6. Count your money. Apparently with a budget of a few hundred millions, you still do need to count the money. Maybe even more carefully!
7. Develop stuff in house. It's cheaper than buying innovations from outside.

Big-boss-man is a good man.

Java 1.6 got HttpServer!

I am totally excited!

I always hated the idea that I need to put in a Tomcat or Resin server for my Java web app. They are excellent web servers by the way, but I need to get a few megabytes and a dozen jars just to do request/response handling? Cmon! I was looking at Simple for awhile, but then I found out that Sun's Java 1.6 has HttpServer built it.

These past few days, I've been writing some test codes around it. The bottom line is that it is fast, dead simple, but it doesn't offer much else. While this is perfect for my cache-to-SDB app, this is probably too bare bones for web app.

It is an intriguing project to build a Rails-like web app framework around this Http server. I don't even need a Java version of ActiveRecord at this point, since the future is not RDBMS (or is it?). A convention-driven httpserver -> controller -> template mechanism is all I need. Looks like Velocity is a great fit. Will have to investigate that possibility.

Management Star Trek Style

I love Star Trek, and I wish that I actually live in a starship. However, would I run a software development team like Kirk ran Enterprise?

1. A lot of orders come from the top. Even automatic ones like to raise shield when a major energy waves are coming, what choice of engine to use when leaving starbase dock.

2. Log everything. While we mostly hear the captain's log, almost every officers seems to have a log. First officer got one, chief engineer's got one, chief medical got one. I bet everybody can log anything to the computer. Even private logs.

3. A lot of face-to-face time. I'd think they would use intercoms and computers more to convey information. Turns out a lot of them walk around and ride the elevators just to bring message and have conversation.

4. Most captain's decision are made alone with very limited discussion with their chiefs.

5. Commands are readily transferable. Whenever the captains are not on the helm, first officer take over and knows what to do immediately. This goes down the chain. Every chief officers can delegate responsibility to next in line immediately.

What will Persistence Layer Looks Like

Data sharding is the way to go. We need a decent node that has the latest data. They layer must be decoupled from web app. Each node (or a manager) can inform requestor where to get the right data. Must support affinity transfer smoothly.

So it will be like this:
1. REST interface.
2. Cache data (like memcached just less awesome).
3. A node only need to handle configured silos (data that it handled was configured in).
4. Probably need a manager node (if a node is asked for data it doesn't have, pass it to manager who knows where to get it from).
5. Support seamless transition. Say if a node should no longer handle silo A, then it will cease taking in updates (redirecting to new node) and slowly phase out silo A cache.
6. Updates SimpleDB on update request. This way, I do not need to perform complicated async SimpleDB update. If SimpleDB is not available, update cannot be performed.

To make it easy, it should be strictly key-value system (like memcached). No query allowed.

Now the question is how to define the data object, or if it should be defined at all. It would suck to have to define the data object on web app AND this layer.

Persistence as a Service

Can this be applied with SimpleDB as the backend?
Looks like it can help to resolve the issues that I was thinking about.

http://natishalom.typepad.com/nati_shaloms_blog/2008/03/scaling-out-mys.html