Twitter

Follow leybzon on Twitter

Tuesday, August 19, 2008

Struggle to be buzzword compliant

I realized that there is a new wave of buzzwords coming on. Here is my very small dictionary:

behavioral targeting – targeting ads based on user's patterns

taking an action on app – interaction but not installing social app, like in new Facebook profile

social advertising - accelerated distribution of news about user actions beyond organic content

soc ads - ads that use social graph

soc ads (alt)- advertising on social media

integrating branding – using brand names/logos to advance applications

social shopping - making buying descriptions based on friends opinions

"buzzword compliance" - using all of the above in speech or writing

Wednesday, July 23, 2008

Facebook Friends Connect

Is a way to extend external sites to provide:

  • FB identity
  • FB friends (relationship)
  • Feed to FB


 

Demo app at http://www.somethingtoputhere.com/therunaround

User experience:

login:

js login method requiresession(): detects state
of usr-FB relationship, log-in into FB if needed. If user has not authorised app -
present app auth dialog. If already has session - just go

init JS, require session


 

access FB data:

- FBML on external site - use JS FBML parser and replace in browser DOM with FB data

- JS based API to get FB data, REST API on the server site. Sessions work accross any API

- only small subset of FBML us supported at the moment


 

adding social content:

- use access API


 

Connections:

app developers can suggest connections (using
e-mail hash)

user get connect request on FB

Move content from external sites to FB app can register feed template (3 types of
stories)

call JS "showfeeddialog" to request user to

confirm data sharing on FB.

privacy protection:

app can cache data for 24 hrs (for performance reasons). Terms are the same as for FB platform

app can integrate data any way they like -

enable info sharing


 

SANDBOX is open, TFL - end of summer

More info: http://wiki.developers.facebook.com/index.php/Facebook_Connect

Wednesday, May 28, 2008

Scalability of Google IO

It was interesting to watch today how Google is solving scalability problems:

Problem 1: Conference registration lines are too long.
Google's solution: Let anyone in. No badges are required before 2 p.m.

Problem 2: Too many people who want to attend the keynote speech by Vic Gundotra
Google's solution: Still let anyone in. People can sit anywhere on the floor

Lesson: relax rules if they stay on the way of scalability

Thursday, April 24, 2008

Design & Learning from Viral Applications FB App lifecycle

Step 1

(Initial Growth):

