I did have one problem that after reading several articles I would keep getting a white screen. I have hundreds of feeds with thousands of articles and interrupted a sync – so maybe that was the cause.

The app is so good I missed two subway stops on the way to work. Woops! But I recommend anyone who has an iPhone and a Google Reader account to get this app.

I am in no way affiliated with the Byline team.

I’ve never been the zealot that makes sure all code is perfect before shipping. I also recognize the tremendous value that aesthetic code brings (that’s why I’m a ruby guy). However, the important part of writing code is getting it out to the users. Those users might be your fellow coworkers (if you’re doing something back-endy) or they might be consumers.

My code will not matter unless someone is using it. So I get it out quickly.

That being said, I’ve seen us cut corners too many times and it always comes back to haunt. It costs hours and hours cost dollars. Bad code is not good for anybody.

My users will suffer from bad code because I won’t be able to react to their needs in a timely manner.

I think I have been intuitively following a pattern now for a while that seems to work out. I’ve been calling it “Path to Pretty” in my head.

It’s ok to ship code that I would consider lacking if the intent and next steps for improvement are clear.

By clear I mean that I must be able to go back in 2 months, look at the code and intuitively see what I was trying to do. If it’s not fully optimized or there are 20 extra lines, so be it.

As long as there is a clear path to pretty I now consider my code shippable.

Footnote: I’m sure I’m not the first person to do this and there’s probably some other name for this technique. This article was mostly for my own selfish benefit.

I started looking around for ruby libraries, but nothing was as mature as I would like. I forked a branch on github and chugged along on getting the jruby and c versions to work with the same api.

Zookeeper exposes a super simple API, but with that simple stuff you can build a lot of complex cluster logic.

A limited api of create, delete, get, set, watch lets you do some really advanced things around a cluster.

Examples

I added some abstractions based on the Zookeeper recipes.

Locks

Message Queues

I also implemented a simple message queue on top of zookeeper. However, because of the way the zookeeper "children" calls are made (returning all children), I wouldn't recommend using this for queues where pending messages will reach into the thousands.

More...

There's a ton you can do with this thing (priority queues, meta data store, etc). I think it's a nice addition to the ruby toolset.

I'm just pondering now... trying to flesh out what I think is going to happen and how we can embrace it sooner.

TO COME:
Events: Modern JavaScript architecture is actually pretty powerful, how can we take the "bolted on functionality" approach to servers.
Messages: They're kinda like events right?
Request/Response Cycle: it's probably dead?

I love the *looks* of the new Facebook javascript API. It's got one major flaw though. It doesn't work in Safari or Chrome. I have an app setup to use http://localhost:7000/ as the connect url and everything works *great* in Firefox. Things even work mostly ok in safari or chrome... but as soon as you try to launch the permissions dialog box you get the browser cycling through "unsafe javascript attempt to access frame with URL."

Best part about this whole thing is: the facebook developer forums throw the *same* error.

Also, when I try to create an account on the forums (not using facebook connect) I get a "cannot connect to socket" error.

I guess I go back to their older clunkier API? Seems to be a number of complaints but no answers from Facebook.

Any ideas?

UPDATE:

That error just keeps growing and growing.

I'm initializing my facebook like:

Minimal Repro:

If you put the following HTML at 127.0.0.1:7000 and hit the page you are UNABLE to do the following from the console:

http://croonmytune.com

or read about it here: http://jumpcanopy.com/?p=21

Then I came across this article: http://stackoverflow.com/questions/1249282/set-method-to-put-in-rails-xml-requests

So... if you're using prototype your "put" methods look something like this:

You can skip the last 10 minutes or so when he dives into this odd crazy future... but the beginning part really makes you think about how you can add game theory to any business you're in. I really like the idea of experience points and leveling up for class. That's something any event-based business could really get into.

h/t Andrew Holz. via fury.com

You can also check that your multi-threading is active by seeing if ActionController::Base.allow_concurrency is true.

We add ::RAILS_DEFAULT_LOGGER.fatal { "Mulithreading is active? #{ActionController::Base.allow_concurrency}" }
to the end of our environment.rb to let us know that it worked.

Google Analytics Launches Asynchronous Tracking
Tuesday, December 01, 2009

Today we're excited to announce our new Google Analytics Asynchronous Tracking Code snippet as an alternative way to track your websites! It provides the following benefits:

* Faster tracking code load times for your web pages due to improved browser execution
* Enhanced data collection & accuracy
* Elimination of tracking errors from dependencies when the JavaScript hasn't fully loaded

This is excellent news. I had implemented something similar on my own, but it always had its own problems. I'm glad to see it officially supported.