Do you know why I am sad? Because, there is a name for what he is advocating, it’s called spam! I’ve been interested in marketing (the regular kind and the online kind) for almost 2 years now and nothing Max said is a revelation. The shadier parts of the online marketing world have been doing it for years, it’s got many names, micro-niche blogging, micro-niche sites, made-for-adsense sites etc. It’s not new, but it has hung around for years, because it works. You heard me, it works, which doesn’t make it any nobler.

I know he is not just advocating building made-for-adsense sites, it’s not the method, it’s the attitude that goes with it, that is the real issue. Lets not care about providing any kind of value, lets not worry about any sort of professionalism, all we want to do is scam some suckers out of $1 a day and believe you me there are plenty of suckers on the web. Let’s turn our craft into a factory that produces cheap, low-value crap, but can churn it out in hundreds and thousands. And maybe after a little while we start calling ourselves a ‘guru’, no ‘junior vice guru’; oh hell, let’s not mince words – ‘marketing consultant’. We’ll branch out into SEO and ‘brand management’. We’re no longer in the code business, we’re in the making $1 a day business.

There are hundreds of these ‘marketers’ lurking around the internet. Releasing “product” after useless “product” specifically designed to sucker poor shlubs into parting with their hard-earned cash. It’s a self-perpetuating meta-industry which makes money, from selling people products, on how to make money. It’s sickening, but also in a strange way seductive, maybe those poor suckers deserve to be taken for a ride, cause that would make you feel like less of a sucker yourself.

Thousands of people follow these spammers on twitter and everywhere else, they want to emulate these guys, I’d like to think that we programmers are better than that as a community. Not just each individual developer, but all of us together. Let’s face it, we’re smarter than your average sucker, more aware, capable of making a difference. It doesn’t matter where we live, we have the tools, drive and ability to succeed without having to resort to producing rubbish (but doing it quick) and spammy tactics.

And if you do happen to live in a country that is not considered part of the first world, think what this kind of attitude will do not just to your reputation, but your nation’s. Many countries in Eastern Europe and Asia are already considered havens for spam, hackers and porn. Whether rightly or not, do you want to perpetuate those beliefs and make life that much harder for the developers that follow you?

Surely if you can create even a marginally worthwhile product that can make you $1 a day, then a little bit of extra effort can turn that $1 into $2. A couple more features can turn that $2 into $4; some sensible promotion can turn that $4 into $40. If anyone (even one person a month) is willing to part with $29.95 to buy an app, then there surely are many others who will consider it (more than 12 people a year), I refuse to believe otherwise. All it needs is a little bit more work, maybe better documentation, maybe finding more people to spread the word. Abandoning it in a half-done state and moving on to build half of another crappy app is certainly not the answer.

I’ve got no problem with people trying to make some cash. But, as a developer you surely have enough skill and brains that you can do so and still maintain at least a semblance of respect for yourself, your craft and the people who use your products.

I really do hope that if you go down the path of creating a $1 a day empire of crap, nobody follows you on twitter, the world has enough make-money-online ‘experts’ we don’t need any more.

Image by chotda

Related posts:

1. How People Can Get You To Do What They Want
2. Do You Morph Into A Different Programmer?
3. It’s Not About The Duct Tape It’s About The People (And More)
4. Stopping People From Switching Off During Standups
5. If Obama Were A Programmer His Campaign Slogan Would Be…
6. In Defense Of The Software Craftsmanship Concept
7. Java and .Net Taking On Contenders And Winning

Tagged as: developers

VS2010 RC is out now and available for MSDN users since now. Other guys have to wait until tomorrow when VS2010 RC is made publically available. Reading first news I discovered that most important thing is hardly improved performance of VS2010 RC IDE. All your feedback is welcome to VS2010 RC Connect site.

To find out more follow these links:

• VS 2010 / .NET 4 Release Candidate
• VS 2010/.NET 4 Release Candidate is Available for MSDN subscribers
• Announcing VS2010 / .NET Framework 4 Release Candidate (RC)

Before installing RC you must uninstall all previous versions of VS2010 and .NET Framework 4.0. It seems like another long nights of hacking and discovering new stuff are waiting for us. :)

There are a few language constructs that, if implemented properly in modern programming languages, could pave the way for alternative methods of doing asynchronous programming that don't have the drawbacks of the event loop. These constructs are coroutines and lightweight processes.

A coroutine is a function that can suspend and resume its execution at certain, programmatically specified, locations. This simple concept can serve to transform blocking-looking code to be non-blocking. At certain critical points in your IO library code, the low-level functions that are doing IO can choose to "cooperate". That is, it can choose to suspend execution in order for another function to resume execution and continue on.

Here's an example (it's Python, but fairly understandable for all I hope):

def download_pages():
    google = urlopen('http://www.google.com/').read()
    yahoo = urlopen('http://www.yahoo.com/').read()

Normally the way this would work is that a socket would be opened, connected to Google, an HTTP request sent, and the full response would be read, buffered, and assigned to the google variable, and then in turn the same series of steps would be taken for the yahoo variable.

Ok, now imagine that the underlying socket implementation were built using coroutines that cooperated with each other. This time, just like before, the socket would be opened and a connection would be made to Google, and then a request would be fired off. This time, however, after sending the request, the socket implementation suspends its own execution.

Having suspended its execution (but not yet having returned a value), execution continues on to the next line. The same thing happens on the Yahoo line: once its request has been fired off, the Yahoo line suspends its execution. But now there's something else to cooperate with--there's actually some data ready to be read on the Google socket--so it resumes execution at that point. It reads some data from the Gooogle socket, and then suspends its execution again.

It jumps back and forth between the two coroutines until one has finished. Let's say that the Yahoo socket has finished, but the Google one has not. In this case, the Google socket just continues to read from its socket until it has completed, because there are no other coroutines to cooperate with. Once the Google socket is finally finished, the function returns with all of the buffered data.

Then the Yahoo line returns with all of its buffered data.

We've preserved the style of our blocking code, but we've used asynchronous programming to do it. Best of all, we've preserved our original program flow--the google variable is assigned first, and then the yahoo variable is assigned. In truth, we've got a smart event loop going on underneath the covers to control who gets to execute, but it's hidden from us due to the fact that coroutines are in play.

Languages like PHP, Python, Ruby, and Perl simply don't have built-in coroutines that are robust enough to implement this kind of behind-the-scenes transformation. So what about these lightweight processes?

Lightweight processes are what Erlang uses as its main concurrency primitive. Essentially these are processes that are mostly implemented in the Erlang VM itself. Each process has approximately 300 words of overhead and its execution is scheduled primarily by the Erlang VM, sharing no state at all amongst processes. Essentially, we don't have to think twice about spawning a process, as it's essentially free. The catch is that these processes can only communicate via message passing.

Implementing these lightweight processes at the VM level gets rid of the memory overhead, the context switching, and the relative sluggishness of interprocess communication provided by the operating system. Since the VM also has insight into the memory stack of each process, it can freely move or resize those processes and their stacks. That's something that the OS simply cannot do.

With this model of lightweight processes, it's possible to again revert back to the convenient model of using a separate process for all of our asynchronous programming needs. The question becomes this: can this notion of lightweight processes be implemented in languages other than Erlang? The answer to that is "I don't know." To my knowledge, Erlang takes advantage of some features of the language itself (such as having no mutable data structures) in its lightweight process implementation.

Syndicate this site

If what people call Web 2.0 was all about creating new technologies that made it easy for everyday people to publish their thoughts, social connections and activities, then the next stage of innovation online may be services like recommendations, self and group awareness, and other features made possible by software developers building on top of the huge mass of data that Web 2.0 made public. It's a very exciting future, and Warden is about to fire one of the earliest big shots in that direction.

Nerds in Space: Social Graph Analysis For Solving Large-Group Problems

