A Work In Progress

מספר המוקד העסקי של אורנג'

Fri, 01 Apr 2011 11:22:00 +0300

מספר המוקד העסקי של אורנג’ בחיוג ללא מכשיר אורנג’ קיים:

074-7054050

לא יאומן שהייתי צריך לחכות חצי שעה בטלפון רק כדי להשיג אותו.

Education 2.0

Sat, 12 Mar 2011 05:13:41 +0200

Seeing Kahn speak at TED reassured me that the classroom indeed has a future (current state: sucks ass). The day is not far when Kahn’s Academy hands out degrees as honorable as Harvard’s or…

Cutting your losses

Wed, 16 Feb 2011 18:04:24 +0200

Cutting your losses:

Admitting to failure is one of the suckiest experiences in a human life. You never know whether you’re a lousy quitter or the only one going against a herd of idiots. This psychological discomfort…

How do you study your users?

Tue, 08 Feb 2011 12:36:49 +0200

There are many options for studying your users: Analytics for every single click in your application; Conversion funnels; recordings of sample user sessions etc.

I find that for product definition and understanding, it’s really effective for me to get intimate with a handful of users. Talking with them or watching their sessions is more effective than crunching statistics.

For measuring success, though, you’ll have to look at those Excel sheets.

Why Google is so different from any other big startup

Thu, 03 Feb 2011 13:28:01 +0200

Google was a “build it - and they will come” kind of company. Their edge was completely scientific: Scoring pages against queries in a very meaningful way.

Most other startups companies, Facebook & Groupon included, have a substantial business side to their operations. The way it looks to me, most of their effort was in user acquisition & business development.

You need a good business man to launch companies such as Facebook & Groupon. And this business man is not very different than any traditional business man. Google, to contrast, didn’t need such persona.

…And many of Google’s current difficulties might be explained by understanding this heritage.

Current web frameworks weren't built for AJAX

Wed, 26 Jan 2011 20:54:02 +0200

The more I work with Rails (and see others with django, cakePHP et al.) the more I realize how ill-suited these systems are for AJAX-y operations.

1. in AJAX, editing is done on fields, not models

Rails’ opinionated software approach assumes every entity is rendered exactly once on the page, thus, the default behaviour is to have an id tag and a single form action that deals with all fields of the entity. This prevents me from having editable elements of several models scattered around a webpage (as they should, in many cases).

An example would be a guest list for an event. I should be able to add or remove guests (i.e. editing the “event” model) but I should also be able to edit a guest’s details (i.e. the “guest” model). I might also want to send invitations to specific guests (“invitation” model) and this should all happen in the same UI-space.

2. rendering should be client side

In an AJAX-y environment the client should be responsible for rendering, while the server should provide the data changes. e.g. server: “Post.title has changed” client: <changes title tag in head section, as well as h1 tag and text references to post.title>

client-side rendering, and smart server-side notifications make implementations of “advanced” AJAX-y features, such as continuous scroll, vastly simpler. A good web framework would also allow high responsiveness by performing the the update immediately on the client side when a user performs an action, and announce asynchronously if a problem occurred. This is most clearly seen in Google Docs. But everyone uses it (e.g. Facebook).

3. there is no page

Facebook works with “pagelets”, which are mini-pages brought together in various layouts. Similar in concept to Rails’ partials, these pagelets are dynamically added and removed from the page. In fact, with new Chrome versions there is no page reloading at all in Facebook. A strong javascript framework is required to determine the layouting and logic in adding and removing pagelets from a page.

Ruby is for SWAT teams

Mon, 24 Jan 2011 14:10:24 +0200

In Ruby projects one finds many code snippets similar to this one, taken from an RSpec presentation:

a.should equal(b) # both pass if a.equal? b
a.should be(b) #

Ruby’s DSLs are one of its prominent abilities, and lib writers go to lengths in making their DSL as talkative as possible - allowing you a wide selection of “wording” for your code.

This is why Ruby is so great - and so dangerous. Maintaining code where the same function has 10 aliases can be very confusing. It takes a disciplined, small team to decide when it best serves the interest of code clarity to actually use more than one alias.

This becomes far, far worse when you capitalize on Ruby’s dynamic features, such as class overrides and method_missing. Beginner programmers might pick up some extremely bad habits working with Ruby.

Mark Zuckerberg: The evolution of a remarkable CEO | VentureBeat

Sun, 23 Jan 2011 00:56:19 +0200

Mark Zuckerberg: The evolution of a remarkable CEO | VentureBeat

Official Google Blog: Google search and search engine spam

Sun, 23 Jan 2011 00:38:48 +0200

Official Google Blog: Google search and search engine spam:

Round 2: FIGHT!