Closer To The Ideal

A very clever trick for using a portion of the Symfony framework to respond to Ajax calls:

Now I can execute a component from the client side. The component architecture offers native View/Controller separation, and the configuration initialization brings autoloading, database access, and more. It does work perfectly, but is it fast? Speed tests show that not launching the filter chain saves about 40% to 50% of the cost of a symfony initalization. This means that you can multiply the number of requests that your server can handle by two – for very simple requests.

Back in the 1990s, I enjoyed programming some games for myself and friends to play. Once the game existed, and we’d played it a few times, we’d start asking, “How would the game change if we changed X?”

Via Brad Delong, I stumble upon this oddly simple economic model from Paul Krugman:

But if the money supply is constant, M’ = M; also, C = L. Given the utility function, consumers will spend a share 1-s of their initial wealth on goods, s on money. So we can represent equilibrium either by the condition that demand for goods equal supply,

L = (1-s)(L + M/P)

or by the condition that demand for money equal supply,

M/P = s(L + M/P).

Both ways of looking at it imply the price-level equation

P = [(1-s)/s)](M/L)

so the price level is proportional to the money supply.

If he’d flunked out of economics school, he could have done a lot to improve SimCity.

I thought the title of this article was funny:

Converting legacy Rails apps to Grails

So now there are “legacy Rails apps”. Sort of makes Rails sounds really ancient. One of the dead languages. You know, Cobalt, Fortran, Rails…

Jeff Howe writes about crowd sourcing and how some sites are getting designers to work on spec:

So one might expect crowdSPRING and 99designs to wither away like so many other seemingly ill-conceived Web 2.0 start ups. Instead, they seem to be flourishing. 99designs says it has paid out over $4 million to its community of 30,000 artists, and crowdSPRING expects to be profitable by next year. The success of crowdsourced design has sparked a vibrant, highly emotional debate within the design industry.

Alarmed by the popularity of the spec model, a group of designers formed a protest group called NO!SPEC to persuade their colleagues (and prospective clients) to just say no to design contests.

He make the point that what is now happening to design is what earlier happened to stock photography:

iStockphoto and other so-called “microstock” agencies capitalized on a similar disparity. The result was the total disruption of the $2 billion stock photo industry. iStock is now the third-largest purveyor of stock images, and some 96 percent of its “workforce” is comprised of amateurs. In my crowdsourcing book I posed the question of whether stock photography was an isolated case, or just the canary in the coal mine. It was an open question as of April 2008 when I submitted the final changes to my galleys. Now it ain’t. The canary is prone, lying motionless on a bed of its own droppings. It looks like it’s time to find another mine.

My dad was a stock photographer during the golden years, 1950-1990, when it was possible to make really good money doing stock photography – adjusting for inflation, 6 figure annual incomes. That began to change in the 90s, due the proliferation of royalty-free images, and distribution over the Internet (some of the same forces that re-shaped the music business). And then, there was the incredible consolidation of the business. An industry that had been made up of hundreds of small and mid-sized businesses consolidated around just 2 giants: Corbis and Getty.

Getty, in particular, acquired a reputation for offering harsh contracts to photographers. My dad was irritated that they offered “on spec” contracts, where sometimes the photographer was asked to shoot a subject, but had no guarantee of pay, or inclusion in the collection. My dad never signed such a contract, but rather, continued to work with some of the smaller stock agencies that remained independent. But these firms all suffered declining revenues.

The new micro-stock royalty free web sites are again transforming the business.

By the way, this is off-topic, but I find it amusing. Be careful what you photograph:

Thibaud Elziere, the CEO of micropayment site Fotolia, was detained by police for eight hours after he took a photo of a security camera at the French Prime Minister’s residence.

According to a posting on the Fotolia company blog, Elziere was testing a new camera while on a walk in Paris on Sept. 21. Police officers stopped him when they saw him snap a picture of a security camera.

According to the blog, Elziere didn’t realize he was photographing something sensitive. He explained to the police who he was and what he was doing, and deleted the picture from his camera as an act of good faith. Police checked his background before releasing him eight hours later.

This looks very promising:

I recently introduced the sfFormSymfony class in the 1.3 branch, which includes this pearl of a method:

$form->bindRequest($request);