Warden studied Computer Vision in college in the U.K., then got into game development. After moving to L.A., he spent six years building graphics drivers for the original Playstation and the XBox. Then he started his own independent business, where, thankfully, he open-sourced much of his work (something he's still doing today).

When he found out that starting his own business wasn't going to work with his immigration status, he was very fortunate to have also caught Apple's eye with the software he had been releasing to the public. Apple bought his company in order to bring him on board. The proceeds of that small sale are now sustaining his next project after going independent again.

After spending five years at Apple struggling to navigate the maze of people and connections and types of expertise in order to get the information he needed, Warden decided to go independent and build a company that solved exactly that kind of problem. "I can't think of a better big company to work for, but it was still a big company," he says. "It was hard to find the right people to talk to, whether for particular expertise or for contacts at external companies." And so Warden left Apple to build a company that would use social graph analysis to solve problems like that. He called the company Mailana.

We've written here a number of times about Mailana's tool that analyzes the social graph of any Twitter user. Enter the username of someone on Twitter and Mailana will show you which 20 other people the user has exchanged the largest number of reciprocal public @ replies with. Find someone interesting or important? Mailana's Twitter analyzer will tell you who they most regularly interact with. See, for example, The Inner Circles of 10 Geek Rockstars on Twitter.

Pulling Down the Facebook Social Graph

Now Warden is about to unveil a much larger project along the same vein. For the past six months he's been crawling public profile pages on Facebook. He now has more than 215 million of them indexed and updated about once a month. When he began he was using the Web crawling service 80legs, but over time he had to build his own crawling infrastructure.

When I talked to him this afternoon, he had already begun uploading 100 GB of user data onto his server to make it available for academic research starting on Wednesday. Warden says he's removed identifying profile URLs but kept names, locations, Fan page lists and partial Friends lists. All those fields of data are just waiting to be analyzed and cross referenced. That's one very rich resource.

Yesterday Warden posted some of his own initial observations from the data on his personal blog. Those included:

• In almost every state in the Southern U.S., God is number one most popular Fan page among Facebook users. Among people in the L.A., San Francisco and Nevada regions? "God hardly makes an appearance on the fan pages, but sports aren't that popular either," Warden writes. "Michael Jackson is a particular favorite, and San Francisco puts Barack Obama in the top spot." In the Oregon and Idaho region? Starbucks is number one.
• In the Mormon-influenced areas of Utah and Eastern Idaho, the most popular Fan pages are The Book of Mormon, Glen Beck and the vampire book Twilight, which was authored by a Mormon.
• The bulk of Warden's posted analysis yesterday was about location networks. People in the western U.S. tend to have Facebook friends all over the country; people in the southern U.S. tend to mostly be friends with people who have remained in the same area.

Taking a Deeper Look

These observations are interesting, but they are only the beginning of what's possible. Name, location, friends and interests are great data points to analyze. Warden has written a program that will estimate gender as well, based on names. All these data points can be cross-referenced with outside data, too. Members of Facebook's own staff did this kind of analysis when they compared user last names to U.S. Census data, which allowed them to estimate changes in Facebook's racial composition over time based on the likelihood of people with particular last names to report a particular racial backgrounds.

"I'm mostly thinking 'What do I try first?'," Warden says. "There's so many interesting ways to slice the data - especially as I'm starting to get changes over time. I'm also trying to map out political networks in aggregate; how polarized the fans of particular politicians are - so how likely a Sarah Palin fan is to have any friends who are fans of Obama, and how that varies with location too. One of my favorite results is that Texans are more likely to be fans of the Dallas Cowboys than God."

Warden says he hasn't talked to anyone from Facebook since he started crawling the site, but he did get an email from someone on the security team asking him to take down instructions he'd posted that exposed a security hole that made harvesting peoples' email addresses easy. So the company is paying attention. "I'd love to see them put me out of business by putting decent data out there," Warden says. He says his Amazon Web Services bill was over $5,000 last month.

Why is he indexing all this content and why is he going to hand it over to the academic world later this week? "I am fascinated by how we can build tools to understand our world and connect people based on all the data we're just littering the Internet with," Warden says.

"Nobody thinks about how much valuable information they're generating just by friending people and fanning pages. It's like we're constantly voting in a hundred different ways every day. And I'm a starry-eyed believer that we'll be able to change the world for the better using that neglected information. It's like an x-ray for the whole country - we can see all sorts of hidden details of who we're friends with, where we live, what we like."

For a great example of the kind of social impact that data analysis can make, Warden points to some of the fascinating ways that GIS data is illuminating the intersection of race and public services. Data has shed light on social injustices for decades, and measurable information about the interactions of hundreds of millions of people every day on Facebook offers opportunities to discover both good and bad news about the contemporary human condition.

Warden says he's not yet been able to interest any investors in his ideas for businesses based on this data, so his girlfriend Liz Baumann, a former insurance actuary, stepped in to help and is now running much of the crawling. He says he's now focused on "working on ways of presenting all this information in a form that answers questions for people willing to pay." His first experiment along those lines is the very interesting FanPageAnalytics.com.

What does Pete Warden hope for from this week's public release of all this Facebook data? "Hopefully I'll get to see a bunch of interesting [academic research] papers come out of it, worst case. And I'd like to be the guy people turn to when they need stuff like this."

Already well-respected among a fringe group of bleeding-edge geeks, we hope that Warden's work on social graph analysis will end up impacting a far larger number of people than may ever know his name.

SAP's chairman Hasso Plattner admitted the company had made mistakes, especially in ramping up maintenance fees.

Plattner said the problems could not just be blamed on Leo Apotheker, who left on Sunday.

Plattner told The FT: "Unfortunately SAP has made a few legal and technical mistakes, especially in Germany. This is nothing that can be put into Léo's shoes. We have made a mistake... I was personally involved in decisions about the maintenance fees."

Apotheker has been replaced by a two-man CEO team of Bill McDermott, previously head of field operations, and Jim Hagermann Snabe, previously head of product development. The continuing role of co-founder Plattner, and promotion of CIO Vishal Sikka, suggests an increased focus on product development.

Referring to an employee survey which revealed deep unhappiness with SAP senior management, Apotheker said, in a memo seen by BusinessWeek: “I regret that I wasn’t able to earn the support of each and every one of you, but I serenely stand before you today with the knowledge - and the clear conviction - that what I did was for the best of the company.”

He said the decisions he took, especially to cut jobs. were difficult but necessary.

James Crawshaw, analyst at S&P, said: "We view the management change positively... Apotheker had over 20 years of experience within SAP, but in our view was unconvincing in his strategy for growth, product innovation and defence of the maintenance/support fee hikes. McDermott is, in our view, a much more articulate spokesperson for the company." ®

We are pleased to announce the availability of the Versioning feature for beta use across all of our Amazon S3 Regions. Versioning allows you to preserve, retrieve, and restore every version of every object in an Amazon S3 bucket. Once you enable Versioning for a bucket, Amazon S3 preserves existing objects anytime you perform a PUT, POST, COPY, or DELETE operation on them. By default, GET requests will retrieve the most recently written version. Older versions of an overwritten or deleted object can be retrieved by specifying a version in the request.

Amazon S3 provides customers with a highly secure and durable storage infrastructure. Versioning offers an additional level of protection by providing a means of recovery when customers accidentally overwrite or delete objects. This allows you to easily recover from unintended user actions and application failures. You can also use Versioning for data retention and archiving. For more information, please see the Amazon S3 FAQs and Developer Guide.

Not that Mountain View will be providing technical support as such, only enquiries into the ordering and shipping process will be dealt with by Google - everything else gets directed to HTC or T-Mobile as appropriate. But if you've got an outstanding order for a Nexus One then you should be able to speak to a real person, which is how it should have been at launch.

Not only has Google succumbed to the inevitability of human contact, but the company has also had to reduce the "Equipment Recovery Fee" introduced in the Nexus One small print and invoked if cellular service is cancelled within four months.

The original version of the terms of sale required a repayment of the entire subsidy: so someone paying $179 for a subsidised handset would automatically have $350 charged to their credit card if they cancelled the T-Mobile connection, in addition to any charge levied by T-Mobile. That's been reduced to $150 for new T-Mobile customers, and $50 for those who switched tariffs to get a Nexus One, but is still automatically deducted from the credit card.

That's probably down to T-Mobile agreeing to hand over the subsidy to Google even if the customer tries to cancel the connection, as happens with any other subsidised handset, "early termination" fees are charged for exactly this reason and Google is unique in billing customers directly for subsidy-recovery.

All this takes Google takes one step closer to being a normal seller of mobile phones: the mobile industry is surprisingly resistant to change, and even Google is going to have to play nicely for a while at least. ®

Toyota Prius software glitch forces global recall

Anti-lock braking software to be replaced in 400,000 cars worldwide

By Martyn Williams

Toyota plans to recall around 400,000 of its Prius hybrid cars to replace software that controls the antilock braking system (ABS), the auto maker said today (9 February).

The global recall is in response to driver complaints about poor braking performance under some conditions. It will see new software loaded into the car that should improve braking while ABS is active at low speeds, the company said.

"We heard concerns from customers and are recalling the cars in order to resolve the problem completely," said Akio Toyoda, CEO of Toyota, at a packed Tokyo news conference.

At issue is a reduction in braking performance when the brakes are softly applied while the car is driving on slippery surfaces such as snow, ice, or even road surfaces that have been painted over.

In normal driving conditions, the cars use hydraulic brakes and a regenerative braking system to recover energy as they slow down, but when the ABS cuts in, the cars switch to hydraulic braking only, which can result in reduced braking performance and a longer stopping distance. Toyota didn't say how much longer that distance could be.

The problem only occurs under soft braking, Toyota said. Applying increased pressure on the brake pedal when ABS is in operation will give better brake performance, the company said.

The new software, already being installed in vehicles in production, will reduce the ABS response time, Toyota said.

Toyoda said he had experienced the problem, which he called "a moment of anxiety," himself while driving a Prius on a Toyota test track.

"The vehicle will stop if you apply pressure," he said.

The recall prolongs an unprecedented spell for Toyota in which the safety of its cars has been in the spotlight. Last month the company initiated a global recall of some of its cars due to problems with the accelerator pedal.

"Let me assure everyone that we will redouble our commitment to quality as a lifeline of our company," said Toyoda. "With myself taking the lead and keeping to the genchi genbutsu principle all of us at Toyota will tackle the issue in close cooperation with our dealers and our suppliers. Together, we will do everything in our power to regain the confidence of our customers."

No matter how good it is, an idea is worth absolute shit until a substantial amount of work has gone into it. Since no one cares about unrealized ideas, all of the initial work usually has to be done by the person that imagined it.

Yes, imo, ideas are easy but building something is not easy. However, good ideas aren't quite as common as you'd think. I volunteer at a local university and teach a startup course to computer science students - and wow, they really come up with stupid ideas. About 1 in 10 of the business ideas that get generated in class are any good, mostly because people aren't realistic. Either their idea requires hundreds of millions of dollars (which they have no chance of raising) or it's a tiny market that no one cares about, and it's a "lifestyle" business, which is quite different than a startup.

But yes, non-technical people that say to me "I want to do a startup, what should I do?" I usually think "Ugh...first, go back to school and get a useful technical degree and then come back and ask me." (obviously I'm being facetious - but that's what I think..)

Even after putting a lot of work into a good idea, you still need to practically ram the concept down peoples' throats to get anyone to give a shit.

Yes, this is true. Always remember, no one gives a crap about you or you're dumb startup idea. So many people out there are shocked by this, but yeah, people have the attention span of 3-year olds. They only care about making money, so unless you are getting "big fast" or have an obvious money maker on your hands, no one will care. This is why raising money can be difficult, obviously.

In spite of the opposite being true, people seem to believe that everyone is out to "steal" their ideas. I've known people who secretly told me their idea for a nifty product, but they had no prototype, no plan or design, and generally no realization of the idea at all. Still, they were convinced that there were wolves around every corner waiting to eat their stillborn dream.

Yes, this is true too. NDAs are pretty dumb and useless, and people that run around with their 'secret' ideas are usually going to end up with nothing. People respect work - eg. realistic financial models, compelling presentations, code, customers, etc.

App developers aren't the only people that get bombarded by people's stupid ideas. I've seen it happen to other constructive people as well: artists, writers, car mechanics, engineers, landscapers, musicians, etc. It seems like anyone who has the power to make something new out of nothing attracts people who think we're all just waiting for some "idea man" to make us worthwhile.

Heh. Yes, "business people" are usually pretty lame. I've hired and fired Harvard MBAs and plenty of "business people" - some of them I've learned a lot from, and have been wonderful partners in business, but most of them don't have much value except to be a cog in the wheel.

Amazingly, these guys never seem to realize that we're also full of our own ideas, and we got good at what we do by trying and failing to realize our own ideas over and over again.

Sounds like you've got some axes to grind. :-) Passion is good.

It's also amazing that if they could be dropped from their own brilliant plan completely, and if I could just do their idea myself and take all the money, then they're probably not bringing very much to the table at all. This is usually what I tell them, and because of #3, they never ask me again.

Yes, well, there is a great saying that I've always liked: "If you don't like the news, go out and make some of your own." :-)

By James Grahame

Posted by James Grahame on May 27, 2009 in Classic Computing | Permalink

You’re the Fleet Admiral of the Navy in World War I. Your ships are being sunk at an alarming rate by the devastatingly effective German U-Boat. The traditional camouflage isn’t working because your environment (sea and sky) changes with the weather. What do you do?

The German U-Boat: Sinking your Battleships

THE INSIGHT

It’s not where you are it’s where you’re going

World War I occurred from 1914–1918; back then sinking an enemy battleship was a three-step process:

Step 1: Locate your target’s position and plot its course.
Step 2: Determine the ship’s speed and confirm the direction it is heading
Step 3: Launch torpedo not directly at the ship, but where you think it’s going to be by the time the torpedo reaches the ship.

*Remember this is early 20th century warfare, weapons don’t travel at the speed they do today

So what’s your solution Fleet Admiral?

HIT THEM WITH THE RAZZLE DAZZLE

Forget about not being seen, that only solves their first problem. Focus on confusing them so they don’t know where you’re going. Then their torpedoes will be shot in vain because they thought you zigged when you really zagged.

British Artist and naval officer Norman Wilkinson had this very insight and pioneered the Dazzle Camouflage movement (known as Razzle Dazzle in the United States). Norman used bright, loud colours and contrasting diagonal stripes to make it incredibly difficult to gauge a ship’s size and direction.

It was cheap, effective, and widely-adopted during the War. Check out the incredible photographs below.

*NOTE: Unfortunately the images are in black and white, being from the early 1900s and all, so the loud, bold colours will require a little imagination. Can you picture a fleet of electric yellow, orange and purple ships coming to get ya!

The Father of Dazzle Camouflage Norman Wilkinson

To give you an idea of colour, here’s a sketch, actual and render

Definitely my favourite of the lot

As sonar and radar technology improved, the once effective dazzle camouflage was rendered obsolete. By WWII the dazzle camouflage was an afterthought. Thankfully contemporary artists like Jeff Koons have kept the style alive with outrageous boats like this:

SOURCES
- Information: http://gotouring.com/razzledazzle/articles/dazzle.html
- Information: http://en.wikipedia.org/wiki/Dazzle_camouflage
- Photographs: http://www.history.navy.mil/branches/nhcorg11.htm





If you’re on Twitter or Facebook, let’s connect!


If you enjoyed this article, the Sifter highly recommends: Can Your Boat Dive 100 Feet Under Water?

// February 8th, 2010 // Amusing, Video

You are going to love this story!  A debt free city and 700Mil in cash reserves.  That is as much as the State of Oklahoma has in their rainy day fund.
Their secret?  Low taxes, jobs jobs jobs, and a mayor that is 88 years old and has the energy of a spring chicken!

Mississauga, Ontario isn’t just your normal metro.  They have done what most people would call the impossible.  A city of no debt and plenty of cash for the grandkids to live on.  Mississauga has set an example for cities around the world.   They are the Canada headquarters for companies like Hewlett-Packard, Microsoft, Pepsico, General Electric,  Fujitsu and Wal-Mart Canada.

Responsible financial management coupled with forward planning policies has resulted in the City’s debt-free status, with hundreds of millions in reserve funds for future infrastructure development.  -Taxes & Assessment

Note that they assess property taxes based on need and not on value of the property.  I really like this concept from a property rights perspective plus there isn’t a built-in disincentive to keep your property, well, worth’less’.

The total amount of taxes collected depends on the municipality’s revenue needs, and not on the value of property assessments within a municipality. -Taxes & Assessment

I also really like the fact that municipalities can’t offer businesses direct incentives like tax breaks and loans.  This probably causes the city to stand on its broad based incentives like low taxes, crime rates, transit, and aesthetics.

The City operates on the philosophy that new development should pay for itself. Funds collected are placed in reserve to pay for capital improvements needed in the future. -Taxes & Assessment

Good stuff.

Enjoy this report and let me hear your thoughts.

Javascript ePub Readers

Category: Showcase

eBooks have gone mainstream, and right now the open ePub format is getting a lot of attention, being the iPad’s book format of choice. Often overlooked in gadget-centric media is the fact that ePub is based on web standards, and therefore amenable to being rendered in the browser, sans plugins. Pure Javascript ePub readers are starting to crop up, and Keith Fahlgren has written about several of them:

Just in the last few days, details emerged of two new JavaScript ePub readers, rePublish from Blaine Cook (@blaine) and JSEpub (screenshot) from August Lilleaas (@augustl). These two new readers join @liza’s epubjs, which will be a year old on Tuesday. An improved version of epubjs powers the ePub Zen Garden, which helps “dispel the myth that digital books can’t also be crafted works of visual design.”

All are open source, and as Keith notes in the comments, there’s also the commercial BookGlutton project. BookGlutton (which we covered earlier) shows the promise of browser-based eBooks: it lets you embed books as lightbox-powered widgets, and supports annotation.

The underlying structure of ePub is described on wikipedia:

EPUB consists of three specifications:
Open Publication Structure (OPS) 2.0, contains the formatting of its content.[5]
Open Packaging Format (OPF) 2.0, describes the structure of the .epub file in XML.[6]
OEBPS Container Format (OCF) 1.0, collects all files as a ZIP archive.[7]
Basically, EPUB internally uses XHTML or DTBook (an XML standard provided by the DAISY Consortium) to represent the text and structure of the content document, and a subset of CSS to provide layout and formatting. XML is used to create the document manifest, table of contents, and EPUB metadata. Finally, the files are bundled in a zip file as a packaging format.

In the case of unzipping, Keith points out the inflate library has been around since 1999. One can imagine other applications for zip too; for example, it’s often used as a format for bundling code (Java JARs, Python Eggs, Firefox and Chrome extensions), so reliable unzipping makes it possible to build browser-based IDEs and exploration tools against such archives.

Posted by Michael Mahemoff at 3:34 am
Comment here

Project management experiences are hit and miss in an industry that is just growing out of adolescence. To engage with these misconceptions we need to take a step back and put agile into context before taking a holistic look at what contemporary game development might mean.

As the Technical Director of a large studio, I oversee our own projects and interact regularly with publishers and other developers. There is plenty of opportunity to observe different management styles in the wild. Agile has certainly gained in popularity in recent years but I have also observed a few trends that go with it.

Firstly, people use the words "agile" and "scrum" interchangeably. The idea that agile and scrum are separate things appears to be an alien concept. Yet despite the prevalence of scrum as the methodology of choice, there is a decided lack of scrum-like language or attitude amongst many of the teams. When pressed on what people actually do on a day-by-day basis it seems that "scrum" is wide and varied. Sometimes I struggle to find any correlation between what the teams are doing and what I understand it to be.

Another common opinion is that the alternative to agile is waterfall. Many people talk in these terms. Therefore, if you are not an agile devotee then you must be stuck in the past, desperate to cling to the familiar and the conventional. Clearly, you need enlightening or worse, you just do not "get it".

We have all been on the receiving end of bad management at some point so it is easy to empathise with developers yearning for a more natural process and agile promises a seductive alternative to the traditional wisdom. However, whilst developers complain about management stupidity, the leadership is often frustrated by the na誰ve views from the rank and file who fail to appreciate the reality of business.

There is general misunderstanding of what agile really means for a company, what the real issues are and how it all fits into the bigger global picture. Ignorance impairs constructive debate and I often find myself spending a lot of time clearing unhelpful philosophical hurdles before we can get down to tackling the actual problems in front of us. This, frankly, is annoying and the driving force behind this little rant.

Many people think agile is a new idea and these are contemporary issues. Actually, project management has been around for centuries and as applied to software then certainly for a few decades. If you consider agile has its roots in lean manufacturing then "agile thinking" has been around at least since the 1940’s (although I suspect the pyramid builders and artisans had similar debates). Over the years, a large body of knowledge, empirical data and case studies has built up so we can make some qualified statements.

However, if we confine ourselves to software development we can see there are in fact quite a few more formal methodologies than just Scrum or Waterfall. Here is a handful:

• Scrum (& XP)
• PSP & TSP
• Prince2
• RUP
• AUP
• DSDM
• FDD
• PMP
• EPF & OpenUp
• HERMES

Of the items above, some are generally considered agile whilst others not so much. All of them have their advocates and used successfully on many projects and this raises a number of interesting questions.

If they are all successful then why does it matter which we use? Are some more effective than others and if so then why? Are the agile techniques more effective than the non-agile ones? If there is more than one approach to "agile" then why is scrum so popular? Is it truly "best-of-breed" or does it just have better PR?

We would not be the first people to ask questions like these or attempt to measure the effectiveness of different project management techniques. For example, the American Department of Defence developed the Capability Maturity Model as a framework for assessing the project management facility of potential military contractors.

However, as a basic thought exercise I want to start with a much simpler proposition.

Of the methodologies listed above, which are more agile and which are less?

A simple question and to answer this we need a formal definition of "agile". Fortunately, the Agile Manifesto provides us with one. I like the manifesto as it shows a clear understanding of software development and a well thought out statement of values. It contains valuable insights that one should not dismiss.

Consider the first proclamation, "we value individuals and interactions over processes and tools". The Agile signatories are making a bold statement (and moreover it is their first statement) in valuing personal interaction over the process-orientated aspects of development.

This gives us a more clear-cut dimension for differentiability. We can consider techniques that focus on people orientated activities as "more agile" and methods that focus on process as "less agile". Of course, this is only one axis of comparison, a crude taxonomy perhaps but a useful and tangible metric to take for a spin.

The idea of "process" is politically charged and one of the reasons people can have strong emotional responses to project management "methodologies". This idea taps into more fundamental and nebulous concepts.

Process is an instrument of authority. A process is a statement of what to do, how we should do it and in what order. Process is conservative, hierarchical and formal. Process upholds the status quo. It is management imposing order and control from the top down. If process were a political party, it would be in the right Hegelian camp (and incidentally the right hand side of our line).

The alternative to process is to delegate responsibility, to trust individuals to organise themselves more effectively because they are better able to understand the task and therefore be more productive. Self-organisation is liberal, communal, informal, a meritocracy. It is emergent, bottom-up, grassroots. If we were to abuse the political metaphor even further, it would be some kind of hemp-wearing longhaired hippy socialist.

This is I feel very much cathedral and bazaar territory. To come back to something more tangible, we could consider "process" as belonging to traditional software engineering and self-organisation as belonging to software artisanship. Something Paul Graham so effortlessly explored in his essay Hackers and Painters.

With all these complex and fuzzy memes floating just beyond the grasp of our consciousness, it is perhaps no surprise that discourse often becomes tenuous and emotional. This milieu of uncertainty is a fertile breeding ground for religions like Agile and the peddlers that profit from it. Ask yourself why there is such a thing as a manifesto in the first place. It is unabashed political positioning rather than an objective view.

I am not a partisan of either camp. I am only interested in results and do not have the time or inclination to advocate a particular point of view. Getting effective and timely results is often about being flexible (although not always I might add) so it is worth understanding what you get from each.

So what is so great about process? Well, it gives us:

• Repeatable and predictable results
• Quality Assurances (through the above)
• Cost savings through the ability to optimise work flows
• Defined work flow allows us to use cheaper labour
• The promotion of best practices and conceptual integrity
• The ability to scale to large numbers
• A means to effectively track our progress against the objectives

McDonalds is a great example of successful process. No matter where you are in the world, you know what you are going to get and you get it quickly and cheaply. This process has successfully scaled to thousands of restaurants. Whether you consider this good or bad it is hard to argue with the results.

Nevertheless, software development is much harder than frying beef burgers. Process is sometimes inappropriate or unconstructive.

Process can:

• Increase cost and reduce performance through bureaucratic overhead and waste
• Hinder our ability to change or adapt to new situations
• Stifle our capacity for innovation and creativity
• Require discipline and training which takes effort
• Only effectively be applied to known quantities

Corollary, it follows that the opposite holds true for more people orientated approaches.

Consider what would happen if we went to the extreme ends of the line. Too much process and the project would grind to a halt, stifled by bureaucratic red-tape, protocol and form filling (much like government). Alternatively, no process at all and the project would be a chaotic mess of uncoordinated activity with lots of energy spent thrashing but generating very little momentum to move us forward (um - ok, much like government).

At the extremes, we always fail but of course, in practice nothing is "all process" or "all people". The trick is to define process where we need it and relax the requirement when it gets in the way. Good management is flexibility, identifying what is important and understanding when to apply a different approach. Many projects get into trouble when they try to take a technique that worked very well in one situation and apply it wholesale in a completely different scenario without understanding what made it a success in the first place.

All projects have different pressures, different criteria to meet and desiderata to balance. When I board a 747 for a transatlantic flight, it is pretty important to me that the plane will get to its destination in one piece and not smack into the middle of the ocean somewhere because some muppet forgot a semicolon. It is not so easy to restart a plane after it crashes to "see if it does it again". Safety critical systems demand assurances they will function correctly within well-defined parameters when we run them. This is more important than the time or cost of development and process gives us those guarantees.

On the other hand, updating an e-commerce website with the latest promotion or the CEOs colour de jour requires the ability to react quickly. An agile approach gives us that flexibility.

Even across very similar projects, the goals can be different. In game development for example, hitting the shelves for Christmas and keeping the costs under control may be crucial for a project. Whereas establishing a new IP then quality may be the overriding factor.

That is probably more than enough exposition, it is time to arrange our methods in order of how much process or people orientated they are.

The problem is that every method contains a mixture of different (and hopefully complementary) activities. In addition, the degree of "process" can change depending on the actual implementation.

Consider scrum. Amongst other things, we can define Scrum as

• Sprints
• Scrum Roles
• Sprint Planning Meeting
• Sprint Retrospective
• Sprint Review Meeting
• User Stories
• Daily Scrums
• Estimated Backlog
• Burn Down Charts
• Release Planning
• Stakeholder Collaboration

Teams often also include related activities such as

• Task Boards (kanban)
• Test Driven Design (TDD)

Clearly, some of these activities are "people orientated", such as daily scrums. However, TDD or Burn Down Charts are in my opinion process.

Microsoft has published empirical data that shows that the process overhead for TDD increases the development effort by 15% - 35%. Despite the many positive benefits from TDD, we cannot possible consider anything that adds an extra 35% effort to produce artefacts the customer will never see as lean. Amazingly, people still try and associate this with "agile".

To get a more accurate picture we should consider each methodology as a dynamic range encompassing all activities, which moves according to the actual real-world practice.

The point that I am trying to make is that when you get down to the details, defining what is or is not "agile" is not straightforward or clear-cut and putting activities into a box and saying what we can or cannot use just seems unhelpful to me. Agile was a necessary and important counterpoint to traditional software engineering thinking but only a small part of the overall picture.

I have seen very successful agile teams but many others that were abject failures. Similarly, some teams that have flourished with a traditional waterfall approach and then there were those that have consistently missed deadlines. It seems that success is not entirely dependent upon any one particular management approach and that the problem is more complicated than we might first assume.

There are many things that contribute to the success of a project and not all of them are always in our control. Whilst there are no guarantees, if we at least recognise the dynamics we have a better prospect of increasing our chances of success.

OK, so saying we need to pick the right tools for the job is perhaps not that profound. Nevertheless, I think it is important to say it and there are certainly people who need to hear it.

Once we buy into the idea that agile is just one of many tools, the questions become much more interesting. How do I know which is the most appropriate tool for a given job? What tools are there in the box? What are the essential characteristics of different jobs? "People and process" is a useful construct for illustration of course but only opens the batting on this front.

To answer these questions we need to get down to the specifics, those dirty and inconvenient details. Every game, every team, every company is unique and there are many factors that can affect a project - the size of the team, corporate culture, internal politics, budget limitations, physical constraints and so on.

However, there are certain dynamics and pressures we frequently find and are unique amongst creative projects. There are plenty of books that cover the usual suspects so instead I have picked out five things that I think are either particularly important or peculiar to the game development.

People
In my opinion, the most important success factor in project management is the people. Talented, motivated and experienced people deliver despite the management. They will find a way around processes that get in the way or add structure where there is chaos.

"Surround yourself with the best people you can find, delegate authority, and don’t interfere", Ronald Reagan

This idea underpins agile development and is fundamental to non-linear management. As this is perhaps, the single biggest factor influencing your success you should put every effort into hiring good people and weeding out the chaff. All this fancy management nonsense is really just icing on the cake.

However to assume you can always hire the best is somewhat na誰ve. There are some other things to consider.

• If you need to scale up the team size significantly you will face some hiring challenges and the best people will not always be available when you want them.
• Experience is expensive and your budget probably will not support an entire team of elite developers.
• Recognising areas where we can "deskill" without the loss of quality reduces costs which means we can either improve our commercial competitiveness or have more funds to redirect to other areas (you would not staff McDonalds with PhD graduates for example, although it might be interesting to try).
• Too many chiefs can lead to trouble. Who will lead and will experienced people be happy playing second fiddle? Unclear direction and authority will lead to poor conceptual integrity.

In the meantime, you have to work with what you have so understanding a person’s capabilities is a key skill for any manager and different people respond better to different things. Whilst some people like structure, others prefer more freedom for example.

Most agile methods assume that you have a brilliant, experienced and motivated team. Many agile techniques may work well but inexplicitly fail when applied to average, junior or apathetic members of staff.

Experience also plays a factor. For example, I would be prepared to take my best programmer, unleash him on some thorny technical problem, give him everything he needs, sit back and wait for the magic to happen. However, I would be less willing to extend that courtesy to a fresh faced graduate straight out of university. Most juniors need guidance, mentoring and structure until they find their feet.

It follows that a process-orientated approach would work better for juniors and a more people orientated approach may be applicable for senior members of staff. Corollary, we can see that the team composition in terms of experience and personalities will have a bearing in what approach works best.

Of course, people are much more complicated and idiosyncratic for this to be enough. My point is merely that different people respond to different approaches and that experience and skill are factors to consider when wondering if an "agile" or a "planned" approach is better for you.

Creativity vs. Production
There are two fundamental drivers in game development, creativity and production.

Production pressure comes from the business need to deliver a product on time and within budget. To do this we need to be able to quantify the work and risks, and this means planning and scheduling. This is hard work and requires a bit of effort but essential for answering those two key questions - when will we be done and how much will it cost?

For a plan to be precise and accurate, we ideally need to work with known quantities. Production therefore naturally leans towards quantifiable process driven activities.

Creativity on the other hand is the heart and soul of games development and pushes us to create better games. It is a woolly organic process of curiosity and exploration. There are no guaranteed outcomes or convenient timeframes and this is frustrating from a production perspective. This often leads to attempts to manage the chaos that more often than not stifles the creative process and blunts that "je ne sais quoi" quality.

It is not surprising then that some of the most innovative and critically acclaimed games have come from studios whose project management could charitably call disorganized . Similarly, "corporate" studios with mature project management structures tend to produce more derivative products. It seems these forces are mutually incompatible.

However, we have to be careful about what conclusions we draw from this. It does not follow that chaos is a prerequisite for creativity or that if we want to ship a game on time and within budget we must forgo innovation. We need to find a way to balance both harmoniously with the objectives and within the boundaries of each project.

There is a lot of mysticism surrounding "creativity", particularly within the games industry. This is a big topic beyond the scope of this essay. However, people have been studying creativity for many years and there various effective models and techniques we could leverage .

Creativity is a skill, like many others that we can teach, nurture and develop in everyone. It is less about a spark of genius and more about fostering the right environment that stimulates and incubates ideas. If you are interested in further reading I highly recommend the book "Orbiting the Giant Hairball" by Gordon Mackenzie which explores his experiences of being creative within a corporate environment.

Because of the iterative and changing nature of the creative process, it lends itself naturally to a more agile orientated management style. However naively applying scrum in the hope that you will magically be more creative is somewhat misguided. Flexibility is necessary but it is not sufficient.

Finding a harmonious balance between creativity and production is not easy and not all projects are equal. Whilst I would love to work on creative and innovative titles all the time, this is not always possible. The reality is that the business sensibilities (and by extension, production) are more important for the majority of companies. To be sustainable all businesses need to be profitable. If we want to keep staff employed and continue to make games then we need a profitable business.

For example, missing a milestone payment could be fatal for a small "work for hire" start-up living hand-to-mouth, so production (survival) is more important in this case. Alternatively, a large publisher-backed operation may want to establish a new IP so they can reap the long-term rewards this offers. For this project, they will have more appetite (money) to grease the creative wheels.

Product portfolio is another aspect to consider, a large studio may have one project to "pay the rent" (production focused) and a second to increase the prestige of the studio (creatively focused). Understanding the business context is important in assessing the capacity and ambition for each game and ergo, the best way to run it.

Some people make the argument that commercial success will simply follow from making a good game. It certainly does not hurt and in a perfect meritocratic world, this would be the true. However, we do not live in that world or at least it is not that simplistic. It is true that some studios have carved a niche out as being creative and innovative; this in turn has led to commercial success and investment interest. This is not viable for all studios and the difficulty they will face will be sustaining that momentum, continuing to be creative and innovative beyond one or two projects and surviving in the long-term. I wish them luck. Ultimately, the market will be the final arbiter.

Phases of Production
Another facet that is peculiar to the games industry (boxed products anyway) is the timeline - pre- production, production and post-production . The exact definitions vary between projects so I am going to define them broadly speaking as:

• Pre-production being the period in which we work out what the game is and how we are going to make it
• Production as the period in which we make the game
• Post-prod as the period in which we take the finished game and actually turn it into a good and shippable product. This in turn has two phases - alpha (game play polish, i.e. making it fun and balanced) and beta ("pure" bug fixing).

Interestingly even the most ardent agile proponent I have met still refers to these phases of development despite the obvious similarities with the design, build and test stages of a waterfall model. It appears they are intrinsic to game development at a fundamental level.

Agile methods prefer iteration to following a plan. This works in environments where the requirements are constantly changing and the overhead of rebuilding a plan each time would be too great. In game development, requirements change constantly so naturally an iterative approach would seem the natural fit.

We could for example apply this idea wholesale to the entire project lifespan and dispense with the pre, prod and post phases, which would look something like this.

However, the problem here is the cost of change increases with the more content we produce. Say we decide to change the distance the player can jump, and innocent enough change. This in turn has a knock on effect on the level designs and potentially a number of other systems and bits of content. The more levels we have produced the more expensive that simple change will be.

Above is a traditional cost of change graph you can find in many books on software engineering. The earlier we make a change the less it costs. Applying an iterative approach to the entire development lifecycle exposes us to potentially expensive changes later on.

Ideally, we want to have all the fundamental questions answered early so we do not have to change them later with the associated knock on cost implications. The pre-production period should have precisely that goal.

Pre-production is the most creative period of any game. Early pre-prod is very organic and exploratory; the latter part needs to focus on providing specific answers and technology so that when we enter production we have a good handle on the scope and pipeline. Therefore, if ever there were a time to be agile and iterative then it would be during pre-production.

The production period is where we create the content and in turn where we spend most of the money. We need to keep costs under control and the more process driven and deterministic this is the better. We still need to respond to feedback and change but we need to keep this manageable.

In alpha, we revert back to an iterative cycle as we refine, polish and tweak. Beyond alpha everyone is working from the bug database, which in my opinion makes it process driven albeit of the self-sustaining, organic kind.

We can change our approach throughout a project lifecycle; we do not always have to stick to the same thing throughout.

Skill Sets
Another peculiar aspect of the games industry compared to other development environments are the skill sets involved, the three most common disciplines being code, art and design .

The different nature of the work and the complex blend of interactions between disciplines is something we need to consider. Analysing the metrics gleaned from our in-house project management software we can see some common trends within my studio.

Art tends to be a deterministic discipline. Once we have generated a list of assets required and the workflow involved we can predict with quite a high degree of accuracy how long it will take and the end quality we will get. In addition, this work is divisible so adding more people means we get there quicker.

Code tasks on the other hand have very different characteristics. In comparison, the data shows that programmers spend much more time doing unscheduled tasks (anywhere between 20% - 40%) and are more inaccurate with their estimates. This is because they respond to change requests more often, fix bugs or deal with hidden complexity and imprecise designs. Additionally, complex systems are not divisible in the same way so adding more people is not always helpful.

It follows that what works well for artists may not necessarily suit programmers and communication difficulties may surface between the gaps. You could for example run the code team in an agile way but apply a more planned production approach to art, particularly in production.

Client
One interesting aspect of agile is the desire for stakeholder involvement. For simplicity, let us assume that our stakeholders are the publisher stumping up the case for the product. In games we have always had stakeholder participation in the form of an external producer who acts as a spoke person for other interested parties on the publisher side (marketing, legal, QA, etc).

This would seem to tick the boxes but whilst customer collaboration is a noble aim, not all clients are created equal. There are many factors to consider - how much trust and freedom are they willing to extend to you? How much meddling and interference can you expect? How much political clout does your EP have within the rest of the business? Just a few things that contribute to the environment in which the project must survive and understanding the external forces helps you plan your strategy and management style.

On a basic level, if you have a flaky client who is constantly moving the goal posts then an agile approach is your friend. If you have a client who does not care about the outcome too much so long as it is cheap and on time, then good planning will serve you well.

To talk about "agile vs. waterfall" is simplistic. My gripe with agile is not that it is bad or does not have value but that it is all too often used as an excuse by too many people for too many bad project management decisions. Developing software is hard and developing games is particularly tough. We only have to look at the software development landscape to see the rotting corpses of failed projects as evidence of this fact. But then if it were easy, it would not be anywhere near as enjoyable.

Whilst we continue to be blind to the essential complexities, there is fertile ground for charlatans peddling their snake oil with the fancy nomenclature and a "silver bullet" promise. Take a step back to consider your own position and revisit your assumptions. To be successful you need to work continually at project management, not be afraid to try new things, to experiment, to measure, to question but above all remember to have fun as you do. After all, is that not why we wanted to make games in the first place?

No two projects are the same, well - unless you make racing games.

Tiny Speck, a company started by Flickr co-founder Stewart Butterfield and three partners, is unveiling its new game, Glitch, on Tuesday. The company has been under the radar since it was founded last March, and no one has known what was being developed. But CNET's Daniel Terdiman reports from behind the scenes.

SAN FRANCISCO--Stewart Butterfield and his business partner Cal Henderson stared at the MacBook Pro in front of them.

For nearly a year, they'd been struggling to figure out what to call the game their start-up was building. Any time a team member loaded a working version, they'd sit through a few seconds of a splash screen with nothing on it but a generic title featuring little more than the name and logo of their company.

But now, the group had finally given their baby an official moniker: Glitch. And this was one of the first times the two had sat through the splash screen since plunking down a low-five-figure sum to buy glitch.com.

Butterfield and Henderson, dressed casually, were hovering over the computer in the bright, east-facing front room in a beautiful Victorian vacation rental that they'd been using for a four-day company off-site in mid-January. Everyone else had already left. Energized from an intense four days of brainstorming (and maybe a coffee run to a local hot spot called the Mercury Cafe) they were running a demo of their game. Watching the bland screen load as they had countless times before, Henderson's eyes lit up.

"I guess we could replace that with the title of the game now, couldn't we," Henderson deadpanned. "Yeah," said Butterfield. "We don't have to call it 'The Game Being made by Tiny Speck' anymore."

Indeed, on Tuesday, CNET is reporting exclusively, Tiny Speck plans to officially unveil their new game, Glitch, and for the first time, people will be able to see what this start-up has been working on since last March. The game will be in private alpha for now, and is expected to launch publicly in the second half of the year.

If Tiny Speck doesn't sound familiar, that's because the company has been under the radar since its founding. But if Butterfield's name rings a bell, it should. He and his former wife, Caterina Fake, were the co-founders of Flickr, the hugely popular photo-sharing site they eventually sold to Yahoo for a reported $35 million in 2005.

Tiny Speck co-founder Stewart Butterfield, who also co-founded Flickr.

(Credit: Stewart Butterfield)

By 2008, Butterfield and the other original pre-acquisition Flickr team members who had joined Yahoo celebrated "Vestfest," a shindig honoring the full vesting of their windfall from the sale, and he decided to move on. His resignation letter was true to form for the 36-year-old geek with a Cambridge degree in philosophy who grew up in a Canadian hamlet once popular with well-educated Vietnam draft dodgers.

"As you know, tin is in my blood," the cheeky letter to his boss began. "For generations my family has worked with this most useful of metals. When I joined Yahoo back in '21, it was a sheet-tin concern of great momentum, growth, and innovation. I knew it was the place for me....Please accept my resignation....I don't need no fancy parties or gold watches (I still have the one from '61 and '76). I will be spending more time with my family, tending to my small but growing alpaca herd and, of course, getting back to working with tin, my first love."

Stewart Butterfield's odd resignation letter from Yahoo was meant as little more than a way to enliven the day of the company's HR team.

(Credit: Stewart Butterfield)

Today, Butterfield explains that the letter was little more than a way to enliven the mundane lives of Yahoo's human resources department, and contained no metaphors. Still, reading the letter now, it's obvious that "tin" refers to Web-based entrepreneurship.

Indeed, despite his Master's in philosophy and an original plan to get a Ph.D., Butterfield was lured away from a life of academia by the excitement of the late-1990s dot-com boom. He consulted for a while, and then helped start, and quickly sold, a small company along the lines of Classmates.com called GradFinder.

True Flickr devotees will remember that before that service blossomed, the team behind it had first been operating as a start-up known as Ludicorp, which was working on an online social game called Game Neverending. Wikipedia defines it as an "atypical role-playing game primarily based on social interaction and object manipulation. [It] was lighthearted and humorous; indeed there was no way to win, nor even any definition of success." Despite developing a passionate audience, they abandoned the game after it became obvious that Flickr was more viable commercially. Now, years later, Butterfield had reassembled a cadre of the earliest members to do what they didn't last time: build a game and a real business around it.

Their rationale? That the lessons they learned about how to build a passionate, actively-involved community while making Flickr a world-famous company, along with their ideas about how to construct a compelling social game, position them uniquely at the potentially highly-lucrative intersection of World of Warcraft and Facebook.

Glitch is a social online game that takes place inside the imagination of 11 ancient giants. It has a series of very artistic aesthetics, as this screenshot demonstrates.

(Credit: Tiny Speck)

I'd written about Flickr since 2004, so when I ran into Butterfield last March at a soul food restaurant in San Francisco during the 2009 Game Developers Conference, I told him I'd heard about his new start-up and made him an offer I was sure he'd refuse: In return for determining when I could publish, but no other editorial control, he'd give me regular, exclusive access for a behind-the-scenes story about the new company.

Butterfield and his partners had built one of the flagship Web 2.0 companies and had become household names among the geek set. Who wouldn't want the very rare opportunity to see behind the curtain as he and his crew tried to do it again? I know I did.

But companies almost never let the press see the sausage works, so I expected a polite no. Instead, after about a month of intermittent e-mail exchanges discussing the idea, a message popped up on my screen that began simply: "Hi Daniel - let's do it!"

Tiny Speck off and running
In an early back story that Butterfield, Henderson, and fellow co-founders Eric Costello and Serguei Mourachov came up with for their new game, an 11-year-old Japanese girl loved drawing in different styles. But she was never satisfied with her work and would crumple up her compositions and toss them out the window. There, said Butterfield, they would "get sucked up into this wind and each one comes to life (like) tiny specks on motes of dust."

In March 2009, the four founders filed articles of incorporation in Delaware for their new company, Tiny Speck. The state of Delaware thought they were called Tiny Spec, and their checks read "Tiny Specks," but no matter. They were off and running.

From their home offices in San Francisco, Vancouver, and New York, Butterfield made the trains run on time; Henderson handled the front and back ends of their fledgling system; Costello built the client; and Mourachov--"the Russian mad scientist guy"--built the game server. (Click here for more on the founders).

Their pitch to venture capitalists was simple: they would do for massively multiplayer online games [MMOs] what Nintendo's Wii did for video game consoles--bring a niche product to the masses. And make a lot of money doing it.

Certainly, they also had what countless entrepreneurs would kill for: a reputation for rewarding investors' faith in them. The team quickly scooped up $1.5 million in seed funding from the A-list VC shop Accel Partners.

Glitch, at its most basic, is a 2D Flash, Web-based, social MMO with a heavy puzzle-solving component. Or, as the team likes to call it, a "collaborative sim." Its back story centers on a great but very dark future, and a group of scientists who discover a path back in time to create the optimistic future everyone wants.

"The whole world was spun out of the imagination of 11 great giants," Butterfield, who often speaks in a soft, hard-to-hear voice, said. "So you have to go back into the past, into the world of the giants' imaginations and grow...the number of things in the world, grow it in terms of physical dimensions, to make sure the future actually happens. So all the game play takes place in the past inside the world of the giants' imagination."

Practically speaking, Glitch is a social game (see sidebar for more detail about the game) about learning how to find and nurture resources, identify and build community, and proselytize to those around you. It's not about epic, bloody battles. "Rather than you and me fighting each other with swords," Butterfield explained, "it could be you and me having rival religious factions battling each other for converts."

Along the way, players level up by completing quests, gaining skills, growing all manner of things, and making their way through a sometimes Mario-esque world of different artistic styles, each of which can be thought of as being inside an individual giant's memories.

Even though Glitch is going into private alpha Tuesday, Tiny Speck already has thousands of people in a testing queue, and the company will likely be inviting about 100 people at a time into the game over the next few months. If you're not already on that list, and you want to play, sign up--but be patient.

In the minds of giants
Beginning last May, I met with Butterfield and Henderson every month or two, usually at the 29-year-old British-born Henderson's Hayes Valley loft here in San Francisco. Though he often walks around in T-shirts and shorts and eats Lucky Charms straight out of the box, there's no doubting he's accomplished. Henderson, who literally wrote the book on building scalable Web sites, is best known in geek circles for having designed and built the Flickr APIs, which influenced many developments on the Web, including OAuth.

During my first visit to his light-filled loft, located on the same block as Second Life publisher Linden Lab's first office (complete with a six-foot-tall plastic Ferris wheel, a shelf full of Make magazines, multiple computers, and the obligatory copies of Halo and World of Warcraft), the two partners weren't sure what to call this open-ended fantasia.

Among their considered, but rejected, ideas had been: Paper Moon, based on the Japanese cut-out collage motif of the 11-year-old girl and her crumpled paper, but another game company beat them to the name while Tiny Speck pondered; One Billion Daydreams, which was about the universe inside the mental wanderings of a billion people; and Inside the Minds of Giants.

Each illustrator used a different style, meaning that players can peer inside the different aesthetic of each of the giants.

(Credit: Tiny Speck)

During an October meeting with Butterfield and Henderson, they told me they'd settled on the latter. But moments into our January meeting in the Victorian vacation rental, Butterfield started things off by saying, over the sounds of traffic from the thoroughfare just outside the window of the front-room salon, "Yeah, so the name of the game is Glitch."

"We were going to call the game Billion Year Itch," continued Butterfield. "And then someone said 'Glitch' and [that] stuck. We just had really positive reaction from everyone we told it to."

On Glitch.com, Tiny Speck spells it out a little more: "It's called Glitch because in the far-distant and totally-perfect future, the world starts becoming less and less probable, things fall apart, the center cannot hold, and there occurs what comes to be called the 'glitch'--a grave danger of disemprobablization."

Tiny Speck's business plan, too, has morphed since its founding. In the beginning, Butterfield wanted to pursue a subscription-only model, but over time, he saw that a free-to-play game would probably attract a bigger audience. Money, then, would come from a combination of virtual item sales, subscriptions offering premium services, and the sale of mini games that unlock new, otherwise inaccessible skills, both for the Web and iPhones and Android devices.

With all those potential sources of revenue, Butterfield believes that Glitch can eventually earn between $30 and $40 per user per year, a range that, if large numbers of people sign up, could mean very significant profit margins.

Even if that's not possible, Tiny Speck's costs are fairly low. It has just eight full-time staffers, including the founders. Though the company will soon open offices in Vancouver and San Francisco, Butterfield said there's enough in the bank to get to launch, hopefully sometime in the second half of this year.

Still, Butterfield expects to secure a $3 million to $5 million A-round of funding in the next few months in hopes of not being distracted by fund-raising while in full production mode.

Ripping out the game mechanic
From its earliest days, the game had a core game mechanic--essentially a system of rules--in which players would initially choose one of five character classes--a dandy, a monk, a mastermind, a huckster, and a gumpteur--and then choose both a primary and secondary talent from among panache, flow, brains, gumption, and wile. A dandy would have panache and flow, while a monk would have flow and brains.

But when I visited with the Tiny Speck team in late October of last year at the tail end of a four-day offsite (see stop-motion video below of the Tiny Speck team's first design charrette--meeting--in Vancouver on April 29, 2009) in the Victorian vacation rental, Butterfield casually dropped a bomb: They were tossing that game mechanic onto the trash heap.

With the house full of engineers and all four of the founders, it was hard to hear as loud voices echoed through narrow halls and rooms with high ceilings. The team had been staying in the house for four days and working non-stop, morning to night, and it had the air of a geek slumber party. The password for the temporary Wi-Fi network they'd set up was "stewartisanass" because, co-founder Eric Costello said with a smile, "Stewart was being an ass the day we set it up."

According to the 39-year-old Costello, who lives and works in the Astoria neighborhood of Queens, N.Y., though the Tiny Speck team had bought into the original mechanic since the beginning, none had been totally happy with it.

"It seemed good enough," Costello, an early blogger and one of the first Ajax scripters, said, "but it was really foreign. Part of the motivation (had been) to make the upfront decision for a player about what type of character they're going to be. But (we decided) to let that come out of how they play the game and the choices they make while they play the game instead of something they choose before they're ever in the world and know anything about it."

From that point on, Tiny Speck began building a new core mechanic centered around skill trees in which players begin the game by choosing from certain low-level talents, such as animal kinship, green thumb, and the like. Then, as they build up skill points, they can spend them on new skills, which in turn open up "a bigger possibility space," Butterfield said.

Happy Place
From the get-go, the Tiny Speck team set out to craft their game using a series of five three-month development cycles, each of which would comprise two months of hard-core work, followed by a month of "cleaning up after ourselves," essentially testing and optimization, and each of which had a set of specific goals and milestones.

Each cycle had a name, and when I first started visiting with Butterfield and Henderson, they had just finished the first, which they called Happy Place. The goals for that three-month period? To get done "the minimum amount of stuff we needed to get done (for the game) to be fun."

The next cycle was to be called Bay of Pigs, and the objectives were to complete the addition of an in-game currency, auctions and stores, groups, object making, and a system for death. Following that was Water World, with mini-games, politics and elections, property taxes, and all things related to water; Macademia, which would augur a private beta; and finally, the "nice and ominous" Jonestown in time for the public launch.

Another big goal, of course, was to staff up. While a core team of four partners was, as Henderson called it, the "absolute minimum needed for developing," it was clear to the founders that they'd need to grow in order to meet their objectives.

Throughout my series of meetings with the team, Butterfield always made it clear that slow and deliberate growth was key. In June of last year, Tiny Speck was still just the four founders plus a small group of contract illustrators--"we don't have an accountant," he said, "instead we have several envelopes stuffed with stuff so when we get an accountant, they'll be busy for months."

But when I stopped by Henderson's place in August, they were romancing their eventual first new hire, then Digg creative director Daniel Burka. It was a secret that Burka was considering leaving Digg for Tiny Speck, though to hear the three of them talking that day, it seemed like a done deal. As Butterfield and Henderson talked to me about the status of the project, they were also filling in Burka on what was going on, and to me, it felt more like an orientation than an interview. If it was an interview, Burka was definitely the one with the upper hand. By October, Burka was on board as the director of design.

Now, Tiny Speck is up to eight full-time people and 12 contractors, including Vicki Wong--who goes by the name Meomi and who designed the mascot for this month's Winter Olympics in Vancouver. Next up, said Butterfield, a vice president of operations and four other staffers.

An article of faith
When Flickr was in its earliest days and still independent, the start-up came up with a clever bit of psychological judo as a slogan. "Use Flickr, because why not use Flickr," it went. Last spring, at my first Tiny Speck meeting, Butterfield remembered that and said they might try that again this time around. After all, he said, "it's a very effective slogan. It's very difficult to argue with."

Now, though he chuckled and agreed with himself that it's hard to argue with that reasoning, he said Tiny Speck won't be borrowing that language. Instead, they're going with a much more succinct and to-the-point tag line: A game of giant imagination.

As anyone who's ever tried to start a company knows, it takes a lot of ambition, talent, luck and, yes, imagination, to make it work. But Butterfield and Henderson have never had any doubts that they will once again build a popular and financial success from the ground up.

"I'm just taking it as an article of faith that we'll make money," Butterfield said.

"If you have a good idea and it's well executed," Henderson added, "then you'll make money."

Come back tomorrow for part two of the Tiny Speck story, a closer look at the game's systems and platforms.

• amazon (aol)
• best buy (bank of america)
• craigslist (cnn)
• dictionary (disney channel)
• ebay (espn)
• facebook (facebook login)
• gmail (google maps)
• hotmail (hulu)
• imdb (itunes)
• jcpenney (jet blue)
• kohls (kmart)
• lowes (lady gaga)
• myspace (mapquest)
• netflix (nfl.com)
• office depot (opm)
• pandora (photobucket)
• qvc (quotes)
• realtor.com (reverse phone lookup)
• southwest airlines (sears)
• target (tiger woods)
• usps (ups)
• verizon wireless (victoria secret)
• walmart (weather)
• xbox 360 (xm radio)
• youtube (yahoo)
• zillow (zappos)

admin data mining

Understand Bikes

• Understanding Handlebars

• Understanding Bike Stems

• Bike Stem Calculator

Discover Bikes

We love bikes. We want you to love bikes too.

Brightspoke is new. Our mission is to put more people on bikes by creating informed consumers. Please share some love or let us know what you think.

Let's get this part out of the way: Attempting this modification to your television could lead to your being left with a non-functioning unit with no recourse to the manufacturer. N.B. This is only tested on a TX-PXXG10B (XX refers to the screen size and is irrelevant).

I'll try and make this as easy as possible, but, if at any time during the process you have second thoughts, don't panic! The only time you have done anything you can't go back on is during the reboot of the television!

If possible you should print out this document before starting the following process!

Step 1: Accessing The 'SERVICE' Menu. Hold down the 'V-' button on the side of the television (it's the 3rd one from the top), while at the same time pressing '0' (zero) on the remote control three times. You should soon be faced with the screen below (don't worry that the colours have become overblown and garish; the television automatically switches to 船ynamic' picture mode when accessing the service menu):

Step 2: Entering The 'SRV-TOOL'. Use the '1' and '2' buttons on the remote to navigate up and down the sub-menus in the 'SERVICE' menu. In this case you only need to press '2' once to get to the 'SRV-TOOL':

Press 'OK' to enter the next menu. You should now be faced with this table:

Navigate to the top right hand cell with one press of the '>' (right) directional Button on the remote control. Then hold down the 'MUTE' button for a few seconds and the cell should change to say 'Memory Editor'. Press 'OK' to access the menu. You should now be faced with this:

Step 3: EEPROM(Peaks). On the top left hand side of the Memory Editor you'll see four areas of memory that are accessible. You only want to enter the EEPROM(Peaks) area. Do so by pressing the 'V' (down) directional button until it's highlighted, then press the 'OK' button to access the menu.

Step 4: The Edit. You should now be looking at this:

It's line 40 that you want to alter. Again use the 'V' (down) directional button to get to line 0000040 (press 8 times). Your line 40 should have an 03 at value 6 (the 6th pair of charaters from the left). It should read like this although value 8 will vary depending on your screen size, but it's irrelevant!

19 06 19 00 31 03 02 20

Use the '>' (right) directional button to highlight it (press 5 times). Using either 'VOL+' or 'VOL-' on the remote control, you want to change the 03 value to 20. The values you scroll through are hexidecimal and therefore alphanumeric (0-9 and A-F). Any mistake here is extremely likely to stop your television working, which will require an expensive repair! Once you are satisfied that your line 40 is now reading this, press 'OK' to save.

19 06 19 00 31 20 02 20

Step 5: Reboot. Simply press 'EXIT' on the remote control twice and then once back in the 'SRV-TOOL' hold 'EXIT' down for several seconds until the television reboots. At this point you'll either have some exciting new menus or a broken television. I'll let you discover all the new menus yourself :)

I Wish You Luck!

Remember:
IT'S AT YOUR OWN RISK!

This is part of my series on Startup Advice.

When I worked in London there were a ton of Aussies.  I love working with Aussies because their outlook on life seems very similar to what I grew up with in California.  Pretty laid back and non-hierarchic.  I also loved learning all of their sayings.

My favorite was when I guy told me to beware of Crocodile Salesmen. What’s that?  ”You know, big mouth and no ears.”

That’s always stuck with me.  Crocodile Salesmen are people who are always talking.  They’re pitching to you.  They don’t take the time to realize what your true motivations are because they’re too busy telling you what they THINK you want to hear.

Trust me – your chances of selling are much lower if you’re talking rather than actively listening.

I’d like to talk about Crocodile Salesmen in 3 scenarios: 1) when YOU are selling (or someone on your team), 2) when you are trying to recruit a sales person and 3) raising VC

