Myspace didn’t have programming talent capable of scaling the site to compete with Facebook.
Choosing the Microsoft stack made it difficult to hire people capable of competing with Facebook. .Net programmers are largely Enterprise programmers who are not constitutionally constructed to create large scalable websites at a startup pace.
Their system had hundreds of hacks to make it scale that no one wants to touch, which hamstrung their ability to really compete.
Because of their infrastructure MySpace can’t change their technology to make new features work or make dramatically new experiences.
Firing a lot of people nose dived morale and made hiring tough. (duh)
Los Angeles doesn’t have startup talent capable of producing a scalable social network system.
Facebooks’ choice of the LAMP stack allowed them to hire quicker and find people who knew how to scale.
Our first product is built on top of StackVM and is called Browserling. It’s an interactive cross-browser testing tool inside of your browser. A real browser inside of your browser! Just go to browserling.com to try it out! (please use Chrome.)
Sharding is a great scalability solution, but as Foursquare recently revealed in a post-mortem about their 17 hours of downtime, sharding also has problems. MongoDB, the database Foursquare uses, also contributed their post-mortem of what went wrong too.
A little self promotion never hurt anybody, right?
We play and play, but we rarely pause to ask ourselves about the humans behind the games that liven up our lunch hour and the hours beyond. But if you’ve ever given up a chunk of your time to conquering Crush the Castle, fighting for your “life” as a zombie in Sonny, or battling through the dirt and blood of Warfare 1917, you’re already made a connection with the staff and community at Armor Games–as have millions of players before you.
It seems as if someone deployed into production that incorrectly cleared values from their caching layer (they use Memcached, 28TB worth of memory across 800 servers). That caused all their app servers to query the DB for the uncached value. This seems to be what ultimately brought the site down.
For four years we have offered the synchronization service for no charge, predicated on the hypothesis that a business model would emerge to support the free service. With that investment thesis thwarted, there is no way to pay expenses, primarily salary and hosting costs. Without the resources to keep the service going, we must shut it down. Our plan is to keep the service running for another 90+ days, after which the plug will be pulled.
Among the list of reported issues in the code are numerous XSS — or cross-site scripting — attack vulnerabilities, a session token thats easy to steal, a lack of user input filtering, and repeated errors when a null character is entered into web fields.
It is not unusual, however, that many APIs that claim to be RESTful actually fail to do so. Mike Pearce gave an interesting talk slides embedded below on how you can easily break REST principles and which mistakes you should avoid when designing RESTful API.
I ran across this intriguing article which proposes a handy taxonomy for discussing and working with a users social networking data.
As we continue our conversations about what sorts of fundamental rights people have with respect to their data, and more countries contemplate regulation on social networking sites and user data, it will be important to keep this taxonomy in mind. The sorts of things that would be suitable for one type of data might be completely unworkable and inappropriate for another.
Service data is the data you give to a social networking site in order to use it. Such data might include your legal name, your age, and your credit-card number.
Disclosed data is what you post on your own pages: blog entries, photographs, messages, comments, and so on.
Entrusted data is what you post on other people’s pages. It’s basically the same stuff as disclosed data, but the difference is that you don’t have control over the data once you post it — another user does.
Incidental data is what other people post about you: a paragraph about you that someone else writes, a picture of you that someone else takes and posts. Again, it’s basically the same stuff as disclosed data, but the difference is that you don’t have control over it, and you didn’t create it in the first place.
Behavioral data is data the site collects about your habits by recording what you do and who you do it with. It might include games you play, topics you write about, news articles you access (and what that says about your political leanings), and so on.
Derived data is data about you that is derived from all the other data. For example, if 80 percent of your friends self-identify as gay, you’re likely gay yourself.