So clean, so simple. Compare that to the code necessary to do the same thing in the 1.2 branch:

$form->bind(
$request->getParameter($form->getName()),
$request->getFiles($form->getName())
);

Ugly, huh? Fabien’s term was “not ugly, explicit” (I couldn’t help but laugh at his turn of phrase).

This would be handy for a project I still need to finish, managing very big imports:

I don’t know if I’m the first or only person to find this functionality useful, but in a recent project of mine one of my tasks was used for importing large amounts of data which took a total of 20 minutes combined. It was extremely nice knowing where in the import it was so I wrote a function which would write out the progress, clear the previous, and re-write.

I’ve had the good fortune to work with some truly great designers. These are people who are understand the client’s needs, who understand the users, and who naturally develop web sites that feel intuitive to the people who use the site. Long ago I learned that, when working with such designers, it was important to empower them with the code they needed, but to otherwise stay out of the way. In particular, such designers need access to the HTML of the site. When I hide the HTML away inside of PHP functions, I’m limiting the ability of these maestros to perform.

This has implications when working with a framework like Symfony.

A lot of computer programmers would add an image to a Symfony template by using one of the image helpers:

<?php echo image_tag(’banner.jpg’) ?>

But what if the designer needs to add a CSS class to this? What if they are working late at night, and they are unable to reach me? Or they are working in the middle of the day, but it is a day I’m spending away from my computer?

The designers I work with can read PHP code fairly well. And they can look up the image_tag helper and figure out its syntax. But this is a big waste of their time. It takes them further into the world of programming than they should need to go.

When creating URLs in a Symfony project, it is important to use helpers. The helpers take care of figuring out what the right URL should be for things like images. The helpers allow us to develop on one machine and deploy to another server when we go live, and even if that other server has a completely different directory structure, we don’t need to change any links, because the helpers take care of all that for us. However, managing the URLs is the only thing that the helpers should do.

So we do not do this:

<?php echo image_tag(’banner.jpg’) ?>

Instead we either do this:

<img src=”<?php echo $sf_request->getRelativeUrlRoot() ?>/images/banner.jpg” />

or we do this:

<?php sfLoader::loadHelpers(array(’Url’)); ?>
<img src=”<?php echo public_path(’banner.jpg’) ?>” />

This way the URL is managed by Symfony’s helpers, but the rest of the IMG tag is still free for the designers to work with. If a designer needs to add a CSS class, they don’t need to call me on the phone and get me to do it, and they don’t have to start researching Symfony helper tags, instead they just add the CSS class like they always have:

<img class=”header” src=”<?php echo public_path(’banner.jpg’) ?>” />

This is an important bit of project management. It allows for a correct separation of concerns – the designers get to focus on design, and the programmers can focus on the programming.

As I recall, when I was getting into programming in the late 90s, and especially when I was getting into PHP, there was a debate about the value of light-weight scripting languages, such as Ruby, Python, Perl and PHP. Some old-school programmers insisted that working with those languages didn’t count as “real” programming – those languages were too easy. And many old-school programmers were critical of the performance hit one takes with the light-weight scripting languages. After all, for some tasks, a routine written in C will run more than 100 times faster than the same routine written in PHP. A two-order-of-magnitude difference in execution speed needs to be taken seriously. Of course, on the flip side, a programmer can rapidly prototype new software with a light-weight scripting language, whereas using C would take much, much longer, and then it would be harder to change once it was done.

Back then, the decision was seen as either/or: either use a light-weight scripting language, or use a lower-level language that is more efficient.

In recent years, the new style has been “both”: mix the high-level and low-level languages. Use light-weight scripting languages to prototype some software, then look at the bottlenecks and drop into a lower level language for those parts of your code that need the speed. For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible:

We rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck.

Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource.

In between C and the light-weight script languages are those languages that added some extras, such as Java, C# and Erlang. Java and C# offer object orientation and automatic garbage collection, whereas Erlang offers automatic concurrency. The crew at 37 Signals has decided to re-write the polling in Campfire, using Erlang:

Last Friday we rolled out the Erlang based poller service into production. There are three virtual instances running a total of three Erlang processes. Since Friday, those 3 processes have returned more than 240 million HTTP responses to Campfire users, averaging 1200-1500 requests per second at peak times. The average response time is hovering at around 2.8ms from the time the request gets to the Erlang process to the time we’ve performed the necessary MySQL queries and returned a response to our proxy servers. We don’t have any numbers to compare this with the C program that it replaced, but It’s safe to say the Erlang poller is pretty fast. It’s also much easier to manage 3 Erlang processes than it was the 240 processes that our C poller required.

The diversity of language choices allows programmers to find exactly the right level of abstraction. When do you need programmer efficiency, and when do you need the code to execute efficiently? One needs a variety of languages so one can always get the right level abstraction for a given project. I think this is part of what Larry Wall was talking about:

Doing it right involves treating the evolution of the language as a pragmatic scope, or as a set of pragmatic scopes. You have to be able to name your dialect, kind of like a URL, so there needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like. This is actually near the heart of the vision for Perl 6. We don’t see Perl 6 as a single language, but as the root for a family of related languages. As a family, there are shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.

As I previously wrote:

Larry Wall is a deep thinker. And he has been developing a deep philosophy of computer languages. Yet the world of Java has, quite surprisingly, opened up and become a world of many languages: Groovy, JavaFX, JRuby, hecl, Jython, etc. No one would have guessed, in 2002, how much Java was going to open up. But while Larry Wall has been thinking about Perl 6, the Java community went ahead and created the reality that he was merely thinking about: “So there needs to be a universal root language… [and] shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.”

I’ve written a little Java in the past, but I’ve always hated how heavy it is. Double casting a variable when you declare it leads to code that strikes me as overly verbose, for my purposes. Most of the time, I work on code that should be built quickly, and execution speed is not a concern. However, I’ve recently started studying Groovy, and I like it quite a lot. It is a light-weight scripting language that runs on the JVM. Using it, one can drop back to standard Java any time one needs a performance boost, or one needs to take advantage of a library that is specific to Java. You could knit together software made of Java pieces, using Groovy as the glue.

This, it seems to me, is the new style. We no longer face an either/or decision about high-level and low-level languages. Rather, the new pattern is, start high, and then drop down to a lower level whenever you need the extra power.

A great tutorial about binary math and PHP’s bitwise operators.

(I’ve previously written a post where I tried to take Martin Fowler’s essay and change some of the examples into PHP.)

Fabien Potencier writes:

During the first five articles of this series on Dependency Injection, we have progressively introduced the main concepts behind this simple and useful design pattern. We have also talked about the implementation of a lightweight PHP container that will be used for Symfony 2.

This looks like a series worth reading, especially as a glimpse of the future of Symfony:

• Part 1: What is Dependency Injection?
• Part 2: Do you need a Dependency Injection Container?
• Part 3: Introduction to the Symfony Service Container
• Part 4: Symfony Service Container: Using a Builder to create Services
• Part 5: Symfony Service Container: Using XML or YAML to describe Services
• Part 6: The Need for Speed

When creating software, you can get the greatest performance speed by getting rid of any framework and writing arbitrary, ad-hoc code that suits the particular problem you face today. But, of course, such code quickly becomes an unmanageable nightmare, which is why so many of us use a framework. But frameworks are slow. Having a formal system of dependency injection adds another layer of abstraction, providing greater flexibility, but even worse performance. Given that traditional trade-off, this sounds absolutely amazing:

How can you have the best of both world? That’s quite simply. The Symfony Dependency Injection component provides yet another built-in dumper: a PHP dumper. This dumper can convert any service container to plain PHP code. That’s right, it is able to generate the code you could have written by hand in the first place.

