http://tgriff3.com/Ghost 0.11Fri, 18 Aug 2017 04:51:41 GMT60A few months ago, I started thinking deeply about the idea of immutability on the web, and what kinds of consequences it would have.

Immutability in programming languages has very interesting features, most of which I learned while trying to implement an Immutable Dict type in Python (i.e. a

]]>http://tgriff3.com/the-immutable-web/b5b6b218-bb32-444f-8f5d-783879344411Mon, 10 Aug 2015 16:43:06 GMTA few months ago, I started thinking deeply about the idea of immutability on the web, and what kinds of consequences it would have.

Immutability in programming languages has very interesting features, most of which I learned while trying to implement an Immutable Dict type in Python (i.e. a tuple with non-index keys).

In particular, immutability brings with it immense benefits in multi-threaded programming, where one thread may modify the value of an object that an unrelated thread is relying on.

The web is the ultimate example of concurrency, in that you have a distributed system of unrelated actors across time and space working on the same data sets for different purposes. It is perhaps the most important place to see immutability, but instead its contents are extraordinarily unstable.

Tim Berners-Lee wrote (in 1998!) about how Cool URIs Don't Change. We've progressed a bit since then - I haven't seen cgi-bin in awhile - but it's notoriously hard to keep things around online. Archive.org does a tremendous job trying to preserve copies of the web for posterity, but even that is a broken model, since it isn't truly immutable.

Posthaven was founded on the idea of a website that never goes offline (based mostly, I would guess, on the experience of the founders having to shutter Posterous after being acquired).

I finally started thinking about what a place on the web that contained truly immutable content might look like, how it might function, and what sorts of uses it might have.

So, I hacked together immut.io. It saves anything to a unique URL based on its content. It is truly immutable, and uses it's Headers as such - using the longest expire times possible for its content.

Since URLs are based on the contents of the file, in theory, it acts sort of as a reverse search engine: you provide content, and immut.io will tell you where on its server to find it - forever. Whether or not this content has been uploaded before is irrelevant, since it's immutable.

So check it out, and see if you can make something fun with it. I'm excited to see what you build on the immutable web.

]]>]]>http://tgriff3.com/if-youre-tired-of-starting-over-stop-giving/98c4d752-92dd-445d-9467-dd1462cc29acMon, 01 Jun 2015 13:00:45 GMT]]>In Peter Thiel’s recent lecture for CS183B he mentioned that they’ve done some studies on recent graduates from MBA programs, and how as a result of who they are and the environment they’re put in, they “systematically end up doing the wrong thing,]]>http://tgriff3.com/stanford-mba-trends/9faefbd8-8242-496d-9fc1-c84ba11b8890Fri, 10 Oct 2014 07:40:00 GMTIn Peter Thiel’s recent lecture for CS183B he mentioned that they’ve done some studies on recent graduates from MBA programs, and how as a result of who they are and the environment they’re put in, they “systematically end up doing the wrong thing, they try to catch the last wave.” He mentions Junk Bonds in the 80’s, Dot Com in the late 90’s, and mortgages/finance in the mid-2000’s as examples of MBA’s catching the last wave, or picking the wrong thing.

I was pretty interested in the idea of MBA industry choices being some kind of indicator of an industry that has just peaked and is about to decline in some dramatic fashion. So I went to Stanford’s Career Management Center and went through all their available reports from 2004 to 2013 to see what trends I might be able to spot.

Probably the most compelling part of this data set is the non-quantitative portion - for 2013’s report Stanford started breaking out Technology into many more sectors with the footnote: “Technology subcategories indicate industries impacted by technology jobs.”

That feels a bit like empirical validation of Marc Andreesen’s viewpoint that software is eating the world. Small chunks of what 10 years ago would have been part of Finance or Media/Entertainment are now under the tech umbrella. It likely won’t be long before the Technology label isn’t really a helpful differentiator, as every business will have to be built on some sort of technology foundation.

As far as quantitative trends, the starkest one is the most alarming - an unprecendented 32% of Stanford MBA grads are going into tech, compared to 16% 10 years ago and 13% just 2 years ago. It could be that this is part of the larger, longer term trend of tech eating into other industries, or if Peter Thiel is right, that Tech might have a correction headed its way.

]]>