1. YOU Selling – My wise old friend & mentor, Ameet Shah, once told me after a meeting we had with clients (when I worked at Accenture), “there are two ways to run a meeting: asking or telling.  You’re a persuasive guy but be careful not to always be telling people the answer.  Nobody likes that.  You learn much more about how other people think when you’re asking.  And you get to better results.”

That stuck with me long before I was ever a CEO (aka chief salesman).  It is my natural style to want to “tell.”  I’m an ENTP.  Many of you are “tellers,” too.  I know because many entrepreneurs I spend time with I can tell are in their own brains when we’re meeting rather than trying to understand what my position is.    You’re in sales mode.  I still do this sometimes, too.  But I’m keenly aware afterward when I’ve done it and kick myself.

This point is also echoed by the author of my favorite business (life) book of all time – The 7 Habits of Highly Effective People (by Stephen Covey) – in which he says as one of the habits, “seek first to understand, then to be understood.”  If you follow that mantra I assure you it will lead to more positive results in whatever you’re doing.

But how to apply “listening” in a sales meeting?  Let’s assume you run a Customer Support software company.  Do you simply begin by asking, “I’d love to understand what your objectives are in customer support?  Where are your current pains?”

Never.

You need to first establish two things: credibility and rapport.  I recommend starting the meeting with a VERY brief introduction of your company, your background and why it’s relevant to the job you currently have.  I would then always say, “Obviously we know a little bit about you but if you feel comfortable we’d love to know just a little bit more about you and about your role.”