Initial Growth (based on advertising principles) – all about conversion rates (#times people see profiles, canvas page, invites, activity stream, feeds). Goal MAX conversion rates for each channel. Consider long-term user experience. Effective (aggressive) methods at the beginning will not work later in app life cycle

Design/implement based on simple concepts. Viral channels are more important than features!


Step 2

(validation):

Goal: concept validation.

  • Iterate/execute rapidly. Viral loop. A/B testing. Do not complicate – it will make execution/testing/measuring. Goal: figure out features, do not be emotional, and be guided by data/metrics.
  • Use web matrix (Google analytics for conversion rates)

[Social Application classes]

  • Channel (superwall)
  • Content
  • Dating
  • Games (related to dating, affinity groups)
  • Gifts
  • Self-Expression


Understand audience, look at market size, potential penetration (set expectation right :). Ning has impressive numbers but segmented. iGoogle (10-15 Mil, virality is not clear yet, how to build initial friend list?)

  • Understand activity stream.
  • Focus on simple
  • Focus on activity stream that all users can engage into

Typical 30 releases/day during the post-launch phase.

Take extra care of 1-st impression (app about page is important!)


Step 3

(grows, tuning along the way)

Start with the call to action

Figure out conversion rate (make sure x*y>1)

Preview Page messages turning

App turning


Step 4

(Promote!)

Buy additional throughput, engage ad network

Make sure that viral loop works – otherwise money will go into drain.

Use different add network.

Cross-promote apps!


Step 5

(Engagement)

Congratulations!

How to make users to come back? How to make users to come back?

Saturated social circles. Critical mass.

Good functionality bring users back – tune for user experience! 1-to-1 becomes more important than invites. Use e-mails and messaging. Do not spam – interact by telling only when something happened.


Step 6

(disengagement)

Understand that every channel will degrade over time. Set your expectations right!

Location Web presentation at Web 2.0

Location Web

Location = context

Context -> higher relevancy -> user experience

Location is a killer mobile app enabler

Yoursite.com?lat=&lon=

Fire Eagle – location broker (get all inputs, have app (publisher) registered). Dopler as publisher. Fireball get access for the info

DO use FireEagle PHP library! (Update, query, integrate)

Geolocation methods:

Triangulation (WiFi 20[m], GPS 1[m], Cell Tower 2000[m]) {Loki JavaScript API http://loki.com/developers} Garmin device plug-in, get path data GPX

Association (IP Geolocation) {quova, ip2location}

Geo Term Extraction {MetaCarta Query Parser API, Urban Mapping GeoMods}

Geocoding {geonames (started with Tiger geoset in Postgres), Google, Yahoo, Geocoder.us}


 

JavaScript API

Browser.getGeoLocation() - LocationAvare.org

Mobile location

iPhone (WiFi, cell tower) and other mobile API

Symbian S60

J2ME/JSR-179

WHERE Widgets $3/mth for users, no need to have relationship with phone network provider – where wil do it for you {where.com}

SkyHook (WiFi only)


 

Cell Tower info sources

ZoneTag (yahoo)

OpenCellID

CellDB

WhereCamp unconference May 17-th, May 18-th. Mt. View

Important: only integrated (combined) location methods can provide reliavle location info


 

Geocoding Links:

  • geoNames web services: geonames.org/export
  • Google Geocoder class: code.google.com/apis/maps/documentation/services.html#geocoding
  • Yahoo geocoding API
  • Geocoders.us

SEO Optimization

Cloaking

(Serve different content, could be in violation of Google policy)

IP delivery is used to get around Google bot (detect if bot is coming from one of Google's computers)

Use English->English translation to detect/display cloaked page

301 redirect

And know when to use 302 instead

Supplemental Index

Supplemental index queries does not work on Google any more. Use method described below:

Site:www.xyz.com –allinurl:www.xyz.com show only main index pages, can be used in calculation in %% of

To take out of sup index – pop-up rank by linking to home page or by any other method

Duplicate content

Dilute page importance – get rid of them when possible

Scan for it!

Block duplicate content for crawlers by rel=nofollow

CSS

Complete control over design/HTML

Menu based on CSS shows SE what is linked (much better than JavaScript)

Can put more emphasis on what is important

Image replacement (careful to not been caught), nice way to get around brand police

Keyword Research

Google Suggest (from toolbar)

Yahoo.com (from yahoo.com)

Keyword Density

Ranks.nl

Density is not as important as location of these words

"Thin Slicing"

Title text is the most important on the page. Have list of all URL, and list of titles. Make sure singular vst to plural, common misspellings

Reverse Engineering of competitors

Siteexplore.yahoo.com (with Y! account) Look into internal pages -> export into single .tsv file as the result of all search.

Generate "smart" inbound links

  • Write an article on W3C and link back to your site. They publish in press articles.
  • Become contributor, etc for non-profits
  • Buy existing site for SEO purpose (slowly change content: weeks, month)
  • Code.google.com passing page rank
  • Donate to site thanking to in-kind donors that put your link on the page
  • Put comments on blogrolls
  • Wikipedia (do not edit from your Co address). Wikipedia is no-follow but journalists and bloggers go-to the link
  • Digg. It is as much about submitter as about content. Know community to target, do a lot of altruistic stuff (like with Wikipedia) or go to top 100 digger list and ask Digg pro
  • YouTube, Flicker are not generating pagerank but bloggers and journalist will find you and link from there articles. Titling is very important. Build a micro-site, have co name as log-in on YouTube.

SEO Tools

SEO for Firefox extensions

Tools.seobooks.com

Blogs

Seomoz.org

References

Netconcepts.com

API Design notes from Web 2.0 Expo

Twitter API Experience

It is ALL around REST these days. Even Google abandoned more complicated API in favor of RESTfull

For Twitter API more that 80% of overall traffic these days

Twitter manages developer community over Google Group

400 applications added by hand to the directory from e-mail, tons more are around and not the catalog

XML, JSON, and many other formats supported

Grow API organically (started with 2 methods and no documentation), from the conversation with developers "I can do X if you do Y"

Documentation is really important – at least reverse engineer. Doc should describe at least: How do I start? Is API crawlable? How to dive into the API?

Support developers 24 hrs is important – be present! If not listening, developers will go forward.

Delegate to other developers who are active within the community. Do not forget to socially reward them.

Scaling from API prospective. XML, JSON are not designed for scale by itself. Do it early is a big win. Dedicate part of server farm for API – do not mix destination and API on the same servers

Security issues. API is where bad-behaving users will go first. Audit. Monitor. Expect what can be leaked.

What twitter did wrong?

  • Did not start with api.twitter.com
  • Did not version the API
  • Did not make life easy (or easier) for Flash developers
  • Did not automate (statistics, admin use, app galleries)
  • Many more

New in twitter API

  • Rudimentary geolocation support
  • More consistency between methods
  • Parity between user-side and API side

Misc Observations

It is unclear how to make API into business. It is a trade-off between value from dev community and users. Mashery pretends to monetize on API. QOS is an option.

OAuth [http://oauth.net/] is absolutely where authorization goes on API. More complex on production and consumer site.

Jabber/XMPP – most clients pull constantly. A lot of overhead can be saved this way. But overhead and lack of libraries slow down the effort.

Web->API->SOA Model provides: separation of concerns, direction to move towards

Faces of APIs: XML, spreadsheets, static virtual maps, static URLs, SOAP, JSON, serialized PHP, JavaScript callbacks, etc

The only way to transfer date/time data – UNIX timestamp

New API directions:

  • Amazon S3/(with billing associated with it and authentication)
  • OAuth – emerging standard for 3-d party in client-server relationship. Create a situation to provision on behalf of other users.

Monday, April 21, 2008

Tagging entrepreneurs at StartupSchool

Tagging entrepreneurs at Startup School

Startup School this weekend was by far the best entrepreneur event this year. By amount of energy floating around and amount of applause from the audience it may well surpass rock concerts in New York.

Interestingly enough it was not as much about mechanics of razing startup money or even building a viable business, but rather about common sense and a choice that entrepreneurs need to make. The choice is between going to venture capital firms in hope of building next great Googles and Facebooks with very little odds and building successful money-making companies with much bigger odds. People interested in later should checkout great speech by David Heinemeier [http://omnisio.com/startupschool08/david-heinemeier-hansson-at-startup-school-08] (creator of the Ruby on Rails framework), others may continue to read my boring notes.

Suggestions for startups to raise money

What to do:

Talk only to “good” investors

Tell existing story

Do deals in parallel

Thech founders are the key in SV

Create San Hill Buzz

Do not be distracted by fundraising process (no more than ½ person assigned to the process)

What all investors look for:

Market (big & growing fast). Startup cannot create markets. Customers with “hair on fire”. Unfair advantage.

Great Team

Great Product

Story that all investors want to hear:

Exploding market.

Best solution.

Best team.

Suggestions and observations

Get twice $$ what you think is needed

Avoid “super pro rata” in terms – makes hard to get second round

Deal making is about alternatives – more the better

Talk to CEOs of potential investors

Evl0-ery company has a rocky beginning

37 Signals

Tagging developers from Fortune 500 to fortune 5M. Different rules in that world – NO VC. No sales cycles – just solving one problem may be at little better than someone else

FriendFeed

-“listen to your users”

Amazon, Cloud computing

· AWS bandwidth passed Amazon retail bandwidth worldwide

· S3

· EC2

· SimpleDB

· SimpleQuue

· Flexible payment service

· Mechanical Turk

BlueOrigin [http://public.blueorigin.com/index.html] (Vertical takeoff and landing vehicle company funded by Jeff Bezos) as user for EC2 for computation

Google app engine. Will it be real competitor to EC2? Time will show.

“Customer focus is more important than competitive focus” – thank you, Jeff Bezos for setting right priorities for Amazon

Monday, February 25, 2008

Chronology of a painter or my weekend with wekendapps


Why? Because programming is fun. Lots of fun. Working as CTO I mostly help organize this fun for others. It’s time to have some fun for myself.

Where? Wekendapps in Santa Clara

When? February 22 to February 24, 2007


Day 1

Started as typical Silicon Valley meet-up, with pizza and bunch of people crowded in small room, event fun was started. Some people came ready and prepared with friends and code snippets. I did not. Anyway crowd (with some help from organizers) gravitated into groups of people with similar skills. Ideas were presented. I liked what David’s idea on searching FB users through their connections and common photo tagging. Started discussing/planning/coding the app.


Day 2

Spent morning socializing. Realized that app we thought about on day one is not viral. David shared another idea – ‘painter’ who will draw a classic masterpiece on user’s profile page over time. Sort of growing gifts but more ‘sophisticated’.

4 p.m. really started to work on the app – put together “project plan” (list of to-do items) and assigned tasks. Plan is to finish the app early Sunday. For the rest of the day (till 2 a.m.) we dug dip into PHP/SQL/CSS/FBML.

12:30 a.m. conversation in the room became more philosophical. Main topic discussed – why do people laugh? Is it because people lose control of themselves?

1:30 a.m. it took me a while to figure out why < href="”link”"> does not work - sleep time.
BIG respect to people who did not leave and stayed for the overnight coding session.


Day 3

9 a.m. we are back. Bagel and coffee are timely. Thank you, organizers.

10 a.m Set up a target to finish coding by 2 p.m. Plenty of time to finish the up (or what we thought)

12 noon realized that we cannot finish by 2 even if we skip the lunch. Skipped the lunch.

2 p.m. uncovering one limitation after another realized that we cannot finish even by 4 p.m.

4 p.m. David added the code to post the painter to user’s profile page. Only dots and occasional lines are visible – no painter, no picture… Started panicking and think about radical change to the design – instead of posting BFML with css – post static images. Thanks to Elsie who saved us from taking that route – it would take forever and ever to finish the app.

5 p.m. Crowd of investors arrived. Asking questions like “do you use PHP libraries?”. All deadlines are passed and we are not finished. Moved to more quit conference room.

6 p.m. Feature complete. Started end-to end testing. Realized that critical functionality (acceptance of the painting after application is installed) does not work. With the tribal knowledge of surrounding people, David figured out what could be done to fix the flaw. Changed DB schema and countless places in the code.

7 p.m. other teams are presenting ... We still working on the code. Promise to organizers that we are close and soon will be ready to present.

7:15 p.m. development server is down… Most of the code is there…

7:25 p.m. server is back

7:30 p.m. moving to “production” – creating production keys and set of files. Integration end-to-testing. Promised that we really-really ready and will come to the main conference room in a minute. App is fully functional

7:45 p.m. testing end-to-end functionality. I want to remove app from my account so that I can test invite-install path. Instead of removing the app from my profile, deleted application all together from the developers environment. Ooops. Should have camera with me to take picture of David.

7:55 app restored

8:05 discussing ‘code freeze’. David still changing message text.

8:15 presentation


P.S.

Side-effect of all of the fun, painter app, http://apps.facebook.com/sendartist/ is up and running.

Enjoy!

Tuesday, February 12, 2008

Highly scalable web solutions

Amazon Web Services user’s group meeting last night was slightly derailed from the presenter’s topic to the discussion about current approaches to highly scalable web architecture. Question is simple: in the new world of Web/Facebook applications when millions of users could be added virtually overnight, question of scalability should be addressed from the day one of application design.

In order to make scalable Web application the most important consideration is the foundation it is build upon – choice of the database architecture. I know have seen four radically different approaches:

  • Database clusters
  • Database replication
  • Federated data layer
  • Non-relational databases

Clusters require virtually no code change, scaled up to 32 nodes and in cases of Oracle (do not know anyone else who did it right) are prohibitively expensive for start-ups

Database replication seems so appealing at the beginning… Basically forward all data update/write requests to the master and read the data from slaves. Not much of a code change, cheap/free databases could be used (think MySQL), any slave could become the master when needed… Unfortunately like with the cluster you can go only so far with that – performance will start degrading to the level of inusability after 10-15 slave nodes.

Federated data layer is what Hi5 and many other smart companies are using today. Basic idea – split data horizontally by assigning range of item ids to separate db instances and have “smart” data layer figure out where to go for data request/updates. Major problems: hard to implement “right”, aggregated queries (like selects/count across large data sets, etc) should be executed against many data sources and then aggregated before returning data to the app. Rather challenging to implement and labor intensive any non-trivial scenarios.

Non-relational approach. Sort of new kid on the block (or may be old fellow we used to call object db?). Anyway, with introduction of SimpleDb by Amazon, people start taking it more serious. Basic promise – you trade database features for scalability. Perfect if data is used just to store and retrieve objects and their properties. But what to do about data set aggregation? Navigate through the whole set of objects? I guess, we have to wait for the answer for a while…

As usual – no silver bullets, no magic wands. Well, at least software architects have job security...