[Update: I've re-written this post to take into account the information that Javier Eguiluz posted in the comments.]

[Update: Jacob Coby points me to Google Trends, which offers the visuals for the numbers that I quote below.]

TIOBE only tracks computer languages, not frameworks. I’m interested in how Symfony compares with the other PHP MVC frameworks. Borrowing the search idea from TIOBE, I just ran these searches:

symfony

codeigniter

cakephp

drupal

The results (how many hits on Google):

Symfony – 6,270,000 (3,900,000 for ‘php’ and ’symfony’ together)

CodeIgniter – 748,000

Cake – 4,540,000

Drupal – 28,500,000

A comparison: Ruby On Rails: 12,600,000

Meanwhile, WordPress blows away everything else: 295,000,000

My guess is that WordPress has retarded the growth of PHP MVC frameworks. The 80/20 rule applies here with some force. WordPress meets the needs of most people who need a website. PHP allows for self-contained software, such as WordPress, which is something the world of Ruby has not seen. Ruby on the web has largely meant Ruby On Rails, which one has to be a programmer to setup and use. Designers, intelligent people who are not programmers, all such people can default to WordPress.

From the point of view of a computer programmer, the code in WordPress is fairly awful. But designers love WordPress, and it needs to be given credit for successfully creating a package that designers feel comfortable with. No designer would know how to set up a Ruby On Rails site, but most web designers know how to set up a WordPress site. And for all its limitations and flaws, it must be acknowledged as the dominant platform written in PHP. Compared to WordPress, all the MVC PHP frameworks are just a footnote.

I’m going to repeat these searches every 3 months, and see how these ranks change over time.

I seem to recall reading that Propel (an ORM written in PHP) could not handle many-to-many relationships. Perhaps I’m actually thinking of Criteria, which Propel uses for database abstraction?

Anyway, apparently Propel has a way of working with many-to-many relationships:

As mentioned in the chapter introduction, Propel’s support for many-to-many relationships involves a middle step: defining the cross-reference table in your data model, and using results to perform lookups.

Take for example, a need to relate books with the people reading them — many people reading a single book, one person reading many books:

<table name=”book_reader_ref”>
<column name=”book_id” type=”INTEGER” required=”true” primaryKey=”true”/>
<column name=”reader_id” type=”INTEGER” required=”true” primaryKey=”true”/>
<foreign-key foreignTable=”book”>
<reference
local=”book_id”
foreign=”book_id”/>
</foreign-key>
<foreign-key foreignTable=”reader”>
<reference
local=”reader_id”
foreign=”reader_id”/>
</foreign-key>
</table>

In your PHP script you will need to make use of the “middleman” cross-reference table to retrieve the related entities:

$books = BookPeer::doSelect(new Criteria());

// for every book get all readers
foreach($books as $book) {
$readers = $book->getBookReaderRefsJoinReader();
}

The code above will execute two SQL statements:

1. SELECT * FROM book
2. SELECT * FROM book_reader_ref INNER JOIN reader ON reader.reader_id = book_reader_ref.reader_id WHERE book_reader_ref.book_id = $book->getBookId()

While this method is not excessively wasteful — as performing a single select to retrieve many-to-many joined results doesn’t usually make sense — but it is also less elegant than the support for one-to-one joins. Requiring the explicitly reference of the cross-reference table is a drawback to using the very literal data modeling approach adopted by Propel (inherited from Torque).

Penelope Trunk says you won’t make money from blogging. I assume she’s talking about personal blogging, otherwise her advice amounts to “You can’t make money with an online magazine” and clearly that is not true, since there are lots of profitable online magazines (like TechCrunch, Salon, etc).

Apparently, in the world of personal blogging mommy-blogging is a profitable exception:

Welcome to the world of mommy blogging, where women juggle the demands of childcare with building audiences online. It’s also, increasingly, a place where top brands battle for their attention, hoping for reviews from “real moms” and access to the valuable power of word of mouth. Being a player in the mommy blogger world can mean access to free products, getting big media buys and even trips to the red carpet in Hollywood and Caribbean cruises.

Reputable news sources on the tech industry, such as Techcrunch, seem very positive about the future growth of the Twitter eco-system:

Twitter is quickly turning into the media sharing platform of choice for many people, despite the fact that it, uh, doesn’t have any actual media sharing functionality. But a variety of services are popping up to fill the need, including countless Twitter-specific sites for sharing images, music, and video.

Twitter seems to be taking off the way weblogs and RSS feeds took off during the last recession. But weblogs and RSS feeds were open platforms, with dozens of companies competing to offer tools. The openness and the competition helped drive the tools forward, which helped the practice of blogging to move forward. There was never a single company that could say “Weblogging will no longer be allowed unless you start paying a fee for our tools” (SixApart tried this and immediately lost market share).

Twitter is just one company. It is only as open as it wants to be. Right now, it is synonymous with micro-messaging (micro-blogging?). But I am doubtful that a single company can come to represent the whole of some online activity. I suppose the nearest analogy would be Google and search, but that seems like an imperfect fit. The highest estimate of Google’s market share is 72%. Whereas Twitter owns 100% market share of Twittering.

(In this post, I will let hecl stand in for all scripting languages that aim to make programming easy to do on cell phones.)

All through the 1980s and for most of the 1990s, Apple made efforts to make programming easy. In 1987, Apple released Hypercard, probably the single easiest programming environment ever. Apple’s dedication to empowering people – allowing minimally-technical people to program – earned it a great deal of goodwill, so much so that Bill Atkinson (the inventor of HyperCard) basically gave it to Apple as a free gift, in exchange for the promise that it would be included on all Macintosh computers. Sadly, in this decade, Apple has forgotten about Hypercard. My sense is that this represents a larger trend within Apple: a general retreat from the goal of giving minimally-technical people easy programming tools. The death of Hypercard lead to mourning among its many fans (myself included). Danny Goodman summed up the feelings of many:

I shed my buckets of tears for HyperCard (and what might have been) many, many years ago. The first crude demo that Bill showed me was, at its root, what the World Wide Web has become. Coulda, woulda, shoulda.

Despite valiant post-version 1.1 efforts by dedicated and exceptionally bright serfs (their recollection brings fond memories), HyperCard never truly recovered from its detour to the Claris dungeon and the dungeon masters. It’s a tale of perhaps the biggest opportunity Apple missed in its self-defense against a rising Windows tide.

When I look at the current product, I see facets that are still ahead of their time, not the least of which is the extraordinarily elegant HyperTalk language by Dan Winkler — a kid straight out of college, who Bill Atkinson said was the only programmer who could keep up with him. At the same time, aspects of the product have been embarrassingly behind the times for years. Kevin was well on his way to fixing that, but the scenery changed.

Back when Apple was still proud of HyperCard, and boastful of its use by minimally-technical people, this is the kind of article that I read over and over and over again:

I thought it was really cool to see – not because I’m interested in quilting, or the program is anything brilliant (it’s simple and functional), but because enabling stuff like this is part of what I built Hecl for: to make mobile phone applications easier, quicker, and simpler to create. Someone went and typed in the code on Heclbuilder, got the program running, and now a number of people have a handy tool to do some calculations for their hobby, which is a heck of a lot easier than fooling around with SDK’s, Eclipse or Netbeans, and so on and so forth.

But this is no longer Apple talking, rather, it is David Welton, talking about Hecl.

The other tool for programming by minimally-technical people that Apple has promoted has been AppleScript. Influenced by HyperTalk (HyperCard’s programming language), Applescript has a syntax that in many ways mimics English, and therefore it is easy for English speakers to learn.

The digital revolution continues to change our lives. The biggest change over the last few years has been the mass acceptance of cell phones. Most people that I know no longer have landlines, they only have cell phones. This is the next great frontier for computer programming. And yet, Apple hasn’t yet made Applescript available to run on the iPhone. Yet hecl can run on Android.

Personally, I would love to be able to write apps for the iPhone. But I don’t want to have to learn the Object C language. I don’t have the time. I agree with Simon Brocklehurst’s criticism of this decision:

Recently, Apple bowed to the inevitable, and has released an SDK for developer testing. The language they chose to base the SDK around is Objective-C. This wasn’t a complete surprise – after all, it’s the “native” language of Mac OS X. However, while it’s not a surprise, I wonder if it’s not a major strategic error on Apple’s part. The point is this: the Mac is a niche platform, and is especially niche in terms of numbers of developers building applications in Objective-C. Compare that to iPhone, which because of its technological lead, has the chance to become a major volume player in the mobile phone space. If Apple wants iPhone to succeed, it seems strange to attempt to force developers to use an unpopular language for programming it. That isn’t the way to win – developers have many, many choices of platforms they can spend time developing for.

Brocklehurst thinks Apple should pick a popular language for its SDK. I think Apple should pick one that is easy to learn. A light weight scripting language. If Apple came out with an implementation of Applescript that ran on the iPhone, then I would start writing iPhone apps tomorrow.

But for now, it doesn’t seem like Apple is planning on doing that. So when I look around for relatively easy ways to get into cell phone programing, other light-weight scripting languages jump out at me. And they lead me to platforms other than the iPhone.

So maybe hecl is the new Applescript/Hypercard? For people who want to put together a quilting site with a cell phone connection, what is the easiest way for them to do that? Who is, right now, showing commitment to the old ideal of empowering minimally-technical people to write the apps that they want?

David Griner has a list of problems for businesses to avoid when they start using social media (I assume he’s thinking of Twitter, Facebook, MySpace, etc. The only site he mentions, in the past tense, is MySpace). At first, these might sound like clever warnings:

1. Lust: Loving your customers is great, but take it slow.

2. Gluttony: Don’t bite off more than you can chew.

3. Greed: It’s hard to shake hands while you’re reaching for someone’s wallet.

4. Sloth: Always avoid the temptation to “set it and forget it.”

5. Wrath: There are a lot of people out there itching for a punch in the nose, but you’re not the one to give it to them.

6. Envy: Don’t be dissuaded by other people “doing it better than you.”

7. Pride: Stay humble, rock star.

Sadly, the post is devoid of any data suggesting that these bits of advice have the slightest validity. Rather, the advice is hopeful, but fact-free:

In the ribald days of 2006, a business would sign up on MySpace and then start “friending” everyone with a pulse. These days, lusting after fans like that will get you labeled as desperate — or even as a spammer. So keep it in your pants and truly get to know the first people who connect with your brand. In return, they might just love you for life.

I’ve written before of my efforts to help The Second Road with their marketing. We spent a lot of time trying to find a marketing firm that we could hire. We were disappointed by most of the folks we talked to. They were fuzzy. What we wanted was a scientific approach. If, for instance, we spent $100 buying an ad on Facebook, how many people would that bring to our site? What if instead we hired a well known blogger? Everything needs to be tried, using small amounts of money. We wanted research, well-tested solutions, or experiments where success and failure were clearly defined. Instead, we got a lot of mush about things that are difficult to measure, for instance, “We will influence the way opinion shapers think of your site”. Okay, but how to measure that? We could potentially measure how many times the site got mentioned on blogs, but how much of that could be traced back to a particular marketing effort? If there was an uptick in mentions on prominent blogs, was that because of the efforts we’d made over the previous 3 months, or was it because of the new marketing firm we just hired? How to measure?

Susan Payton’s advice was a bit of a shock to me. I was almost offended by her tone of “let’s ignore the facts and do this anyway.” Her argument for social media marketing was wholly faith-based:

I think we need to shift our thinking about marketing results in terms of having absolute control and ability to micromanage the results and just sit back and let it happen. You won’t see results overnight, but if you use social networking sites correctly and participate in the right conversations, you will see a positive change. You will see traffic to your site increase. You will see sales climb. Just relax and let it happen.

Let’s all take a deep breath and let out all those years of being control freaks, of needing to know exactly how everything will pan out. Marketing 2.0 is happening as we speak. There is no precedence set. We are making history with internet marketing and social media. Do you want to go along for the ride or sit this one out and regret it later?

I’m unwilling to have that kind of blind faith in a strategy that has never been tried before and, frankly, I have to question the reasonableness of anyone making such a suggestion. I need some data before walking down that road. Even a few success stories, however much over-hyped, would help to justify this strategy. But where are the great breakthroughs? What company can say “We made friends with our customers on Facebook and results were amazing! Sales doubled!”

I apologize for picking on David Griner. I’m sure he is a nice guy. But his post gives me a good starting point to repeat my concerns about hype regarding “social media marketing.” Griner is apparently in the marketing industry. His blog describes him thus; “David Griner is a social media strategist for Luckie & Company. He’s also a contributor to Adweek’s blog, AdFreak.com.”

What I feel is missing from some of Griner’s advice, and from the advice I’ve been hearing from other enthusiasts of social media marketing, is a sense of ROI, some concept that maybe the dollars might be better spent elsewhere. Consider this concluding bit from Griner:

Successful social media really is easier than you’d think. If you plan ahead, pace yourself and listen more than you talk, you’ll strike a chord with existing customers and potential fans alike.

Right, but is it cost effective? I’ve no doubt that a company can forge close relationships with a few hundred people on Facebook or Twitter, if it makes enough of an effort to do so. But will those few hundred people actually be worth the effort? I’d like to see a lot more information on this, detailed studies, before I’d trust this approach.

I ran into this same problem, for which Symfony fails to offer a sensible error message:

It then occurred to me that the entire validator schema was being processed, not just the fields that are actually posted! This means that all the validators that are required=false will silently return a “clean” value, which is most likely the database default.

So what did this mean? Well, it meant that the validator was “cleaning” all the columns that had not been submitted with the form, including the version column, which was being set to null. When the versionable behaviour kicked in, it read this null value and incremented by 1 for the next version, which then became 1 – a version which of course already existed, causing the error.
The solution

The solution is blindingly simple, we don’t just declare the widget schema, we must also declare the validator schema. Whilst this seems like it makes sense, I feel that it is a shame that I have to essentially copy and paste the necessary validators from the base class.

A while back I asked for advice about using Subversion to track a Symfony project. Scott Meves points to this informative article.

If one’s intelligent and thoughtful analysis of a situation has determined that there is an opportunity worth pursuing, then I think the best strategy is to start the pursuit and figure out things as one goes. Each problem domain has a thousand issues that are specific to it, and one has to become the expert of those thousand issues if one is to do well, but there is no way to become expert until one is focused on that domain and working with it everyday. I’m pleased to see 37 Signals says the same thing:

Why don’t we just call plans what they really are: guesses. Unless you’re a fortune teller, long-term business planning is a fantasy. There are just too many factors that are out of your hands: market conditions, competitors, customers, the economy, etc. Writing a plan makes you feel in control of things you can’t actually control.

In fact, you might as well change the name of your business plans to business guesses, your financial plans to financial guesses, and your strategic planning to strategic guesses. Do that and you’ll probably start putting a lot less weight into those things.

Ian MacMillan, Wharton professor of innovation and entrepreneurship, and Rita Gunther McGrath, a professor at Columbia Business School, believe “the only plan is to learn as you go.” They say 1) conventional approaches and planning don’t work when you’re trying to get into new spaces, 2) assumptions are what get most companies into trouble, and 3) it’s not failure that companies need to avoid, but rather “failing expensively.”

