What's Awesome? Fuser.

So I was poking around in the blogosphere and I saw something about Fuser and its latest release. It's a browser app that aggregates all your mail and your myspace and/or facebook account into one webpage, with tabbed view like Yahoo mail.


I need something like this, because I use 5 different computers when you count the dual-boot laptop. All my stuff is scattered in different sent mail folders in Live Mail on Vista, Evolution on Ubuntu, and Thunderbird on my Mac at work. I would rather it be in one place, and with Fuser I get that. It's got a pretty good UI, and seems to work relatively quickly. Setting up your accounts (I have hotmail, yahoo mail, gmail, and an IMAP mail account) is quick and painless, and the initial sync really isn't too painful.

All the basic features are there, except for one thing: Search. (Edit - Emily from Fuser has enlightened me - it's tucked away in the top right, and isn't that peppy, but certainly better than nothing!)

I did have a problem using this site on Firefox 3.0.3 on Mac Leopard, but it turns out it was just something weird with the latest Java update. I found a great post, describing my symptoms, and once I followed the instructions, the site seemed to work again there.

The only thing that would be really great would be to make this site work in Fluid for the Mac, but currently the browser certification doesn't allow to load this page in Fluid. I plan to try tonight in Prism to see if that works instead.

What's That, Amazon?

Now, before I start writing, I have to confess - I love Amazon's recommendation system. I frequently head there whenever I want to find a new book, a new album, or perhaps a new band to check out. 95% of the time when I go there, I think to myself - wow, that's pretty good - I really did enjoy that. They have done a good job harnessing the 'wisdom of crowds' in a way that produces strong output that keeps me coming back. That's why I found this one so funny:


Note the reasoning behind the recommendation of the Opera album:

Recommended because you rated Mother's Milk and more.

I clicked the "fix this button", and it showed me that I got there because I rated Mother's Milk by Red Hot Chili Peppers and Blue Train by John Coltrane. I can't fix that I liked those, so I have to sit idly by and hope that saying I am not interested will result in Amazon clearing it's head of the thought that I want to listen to the great tenors of our time sing opera to slap bass played by Flea and jazz sax by Coltrane. So strange!

Facebook FAIL

A few hours?

When Bad Things Happen To Good People

Man this football weekend was tough. Michigan lost to Toledo, mostly because of a 100-yard touchdown return that was a 14 point swing in the game. (This was the only touchdown Toledo scored). Sunday, the Redskins lost to the lowly Rams, on a long TD return on a fluky, fluky play. That touchdown was...wait for it...the only touchdown that St. Louis scored. What a bad football weekend.

One another and much more positive note, I may have invented a new incredible staple in my football watching menu:

THE STURGER

The sturger is an incredible thing. It's the combination of a 3/5 lb hamburger topped with a thinly sliced, marinated steak, about the size of a hamburger bun. I must say that it was one of the most delicious things I have eaten in a long time, though I can't say that I really was left wanting a second one, which made my friend Richard's double play seem quite amazing.

I think I will be marketing this idea to Carl's Jr, leaving the software profession behind. The sturger is just too good to ignore, and I think I will be able to retire in a year, tops.

Software Estimation Is Hard

So as part of my new role at Sportsvite, I am taking over the leadership of development on partner projects. These are usually slightly smaller projects that are either directly on our site, or somehow interfacing with our site. While they are smaller, they are a lot MORE of them. Like, currently we have six projects ongoing, and I have to estimate all of them.

I don't know how other software developers feel about estimating projects, but for me, it's always the most difficult part of my job. If I developed software like I estimated it, I would be in serious trouble - it would go something like this:

"Here is my code. It may or not work, depending on A, B, and C, and it could be right, but probably not, and you could probably take the expected response time and multiply it by 1.5 to get a more accurate number."

That probably wouldn't fly, right? But for some reason, in software estimation seems to work like that. I think that's kind of crazy, but there hasn't been any better methodology put out there, really? Has there?

From wikipedia on sofware estimation:

The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion is a serious problem for software engineers. The use of a repeatable, clearly defined and well understood software development process has, in recent years, shown itself to be the most effective method of gaining useful historical data that can be used for statistical estimation. In particular, the act of sampling more frequently, coupled with the loosening of constraints between parts of a project, has allowed more accurate estimation and more rapid development times.

So I am not alone! This is a problem for other people, which makes me feel better. There are methodologies:

Function Point Analysis
Proxy-Based Estimating
Evidence-Based Scheduling

The problem is that, especially in a small shop, we

a) don't have comparable projects that can be used to provide historical data, especially for partner projects that are often more one-off than core product development. I can say with some confidence how long it takes to add a new Struts 2 action and mapping - that part is easy, but what about the elements on the page? What about the logic?
b) don't have the infrastructure in place to really record time spent on any one task, and often find that if we did, it would be inaccurate because we wear so many hats, each hat being taken on and off randomly throughout the day/week.
c) can't afford just yet to spend a lot of time making exhaustive estimates, because that's time that won't be spent in construction and testing.

I wish there was a silver bullet that you could shoot at this problem, but it seems like there isn't. Like anything else, there has to be a point where you make something a priority to really solve it, but it's become such a joke in the industry it seems, that people aren't trying too-too hard to really get good estimates.

Ah well, if anyone has an idea, or a good experience as a successfull estimator at a small software outfit, please feel free to leave a comment describing how you did it well.

Obscure Things Every Java Developer Should Know Depending On Who You Talk To

In my career, I have found that the best way to learn something is to give a presentation on it. In lieu of that, perhaps writing about it would be a good way to make it sink in, and hopefully someone else can stumble across it and benefit from it as well. Here are some of those things:

hashCode() v. equals()

The following comes from this awesome site javapractices.com:

All objects have both identity (the object's location in memory) and state (the object's data). The == operator always compares identity. The default implementation of equals compares identity as well. Fun facts:

• if a class overrides equals, it must override hashCode
• when they are both overridden, equals and hashCode must use the same set of fields
• if two objects are equal, then their hashCode values must be equal as well

From an interesting blog post on hashmaps and hashcode():

When an object is inserted into a HashMap, the position at which the Value object is inserted in its internal Entry-array depends on the hashCode of the Key object passed in. The hashCode generated by the Key object is not used directly, but is processed by the hash(k) method.

Immutable Objects

What is an immutable object?

Immutable objects are simply objects whose state (the object's data) cannot change after construction.

Why are they so good? They:

• are simple to construct, test, and use
• are automatically thread-safe and have no synchronization issues
• do not need a copy constructor
• do not need an implementation of clone
• allow hashCode to use lazy initialization, and to cache its return value
• do not need to be copied defensively when used as a field
• make good Map keys and Set elements (these objects must not change state while in the collection)
  

Wanna learn this stuff visually, without paying tuition??

CHECK THIS OUT - Cal Berkely Data Structures Lectures (kinda awesome)

This is one of those "man the internets are sweet" type things. I will use this to learn all the nasty bits that I don't really want to but might have to.

Humility

Every so often you get to thinking you are pretty smart, and fortunately, someone or something is waiting around the corner to snap you back to reality. I think the only way to get better is to realize that you aren't very good at something. I think that this is good for the soul. The problem is, what if what you need to get better at is something you don't want to get better at?

As a programmer the next step is to be a better programmer, right? But a lot of these high-paying programming jobs that are out there have these barriers in front of them. They are made of giant heaps of time complexities, big o notations, stacks, queues, data structures, algorithms, and all sorts of other terribleness. I don't know any of this stuff, and the only thing that makes me want to learn it is so that I can tell other people that I know it when they ask me. I should want to know it to know it.

In my last job I did a ton of interviewing people, and I didn't really bother to ask these types of questions - why not? Obviously a) because I don't even know the freakin answer, but also b) because I can't really fathom how it was honestly relevant to the position.

So the question is - should I bother to learn this stuff just so I can get a job and not use it, or should I not bother, and then only get jobs in the future that don't require the brainteaser quiz answers? I think I know the answer, but I really dread it. Sigh.