Memeorandum

Memeorandum is another one of those websites that I first put in the Web2.0 Hot Air Bucket. That was until I tried it out and got hooked on it. It gives you a nice overview of what’s going on in the world and a whole lot of sources if you want to go a bit deeper.

It’s really neat to see how the topics shift from day to day. Studying the data flowing around the web is a really interesting problem. There really is so much out there these days and being able to make sense of the patterns moving about is valuable.

Give it a shot if you haven’t already.

Bloglines acting up again

Seems to be some issue with their service. Feeds are reporting new stories, but then only showing feeds titles when you click. They also won’t show as read after clicking. Not exactly working properly.

I love the service, it really is great, and it’s free so I can’t complain too much. But, I really do notice when it’s acting up.

It’s almost to the point that I’m ready to implement it for myself. Could be fun to play with some the concepts. Spidering, AJAX, document management, search,… There’s all sorts of fun stuff in there. Well, we’ll see. So much to do, so little time.

Update 2/2
After sending in a feedback to bloglines describing the problems I was having they seem to have fixed it. Took about 3 days, but everything is back to normal again. Good job Bloglines.

Loving Emacs

I’ve been getting several emails lately from the ACM about nominations for the best classical computer books. They’re holding a vote to find the best of out of print computer books. There was an initial nomination process and now they’re into the voting. There is even a wiki setup to peruse and comment on the nominees. This got me going on a search for expanding my programming knowledge. I’ve exhausted the commonly available sources and have to look far and wide for new things to study. In so doing I’ve come across several books by Paul Graham and Peter Norvig on Lisp.

I’d heard a lot about the language over the last several years, but never had the time to sit down and try it out. There have been several articles that have popped up lately about the positive experiences in learning the language so I thought I’d take a look.

My studies have started with three books, “Structure and Interpretation of Computer Programs”, “Ansi Common Lisp”, and “Paradigms of Artificial Intelligence Programming, case studies in common lisp”. I’m moving through all three books at the same time and so far I would highly recommend these to anyone trying to get to a deeper understanding of computer programming. There was also a history of Lisp on Paul Graham’s website that is a very interesting read. It’s rather awe inspiring that Lisp is second only to fortran in age, but has concepts that most other languages are only now catching up with.

As a side effect of studying lisp, I’ve had to pick up using Emacs as an editor. I had used vi primarily for command line editing, but I’m really starting to take to emacs. The commands seem more intiuitve to me and a bit easier to get more power out of the editor.

Well, I’m excited about the mind stretching to come. Not sure how useful lisp will be in terms of paying the bills, but it should be good for an intellectual excercise. Besides, keeping the brain sharp is job #1 for a programmer.

When to worry about scale?

I’ve been working with a startup since September and it’s been a great learning experience in how to start a company from nothing. I was actually the first full time employee of YouService, and was brought in to beef up their server side experience. I came in with a fair amount of experience working with high volume J2EE, having spent several years as the lead engineer on webshots.com and was tasked with designing a system that would scale to millions of users.

Working with a startup is very different than working with an established company. The skies the limit on what you can do and often you need to focus on what’s important if you’re going to get anything done. I’ve tried to balance out some ideas on where we should be spending time.

While I believe it’s always a good idea to keep the future in mind and be prepared for success when you’re building systems, you can also take this way too far. You can paralyze yourself worrying about being able to handle millions of users when first you have to handle hundreds. In order to handle hundreds of users you have to work properly and as expected. For a startup keeping this balance is key. Get the first customers in the door, paying, and happy before you put too much time worrying about the millionth customer.

Inorder to get the first happy customers, you have to be able to deliver a product that people will pay for. For this to happen the product has to work as expected and be reliable and stable. So for a startup these are the key points. The system needs to be bullet proof more than anything else. If your first few customers find issues, they’ll leave and there won’t be any more following.

So this is where the balance comes in. How to design bullet proof systems without painting yourself into a corner when it comes time to expand. It’s also much easier to calculater ROI of expanding if you have actual paying customers to set up that equation instead of estimates pulled out of nowhere.

AJAX, Thick or Thin client

There’s an interesting blog post discussing the pros and cons of rendering a page on the server or client side. The main point was that by using a technology such as JSON to only transfer the data necessary for the page to the client and keeping all display logic in javascript(Thick Client) you reduce data transfer requirements. The greater the amount of data that needs to be transferred the more sluggish the app will feel.

An area that I’ve been working with and have seen mentioned over at Ajaxian is to use a Thin Client approach (logic on the server side), but then use hidden divs and use local javascript to manipulate the divs. You take a slightly higher hit up front for page load as extra non-visible data is passed to the client, but later interaction time is reduced as further communication isn’t necessary. This also simplifies app development by leaving the logic on the server. Not only is the development of a full MVC environment difficult in javascript, but you open yourself up much more to browser incompatabilities.