What's it all about, Alfie?

Today I was using Skitch to add a simple screen grab to a web page that I was building, and when I tried to save it to the Skitch.com server, is told me that Skitch had transitioned to Evernote. In short - the server shutdown they had talked about was upon us.

Skitch was dead.

But I was ready. I had signed up with PinkHearted.com, and that gives me everything I need from Skitch's back-end. Even if that weren't enough, I have a CloudApp account, and can use that as well.

So Skitch is alive and well. Just not with the guys that brought it to life.

It's sad to see something like this, but the market works in sometimes sad and gloomy ways. I'm just hoping that someone picks up the mantle of the original Skitch team, and makes a worthy successor. With a reliable back-end.

I had no idea that the decompression I'd feel from leaving Finance and entering a pseudo-startup. I really didn't. In the beginning, I was thinking it'd be really nice. Sleep in… have lots of vacation… take your time learning new things - what's not to like about that? But that's not the whole picture, is it? It's never as easy as one quick look might suggest.

Today is another great example of some of the problems I'm facing in moving from where I was to where I am - and it's not about jerks, or mean people… it's about being in a Team, and having a Team member decide that he knows better than you - even though he's got far less experience than you.

I'm currently in a team that has lost three people - one to leaving the company, and two to other positions in the company. Unfortunately, two of those were really good guys, and I'm going to miss their approach to software development. As I told my manager yesterday in a 1:1, every project has "grunt work" to do - things that have to get done to move the project forward, and get deliverables out the door. It's called production for a reason.

Now I'm good at delivering code. Really good. Primarily because in Finance, you have to be, or you have to find another job. So I got good at it. That's not to say that's what I prefer to do, but I know that if the team doesn't deliver, it's not going to be long before they look to "lighten the load" of the team. I've no intention of that happening to me.

So I pick up the work if it's sitting there.

In a good team, others do this as well, so any one individual does a little, and the load is not dependent on one guy doing it all. But if you're in a group of people where they don't see that as "necessary", or they feel it's "beneath them", then you end up with a group that's very dysfunctional. In my case, that's where I am - doing about 90% of the code that's delivering.

This by itself, wouldn't be so bad. After all, I know what I'm doing, I trust that management sees the effort I'm putting in, and I'll get compensated for it. Not bad. But for the last several days, one of the guys in the group has been working on integrating the log files with an automated scraper - splunk, and while it was possible to build all the queries he needed with the tools at hand, and the log lines as they were, he decided that it was really time to make the logs less human readable, and more easily used by splunk.

This, I argued, wasn't a good idea. Log files are for people, not machines, and this was making them less readable, and that was bad. I tried to convince him that this was a bad direction, and he'd have none of it. No way I was going to convince him.

All this work - three days worth, because he wanted to gather a series of numbers in one query - not two.

Really!?

Two queries is "Bad"?

I had to walk away. I tried to talk him out of it. Just like I told my manager I'd try to do. But he was insistent. Totally unwilling to compromise. Yet I caught several errors he'd made because he wasn't paying attention to what he was doing.

I really hate this. I'd rather he just take time off and not be a problem as opposed to making things worse for me. And that's all he's really done. He's made the logs worse, and for no good reason whatsoever. None. The data was there, it's now there, but in a non-human-readable form, and he thinks that's "even"?

These kids, and that's all I can think it is… these kids have no respect for experience. None. But hey… why should they? They have done it all, right? They have built it, and it only took three days. Total crock.

Every now and then I find that CouchDB on my laptop really needs to be restarted. Because it was installed with Homebrew, it's for an entry in my ~/Library/LaunchAgents/ directory - so it's best to do it nicely. Meaning don't just kill it. The simplest way to do this is just:

  $ cd ~/Library/LaunchAgents
  $ ls
  org.apache.couchdb.plist
  $ launchctl unload -w org.apache.couchdb.plist
  $ launchctl load -w org.apache.couchdb.plist

The unload stops it, and the load starts it again. Very neat and clean.

