מספר המוקד העסקי של אורנג’ בחיוג ללא מכשיר אורנג’ קיים:
074-7054050
לא יאומן שהייתי צריך לחכות חצי שעה בטלפון רק כדי להשיג אותו.
מספר המוקד העסקי של אורנג’ בחיוג ללא מכשיר אורנג’ קיים:
074-7054050
לא יאומן שהייתי צריך לחכות חצי שעה בטלפון רק כדי להשיג אותו.
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…
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…
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.
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.
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.
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? ba.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.
