Using Web Clipping to Monitor DZone

Now that I've installed Leopard I figured I would try out a few of it's new features. At first I didn't really get this new Web clip button on Safari. Turns out, it's really kind of useful. It allows one to choose a piece of a web page and auto magically turn it into a widget.



I like DZone's little rising links section on the top left of the home page so I thought I would try it out on that. It's pretty much so easy that even the least technical person should be able to handle this. Here are the steps:

1. Go to the web page that has a part that you like to watch. Some examples might be my.yahoo.com or dzone.com (the one I chose)
2. Click on the button in the top bar of your web browser that looks like a pair of scissors and a dotted rectangle. Should be between the refresh button and the add link button.
3. Move your mouse around and see what clips get highlighted. When one you want to use as a widget is highlighted just click on it.
   
4. Towards the upper right click the "add" button if you like what you have selected and you are done.
5. Now, when you go to your widgets it will be there and refreshed every time.

Enjoy...

No Java, Bye Bye Macbook Pro's...

I have liked Mac's for as long as they have had OS X, didn't like them before that. Over 50 percent our Development/Field Eng team, have a mac. I've been accused of being an Apple fan boy on a few occasions. Unfortunately Apple is backing us into a corner. We develop Java infrastructure software and if Apple isn't going to take JVM on OS X seriously we will have to move off the platform.

http://www.cio.com/article/149200

http://javablog.co.uk/2007/10/26/apple-os-x-leopard-doesnt-have-java-6/

This would be very unfortunate for me, since I like my Macbook Pro, my team, because they like theirs and for Apple itself because we will stop spending thousands of dollars a year on Apple hardware. Hopefully they resolve this issue as I will be unable to purchase more Macs if this situation doesn't get resolved soon.

Goodbye Randy Pausch

Don't need to be a geek to learn from this one. One of the best CS professors I ever had is going too pass in the next month or so at the way to young age of 46. He has inoperable pancreatic cancer. For those who had the luck to have met or learned from him and for those who have not, this is his must see last lecture.

The Lecture
WSJ piece on him

Also check out some of his projects:

Alice
A bunch of his papers

My best to his family and friends and may his legacy live on. I only wish I could take one more class with you at the helm.

3.5 Rules in Distributed Algorithm Design

In highly concurrent distributed computing their are all kinds of algorithms one can learn. One can read books like Concurrent and Distributed Programming in Java and Distributed Systems: Principles and Paradigms. One can learn how to write scalable servers by reading things like these papers on SEDA. But when creating a distributed algorithm their are 3 simple Goals/Rules you need to follow. While these rules were developed with the Terracotta approach in mind they are mostly applicable to any distributed computing approach:

• Use algorithms that allow for maximum concurrency
• Seems obvious but design your algorithm to allow maximum concurrency. In a single JVM concurrency is important. In a distributed environment where lock acquire and release is almost certainly more expensive it is that much more important
• Use read locks where possible. If you can have multiple readers look at something, duh, don't stop them.
• Try strategies like striping, lock on fine grained objects etc (this is some of what concurrent hash maps do).
  
• Minimize chatter
• Many really cool concurrent algorithms are less good for distributed computing because of the amount of chatter (data that needs to be communicated between nodes).
• Algorithms that require too much cross node book keeping are a problem. Networks are slow and relatively thin pipes. Chattiness plays into that weakness and can also eat cpu.
• Take advantage of locality of reference
• Use algorithms that partition well
  
• Use algorithms that can mostly or entirely act on local data.
  
• Scale-out architectures don't have all the data everywhere. They rely on various levels of caching both near and far for optimal performance. When hitting data try to hit data in the same node where possible.

Rule 3.5 exists as well. Remember not to guess at the performance of something. Test it, time it and automate as much as possible of those tests and timings.

This has been a public service announcement.

E-mail Sucks!

E-mail is absolutely an awful way to communicate with people. Orion, who works with me at Terracotta, and I joke about this all the time. More lost information, mistakes, fights and miscommunication can be attributed to e-mail than almost any other cause I can think of. Here are a few of the problems with email communication that I’ve noticed over the years:

1. It is almost impossible to properly convey emotion in e-mail (so don't try).
2. Most people only skim e-mails because they get so damn many of them
3. E-mail is slow and problematic for conversations
4. E-mail is permanent.

Solution:

Here are some rules that I try (and fail sometimes) to follow.

1. Never try to express anything but the simplest of emotions via e-mail. You can't see the persons face, or even make judgments based on communication pauses or tone. So don't send emotion in e-mail.
2. Don't send e-mail if you are angry. (Alex miller pointed out that it is often helpful to write the angry e-mail but not send it. It's a good way to vent). Always make your e-mail twice as positive and/or emotionless as you think you need to. As they say on dragnet: Just the facts ma’am.
3. Don't assume that your e-mail was read. How many times have you heard, "But I sent an e-mail." Doesn't mean squat. Check in with people on chat, drop by, or call and make sure that they got/understood your e-mail. If you didn't get an ack (geek for response), you should assume that they didn't get it. Let me say it again. Don't ever defend yourself with "I sent an e-mail"
4. If you want to have a conversation, use a synchronous communication mechanism like chat, irc, talk in person or on the phone. E-mail is strictly good for relaying facts (and not even very good for that because they get lost in the ton of other e-mails you have. Try a wiki for facts).
5. If you send a dumb e-mail be assured that the receiving person has passed it around to a few friends to get a laugh or opinion. It is a permanent record of your stupidity (kind of like this blog is for me). So don't say anything in e-mail that you don't want to see on the cover of the NY times.

I must admit that I learned some of the above the hard way. I assume most people have received an e-mail that made their blood boil. You’re just dying to write up a response outlining what a jerk someone is. Well don't do it!

The thing to keep in mind is that there are a million ways to get yourself into trouble with email, but you almost never get yourself into trouble by NOT sending one.

A Job building Terracotta

Opportunistic would be the best way to describe our hiring style at Terracotta. We always have our eyes open for the super sharp so I figured I would post about what we generally look for and see if anyone out there shows up to make more magic happen for us. I talked a bit about what I think people should look for when hiring in my blog on teams.

If you are:

Passionate - Do you actually love having complex problems to solve. Can you not sleep at night thinking about how best to design, factor, improve software. Are you always striving for improvement and learning.

Knowledgeable - I'm not going to list a bunch of frameworks here. The knowledge we mostly look for is about knowing how to solve tough problems. The one thing that is a must is you must know multi-threaded programming. Having experience building some kind of infrastructure software is a big plus. Whether it's building an App server, a database or jms system isn't so important but knowing how to build things that need to be scalable is a big plus (just to be clear, not using those things, building them). For some of our stuff knowing classloaders cold and byte code manipulation is a big plus as well. Most of all you must love and be good at writing software.

Respect/Teamwork - This is complex stuff and we are not a big company so you need to be able to talk to and work with others. No room for people who are pedantic and or self serving. It has to be about the product and the software for you not the title. This is true no matter what role you are looking at filling.

Judgement - Each person has to have excellent judgment. Must be able to focus on what's important. If you don't know something, that's not a problem but communicate, ask questions don't rat hole and don't hide problems.

Intelligence - Not going to lie. You must be smart. You should be a person who can analyze and design complex algorithms. Debug and solve complex problems. We will ask you to answer algorithm questions and write some code in the interview.

I know that's a pretty tough list but if you think what we do is cool and fit most of that please shoot your resume to careers at terracottatech dot com.

For those who don't already know about Terracotta here is a brief overview:

We are a well funded startup based in San Francisco but with developers all over the world. Our product is open source network attached memory for Java and is probably the most interesting and diverse product one could work on stretching from distributed computing, to byte code manipulation.

What were those results again?

This is a small follow up to my blogs about anti-patterns. When trying to debug a complex logic or performance problem one of the most important things one can do is take notes. I had a conversation with someone the other day where the person said, "I'm in a rush, I don't have time to take notes about my runs." To this I replied, you don't have time not too.

So often we are in such a rush to solve a problem that we cut the wrong corners. When performance tuning, and/or tracking something down that requires multiple runs or configurations of your software always always always take notes on each run. They don't have to be super formal but you should write down all the details you can think of. Some examples include, what were my settings, what did the cpu usage/machine stats look like. What problems did I run into. Always keep a date/time stamp on the tests. This will prevent the inevitable rerunning of tests because you forgot the results, or mixing up what you have tried and not tried. It only takes one mistake to use up more time than tons of note taking would require.