We have been trying to move to JRuby 1.7.0, and running into a fair share of issues along the way. But still, we press on. Today we tried again, and failed, being stuck by another Dir.glob issue that has been a persistent little problem for us.

There are a lot of reasons we want to be on JRuby 1.7.0 - better socket implementation, better handling of exceptions up the stack, and better ruby 1.9 compatibility. All good things. But not being able to deploy in a jar has been a real pain. We need to be able to do this, and without it, we really can't move.

So we have been digging into the issues. Thankfully, for the latest one we have a work-around. It seems that JRuby 1.7.0 can handle Dir.glob, but only if the "path" does not start with jar:. Very interesting.

The work-around, then, is very simple:

  def project_root
    @project_root ||= File.dirname(File.dirname(__FILE__)).gsub(/^jar:/, '')
  end

will get the root of the project in the filesystem or jar, and then if it starts with jar:, it'll strip it off. We use this for all file pathing, and we're good to go!

This morning I noticed that Google Chrome dev 24.0.1305.3 was released with some really nice updates including the V8 javascript engine 3.14.5.0 and a significant update to how bookmarks are handled in the omnibus. From the comments, it's pretty clear that the omnibus is used by a lot of people for much more than a place to type a URL or a google query - which is nice, but it's certainly not behavior I'm looking for, so I never really "missed" it.

But as always, it's great to see the progress - even if it's something I don't really use.

I've built a few rule-based systems in my time. Nothing like an Expert System, but enough to know that the business logic of most businesses is a complex thing, and care needs to be exercised in creating the rules, naming the rules, putting the rules into a cohesive system, and in general, making it work. What I'm a little surprised about today is that this isn't something that people seem to naturally pick up on.

I'm looking at code written by a smart guy. He's no dummy. He's got experience as well. Yet it seems that he's into making the worst named rules, and combining rules in ways that it's not clear what's being checked (asserted) in a rule, and why. The resulting combination of these rules is worse that just a series of if/then/else statements because it hides the things that are being checked behind very poorly named methods.

Yikes!

So today I did a lot of clean-up. The rules are clear, more reasonably named - when the functionality changed, and the layout is far better. I was pairing with someone and they weren't able to follow until I made it clear that there really was a "good way" to write these rules, and combining completely different rules into one wasn't really a "winning way".

It's not done, but it's getting closer, and I'm really surprised that this part of the codebase is so easily done. I had expected more, but again, it was blown out of proportion due to the things I'd heard from the people working on it.

Get good data. Understand it. Write good rules. Combine them. It's really not all that hard.

Today I had a really sad realization - there are a lot of lazy people in the world, and unfortunately, I have the pleasure of working with a few. These aren't the Code Monkeys I've written about several times - these are just really honest to goodness lazy people. Just looking to do the least work they have to do in order to get by. Fighting about it in meetings even. Amazing.

Case in point: Countries. We get the demand for things from a service that gives us location information as postal codes. In the US, that's great as a 5-digit zip code is just the right "size" for the localization of the demand. But in Canada, I found out that I should only be looking at the first three characters of the postal code. OK, I can do that, but the question then becomes: What country am I in?

I was thinking it would be a simple thing to have the service that generates this data to add that in. After all, it knows the postal code, so it's got to know the country - right? Well… as it turns out, it should, but it's written by some really bad coders, and it doesn't. And these bad coders are lazy to boot, and aren't interested in adding it.

OK, after about 30 sec of this "debate", I just said I'd do it. It took me about 30 mins to add this to my code, and now it's done. They later realized that they needed this as well, so they have hacked something together that I couldn't possibly care less about, but whatever. I have the country now.

I'm now able to map the postal codes right, but it's amazing how hard some people fight against making their code better - only to later realize that they should have made it better in the first place, and put another hack on a hack, etc.

Not me. Amazing people.

One of the problems of working with a lot of string data posing as enumerables, is that people are fuzzy logic kind of things, and the difference between "Wed to lead" and "Web to Lead" is totally lost on most people. But for the logic in the computer, they are apples and oranges. Unfortunately, we can't really turn them into enums, we have to leave them as strings. But the look-up tables have a certain case - defined by the Data Science guys, and that's something I had to work around.