It turns out that if certain objects are made visible and salient, people's behavior can be affected. Objects characteristic of business environments, such as briefcases and boardroom tables, make people more competitive, less cooperative, and less generous.

A compelling argument for the casual office from Nudge by Thaler and Sunstein.

It turns out that if certain objects are made visible and salient, people's behavior can be affected. Objects characteristic of business environments, such as briefcases and boardroom tables, make people more competitive, less cooperative, and less generous.

A compelling argument for the casual office from Nudge by Thaler and Sunstein.

This is a great write-up by DHH of Rails fame about the Basecamp approach to native app development. They’re using a hybrid approach to take advantage of native experience where it matters, and development speed where the

This is a great write-up by DHH of Rails fame about the Basecamp approach to native app development. They’re using a hybrid approach to take advantage of native experience where it matters, and development speed where the native responsiveness isn’t as critical.

It’s a great follow-up to my post on Mobile Web Performance from a few months ago, and hopefully a sign of things to come in terms of web applications making a resurgence in the mobile paradigm.

In an effort to meet some new people in the tech scene in San Francisco, I’ve set up a one page site to encourage people to let me take them out for coffee.

I’m approaching this a little bit as an experiment. How many people (out of those that visit the site) will be willing to meet a random person on the internet (albeit one in the same industry)? What kinds of people will they be? What kinds of things will they want to talk about?

I’m hoping I’ll get to meet some people I’d otherwise never run into, just because they’re curious and willing to put themselves out there. Plus, who can turn down a PSL?

]]>

An ad for a mortgage re-fi I saw on TechCrunch that has me wondering: will she be my mortgage officer? Or is she the LendGo mascot?

There can be good reasons for software fragmentation: the use cases and capabilities of a refrigerator, a TV, and mobile phone are all very different. However, fragmentation within a category, and even across similar categories, is superfluous and was, prior to the introduction of mobile, a solved problem thanks to web apps.

Speed is the other big issue when it comes to the new wave of devices around us. As discussed at length in his excellent article on the topic (which should be required reading for anyone participating in the native vs. mobile web debate), Drew Crawford points out that there are serious performance issues on mobile that you don’t see on the desktop which cripple mobile web’s performance capabilities. As illustrated in Crawford’s chart below, the iPhone 4S has browser performance that edges out IE8 in 2010, and doesn’t come close to the fast browsers available at the time.

According to Crawford, all the assumptions about the platform that have made Javascript (and web apps generally) successful on the desktop (tons of memory, fast CPU, low latency internet connection) aren’t available on mobile, and as a result, the performance trade-off made by Javascript in favor of programmer productivity is not tenable.

I can’t argue with Crawford’s numbers - mobile web is too slow for serious web apps today. Facebook’s HTML5 reversal should be evidence enough of that. However, as Crawford pointed out, the iPhone 4S (released in late 2011) is comparable to a slow browser in 2010, so we should expect phones released this year, like the iPhone 5S/6, to have performance near slow browsers in 2012, which is not bad when it comes to web app development. Even if hardware gains are all that we have to look forward to in mobile, it would be a mistake to bet against Moore’s law when it comes to more powerful computing making its way to phones and other devices.

While mobile devices will always lag behind their desktop peers, they will soon be “good enough” for most applications that matter to most users. Facebook’s experiment with mobile web was a failure, but as with many things in technology, it was a failure because it was before its time - in a few years (or sooner), a mobile web Facebook experience will be near native, and close enough to make the development and deployment benefits outweigh the performance costs.

Performance is an issue that time and Moore’s law will solve, but platform fragmentation is a drag on innovation that the march of technology can’t fix.

]]>Facebook recently released a “Payments Test” that allowed users at certain e-commerce websites to autofill their billing info as it’s stored on Facebook’s website (from previous Facebook purchases). There was some speculation that this was an attempt to compete with the likes of PayPal]]>http://tgriff3.com/facebook-should-buy-stripe/8a2c8f2c-2b55-4b4b-8377-0a83067fb32bMon, 19 Aug 2013 23:34:39 GMTFacebook recently released a “Payments Test” that allowed users at certain e-commerce websites to autofill their billing info as it’s stored on Facebook’s website (from previous Facebook purchases). There was some speculation that this was an attempt to compete with the likes of PayPal as a full-fledged payment processor, but it has since been confirmed that this is more akin to Chrome saving form details, and therefore not a threat to processors.