Too many people are racing through the pitch, pitch, pitch that they don’t realize it’s polite to let the “opposing team” talk and do intro’s also.  They’re into crocodile mode.

After that you need to begin discussing your company.  You need to identify a customer problem and talk about how your solution meets the needs of that problem.

What I personally recommend is that you use “What We Find’s.” Highlighting a few problems that you have seen in some of your existing  customers.  You can mention them generically.  Even better if you have permission to discuss actual names as a “reference client.”

So you would say (in the Customer Support example), “What we find is that many of our clients have existing ‘trouble ticketing’ systems.  But many of these aren’t integrated with the way that their customers want to communicate with them in 2010.  They don’t handle Twitter feedback, emails or IM.  So ‘what we find’ is that many of our customers are using separate tools for managing these but don’t have a holistic view of the customer.”

So you’ve identified a problem.  But DO NOT crocodile into your solution page.  You have hopefully established enough rapport and credibility by this point to enable you to ask a question.  Start very simply and subtly, such as, “do you find similar challenges at your company?”  Hopefully this will elicit a long-enough answer for you to engage in a discussion.

If you get no love after that you might be in for a tough meeting.  You have no choice but to jump into solution mode for a bit to see if your case studies on a successful implementation at other customers opens up the person you’re meeting a bit.