Haven’t tried it. Could be interesting. Glimmer.

Back in 2005 I read The European Revenge. It was published in 1973. It was written by two journalists from the Economist magazine. They made the daring, controversial argument that at some point in the near future, European car makers such as BMW and Mercedes would be able to make cars that had just as much quality as American cars.

Their daring idea is something for my generation to laugh over. I came of age in an era when it was simply assumed that European cars were naturally better than American cars. Over the course of 30 years, the reputations of the various car makers had reversed positions.

Tonight, I find myself thinking daring, controversial thoughts about Ruby On Rails and PHP.

I recall in late 2005 when I first started hearing about Ruby On Rails. It was an amazing system for building big web sites much faster than anything before had allowed. I watched the video that showed how you could build a weblog system in 15 minutes. The company I worked at then hired a consultant who was also a very great programmer, a fellow who, by coincidence, had been writing about Ruby since 1999, well before most American programmers had heard of the language.

At that time, it seemed like Ruby On Rails was going to sweep all before it. PHP seemed like a dinosaur, headed for extinction. Software written in PHP was notoriously sloppy and insecure, and the programmers who worked with PHP tended to be less experienced than the programmers in almost any other programming community.

I started to study Ruby On Rails on the assumption that all PHP work would eventually disappear, and if I wanted to have a job in 2008, I’d better get with the new, new thing.