Sadly, I couldn't just lower-case all the data as I read it in - that would adversely effect the look-up results. What I needed to do was to specifically lower-case the components of the key for the table, and leaving the rest of the data alone.

My goal in this little bit was to keep the knowledge of the key generation in the class doing the look-ups, and I got what I wanted. But I needed to make it a little smarter than it was originally. Not bad, and in the end, I don't have to worry about case of any of these "string enums".

There are times I'm amazed I keep my mouth shut. Today has given me several such times. Really. I'm grateful for this job, I truly am. I like that I'm learning ruby, and there's a lot of interesting work there, to be sure. But I'm working with the Code Monkeys, and it's really getting on my nerves today. Really.

One instance today was best typified by the mental picture of working around a bunch of eighth graders. Yup, kids. I enjoy chatting just fine. There's nothing wrong with learning more about your co-workers, but there's got to be a point where you turn around and get to work. After all… we're here because it's a job, not a clubhouse.

I don't know about the rest of the group, but I'd be home if it didn't matter to anyone else. I don't love the chair, or the desk, and the commute - well… don't even get me started. But it's OK - for a place to work.

I just seem to be in the vast minority some days. They want to play around, giggle, watch bouncing cats on a 40" plasma TV for fun - for far, far too long. Again, I like my job, but this is really getting annoying.

And if I say anything, I'm the kill joy, or the "old" person that doesn't understand the value of fun. After all, they'll get the work done - eventually.

Please… if you could get all the work done in the time you give it, think of what you could accomplish if you came in before 10:00! Or stayed after 4:00. Or didn't mess with the bouncing cats. It'd be like you had an entire day extra. Wow!

But that's only part of it… the other part is what I blame on the Agile approach, and it's focus on continual refactoring.

Again, don't get me wrong, I like that there's a focus on refactoring in the workflow - it allows you to go back when things have really changed, and fix them up the way you would have if you'd have known what the end-result was really going to be. But there should be a limit to this. Fixing broken, or badly laid out code is OK - if you're adding something, but if you're just looking around and just decide to change the code "because", then what you're really doing is wasting time. Lots of it.

You're also really running the risk of breaking things - unless you're really careful. I'm not convinced a single one of the Code Monkeys I work with is really careful. Smart - yes. Careful - not in the least.

There's no solution because it's all a matter of degree. I may think it's "too much", but that's an opinion, and as long as management is OK with the productivity, then there's nothing that's going to be done about it.

This morning I wanted to again try to get JRuby 1.7.0 installed and working for our project at The Shop. It's not that it wasn't working - in fact, I figured out that it was all in the handling of '/../' by Dir.glob() in JRuby - but we have a way around that, so we're good to go. No… this was meant to wait until 1.7.0 final was out, and then move to it as a group.

The test repo I've been working with is pretty simple, but it has all the components I need. It's got an .rvmrc that points to the right version of JRuby:

  export JRUBY_OPTS="-Ilib --1.9"
  rvm use jruby-1.7.0@jar-test --create

and so I should be able to simply install JRuby and use it:

  $ rvm install jruby-1.7.0

but when I do that, I got all kinds of problems. Problems with bundler, problems even with rvm. So I go to the jruby channel on IRC and ask what's up? I get the answer:

  $ rvm get head

Seems the latest stable rvm can't handle the install. I had to get the very latest version to make it work. Yikes!

After that, you might be tempted to install jruby-1.7.0, but don't! There's one more thing that's a known issue with Mac OS X and rvm - the CodeSign with OS X. Currently, it's not working, so you have to:

  $ chmod -x $rvm_path/hooks/after_install_codesign

to make it not executable. This will then leave you with something that will work when you install jruby-1.7.0:

  $ rvm install jruby-1.7.0

Still, when I did that, I was able to then use it:

  $ cd jar-test
  Using /Users/bbeaty/.rvm/gems/jruby-1.7.0 with gem set jar-test
  $ bundle install

and everything gets up to date.

Very cool - but had I not messed around with this for an hour, I would have been a lot happier.