The end goal in your meeting is to get the customer to trust you enough to talk about their existing problems.  You should be actively listening the whole time (actively listening as in listening, writing important things down and asking relevant questions as they talk about their problems).  At the end I normally like to say “I’d love to list out what I  think I heard are your issues to test whether I had properly understood them.”  Normally after I read off my summary they clarify points a lot and I realize that I was only directionally correct.  Always “test your understanding.”

The art of building rapport, establishing a base of credibility and then shifting to a discussion is how the best sales processes work.  The quicker you slip into Crocodile Mode the greater the chance that you’re telling somebody about solutions you have to somebody else’s problems – not your prospect’s problems.  Or you’re not speaking in their company’s vernacular so they’re not making the connection.

Beware of Crocodile Sales.  They are seldom productive.

2. Hiring a Sales Person – So you’re running your own startup and you need to be able to hire a sales leader and ultimately more junior sales people.  You conduct an interview.  How do you know if you have the right person?  The best sales people understand that an interview is a sale and they demonstrate that they understand the process by conducting your interview in the format I outlined above.

If they start the meeting with, “I’d like to know what you’re looking for in your VP Sales person – what’s important to you?” then it’s going to be a long meeting.  They clearly don’t understand that until they’ve established rapport they haven’t earned the right to ask that question.  This happens in about 10-15% of the candidates I interview.