But, of course, Ruby On Rails failed to sweep all before it. It had a big impact on programming in general and on web development in particular. But of all the programming communities, Java was probably more profoundly effected than PHP. For Java programmers, Ruby On Rails lead to a re-thinking of fundamental assumptions.

When Ruby On Rails first came out, PHP was not competitive. There were no high productivity frameworks for PHP. But that has changed. PHP now has Cake, CodeIgniter, Symfony, and many other frameworks. These are all full-featured MVC frameworks, with command line scaffolding tools that automate the construction of basic CRUD forms and basic layout templates, and which therefore offer some of the same productivity gains that Ruby On Rails offers.

So much contempt has been poured in the direction of PHP that it seems normal to think it must be inferior to every other programming language. But it is worth remembering that some very good programmers have never liked Ruby:

I classify myself as one of those developers who don’t get Ruby, just like I don’t get Perl. Both are too hard for me. And there seems to be something in my brain that prevents me from learning both. It’s strange I never had the problem with C or C++ or Python or Lisp or awk.

…I just don’t like Ruby. This has more to do with how I think and work than with the true quality of the Ruby language. I’m sure Ruby is a fine programming language offering good OO features. But there is something in it that rubs me the wrong way. I tried to learn it when the first edition of the PickAx book came out. But somehow I can’t get past the “we are so OO, we write 3.abs instead of abs(3)” noise. I’m sorry. It’s not for me. There. I said it.

