What you have to do is, “Grab the nearest book, turn to page 56, and post the fifth sentence to your blog.”

Here’s mine:

“You must make it very clear that this code is disposable, incomplete, and unable to be completed.”

- from: The Pragmatic Programmer by Andrew Hunt & David Thomas.

The chapter is called, “Prototypes and Post-It notes”.

This book has been on my desk for months. I kinda stalled during chapter one to read other more exciting books. I will read this book one day, it is brilliant.

When a friend approached me a few months ago with a new idea for a new kind of enterprise social software I was a little skeptical at first, particularly because I didn’t want to stop working on what I was working on.

However after a good amount of research and prototyping, I am now totally convinced that we have an exciting and unique proposition for medium and large companies. I believe it’s software that many will believe they need even though they haven’t yet seen it.

I love TED talks, and this one from David Rose on pitching to VCs is brilliant.
Enjoy.

Having spent quite a lot of time and money training for my PPL, I have learned that it takes quite a lot of time and money to fly light aircraft. With 100 hour overhauls, skyrocketing airport fees and a continuous fuel burn - it all adds up.

To top it off, here in Sydney at least - it’s arguable exactly how much freedom flying a plane actually buys you.

Recently I’ve been staggered by how much technology has changed things and I hadn’t even noticed.

Hobby scale microelectronics is now so approachable that a software developer with the most primitive understanding of electronics can build industrial quality prototype products.

Check out what engineering and modern composites have done for the humble sport of gliding!

This video, shot in France, shows a glider which is tow-launched to a low altitude. Two gliders then circle together in a thermal soaring to a high altitude. They then head off into the mountains to find a ridge to surf along using the updraft as lift.

Afterwards, they head out of the peaks and over a lake to find another thermal to ascend in ready to surf the next ridge!

I’m pretty keen to start my training this summer - where do I sign up?

“I think it’s important not to confuse OAuth with OpenID. I think OAuth might be very useful indeed, and I’d like to see it succeed. Tying it to the Titanic will not help.

…

From a site developer’s standpoint, OpenID solves the wrong problem. Nobody is avoiding your site because they have to remember a password. That requirement hasn’t killed eBay, Gmail, Amazon, PayPal, Facebook, Plentyoffish, HotOrNot, news.yc, or any other site in history. Frankly, if people are avoiding your site, it’s probably because it sucks. Spend your time making your site suck less.

A good way to make your site suck less is to eliminate the need for signups at all, to delay that need as long as possible, or to get the user so excited about the site that they barely notice the signup process. OpenID doesn’t do these things. The problem with signups is not the typing, remembering the passwords, or even securing the passwords — it’s the mental overhead associated with deciding whether or not you want another relationship in your life. Can you trust this new site? Will it waste your time? Will it spam you? Will it hit you up for money, forcing you to feel embarassed as you say no over and over? Will your friends find out that you signed up on the site? Will the site plaster your Amazon purchase history all over the open Internet?

Signing up for a site is exactly like making a new friend, and if you think it would be great to automatically be friends with everybody in the world, find a recent multimillion-dollar lottery winner and ask them what that’s like. Managing your relationships takes thought, attention, and judgement. Nobody’s automated that yet.”

Quality.

Source: http://news.ycombinator.com/item?id=97625

PS: I also recommend: What OAuth is for.

All I wanted to do was look at a friends photos!

I’d forgotten that I’d installed the Woopra for stats on Jetfar.

It has a desktop interface that provides a very impressive real time view of who’s on your web site at any moment in time, including a very bondesque world domination full screen view.

Using the lo-fi web based interface you still get detailed real time statistics, including this chart of screen resolutions for unique visitors:

Note in 11th position, we have 320×396. Which, at ~1%, is almost on par with 800×600.

Given that the iPhone 3G only came out in the last week its going to be interesting to watch how this trends over time.

For the last couple of weeks I’ve been playing with Google App Engine.

In case you’ve been living in a cave for the last month; App Engine is a mostly complete, sandboxed, Python 2.5 environment with a WSGI web server and a very interesting Datastore API.

Production Like Dev Environment

App Engine comes in two flavours. Firstly, there is a development server which contains everything you need to run app engine code on your desktop (mac, linux, or windows); it includes the datastore, a web server and a rudimentary web interface for the datastore.

Simple to Deploy

The development server comes with a ‘deploy’ feature that lets you deploy, with pretty much one click, your whole application to Google’s infrastructure.

What’s so cool about it?

Firstly, ‘No Assembly Required’. That means no fiddling with database parameters, creating databases, users, permissions, no installing updates, patches, libraries, no configuring web servers, firewalls. Nothing. This, in itself, is a HUGE time saver.

Secondly, it’s Python, and it’s WSGI. That means you can use Django, web.py, Pylons, or just about Python framework with it. If yours doesn’t work out of the box, then it shouldn’t be hard to modify to fit.

However, in keeping with, “no assembly required”, App Engine comes with it’s own minimalist webapp framework.

