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.
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.
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.
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.