Most programmers first heard of the Ruby language when they heard about Ruby On Rails, so the language and the framework have always come in a bundle. If we unpack that bundle, do we find that some portion of it is stronger than the other portion? Since some good programmers dislike Ruby, yet the whole programming world has fallen in love with high-productivity frameworks like Rails, isn’t it safe to assume that Rails, the framework, is what made Ruby On Rails so awesome? That the awesomeness is clearly not tied to the language is demonstrated by the vast number of frameworks that have now been implemented in other languages. Most of these framework imitate aspects of Rails. If the awesomeness of Ruby On Rails was due to the Ruby language, then surely more programmers would be learning Ruby, rather than trying to imitate Rails in whatever language they know best. Many of these new frameworks have become successful in their own right, and have kept programmers in one language who might have otherwise converted to Ruby. Certainly, back in 2005, it seemed like there was likely to be a mass conversion of Java programmers to Ruby On Rails. That mass conversion was forestalled by the emergence of frameworks like Grails, written in a language derived from Java.

If the language Ruby doesn’t explain the awesomeness of Ruby On Rails, then that awesomeness can be captured by other languages, including PHP. I’ve been working a lot lately with Symfony, and I am impressed with the tools this framework makes available to me. Although all of the PHP frameworks had a late start, relative to Ruby On Rails, the PHP community now has a much greater diversity of frameworks to choose from, and the competition between the various PHP frameworks is likely to cause all of them to improve at a rapid rate, and also to specialize toward particular niches.