The much more common is – you guessed it – the crocodile sales person.  After some basic banter of getting to know each other I turn to their resume and ask some questions.  A good sales person knows to answer each question briefly and then check back with you, “would you like me to go into more detail in that area?”  A Crocodile Salesperson is off to the races.  Turn on your stop watch – they’ll be talking for the next 12 minutes about all of the great and successful campaigns they’ve led – even before you’ve asked.  Zzzzzzz.

I always politely listen even though I may have already written them off.  I probably will jump in with a few questions about their industry and start a discussion.  I know they’re not going to get the job but I don’t want to be rude and end the meeting in 10 minutes.  But to spare me from 50 minutes of totally wasted time I figure I might as well use it as a chance to learn a bit more as an industry.  Unfortunately this happens in at least 40% of my sales person interviews and confirms my theory that at least 40% of sales people suck.  Probably higher.

The GREAT sales people know how to turn an “interview” into a “discussion.”  This is a rare gift since the interviewer often feels empowered to run the meeting as he / she sees fit and doesn’t intend to cede control.  But I’ve had situations where I’ve intended to interview a candidate and he’s flipped it to a point where I feel like I’m trying to convince him what a great opportunity this is.

It’s subtle and slow.  It starts with the basics: rapport and credibility.  Then it moves to politely answering questions as asked and short bursts.  But after a few of these I’ve noticed some great sales people then throw in a question.  They are not generic questions.  They are specific ones that show that they’ve done their research.  ”I noticed that you’ve had some success with your customer support software on Twitter accounts, but how do people using Salesforce.com typically respond?  Do they want it all in one solution?  I’d love to understand how that part of your sales process goes, if that would be ok.”