According to TechCrunch, the strategy behind the autofill feature is to be able to track the ROI of ad placements on Facebook – they are tracking similar metrics with Datalogix in physical stores. The hope of course is that if Facebook can prove the effectiveness of their ads (which has been disputed in the past) they can win more advertising dollars.

Facebook is (was?) in an extraordinarily unique position of being a nearly universal identity provider on the web. In the early days of Facebook Platform it seemed as though “Connect with Facebook” was going to obliterate home-grown authentication systems. While the expectations are much lower now, Facebook Connect is still an incredibly popular choice, especially for the average internet user.

Ads are not the only way to monetize their position as an identity provider. In fact, they may be the least interesting way. Google revolutionized advertising, and has able to make killing on it, but that doesn’t mean that ads are the only way forward.

While there are tons of ways to take advantage of being an identity provider, payments is an absolute slam dunk. Payments online are still roughly the same as they were 10 years ago, and there is still a lot of FUD regarding the process for end users. Having a single provider that people trust, and that has their billing information on file, would be a game changer for online commerce.

In the same way that Apple has created an environment in the App Store and iTunes Store that leads to easy, nearly thoughtless purchases, so could Facebook create a safe, simple environment for every single transaction that happens online.

Were Facebook to tackle such a huge opportunity, they would need to ask themselves whether to build or buy a solution.

While they have an enormous amount of technical talent, the regulatory hurdles involved with payments makes an acquisition much more attractive, and who better than Stripe, a developer-friendly processor that is rapidly gaining marketshare on the simple premise that accepting credit cards should be easy for the people who build websites.

Stripe could continue building an amazing product, evangelizing more and more developers to switch from something like PayPal, with the added benefit that with the flip of a switch, they could enable “Pay with Facebook” - a seamless way for users that already have payment data stored to check out in seconds.

The boost in conversions that developers would see would do the marketing for the “Pay with Facebook” option itself, and if Stripe allowed customers to save billing information with Facebook after every purchase, Pay with Facebook could rapidly become a contender in payment processing, even alongside such behemoths as Braintree, PayPal, and Square [1].

There are good reasons why Facebook shouldn’t pursue payments, of course. It takes away from their core focus, and they would be competing in a space with well-established competitors (and possibly their customers).

The reality is, however, that Facebook’s current business focus is advertising, and taking focus away from that to work on payments seems like a prudent choice. In addition, Facebook Payments would compliment advertising - imagine an ad that allowed users to make a purchase with a single click, and all without leaving Facebook.

There is very well-established competition in this space, but none of the big competitors have addressed the social aspect of commerce, or established themselves as anything close to a universal identity provider, both of which could be critical for the future of e-commerce.

It seems (and this is mostly anecdotal) that Facebook’s social product is losing steam, and they might not have this opportunity for long. Building Facebook Payments would solidify their position as necessary infrastructure for the next wave of innovation, regardless of whether the social product continues to be as successful as it has been.

The looming question in my mind is why this strategy didn’t work for Google. A huge percentage of the internet population has a Google account, and Google has a good reputation with the public and with developers. They created Google Checkout to compete with PayPal, but are retiring it this year to focus on Google Wallet, a mobile payments play. With Stripe’s success, it seems that getting merchants to switch processors isn’t impossible, so perhaps Google’s execution was simply lacking.

I still think $FB is a buy, but only if they take advantage of the opportunity that they have by making a play into an open space, like payments with Stripe. They may not have an unlimited amount of time to convert their popularity into a long-lasting business.