Where does that trend get us in another 3 years? Just as Mercedes went from being an inferior car to being a superior one, it seems to me that we could end up in a situation where the PHP frameworks are actually better than Ruby On Rails for any particular purpose that you can imagine.

Does local news have a future in the era of the web? Sarah Lacy has a regular column with BusinessWeek and TechCrunch. On her personal blog, her best friend Olivia sometimes puts together these informal, amusing videos.

Once upon in a time, in a land far, far away a journalist by the name of Walter Cronkite could be found, via a Gallup poll, to be the single most trusted person in America. Yes, a lowly journalist was the person that Americans trusted most. And how did he get to be so trusted? Largely because he did his best to tell people the truth, in so far as he knew it. He had the advantage of living in an era before the anonymous sourcing of stories had become important. When he got important information, he shared it with the public.

To my way of thinking, basing important stories on anonymous sources is one of the banes of the present eras.

I’m surprised to see, over at TechCrunch, that Michael Arrington was sent some important information via emails, and he promptly published all the emails, and his readers, in the comments, are almost wholly opposed to his actions:

OoTheNigerian (@OoTheNigerian) – April 30th, 2009 at 5:20 pm PDT

Bad Journalism Mike! Never reveal your sources. You have just killed this guys credibility. He was trying to give you inside information and you played it wrong!!
Not Nice!!

Bob 3 – April 30th, 2009 at 5:42 pm PDT

Michael Arrington, here goes your credibility….
Doing this will further reduce your website traffic..

Cicero – May 1st, 2009 at 12:28 am PDT

I agree … don’t reveal your sources

Too many ones – May 1st, 2009 at 8:58 am PDT

Right. Owen Van Nutta would never have done this mike, and you say his integrity is questionable.

Rehan yar Khan – May 1st, 2009 at 12:01 pm PDT

V bad Mike, totally killed your credibility!

Seb – April 30th, 2009 at 5:33 pm PDT

I COMPLETELY agree…

Seriously mike…
“Not Nice!!” does not even begin to describe this

…But you probably don’t care what we think anyway

These people live in some kind of alternate universe where building a story around anonymous sources is actually a good thing.