asher

The web industry needs a positive political platform. A platform we can explain to legislators. A platform that delivers clear benefits to the economy.

The content industry has done a good job of packaging their platform. Legislators, who deal only in big-picture abstractions, understand that they're protecting intellectual property, and thus enhancing the US economy.

The opposition to DMCA, ACTA, etc. has been fragmented, reactive, and based on an implicit set of values. These values are not easily explained to our legislators.

Open roads were key to the growth of the physical economy. Open networks will be key to the growth of the info economy.

Can we explain, package, and simplify this concept? Work it into a congressional resolution? A focal point for political fund-raising?

I agree with Alex. We can say that e-commerce is still in the "pre-google" phase, by analogy to search.

E-commerce sites could be much more than electronic mail-order catalogs. Amazon has tapped one dimension with customer reviews, but there's enormous room for improvement.

As Alex points out, the burden is still on the consumer to perform labor-intensive research. We need to change this.

I think this is the tip of a large iceberg, and we may see more of the iceberg in upcoming years. A large number of web users have discarded traditional ideas of privacy to post information about themselves.

Suppose Facebook applies some Machine Learning algorithm and can predict roughly which users will incur insurance claims. Inputs could include user-generated text, size and shape of social graph, entities recognized in user-generated photos, etc. That data would be valuable to insurers.

It seems like many of these users are mentally in a living room with their friends, while actually uploading their private info to a corporation's servers.

I just tried it.

With 10M entries in the array, the "slow" way takes 509 ms and the "faster" way takes 362 ms. So we can save roughly 15 nanoseconds per iteration. Or a 30% speedup - assuming nothing happens inside the loop.

(Of course the numbers may vary wildly per browser.)

Somehow I doubt this is the performance problem behind slow web pages.

That was my first thought. I ran the "slow loop" through the online compiler at:

http://closure-compiler.appspot.com/home

And whether I checked "Simple" or "Advanced" I got:

for(var a = 0;a < arr.length;a++)

So it's not optimizing that pattern yet.

Can you suggest any way of gaining a broader perspective? Both companies mentioned in the article are B2C and highly visible. They may have "visual punch" outweighing their "economic punch".

How can we get a broader, more realistic picture of what's really happening in the economy?

"Simple" as a discussion-starter? Great. "Simple" as a universal prescription? Maybe not.

Chipotle thrives on its simple offering; Cheesecake Factory thrives on its deep menu.

Larry Ellison fought against the "best of breed" concept to promote a unified Oracle Applications. A Cheesecake Factory style package.

The argument for "complex" is that once you've earned the trust of a customer, you can provide the spectrum of products/services that customer needs. You can be counted on to pick up all dropped balls.

(But maybe there is a completely pointless complexity - proliferation of marginal features - which we can simply avoid.)

The only reliable guide is complete focus on the customer's needs.

I think this is PR.

http://www.paulgraham.com/submarine.html

And I have great respect for the person who secured $2m in funding for an url-shortening site.

Thoughts so far:

The templating system is interesting. It does something I have not seen before: You can define one template, then execute it server-side (in Java only) and/or client-side (compiled into Javascript).

To achieve this, the template language is quite restricted. It seems that we could write interpreters for this language in Ruby, Python, etc.

Also, we could write a compiler back-end which generates C to run inside nginx or Apache; this could yield a high-performance templating system.

Here's an example template I made. Note that the "javadoc" portion is mandatory and is parsed by the compiler.

    /**
     * show a table
     *
     * @param data      array of values
     * @param ncols     num columns
     */
    {template .vvtable}
        <table cellspacing=10><tr>
        {foreach $d in $data}
            <td><div style="background-color:#f00;padding:5px">{$d}</div></td>
            {if not isFirst($d) and index($d) % $ncols == 0}
                </tr><tr>
            {/if}
        {/foreach}
        </tr></table>
    {/template}

This is wonderful news; I'm really grateful to Google for opening this.

We already knew that Google's major javascript apps were not using GWT. I always had reservations about GWT because I think javascript is a very nice language. (Just the language - not necessarily the DOM or implementations).

While java seems like a step backwards.

The main thing missing from javascript is some stricter checking, and it looks like Closure Tools provides this.

Excellent article. For some time I have felt the need for this, but not acted on it.

Can anyone compare the merits of the proposed tools? Also, how does Zotero compare?

Sounds like you're ready for a good sales book or two. I think one of the best is "SPIN Selling". It's not what it sounds like. It's almost the only sales book based on real research.

http://www.amazon.com/SPIN-Selling-Neil-Rackham/dp/007051113...

I see advice in this thread to make a great product or know the product really well. I'd say the focus needs to be on the customer, not on you or the product.

Better to know the customer really well than to know the product really well. Of course if you can do both, do both.

Read a few good books on sales and you'll start noticing how inept almost all salesmen are. They just want to talk about their product, and don't ask the "obvious" questions about the customer and his needs.

This is the developer blog for Twiki, one of the most powerful wikis.

http://twiki.org/cgi-bin/view/Blog/WebHome?category=Developm...

Here are some things to consider up front:

* Pluggable authentication and authorization. In the beginning both are simple, but if you weave that simple assumption into the code, it will be hard to add finer grained control.

* Keep read latency low. This might mean some form of caching. Twiki is slow in my experience.

* Expose all features to a web service interface from day one. Don't weld functionality to the GUI. Side benefit: makes testing your software easier. See:

http://twiki.org/cgi-bin/view/Blog/2007-11-14-how-to-rest

I think you'll find much of what you want by poking around the Twiki site.