[1] - Google is a player in this space too, but they are now focusing on mobile with Google Wallet. PayPal and Square are also heavily involved in mobile. Facebook going after traditional e-commerce might seem like skating to where the puck is, but I think that having customers accustomed to “paying with Facebook,” having their billing information on file, and having a large installed base on mobile would go a long way towards whatever happens with mobile payments.

This is a great look at startups through the lens of anthropology, and dissecting them as tribes, a human organization as old as humanity itself. All the attributes we think about when imagining a startup make a lot sense in the context of creating tribal rituals.

This is a great look at startups through the lens of anthropology, and dissecting them as tribes, a human organization as old as humanity itself. All the attributes we think about when imagining a startup make a lot sense in the context of creating tribal rituals. It also supports the common startup truism that it is critical for a startup to have a cohesive, nearly homogenous culture, and to have a set of uncompromising values upon which decisions are based (so called Sacred Things).

Adding streams support required that I rewrite most of the module to be more flexible in terms of method signatures allowed (previously, a callback as the final argument was required for the module to function properly).

While doing the rewrite, I also changed the way new methods were added to pass the Grep Test. The actual logic of what’s happening when the methods are called is much clearer now, which should make maintenance and extension much easier, both for myself and other contributors.

The beauty of using JavaScript on the front- and back-end: I can use identical sort functions, assured that I’ll be getting the same result. (If I was really slick, this would be shared code and I could update it in the same place.)

The beauty of using JavaScript on the front- and back-end: I can use identical sort functions, assured that I’ll be getting the same result. (If I was really slick, this would be shared code and I could update it in the same place.)

I came across this short post about increasing signups through the use of a minimal homepage via Andrew Chen.

While a lot of the advice in the post is sound and all of it undoubtedly leads to more signups, I have a problem with Mattan’s first point: “No access without signup.”

He argues:

Most startups make the mistake of giving people who visit their site free access to content, whether it's apartment booking or daily deals. This is often a bad idea. Contrary to popular belief, the more things a visitor can interact with on your site before they're prompted to sign up, the lower your signup rate will be.

He is almost certainly correct that such a design will increase signups, but the question becomes - are signups the most important metric to be tracking? User numbers a frequently a vanity metric, especially for venture-backed or venture-seeking startups, which use them as a proxy for potential monetization (however dubious).

The focus should really be on creating enterprise value. In the case of a startup like Dropbox that has a revealed business plan and is generating revenue, the relevant metric would be whether giving “no access without signup” results in the greatest increase in revenue - that is, users who ultimately sign up for Dropbox’s non-free accounts.

It might be that signups correlates well to revenue and income, but getting too focused on the intermediate goal of increasing signups can cause you to lose sight of long term value.

A good example of this is Quora, which has taken the strategy of “no access without signups” almost to an extreme, only allowing non-registered users to view the first answer to a question on their site. The practice has received a lot of criticism, but I’m sure the Quora team justifies it with increased signup rates. For Quora, however, with their unknown business model, I’m skeptical that “increased signups” is the relevant metric for their long term value [1].

[1] To me it is the difference between StackOverflow and ExpertsExchange - yes, ExpertsExchange probably had a lot more signups by denying access before paying, but ultimately StackOverflow won the war.

This comparison between Hollywood and Silicon Valley is fascinating - two industries that rely almost exclusively on big hits to finance all their other projects.

An interesting thing to note is that in the same way that Hollywood producers try to de-risk their films, leading to the same bland retreads of past successes, so do VC’s try to de-risk their startups, leading to so many startups doing the same tired routines. Hollywood relies on “bankable stars” as a way to boost their chances of success in the same way that VC’s are willing to give ridiculous amounts of funding to entrepreneurs with past successes prior to any traction in their current company (see: Color, Airtime, etc).

The romantic notion is that of the indie film with little to no insider funding that defied all odds and became a huge success - which has its parallels in bootstrapped startups and other companies overlooked by VC’s, who are only too happy to provide funding once it is a known quantity. While those stories are inspiring, it’s due to their improbability - most indie films receive little to no recognition, and while they might be a great form of artistic expression, they aren’t going to be the right type of venture for a Hollywood producer to back.

But that’s ok. For the filmmaker, it’s about a passion for telling a story. Startup founders should feel the same way.