BOOM.  Now I’m selling.   And just when I thought I’d answered it he finds a clever way to ask a follow on question that demonstrates both his research / knowledge of my company AND he’s asked a question in a way that he’s demonstrating his sales knowledge so that he’s still scoring points, “when I was at Oracle the problem we ran into competing with Salesforce was A,B,C.  We found some success when we tried D, E, F.  Have you guys faced similar experiences in selling?”

3. Pitching a VC – As I said in a previous post – the best VC meetings are discussions and not sales pitches.  Let’s be honest – raising money IS a sale and you need to treat it as such.  You’re running a sales campaign to raise money.  You have target customers, you have competitors and you have a product to sell.

So all the same rules apply.  Prepare for your meetings by doing research before you go.  Try to find out who in the organization is most likely to buy your product.  It’s always best to “sell high,” which means to get in front of the most senior team if you can.  But also to focus on somebody who is interested in your area – not just the partner you can most easily get intro’d to.

And importantly – when you have your meeting: build rapport, establish credibility (if you haven’t seen why I believe the first slide in your deck should be your bio’s see this post), and find a way to flip it and ask the VC to respond with their point of view on topics.  VC’s have a crocodile aversion as much as the next guy.

(Cross-posted @ Both Sides of the Table)

Any assessment of your own abilities is necessarily polluted by your optimism, your pessimism, your passion, and your everyday delusions. On top of that, you are influenced by other people's opinions of your abilities, and other people are just as clueless as you.