Now webapp is actually very nice to use. It uses the elegant and simple WebOb library, and while it doesn’t impose any module / directory convention, you can easily adopt whatever structure you like.

All of this is cool, but it’s not what’s really cool.

BigTable

BigTable and the Datastore API are awesome.

A BigTable is a sparse, distributed, persistent multi-dimensional sorted map.

Ostensibly, A BigTable is an alternative to a relational database. Google engineers designed BigTable out of necessity as a mechanism to facilitate the storage, indexing, and retrieval of petabytes of arbitrary data across multiple distributed data centers.

We all use BigTables every day through Google search, Gmail, Google Maps, Google Earth, etc.

Datastore API

The AppEngine Datastore API exposes BigTable to our Python applications as an object persistence API. It does this in such a simple way that it almost escapes you just how beautiful this is.

Take a look at this model definition:

from google.appengine.ext import db
class Pet(db.Model):
    name = db.StringProperty(required=True)
    type = db.StringProperty(required=True, choices=set(["cat", "dog", "bird"]))
    birthdate = db.DateProperty()

That’s it. No Hibernate mapping files, no database connection properties. Just a class definition.

If you write some code to query the datastore on a property, then the indexes are defined and created automatically for you at deployment time.

Expando: Dynamic persistent objects

App Engine comes with dynamic persistent models called expando models.

These really begin to demonstrate the flexibility of a BigTable over a relational database. A model that subclasses the expando superclass may have properties dynamically added at run time.

For example:

class Person(db.Expando):
    first_name = db.StringProperty()
    last_name = db.StringProperty()
    hobbies = db.StringListProperty()
p = Person(first_name="Albert", last_name="Johnson")
p.hobbies = ["chess", "travel"]
p.chess_elo_rating = 1350
p.travel_countries_visited = ["Spain", "Italy", "USA", "Brazil"]
p.travel_trip_count = 13

Map, Reduce

Google applications operate on a scale in excess of what most people consider high volume. To manage this, Google engineers developed a programming model called, MapReduce.

Users specify a map function that processes a key/value pair to generate a set of intermediate key/value pairs, and a reduce function that merges all intermediate values associated with the same intermediate key. Many real world tasks are expressible in this model…

As I understand it, MapReduce allows Google to use BigTable while taking advantage of the virtually unlimited parallelism provided by their underlying hardware infrastructure; which is famously a vast array of commodity cheap PC’s.

What does this mean for programming?

Putting MapReduce aside for a moment, I believe the the AppEngine datastore API provides a clear indication of the future of data persistence.

In Enterprise IT today, some of the biggest challenges and complexities arise from trying to make fast, reliable distributed and fault tolerant persistent indexed storage from relational databases, and making that available to application developers in a secure and simple way.

I believe that by redesigning persistent object storage form the bottom up, Google have blown away the multi square peg / round hole problems of objects, databases, servers and data centers.

In providing the AppEngine Datastore API, Google have shown us that we can take full advantage of BigTables in our current, everyday, mortal programming ways.

It’s like we’ve been using rocket engines and Google’s just shown us the warp drive!

BigTable and Why it Changes Everything first appeared on jetfar.com.

Remember the days when we developed for 640×480 and optimised for 800×600. Well those days are gone… or are they?

Screen resolutions have exploded in recent years with 1680×1050 now not uncommon. My Dell laptop three years ago had a 1900×1280 resolution. The twin displays in my cubicle are each 1280×1024. But I’m a geek who makes web sites, so I’m not typical, right?

A similarly skewed view of the world can be obtained from W3 Schools who publish browser statistics and trends derived from their own log files. Whilst the percentages they provide are perhaps skewed towards web professionals, the trends are useful, although unremarkable.

Behold, Liquid Fold. Liquid Fold is a cool little app-engine project built by Simon Willison (of Django) and Natalie Downe.

It provides a JavaScript bug that you can include in your web pages to record the actual viewport size of your unique visitors as opposed to the less useful screen resolution.

Most interestingly, they are sharing their global stats which offer some useful insights… 780 pixels wide anybody?

Check it out.

I met a very interesting team last week who run a successful advertising & marketing agency, and also are working on a web start-up part time.

In a more humble sense, this also describes what I’m doing: Building my start-up while contracting full time and having a real life.

I just read this article by Tony Wright, Bootstrappers Beware which is a good reminder of how long you can expect to be in this boot strapping phase, and what the end goals might reasonably look like.

This is one of the best, Paul Graham’s 2006 essay, “The Hardest Lessons for Startups to Learn“.

In summary:

1. Release Early

2. Keep Pumping Out Features

3. Make Users Happy

4. Fear the Right Things

5. Commitment Is a Self-Fulfilling Prophesy

6. There is Always Room

7. Don’t Get Your Hopes Up

…and what it’s all about: Speed, not Money.

Read the essay, “The Hardest Lessons for Startups to Learn“.