When I was a kid, I wanted to be a famous cartoonist. I assume now that it was more wishful thinking than premonition. But my self-assessment at the time was that I didn't have the necessary talent. I thought I might someday be a pretty good lawyer, or a banker. So I became an economics major. I got lucky in the sense that I poked around at the wrong professions, trying this and that, including cartooning, until finally something worked. And even as my cartooning career was taking off, the majority of experts were pretty sure I didn't have the talent to make an impact. All but one syndication company rejected my original submission for Dilbert. And for the first several years, 90% of all newspaper editors didn't see any potential in it. I was sustained through those years by a handful of insightful people at United Media who thought Dilbert could someday be big.

In summary, the two opinions about your abilities that you should never trust are your own opinions, and the majority's opinions. But if a handful of people who have a good track record of identifying talent think you have something, you just might.

Dear Entrepreneur:

It has recently come to my attention that you are making some rookie mistakes raising capital. I’m told some of these have been expensive mistakes, sucking hundreds to thousands to tens of thousands of dollars out of your moth-eaten pockets. As it is in the best interest of the entrepreneurial ecosystem for all parties to be educated, I am writing to you today to address one error you are committing.

That error is the sin of paying to pitch to investors. Please, for the love of all that is good in the world, just stop doing it. It rewards shitty behavior. It props up lame investors. It makes you look like a fool. It propagates bad behavior throughout the ecosystem.

If you really have something cool to pitch, I promise you that investors really really want to hear from you. Trust me. Pick up the phone and make some calls. Talk to your mentors and co-workers and professors and friends and family and make some connections. Do your research. Get in touch with the right investors. You don’t have to pay to get a meeting.

In fact, if you walk up to an investor and tell them “Hi, my name is Bob and I just paid thousands of dollars to pitch to you!” I promise you the investor is going to think: “Wow. Bob’s a moron. I’m sure as shit never gonna fund Bob.”

If you want to pitch investors, make a connection to them. In the world of LinkedIn, Facebook, Twitter, and more (and don’t forget the old standby: the telephone!) anybody with a pulse and useful brain cells should be able to make connections to meaningful investment groups. A few emails and calls are a LOT cheaper than some of the whack things I see going on out there. Let’s stop the insanity.

Of course it is a free country. If you must flush your money down the toilet, then that is absolutely your prerogative. Just don’t expect caviar and wine to spew out when the toilet backs up.

Sincerely,
YT

This entry was posted on Monday, February 8th, 2010 at 23:12 and is filed under Business. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Human rights 'threatened' by Digital Economy Bill

Parliament warns government of danger of file sharing bans

By Carrie-Ann Skinner

Banning web users suspected of illegally downloading content from the internet could breach human rights legislation, says the Joint Select Committee on Human Rights.

According to the group of MPs and members of the House of Lords, the proposals set out in the Digital Economy Bill reference 'technical measures' which could be employed to block internet pirates' web connections.

However the committee said the technical measures had not been "sufficiently specified".

"The concern we have with this Bill is that it lacks detail," said Andrew Dismore MP and chair of the Committee.

"It has been difficult, even in the narrow area we have focussed on, to get a clear picture of the scope and impact of the provisions."

Dismore added that the internet is constantly creating new challenges for policy makers but "cannot justify ill-defined or sweeping legislative responses, especially when there is the possibility of restricting freedom of expression or the privacy of individual users".

The Department for Business, Innovation and Skills (BIS), which is responsible the Digital Economy Bill, said the proposals do not contravene human rights.

"Slowing down or suspending people's broadband would only be invoked following several clear warnings," said a spokesman, adding that the technical measures will require "secondary legislation". ISP TalkTalk has also voiced its concerns over the 'three strikes' rule.

In October last year, Andrew Heaney, the executive director of strategy and regulation at TalkTalk, told The Guardian: "If the government moves to stage two we would consider that extra-judicial technical measures and would look to appeal the decision [to the courts] because it infringes human rights".

As a result of its concerns, the ISP launched the Don't Disconnect Us campaign which aims to ensure the government gives every web user accused for illegally file-sharing a fair trial before cutting them off from the web.

I’ve heard the argument "you don’t need a compiler, since PHP is rarely the bottleneck" for many years. I think its complete bollox. But I wrote a compiler for PHP, so I would say that.

Unless your PHP server is sitting there idling (which is probably the case for many PHP servers out there), then you could make use of a PHP compiler. For small timers, all components of your application are going to be sitting on the same box, contending for the same resources. Even if you assume the DB is the bottleneck, the resources the interpreter consumes could be more profitably spent on the DB.

The PHP interpreter is also quite memory hungry, as interpreters go. Any PHP value in your program uses 68 bytes of overhead [6]. An array of a million values takes over 68 MB. If HPHP is able to convert your million value array to native C types, it will only take 4MB. I’m sure your caches could make good use of that savings.

However, optimization isn’t only about speed. The main value is that they give you freedom in how you code.

There is a meme in the scripting language communities that {PHP,Ruby,Python,Perl,etc} are "fast-enough". If you need it to go faster, then you should take your hot-loop and rewrite it in C. HPHP will free you from such concerns.

You should consider also that PHP is considered relatively fast. Its not — the interpreter is dog-slow — but programs written in PHP are typically not that slow. This is because most of PHP’s huge standard library is written in C, with a thin layer of PHP over it. Anytime you call a string function, your PHP C string is passed into the C library, the pointers are manipulated and the bits are twiddled, and then it’s handed back to your code. Its a bit like driving in America: it takes a few minutes to get on the freeway, but once you’re on it you’re there in no time.

This is not necessarily a good thing:

1. if you want to write a library, and it needs to be fast, then it needs to be written in C,
2. if there is a PHP function that does almost what you need, and you write your own version instead, it will be slow.

Believe me, if your entire application just ran PHP interpreted code, it would not be fast at all. But people who write PHP functions and libraries don’t want to write C. They like PHP, are productive in it, and any time spent arsing around in C is wasted when there’s a website falling apart and a long list of features due yesterday. HPHP will free you from such concerns.

Compilers also provide other niceties. You don’t have to unroll your own loops, or move constant expressions out of loop headers. I don’t know if HPHP supports these, but I’m sure it could.

Allowing your existing code to go faster is hardly the point though. Really, the point is that you can do more in less time. Suppose you’ve decided that your application needs to response to the user in 500ms. The DB takes 200ms, the request takes 200ms, the framework takes 50ms and your code only has 50ms to run [7]. That’s quite a constraint. This leads to people using PHP as a simple templating layer, instead of as the Turing-complete langauge it is. I expect we’ll hear a lot more about HPHP, simply because of how freeing it is to the user.

So even if you only have a small VPS, instead of massive server farms like Facebook, you’re likely to find a use for HPHP. I’m sure shared hosts will set it all up soon for their users, and everyone will be happy.

Versioning provides an additional layer of protection for your S3 objects. You can easily recover from unintended user errors or application failures. You can also use Versioning for data retention and archiving. Once you have enabled Versioning for a particular S3 bucket, any operation that would have overwritten an S3 object (PUT, POST, COPY, and DELETE) retains the old version of the object. Here's a simple diagram of Versioning in action:

Each version of the object is assigned a version id. For example, each version of Robot.png has its own version id:

The actual version ids are long strings; I've used v1, v2, and v3 to simplify the picture. You can retrieve the most recent version of an object by making a default GET request or you can retrieve any version (current or former) by making a version-aware request and including a version id. In effect, the complete key for an S3 object in a versioned bucket now consists of the bucket name, the object name, and the version id.

S3's DELETE operation works in a new way when applied to a versioned object. Once an object has been deleted, subsequent default requests will no longer retrieve it. However, the previous version of the object will be preserved and can be retrieved by using the version id. Only the owner of an S3 bucket can permanently delete a version.

Normal S3 pricing applies to each version of an object. You can store any number of versions of the same object, so you may want to implement some expiration and deletion logic if you plan to make use of this feature.

Enabling Versioning's MFA Delete setting on your bucket provides even more protection. Once enabled, you will need to supply two forms of authentication in order to permanently delete a version from your bucket: your AWS account credentials and the six-digit code and serial number from an MFA (Multi-Factor Authentication) device in your possession.

You can read more about Versioning in the S3 documentation.

-- Jeff;