Show HN: Autocode – Automatically generate API code for SaaS apps - <AUTHOR> https://autocode.com/ <comment><AUTHOR> Hey all,

Keith here, founder and CEO of Standard Library (we made this <3). The problem we're focused on solving is simply -- building modern integration software is too difficult. (1) For professional engineers, it's mundane work nobody wants to do and (2) for non-developers, best-in-class integration tools that rely on visual workflows just don't cut sophisticated use cases for modern businesses, they often need some code.

Autocode solves these problems by providing an IDE that professional engineers can use to ship simple integrations in minutes and new (or "low code") devs can use to automatically generate API integration code without needing to know much to start with. We provide a ton of features: an API registry, API autocomplete, code generation, serverless hosting for your APIs, an in-browser execution engine for your workflows, observability + logging, complete revision history. It's kinda like Heroku and Zapier had a really, really ambitious child.

We've been at this, somewhat quietly, for four years and Autocode is what we're the most proud of to date. We've been very fortunate to have the opportunity to work with some of the best companies in the industry to support our vision -- Slack and Stripe have been investors since (nearly) day one. That said, we're a small team -- just five people -- and we still have a hell of a lot of work ahead of us. We would love thoughts and feedback!

YouTube video here for anybody that wants to see the full demo:

[https://www.youtube.com/watch?v=ha3C0X3Vyi0](https://www.youtube.com/watch?v=ha3C0X3Vyi0)

Thanks so much! :)

<comment><USER2> Very cool stuff, so I want to give some feedback hoping it will succeed :)

1 - Some playground prior to signup, similar to Runkit could get you more users.

2 - Some simpler signup by Github etc. would get you more users.

3 - Right click is taken over by the site, which blocks LastPass context menu which adds another layer of difficulty to signup.

Good luck, thanks

<comment><AUTHOR> Thank you!

Ooh! Right click / context menu. I gotta fix that. D'oh.

I think there are different schools of thought re: providing a playground. We certainly have done that before with smaller launches. Our experience (anecdotally, I haven't measured exactly) is that while "playground" type experiences can sometimes increase signup volume, they tend to result in _lower_ engagement rates overall.

I believe the basic underlying hypothesis is that if you can solve a problem somebody is having and they know that, they don't care how it works: they'll sign up and figure it out. However, if you provide a playground, you artificially select for a much higher proportion of folks who enjoy the novelty of new technology / products and aren't necessarily likely to stick around.

Food for thought, anyway. Don't have raw numbers here.

<comment><USER3> Yes and no.

This particular product probably has broader appeal than you think—

For a broader audience you'd definitely want to dumb down the entry point. If you're still in the smaller audience/specific traction stage, it probably makes sense to stay more technical.

</comment></comment></comment></comment><comment><USER4> This is pretty interesting! I've been working on a web scraping API that returns Open Graph information for a URL, and decided to see how easily I could build and deploy this using Autocode.

In about 15 minutes I ported the code I had written to Autocode. A few things that felt pretty magical:

        - auto recognized and imported required NPM modules to my project
        - ability to run code in-line (via Runkit)
        - auto-generated documentation

You can see the docs for this API here:

[https://stdlib.com/@carter/lib/open-graph- api/](https://stdlib.com/@carter/lib/open-graph-api/)

...and can see an example API GET request which returns the Open Graph information for one of the top stories on HN today:

[https://carter.api.stdlib.com/open-graph- api@dev/api/?url=ht...](https://carter.api.stdlib.com/open-graph- api@dev/api/?url=https%3A%2F%2Fgithub.blog%2F2020-02-12-supercharge-your- command-line-experience-github-cli-is-now-in-beta%2F)

I'm pretty curious to see where this product goes! It would be super cool to be able to easily tack on auth and a pricing model for heavier (enterprise) users of this API.

<comment><AUTHOR> Thanks for the feedback!

We do indeed have custom auth and pricing in the works :). Can't give an outline on delivery because we have so much other stuff to take care of, but the API registry is already built to handle these use cases.

</comment></comment><comment><USER5> Preliminary feedback: it took me 5s and single downscroll to grasp what this does and why it may be useful.

In current climate this by itself is a remarkable achievement so wanted to point it out.

<comment><AUTHOR> Thank you so much!

I will say it hasn't been a small effort. We've been working on the suite of products that have led up to Autocode for years. At this point I've personally done hundreds of 1 - 2h sessions with customers to figure out what works and what doesn't, and I think that has sort of enabled us to focus on the features that matter and why they're important.

As you play around, I'd be interested to learn what you like and what you think is missing!

</comment></comment><comment><USER6> I've developed a personal sniff-test for software development work that exists right now but isn't actually very intrinsically hard. Those areas are ripe for products like this that simplify or partially automate the process. It was only a matter of time before "glue code" got streamlined.

</comment><comment><USER7> It is not difficult to see there is considerable effort spent building this.

However, why would anybody use it ? I see following issues

\- Editors are getting mighty powerful. So why would a developer trade their favourite tool to your editor in browser ? I wouldn't switch to another editor even somebody is going to pay me more.

\- The process-and-cost of deploying backend has gotten way easier-and-so- cheaper - why would anybody write trivial code in autocode and then deploy on your servers ?

Having said the above - I liked autocomplete provided for different apis in your editor. Sorry, if that was harsh.

<comment><AUTHOR> No problem! It's not harsh at all. I think what a lot of savvy professional developers don't necessarily grok is that they're just the tip of the iceberg, or the top of the pyramid, in terms of the types of people writing and delivering solutions with software inside of organizations.

Let's say BIGCO pays you $X00k to build big, awesome production systems. There are 10x as many _professional developers_ as you building small, hacky transient code within enterprise cos and SMBs and 100x as many _tinkerers, creatives, admins, product managers and more_ just slapping together Airtable and Zapier as fast as possible to automate their jobs.

Autocode isn't designed for the top of the pyramid. I mean, all the features can (and should!) certainly be used by folks at the top. You'll find that for a huge # of simple tasks -- tasks that don't matter where they live, like one- off daily crons -- Autocode is just plain faster. But the important thing to think about is the folks a bit downstream of the "top", the ones implementing solutions less focused on architecture and more focused on solving immediate business problems... that's where Autocode is designed to play well.

Hope that helps!

<comment><USER7> >> You'll find that for a huge # of simple tasks -- tasks that don't matter where they live, like one-off daily crons -- Autocode is just plain faster

This is what you are building. Perhaps title of post is totally misleading/off-putting - 'Automatically generate API code for SaaS apps' ?

Title could have been easily 'A serverless platform with zapier abilities' ? :) - could you argue why autocode is not ? :)

Getting your message to early adopters is so important.

I hope it helps!

</comment></comment></comment><comment><USER8> As a power user of no code apps like zapier. This is really amazing, for some of the more complex work flows I've had to write python code and initiate via lambda functions. This seems like it would alleviate that need completely. Would love to see the ide support python as well as js

</comment><comment><USER9> Dev1: "Is that in stdlib?"

Dev2: "Yeah"

Dev1: "Then why isn't it working?"

Dev2: "Because unlike EVERY OTHER THING called stdlib you need to install this one because it's not actually a stdlib"

Dev1: "..."

<comment><AUTHOR> So, fun fact: our organization name is actually Polybit Inc. -- we do business as "Standard Library" because the registry we've built is pretty much core to everything we do.

I expect the easy way to get around this is for folks to refer to us, when speaking technically, as "stdlib.com" ("standard lib dot com").

<comment><USER9> How would this work in languages where stdlib is an established way of talking about the actual built in standard library like [https://devguide.python.org/stdlibchanges/](https://devguide.python.org/stdlibchanges/) vs [https://github.com/stdlib/lib-python](https://github.com/stdlib/lib- python) ?

Also you aren't worried at all about confusion or typosquatting (or what you would call it with a common name) with all the variations of standardlibrary, standardlib, stdlib?

The npm package name standardlibrary was open, let me know if you want it transferred. No charge or bullshit, of course. I just claimed it because it was free and I guessed that somebody would typosquat it sooner or later considering your company name. If not I'll just release it

<comment><AUTHOR> We're not particularly concerned about typosquatting for now. The name is based on the `.com`, i.e. all APIs / workflows built on Standard Library go to `username.api.stdlib.com`. The packages we use in NPM, RubyGems and Python are just called `lib`.

The way 99.99% of developers have used us to date is starting with our in- browser or CLI tooling which installs / requires the correct package automatically. So I think that removes some of the risk you're talking about. :)

You can hold on to the NPM package for now if you'd like! That's a good one. If we do find typosquatting becomes an issue, do you mind if I reach out?

</comment></comment></comment></comment><comment><USER10> Very cool.

I just signed up, but was a bit frustrated by the hijacked experience for sign-up as it broke my LastPass plugin to generate and save my password. Just wanted to point this out.

<comment><AUTHOR> That's great feedback, thank you! We'll definitely see if we can test across a few different password managers / signup experiences to make sure it's a smoother process.

<comment><USER11> Same here. Was expecting Safari to suggest a password, yet it did not. By inspecting the cause I was appalled to see custom inputs! Mother of dragons!

<comment><USER12> Honest question: what would compel someone into making a decision like this?

<comment><AUTHOR> You mean why would somebody build custom inputs? We need our inputs on Autocode to do a whole ton of custom stuff; support emoji insertion, allow for an autocomplete dropdown, support typeahead autocomplete, have multiple layers for syntax highlighting (code editor).

So we roll our own components for a lot of this stuff. We don't have problems with every password manager; the raw HTML input element is still there. I think it's probably an easy fix, we just gotta look into it.

<comment><USER13> None of those use cases apply for authentication though right? Or are people using emojis for logins now? Even if they were, standard browser form input I'm sure would handle them fine natively.

<comment><AUTHOR> (1) Design systems and components. We'd rather use the same thing everywhere, if possible. (Unless of course, it disrupts user login and end-user experience... which is why we'll look into making it better!)

(2) I actually think this can be fixed with a few HTML attribute changes but I won't know for sure until I dig in. If you can imagine, we have a laundry list of items piling up to take care of :)

<comment><USER14> For (2), you may find the section 'Other useful autocomplete values' from this article helpful:

[https://www.twilio.com/blog/html-attributes-two-factor- authe...](https://www.twilio.com/blog/html-attributes-two-factor- authentication-autocomplete)

Discussed on HN: [https://news.ycombinator.com/item?id=22022106](https://news.ycombinator.com/item?id=22022106)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Excellent. I can FINALLY start migrating away from Zapier.

<comment><AUTHOR> We'd love to help! Feel free to e-mail us (email@example.com) if you have any questions. We also have a Slack community that you can reach by clicking the Community -> Slack tab at the top of autocode.com. :)

<comment><USER16> Is workflow import on the roadmap if you're authenticated to your low/no code provider? With many, you can get the workflow out as a JSON blob their own frontend consumes.

Love the product! Very cool!

<comment><AUTHOR> That's a _very_ good idea. We'll definitely be looking into it.

</comment></comment></comment></comment><comment><USER17> Can I run this code outside of stdlib somehow or does it only work there?

Just have to plan around if stdlib went down or something.

<comment><AUTHOR> It's just JavaScript. It's absolutely portable. The APIs that run atop us use the Standard Library registry, you can think of it like a package manager / proxy of sorts. But if all you're doing is writing logic to connect things, you could conceivably host it on your own after you prototype with us -- you'll just lose some of the goodies we provide like automatic webhook signing.

Also, our gateway / schema specification is open source and portable as well:

[https://github.com/FunctionScript/FunctionScript](https://github.com/FunctionScript/FunctionScript)

<comment><USER18> Why should somebody use this instead of OpenAPI?

<comment><AUTHOR> They're compatible. FunctionScript is just a system for easily adding schemas to JavaScript functions inline. We needed to write a specification that made it easy for people to build Serverless HTTP endpoints strictly from within JS.

<comment><USER18> That's not an answer, though. Why should somebody use _any_ of this over an OpenAPI specification? I'm biased, as I've written two web frameworks that both generate OpenAPI documentation trivially and inline (for Ruby[0] and for NodeJS[1]), but I've looked pretty deeply into the project you're offering here and I'm not seeing the value over existing, open, collaborative solutions.

I have a strong interest in APIs being very good and very accessible (as those links hopefully demonstrate), but I also have a very strong interest in APIs not being _intermediated_ unnecessarily. What does any of this do that can't be effectively done with current, broadly accepted technologies?

Put another way, and forgive the bluntness: why should people give your company a vig for this?

[0] - [https://github.com/modern-project/modern- ruby](https://github.com/modern-project/modern-ruby)

[1] - [https://github.com/eropple/nestjs- openapi3](https://github.com/eropple/nestjs-openapi3)

<comment><AUTHOR> Congrats on all your hard work! Those are some impressive libraries. I come from an OSS background, it's what started all of this, so I appreciate the hustle and contributions! The project that spawned all of this was a Node.js framework for easily building APIs that went viral here four years ago [0].

If it helps clarify, Autocode is for people looking to solve integration problems (A to B) for businesses easily. We can talk all day about which specification we use, but that argument is adjacent to the fact that the combination of tools we offer are faster by one — if not two — orders of magnitude at just delivering business value — a finished software product that connects A to B (to C to D).

We've spent years of work developing this tooling and thousands of hours talking directly to both API companies and end-users about what they need. This is the result, and we've worked at making sure the tools we use — even if bespoke — are open source for others to learn from [1].

P.S. If this is your jam, reach out! We are hiring :)

[0] [https://github.com/keithwhor/nodal](https://github.com/keithwhor/nodal)

[1.0] [https://github.com/FunctionScript](https://github.com/FunctionScript)

[1.1] [https://github.com/stdlib](https://github.com/stdlib)

<comment><USER18> Thanks for the kind words. I don't drop those links to brag or troll for compliments, to be clear--more to establish bona fides. I've spent a lot of time building stuff for an open and interconnected web. I think you should be, too. But it looks like you aren't, and that sure seems like a real bummer.

I get that it's both unsexy and probably a little uncomfortable, but the thing is, the demand for control that you're expressing here by going against open and collaborative standards really and truly does matter. Like--fundamentally and inescapably, the messaging I'm getting from you is "it's 'open source' but we demand to own it." Why do you need to own the specification to do what you do? What is OpenAPI stopping you from doing? Did you try to work with the OAS folks to improve it to enable whatever (if anything) can't be expressed? Did you evaluate stuff like vendor extensions to it to express those things?

I get that the core of your Standard Library is open-source--but "open source" and "community collaboration" are pretty far apart. I understand the process for OpenAPI's evolution and change over time. What's yours? Whose commits get in? Who decides?

I realize that the likely answers to these questions are trivial in the power- politics/realpolitik sense. Which is why my hackles are up, TBH. Not playing in the sandbox with all the other kids is a clear indication that you have it in you, whether you are or not _right this second_ , to raise barriers to entry against anyone else who'd consider doing something with your tech. And that leads to a fragmentation ("welp, we'll have to fork") that this space well and truly doesn't need. If this was using standard tools and standard approaches--which _all totally work with this_ , by the way, I've written a simpler but spiritually similar thing just by using openapi-js to dynamically generate clients--I'd be cheering you on. As-is? This sure looks like pissing in a community pool for your own benefit.

How am I wrong? (Because, to be clear: I'd love to be. Stuff like this is important.)

<comment><AUTHOR> This may be a little different than you expect: OAS didn't meet our needs for defining serverless function schema semantics.

We considered an open approach, but we then watched numerous small companies die trying to convince standards bodies to adopt their innovations. Like, raised money, convinced nobody, stagnated or died, and highly paid engineers at BigCos that were unintentionally unempathetic to the excitable new founders — whose dreams just evaporated in smoke — kept attending open spec design-by- committee meetings with little forward progress.

So we decided to work directly with API companies — not standards bodies — and figure out how to deliver the right product(s) to solve real customer needs.

That's all there is to it. We stand on the shoulders of giants and we certainly love working with companies that adhere to existing standards — as mentioned, the things we've contributed are completely compatible! We don't have an ego about our specifications, we just have a desire to deliver value and not die — and waste the most productive years of our lives — waiting on standards bodies.

<comment><USER18> Can you elaborate on how OpenAPI didn't meet your needs for serverless function schema semantics? Because if OAS3 doesn't meet your needs, it clearly needs revision. I'm very happy with my current gig, but I'd certainly be interested in contributing to the OpenAPI specification to be enable it to be flexible enough to express what you need it to express. The community of open and collaborative APIs doesn't need to be fragmented to do encompass whatever's concerning you, does it?

I'm happy to make that offer because, frankly, I have also spent a pretty long time observing the OAS3 work, and it is not a committee where things get "bogged down" for years. The characterization strikes me as pretty unfair--the prevailing attitude certainly seems to be open, inclusive, and driven towards solutions. Everyone wins when the OAS stuff gets better, so the drive is to just _do that_. It's not an XML standards body or something.

Beyond that, OpenAPI certainly doesn't require a company to adopt a single thing about it in order for somebody to write a spec and to generate a client from that spec. It helps, but there's no need to _advocate_ anything. It sounds like a misdiagnosis to claim it as the reason a company would fail as an integration partner given the significant help that being able to work directly with that company actually is.

Tearing down OAS for what have to be pretty minor flaws (and I use "minor" judiciously; if they're impactful upon "serverless function schema semantics", it's a niche of a niche--and AWS's API Gateway sure doesn't seem to have a problem building OpenAPI specifications off of serverless functions, either via import or export) and a downright fictional characterization of the process of its evolution is really unfortunate.

<comment><AUTHOR> There are thousands of companies with production APIs that don't adhere to any specification, let alone OAS.

On top of that, Companies that were considering OAS now have GraphQL APIs instead — or even JSONAPI. When we need to respond to the needs of one of these companies, we need to move quickly.

I think we're just comparing apples and oranges. We're working on solving API integration issues in a real way, which means we build the tool for the job. OAS is an idealized, democratic position that — while absolutely a best -in- market solution — does not directly and meaningfully incentivize companies to rely upon it.

<comment><USER18> As 'codegladiator indicated, OpenAPI is descriptive, not prescriptive. If you have an API that cannot be described in OpenAPI, that is a bug in OpenAPI. And personally, I've _literally never_ seen an HTTP-based, non-GraphQL API that cannot be expressed, and fairly easily, in OpenAPI and even in a subset that can generate programmatically "acceptable" to "great" API clients in a variety of languages. Heck, it's not even that hard to make a RPC-based API with XML as its lingua franca work just fine in OpenAPI.

Now, you're correct about GraphQL, but it's also apparently not super relevant, as the APIs you're trumpeting on your site are overwhelmingly either RESTful or adjacent to RESTful. But even so? You could pretty easily have vendor extensions (`x-` properties) for GraphQL--ones that in the future maybe even become canonical ones!--in OpenAPI while using it for standard APIs, an approach whose deficiencies you've consistently chosen to retreat from after you state them.

This fundamental misapprehension about specification versus description, and the way you dropped your "serverless function schema" claims like a hot rock (and I want to underline that the offer to work to improve OAS wherever it happens to lack is genuine and is work I am very happy to do) and the absolute unwillingness to address any question that touches on your obvious attempts at barriers to entry, frankly, makes you think you're just bullshitting me.

I'd like to wish you well, but you have demonstrated to my satisfaction your intent to piss in the public pool for your own benefit. I wish you wouldn't be so bound and determined to do so.

<comment><AUTHOR> Alright.

To be direct, I don't really understand your criticism — we're a small team working like crazy to create value for folks. I get that you don't like the way we've implemented our own specifications, and that's okay, but to be honest I'm a little offput that you're accusing me of bullshitting when I believe I've been straightforward with you.

If you'd like to use the product / platform and work with us to make things better, we'd love the support!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> This is really cool! As a PM I'm somewhere in your "100x other people trying to automate stuff" category of user. My question is, would many of your features work if provided as a plugin for an existing favorite IDE? Having to use the proprietary IDE would probably be my sticking point, as it's not easy for me to understand how or if I could start using this with an existing project in VSCode, say.

<comment><AUTHOR> Our team is literally itching to build plugins. E-mail us and let us know what you want!

<comment><USER20> Would the Language Server Protocol make sense for your approach here?

[https://microsoft.github.io/language-server- protocol/overvie...](https://microsoft.github.io/language-server- protocol/overviews/lsp/overview/)

Really interesting concept for exploring a new API, but I don't see myself dropping my IDE of choice for it.

</comment></comment></comment><comment><USER21> Very cool product, and could be useful for learning also.

I suspect the fundamental [business] limitation of a tool like this is that those willing to pay recurring big bucks (medium to large software shops) tend to rely minimally on 3rd party APIs.

Those who benefit the most (weekend projects, learning, rapid prototyping) where time is of the utmost value generally wouldn't end up using it enough to become recurring customers.

<comment><AUTHOR> I think you're vastly underestimating the B2B API tooling space. Large enterprises and SMBs run tons of things atop SaaS APIs, often held together with staples and duct tape.

We have businesses that run on top of us today that are only just beginning to automate huge chunks of their operations with us, Airtable, Slack and other tools. Previously these things were hacked together in an unmaintainable fashion. It's a big space.

</comment></comment><comment><USER22> Interesting project, I went and looked at the [1] npm module "lib" (side note: well done, you guys must have bought it as it was first published 9 years ago)

I saw in the API that you reference in the following manner, which stunned me!

        const lib = require('lib');
        lib.yourUsername.hostStatus(...)

How could you have a dynamic property on a synchronous object like that?! Well it turns out in the [2] source code, you can have some kind of "anonymous getter"?

        get: (target, name) => {
          return LibGen(...);
        }

I've never seen this before and can't find any documentation about it...

[1] [https://www.npmjs.com/package/lib](https://www.npmjs.com/package/lib)

[2] [https://github.com/stdlib/lib- node/blob/bd7cada7ae366c10e316...](https://github.com/stdlib/lib- node/blob/bd7cada7ae366c10e316795300078182700bd87b/lib.js#L31)

<comment><AUTHOR> It's referred to as a Proxy (type of Object) and they're relatively straightforward and a newer addition to JavaScript. :)

</comment></comment><comment><USER23> Keith, do you plan to support other languages beyond javascript?

This brings me back to 2004 when I used to work for Safeco. Business analysts / insurance agents would write business rules in VB.NET. Engineers would write application / integration code which would execute the business rules (both languages compiled to the .NET runtime so were compatible)

<comment><AUTHOR> Candidly: not immediately. There's a lot of stuff we do that's a Hard Problem (TM) to get working across a bunch of different languages, mostly associated with static analysis of code / Abstract Syntax Tree parsing. We've foregone multiple language support for now to focus on enabling people to be deeply productive with JavaScript by being highly opinionated.

</comment></comment><comment><USER24> Nice concept. Please think about adding a showcase to your homepage, i.e made with autocode. This will not only help it make it easier to understand but also show users the possibilities of what can be done with your platform.

<comment><AUTHOR> It's next on our list! We support deploying from GitHub already, we just had to chop a few desired homepage features to make sure we shipped this on time. :)

Coming soon!

</comment></comment><comment><USER25> Hey - great work! This project can save me a lot of work writing integrations, which I find tedious at times, so I'll take a look at it.

One piece of feedback: it's confusing that the org's name is Polybit, the site is [https://stdlib.com/](https://stdlib.com/), and there's also something called Autocode.

Please consider choosing one name for all of them (Standard Library, preferably).

<comment><AUTHOR> Polybit Inc. is an implementation detail.

Standard Library is the platform / registry and Autocode is the IDE. We'll keep these two. Outside of legal docs and filings you probably won't see Polybit that much at all :).

</comment></comment><comment><USER26> So the idea is like, everyone who wants their app to integrate with Stripe has to write their own code that goes "response = /connect/to/stripe/${accountNum} + (json payload)", and this does that for you?

</comment><comment><USER27> Looks like a hug of death "service is unavailable" with an on-screen JS stack trace.

<comment><AUTHOR> Try again? Everything is looking good for us right now. We run on entirely serverless architecture so any failures should be completely transient. I'll get my co-founder to pay attention and see if he notices anything out of the ordinary.

</comment></comment><comment><USER6> Wow, impressive that they got their hands on stdlib.com

</comment><comment><USER28> Isn't this what GraphQL was designed to solve?

</comment><comment><USER29> Where are the list of existing integrations?

<comment><AUTHOR> You can view connector APIs at [https://stdlib.com/search/](https://stdlib.com/search/) \-- if there's something we don't offer, you can build your own Connector APIs as well. Expect this list to grow substantially: part of our model is that we work with large API companies to ensure they're supported on the Standard Library registry.

</comment></comment><comment><USER30> horizontal scrollbar showing on chrome

<comment><AUTHOR> Do you mind sharing a screenshot and your Chrome version?

<comment><USER31> Not the same guy but

[https://i.imgur.com/BspPL2H.png](https://i.imgur.com/BspPL2H.png) [https://whatsmybrowser.org/b/JZAUZ62](https://whatsmybrowser.org/b/JZAUZ62)

Appears to be caused by using 100vw, which doesn't factor in the width of the scrollbar.

Notably on the selectors:

      [control="LandingPage"] .hero-header

and

      [control="LandingPage"] .platform-information .info-section

<comment><AUTHOR> Aha. So likely a Windows issue / those with visible scrollbars enabled? We'll add this to the bugs list. Thanks for the info!

<comment><USER32> Linux + Firefox too :)

</comment></comment></comment></comment></comment><comment><USER33> wsdl, right?</comment>


Alaska fixes earthquake destroyed roads in days - <AUTHOR> http://www.thedrive.com/news/25367/alaska-fixes-earthquake-destroyed-roads-in-days-makes-your-state-dot-look-really-bad <comment><USER2> WaPo has a bit more information. It's a temporary repair that will need more work in the spring.

[https://www.washingtonpost.com/transportation/2018/12/07/an-...](https://www.washingtonpost.com/transportation/2018/12/07/an- earthquake-created-highway-hellscape-alaska-days-later-road-reopened-good- new/)</comment>


Paredit Presentation - <AUTHOR> http://www.slideshare.net/mudphone/paredit-preso

<comment><AUTHOR> ParEdit (paredit.el) is a minor mode for performing structured editing of S-expression data.

<http://www.emacswiki.org/emacs/ParEdit></comment>


Making Crash Bandicoot - <AUTHOR> http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/

<comment><USER2> Part 4 is probably the most fascinating piece, as it discusses how their technical choices were different from their competitors and how the leveraged those differences.

</comment><comment><USER3> Incredible! Just Incredible.</comment>


MPEG LA Seeks More Rent, Announces Call for Patents Essential to DASH - <AUTHOR> http://www.streamingmedia.com/Articles/News/Online-Video-News/An-Unhappy-Surprise-MPEG-LA-Is-Forming-a-Patent-Pool-for-DASH-105419.aspx

<comment><USER2> Can we please stop using MPEG-LA technologies on the web?! This nonsense will never end otherwise. At best you buy a few years with some new technology while they pretend to not charge you so everyone adopts the technology. And then they come knocking.

The only way to end this cycle is to stop using their technologies. Full stop.</comment>


SquirrelShell - a cross-platform alternative to (e.g.) bash and cmd.exe - <AUTHOR> http://squirrelsh.sourceforge.net/

<comment><USER2> Until system scripts start being written in alternative shells (which will never happen), I wouldn't bother learning any other shell than /bin/sh (and, by extension, bash). For more complex applications, stick to Python.

Also, I never really understand why everyone wants to tout the "cross- platform" nature of their applications. You always run up against OS differences fairly quickly, negating any supposed "cross-platform" benefits. Especially if you want hooks into the OS (and who doesn't want OS hooks?)

Cross-platform apps that do provide hooks into the OS are excepted: those are indeed useful: Python, etc.

</comment><comment><USER3> I don't understand why I would want C++ syntax when I could have python syntax for the same task? I checked and the python code for that matrix multiply is significantly shorter and arguably more readable, and that's without making a Matrix class!

</comment><comment><AUTHOR> Via: [http://www.ibm.com/developerworks/aix/library/au- spunix_squi...](http://www.ibm.com/developerworks/aix/library/au- spunix_squirrel/index.html?ca=drs-)

I think I'll play around with this over the weekend (well, if I have time for it), seems like it could come in really handy.

</comment><comment><USER4> I can use alternative shells 'til the cows come home, but until everybody else that I work with abandons cmd.exe it's not going to be all that useful. For now I'm stuck with bad cmd scripts and python (which I love).

</comment><comment><USER5> It appears too awkward to use as an interactive shell, and looks more like an alternative to perl or python --- what advantages does it have over them?

</comment><comment><USER6> The emacs shell is also cross-platform and provides the basic shell commands. It can be customized easily with pieces of elisp.</comment>


Ghcjs: Haskell to Javascript compiler - <AUTHOR> http://github.com/sviperll/ghcjs

<comment><USER2> Hey, it seems awesome. Here's a suggestion: On the main page, even thought you specify where to find examples, it would still be nice to have a small example of what this library does.

</comment><comment><USER3> I'm pretty excited about this. There used to be another Haskell -> Javascript compilation tool in the York Haskell Compiler and it kinda disappeared into the bowels of the Internet. Haskell is an incredible tool for writing parsers and interpreters. Leveraging this in Javascript could give us some interesting web software. I've always gotten the feeling that Haskell could fit in the same problem solving spot that some Javascript functions do with respect to passing call backs and higher order functions and all that. Nows the time to give it a try!

</comment><comment><USER4> So there's now a haskell to javascript compiler, and an implementation of haskell in javascript. I want to see a benchmark comparing the two.

</comment><comment><USER5> Haskell to Javascript, Clojure to Javascript... Javascript is starting to play role of intermediate representation rather than programming language, and bytecode that could be embedded or referenced by web pages would be more appropriate for this task.

<comment><USER3> Sure. So draft a spec and submit it to a standards committee!

<comment><USER5> Here it is: [http://java.sun.com/docs/books/jvms/second_edition/html/VMSp...](http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html)

</comment></comment></comment><comment><USER6> Awesome. I really think there is a strong opportunity for javascript compilers, and while I don't think haskell->js is where we will be "eventually", I think this is a very admirable effort.

</comment><comment><USER7> Related: Python to JavaScript compiler <http://pyjs.org/>

Pyjamas is a port of Google Web Toolkit to Python.

</comment><comment><USER8> Any idea how this deals with the DOM?</comment>


Man Implants Giant Computer Into His Arm Without Doctors - <AUTHOR> http://newsfeed.time.com/2013/11/01/this-guy-implanted-a-giant-computer-chip-into-his-arm-without-medical-supervision/ <comment><USER2> It can read his body temperature and send it via bluetooth. It also has 3 status leds. Now honestly, the question really is, why is this so large? You can easily get a temperature sensor and logger along with a small battery that would be the size of a coin in total. Since it has wireless connectivity he could just transmit status over that instead of using leds? It looks far, far too large for what it does...

<comment><USER3> I think it does more than just temperature, but has other biometrics. I'm assuming this based on the project on their site: [http://www.grindhousewetware.com/Circadia.html](http://www.grindhousewetware.com/Circadia.html)

</comment></comment><comment><USER4> Part of the reason it's huge is that it's a body-modification. That's an aesthetic choice. It could be made smaller, but then people don't see it, and so what's the point of having it? With a huge lump under your arm people say "What's that huge lump?" and you can then talk about how you're a cyborg.

In the UK getting someone else to help you is putting that person at risk of serious legal problems. Probably around the assault or grievous bodily harm.

Gibson said something like 30 years ago (about implantable watches) "Why don't they just carry it around in a pocket?". I forget which book, and what the exact quote is, and I don't have them at this house to check. But if I want to know my temperature I'll use an infra-red thermometer in my ear.

</comment><comment><USER5> I am not put off by the DIY surgery or the size of the computer. But I was astonished by this line: 'the chip can record Cannon's body temperature and transfer it in real time via Bluetooth.' If I would attempt such a thing like this I would make sure it could do a lot more!

Direct link to the article: [http://motherboard.vice.com/blog/the-diy- cyborg](http://motherboard.vice.com/blog/the-diy-cyborg)

Spoiler: there are no pictures of the biohack surgery

<comment><USER6> I certainly agree with that, it seems the only two functions of the implant are measuring the temperature and making light up his arm a little bit.

I am however curious to see how this project will advance, will he be able to use his arm like he did before, won't it affect his health in any way... how about heath generated by the device itself...

But being honest about it, this is cool! I always imagined with the current technologies (think google glass, thalmic's myo, current smartphones) we will come very soon to a time where wearable computers will make our live much easier, the only bottleneck seems to be we haven't got batteries that could last longer than a day and power such a device.

</comment></comment><comment><USER7> I feel like the actual medical community is almost certainly working on technology like this that will actually be:

1) Useful.

2) Safe.

That'll be cool. As for what this guy's actually contributing... Not really sure.

(Other projects on their site also kind of sound like bullshit. For example:

"The idea is to stimulate your brain with direct current (in the case of tDCS) or with square waves of current (in the case of CES) which can either raise or lower the potential energy of the stimulated neurons, depending on the orientation of electrodes. This allows them to fire more or less easily, and activates or deactivates a given region, thus engaging certain brain states." -[http://www.grindhousewetware.com/thinkingcap.html](http://www.grindhousewetware.com/thinkingcap.html)

Sounds like either pseudo-science or wishful thinking to me.)

<comment><USER8> Nothing pseudo-science about tDCS: [http://en.wikipedia.org/wiki/Transcranial_direct- current_sti...](http://en.wikipedia.org/wiki/Transcranial_direct- current_stimulation)

<comment><USER7> Interesting. Also: [http://www.hopkinsmedicine.org/psychiatry/specialty_areas/br...](http://www.hopkinsmedicine.org/psychiatry/specialty_areas/brain_stimulation/tdcs.html)

At any rate, if these were researchers at Johns Hopkins, that'd be one thing. But I won't believe that this product does what they claim unless they do actual studies with it and post them on their site. But. I suspect they won't. Because I suspect they're using the Soylent scientific process: "We tried it on ourselves and it seems to work! And didn't kill us!"

<comment><USER8> tDCS devices are simple like that, just DC current in your brain. There has been a lot of discussion about them on HN: [https://www.hnsearch.com/search#request/all&q=tdcs&start=0](https://www.hnsearch.com/search#request/all&q=tdcs&start=0)

</comment></comment></comment></comment><comment><USER9> Some body modification enthusiasts currently get significantly large silicon implants placed under the skin. The most common one appears to be synthetic horns, but large symbols in relief and larger abstract forms placed along muscles/against bone are also feasible. Note, when I say "feasible" I mean that no apparent reduction in function is caused by the implant. In this fellow's case, it might even be a good idea for him to encapsulate a wireless unit within a silicon sheath to avoid any kind contamination. That could increase the bulk of the unit considerably.

</comment><comment><USER10> >It's also huge, since it comes with a battery pack that charges wirelessly.

This is one of the main problems with sub-dermal implants. You don't want anything trans-dermal, because it's a recipe for infection. But if it's sub- dermal, it not only needs to be biocompatible but also needs to wirelessly transmit data. This implies a need for a power source of some sort that won't overheat. I sincerely hope he's thought this through, because if that battery gets too hot, he's going to destroy a lot of tissue, to say nothing of how biocompatible the device is.

</comment><comment><USER11> I don't understand why the thing is roughly the size of a phone...

</comment><comment><USER12> Well, that arm is going to basically be unusable.

<comment><USER13> Oh, I hope he never falls on it.

<comment><USER14> You'd be surprised how limited you are once you get a piercing. A simple piercing.

I got one at the eyebrow, I loved it (and especially the ladies my age) but you have to restrain yourself a lot. You can't bump into someone, you cannot really sleep on your head, you have to take care when you're taking off your Tshirt, or when you're washing your face, drying your face, wearing glasses, and on and on.

</comment></comment></comment><comment><USER15> The functionality doesn't seem to be greater than that of wearable sensors. It does get people's attention though and like good art, makes you think. Where's your threshold? What would it need to do before you'd be willing to take the risk? Are there better locations for the device? What about upgrades and recharging? Their way works but what's better? Definitely a useful exercise.

</comment><comment><USER16> This guy is crazy. [http://www.youtube.com/watch?v=_R3hxcgvOTw#t=144](http://www.youtube.com/watch?v=_R3hxcgvOTw#t=144) I think he is in it for the thrill. Not usable at all, much to big, better to just have a smartphone in your pocket. Or an arduino with sensors on your skin. Instead of implanting this.

</comment><comment><USER17> For people complaining it's big, the guy on reddit's futurology subreddit who helped design it said it was just the first step, it will shrink in size and grow in features.

[http://www.reddit.com/r/Futurology/comments/1ohqpl/this_is_t...](http://www.reddit.com/r/Futurology/comments/1ohqpl/this_is_the_very_first_prototype_of_something/ccs19fx)

He also said it's just temporary, for 3 months.

[http://www.reddit.com/r/Futurology/comments/1ohqpl/this_is_t...](http://www.reddit.com/r/Futurology/comments/1ohqpl/this_is_the_very_first_prototype_of_something/ccs7pc6)

</comment><comment><USER18> I disappointed that device have no USB plug aka BioPort ;)

</comment><comment><USER19> About time. The fact this can be done with "relative" safety needs to be publicized. It wont get safer or smaller until people make statements that there is a demand for such technology. And as to all the people going on about how foolish it is, right now with the legal, financial, and social barriers, this is the only way it can be done. And even smarter to do it while we still have effective antibiotics.

</comment><comment><USER20> Why doesn't he just use a basis band or a bodymedia device? It measures temps & more and you don't have to risk an infection.

</comment><comment><USER21> The cyborgs I thought about as a kid were way cooler than this lameness. They talk about this like it's some history making implant that's never been done before, yet much more sophisticated implants for various ailments like ICDs are quite common.

A 10 year old with a cochlear implant is way more impressive than this.

</comment><comment><USER22> I'm not clear why this is a story. This is hardly interesting from a technology standpoint even as a proof of concept.

I'm guessing it grabs peoples' attention based on the pain this person went through to perform surgery on himself, but this too doesn't strike me as a story.

</comment><comment><USER23> This is the original article: [http://motherboard.vice.com/blog/the-diy- cyborg](http://motherboard.vice.com/blog/the-diy-cyborg) (which would have been better to submit than the Time magazine blogspam).

</comment><comment><USER24> Being that big and having a battery, I would have implanted a tiny mp3 player with a smallish speaker. Waay cooler (because to me he did it pretty much for the 'cool' factor).

</comment><comment><USER25> How completely and utterly ridiculous and reckless. I understand the thrill, but jeez... And good luck walking through an airport in future!

</comment><comment><USER26> Even a nexus 4 in a complete sealed bag would be smaller and more functional.... included leds, lot of sensors, cell chips and others...

</comment><comment><USER27> you weren't joking when you said GIANT. Couldn't he have made it the size of an ipod/fitbit or something.

<comment><USER6> I'm only guessing, but I think the reason it's soo big is because they want it to be "DIY" and a bluetooth-module and wireless-recharging module cannot be made much smaller, not to forget that thing also needs to have a battery that can hold out long enough!

<comment><USER28> Wireless charging, perhaps, but I have a bluetooth module with embedded CPU and GPIO pins that's not much larger than 2x2cm.

I'm pretty sure the reason for the size is aesthetics, rather than requirement.

<comment><USER3> Does the GPIO include analog? If so, can you link me :D

<comment><USER28> [http://www.ti.com/product/cc2540](http://www.ti.com/product/cc2540)

12-bit ADC onboard. Also two serial (SPI/UART) and an AES module.

Microcontrollers pack so much in these days.

</comment></comment></comment></comment></comment><comment><USER29> I saw that a few days ago. It's disgusting. I couldn't even read the article because of the images.

<comment><USER30> ok, thanks for letting us know, author of most useless comment ever.

<comment><USER4> Warning people of gore isn't useless. Your comment, however...

<comment><USER31> C'mon, everyone. Our [deepest felt] opinions just have to be valid, or else where will all that humanity go?

</comment></comment></comment></comment><comment><USER32> Wow, at least round off the corners!

</comment><comment><USER33> Duuuude, do a Kickstarter campaign or something to cut that down to size!</comment>


The CMS Is Broken. - <AUTHOR> http://labs.talkingpointsmemo.com/2011/07/the-twilight-of-the-cms.php

<comment><USER3> "Drupal, Wordpress and Joomla use PHP. — the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren't designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of programmers."

This is true of Joomla, and to some extent Wordpress, but as someone who makes his living using Drupal, this statement is patently false and indicates that the author isn't truly familiar with the systems he's criticizing.

The cast of characters behind most Drupal plugins (modules, in Drupal parlance) is well known and most have been iterating their plugins for four to six years (or more). Drupal.org serves as the sole repository for plugins, providing usages statistics, notifying users of upgrades and patches to modules, serving issue queues, and generally keeping the Drupalverse running quite smoothly.

Drupal plugin A and Drupal plugin B _are_ designed to know about each other, at least indirectly, because they use the same fundamental elements (the menu system, the hook system, common APIs) to manage data.

I'm not going to claim that Drupal is "Wordpress easy" to install, or that you'll just sit down in a day and master the system as it's as much a RAD framework as it is a CMS. It's big, powerful, and flexible, and these traits are the natural enemies of "easy."

FWIW, I'm not a core contributor or anything like that, I'm just a guy who's made a hell of a nice living using Drupal.

<comment><USER4> I'm not sure the problem is necessarily Drupal, but I tend to agree with the post's authors that a Drupal written in something other than PHP would be a nice thing to have. Specifically Python would be really nice.

<comment><USER5> Why? Look, I hate PHP as much as the next passionate software developer. I did PHP full-time from 2000-2005 until I couldn't take it anymore. I spent a fair amount of time with Drupal and it was technically very impressive even though ultimately it was not for me because the tradeoffs were not where I wanted to be as a developer.

The thing is, what a CMS does is cater to a site which does not have the budget for custom software. A system like Drupal gives a tremendous amount of bang for the buck, and of the open source CMSes, it's hook system is definitely the most powerful once you really understand how to drive it. In the end you're hitting the Drupal sweet spot when you write just a bit of glue code here and there to tune the functionality of existing modules to what you need.

In short Drupal and other CMSes let you build sites with a scope of functionality which would be impossible to do custom development for. In this type of market cost is such a factor that anything less ubiquitous than PHP would be a strike against the system. Furthermore, as the number of modules grow, you need a very large community to keep everything working smoothly, so you don't want to go with a language that has lesser adoption.

Personally I can't stand CMSes because I feel like the abstraction is at the wrong level. To me it's mediocrity by 1000 tiny assumption mismatches. Using Rails or Django I feel like I can craft a minimal, excellent and highly tuned UX _exactly_ to my vision with a better language and lower overhead. Making a CMS in Ruby or Python doesn't address the root pain of living within a heavy and immobile scaffolding. There's a reason you don't hear much about the many open-source Rails CMSes that have been floated over the years.

<comment><USER4> I don't know about Drupal - I would tend to agree it's a little too cumbersome to the point where I would rather write something with a good framework like Django.

But WordPress is really nice, aside from PHP, and my once-off design-a-simple- website projects that use it would be a lot simpler if there were something similar that had a better language. PHP does add a significant amount of gymnastics that make plugin development more difficult.

I don't mind living with a heavy and immobile scaffolding for small projects - but using bubblegum, shoestring, and when necessary sauter to put what little additions I need on is a lot more annoying than just having a clean, standard set of screws and brackets. WordPress especially has a decent set of screws and brackets, but at the end of the day it is PHP and I see a lot of stuff that looks suspiciously like bubblegum.

As for Drupal, I'm not saying I have an incredible amount of experience in it, but taking it for granted that it's a useful framework, I imagine it would be more useful if written in Python or Ruby. Also, I don't buy the argument that PHP is easier to find - I think you would actually have to go out of your way these days to find a place that had PHP but not Python or Ruby available. Certainly all the cut-rate behemoths like HostGator support it.

<comment><USER6> The problem you see with these applications is that they are _bad_ PHP, not that they are PHP.

If you would, go take a peek at the Symfony2 framework. It's positively brilliant code, and it's PHP--Fabian Potencier and friends are excellent programmers, and they write excellent code in PHP.

<comment><USER7> I'm currently in the process of building a migration path from our two different older PHP frameworks (MidCOM and Midgard MVC) to Symfony2, and I've really been impressed by the community.

They seem to be very receptive to new ideas, and passionate about code review. I've received lots of GitHub comments on my bundles even though the commenters probably would never actually use them.

And when I found an issue in Symfony2 itself that made integration with AppServer-in-PHP harder, Fabien fixed it within the hour of getting reported.

</comment></comment></comment></comment></comment></comment><comment><USER8> I find this interesting because TPM's solutions reminds me of the classic UNIX "pipes and filters" strategy - a series of small components with well-defined inputs and outputs that can be strung together to produce a sophisticated result. (Of course, "small", "well-defined", and "sophisticated" could be relative terms.) The pipes and filters "API" was plain text transmitted through stdout.

It also strikes me as an example of software development becoming more deeply embedded in media companies. It's not an accident or a coincidence that most content management systems work on the framework-with-plugins model. Dedicated software developers build the framework, and it's expected that organizations who use it only have the technical chops to deal with plugins. TPM's architectural change is also a change in the amount of development work they plan to do - they're saying that they can afford to rewrite/develop/debug/etc. 10% or 20% (percentages are arbitrary) of a CMS-size framework and string those components together, rather than work with the 2% of a plugin and sprinkle it on top of the main 98%. They've moved up the food chain in the size of their internal development.

<comment><USER7> I think the natural next step of "UNIX pipes and filters" is Flow-Based Programming (<http://en.wikipedia.org/wiki/Flow-based_programming>). Processes can have multiple named input and output ports, and data flowing between them can be objects and other data formats.

In currently building an Open Source FBP tool called "NoFlo" on top of Node.js, and at least the initial results of building websites with it are promising.

<comment><USER9> This is definitely the direction i see things going.

Node.js is also perfectly suited for it, and I recall hearing that it's also on the core team's mind.

<comment><USER7> Here's my project: <https://github.com/bergie/noflo>

</comment></comment></comment></comment><comment><USER10> Blog engines are a subset of CMSs. They're _supposed_ to be restrictive - <USER2> simplicity is part of their value. If they wanted a CMS that would allow them to add their own types of content, they should have gone with a CMS that was more "framework" than "application"

<comment> dorian-graph That's what I was thinking, especially when I read this part:

"The CMS has to be everything to everybody. Wordpress has to optimize for both the cat-picture faithful and the ring-bejewled, hair-fisted mogul. Moveable Type has to work whether you are running a lad mag or poetry journal. This is an impossible proposition."

Expecting every (?) CMS to be the end-all solution to every possible content situation is ridiculous. It would be nice/neat but that doesn't seem to be quite how it works—is that idea akin to expecting every vehicle to be able to perform every type of situation available? Expecting your family sedan to also be the workhorse carrying materials and whatnot?

What if you only wanted to ride a simple bicycle down the street and not have to worry about a more intricate/heavy one? I use different CMS for different things though admittedly, that makes it harder to master one in particular.

<http://www.thesecretary.org/> \- For portflio type sites. <http://staceyapp.com/> \- For incredibly simple sites. <http://textpattern.net/> \- For most other things.

I do feel as if CMS have kind of stagnated for a bit and am a little tired of most so I'm thankful for the author bringing Netsta to my attention—it looks interesting.

</comment></comment><comment><USER11> It sounds like Separation of Concerns[1] applied on a larger scale. Software is easier to manage and more flexible if each piece does one thing and does it well, with as little overlap with other components as possible. This is what makes OOP a good system for designing large programs. I helps people separate out the various components so that maintenance is of many small pieces with clearly defined boundaries instead of one large piece with none.

Separating out these services into their own "apps" is like splitting up classes. It's a natural and good way to increase maintainability and flexibility.

[1] <http://en.wikipedia.org/wiki/Separation_of_concerns>

<comment><USER7> Exactly the approach I'm pitching to CMSs in here: <http://bergie.iki.fi/blog/decoupling_content_management/>

</comment></comment><comment><USER12> This is roughly what Ars Technica was doing before I left, I think moreso now. The Movable Type "post" interface was relegated to "the box people write text in", which was then pushed into the app that handled rendering a site.

</comment><comment><USER13> The world of Content Management Systems is definitely an awkward place to be in, However, I don't think that the notion "The CMS Is Broken" is really justified.

I think the first major problem with CMS' is that people expect them to be the end all be-all solution to their site and content needs. Clients expect them to be an intuitive cheap publishing platform that will magically format, organize and display an endless array of content and content types, while developers expect them to be fast, easy to extend, scaleable, lightweight and fit a theoretical "goldilocks zone" of adhering to conventions but still being flexible.

To fix the client problem, clients need to understand software does not create good content for you. Content needs to be curated and software is there to help with the heavy lifting. Instead of forking out X amount of money on software, spend half that and spend the remaining half on writers, photographers and people to make your content great.

As for the software/development problem, each specific case can require a different platform. Just like one specific programming language is only one tool in the box, one CMS follows the same pattern. Educate yourself about all your tools and explain the pros/cons to the client before making a decision, but in the end, isn't that what were being paid to do?

Sorry if my comment is a little more about the business side of things and not necessarily about the CMS itself, but I feel its a pretty important point on this issue

</comment><comment><USER14> Definitely an interesting perspective from the media industry. Although the pattern described is a relatively common pattern across a lot of "webapps-at- scale." For example, the CTO of Trip Advisor recently talked about how Trip Advisor is a series of distinct services exposing APIs that all run separately and are pulled together for a page render[1]. At some point most growing web apps simply outgrow the ability to be a single monolithic PHP/Rails/Python/whatever app and need start breaking things up.

Although, it seems like TPM is seeing benefits from this that go outside the typical reasons folks start to go this route, like outgrowing a single relational database or wanting teams working on different components to be able to work and deploy independently of each other.

[1][http://highscalability.com/blog/2011/6/27/tripadvisor- archit...](http://highscalability.com/blog/2011/6/27/tripadvisor- architecture-40m-visitors-200m-dynamic-page-view.html)

</comment><comment><USER15> Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API:

[http://www.gethifi.com/blog/first-we-built-an-api-then-we- bu...](http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms)

That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint and trade-offs.

Blog Engine CMSs are restrictive because they are Blog Engines! You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

<comment><USER16> The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy.

Info about Vortex CMS (in Norwegian): <http://www.uio.no/tjenester/it/web/vortex/>

<comment><USER7> Sounds very good. Would the DAV (REST) APIs be accessible for something like <https://github.com/bergie/VIE> ?

<comment><USER16> Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.

<comment><USER7> Admin pages are one thing, but with VIE you can make content also editable right where it is. See for example what we did with Midgard:

[http://bergie.iki.fi/blog/introducing_the_midgard_create_use...](http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/)

<comment><USER16> I really like the constraints you set on your project: "Build a CMS, no forms allowed". Aloha and other wysiwyg editors can hide the CMS almost totally. Using RDFa to store content is not a bad idea.

<comment><USER7> If you're interested in integrating VIE into that system, then the EU-funded IKS Project might be able to help you with that: <http://www.iks- project.eu/get-involved>

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> "Our new system will simply wrap the MT database in a cached layer and incorporate its content. Our new gallery app — currently active on the site — creates slideshows, writing its changes to central datastore as well."

Also known as "now they've got two problems", or in this case, four. Or I don't understand it - it sounds as if they have introduced another layer between frontend and backend, which probably increases complexity.

The road to hell is plastered with abstractions...

<comment><USER18> Well there are certainly tradeoffs. We do have more apps that can fail. Then again, when one does start to choke, as will happen, the others don't die. So if Baroque locks up, or starts to churn, or I do the ol rm -rf / all that is impacted it our ability to press frontpages until Chef can mint us another Baroque.

Also, there's not, so much, another layer between frontend and backend as there is a multiplication of frontends. It certainly may get us into trouble. Luckily, we already were in trouble and, worse case scenario, we all learn a lot from the experience.

The hell-road blacktop is something we are trying to tear us by substituting the abstract relation of CMS to site for a closer isomorphy of app to function. Who knows? Might work.

</comment></comment><comment><USER19> Wasn't this exactly the problem that Django was originally trying to solve?

<comment><USER20> Indeed, Django was made for news rooms!

Certainly the whole "homepage is an app" concept maps perfectly onto Django's ontology of projects and applications.

The API, however, is not something that's built in. They might want to take a look at Ellington (<http://www.ellingtoncms.com/>).

</comment></comment><comment><USER16> I like the feature-as-app paradigm, but the article says nothing about the underlying API. I have used a CMS the last couple of years at work, where documents are stored as JSON files on the server using WebDAV protocol, which off course is totally REST based. Access control is done using the PROPPATCH verb. The CMS is named Vortex, developed at the University of Oslo and has an open sourced license. Too mee this API seems to function better than the usual custom made REST based API.

</comment><comment><USER21> The most complex piece of software I've worked on was a CMS. I spent a lot of time doing competitor evaluations, and, without fail, the only successful implementations were using small products in small workgroups. Trying to solve the "enterprise" problem always failed, both because the software became stupid complex and the processes became even worse.

I don't think its an intractable problem, but the people issues surrounding it make it a hugely difficult one.

</comment><comment><USER22> Blaming technology isn't going to change the fact that journalism is still broken.

Folks like John Gruber and Matt Drudge make a ton of revenue by serving their readers. They have simpler technology than everything stated in this article.

<comment><USER23> You'd be hard-pressed to find an entity less representative of the 'old media being outflanked by the young hotshots' stereotype than TPM.

</comment></comment><comment><USER24> His discussion of editors' thought process about CMS tools and making site parts from apps sounds suspiciously like the reasoning over at the Lawrence Journal-World newspaper. I'm curious why their solution wasn't mentioned.

</comment><comment><USER25> I think this is somewhere that highly adapted mini-frameworks could take hold.. something like Padrino for Sinatra, yet slightly more publishing friendly.

</comment><comment><USER26> Yep, we here at Working Software _definitely_ think CMS is broken ;) [1] but mostly because of the deployment system and reliance on "designMode" word- style editing. Basically, we hate "plugins".

[1] <http://decalcms.com/mockups/>

</comment><comment><USER27> Holy shit people still use Moveable Type?

<comment><USER28> NPR.org still uses it. And it's a great example of MT's potential.</comment></comment>


Microsoft sues Barnes & Noble over Android in Nook - <AUTHOR> http://www.geekwire.com/2011/breaking-microsoft-sues-barnes-noble-android

<comment><USER2> I'm going to make this a stand-alone comment instead of inserting it to an existing comment thread, because there are too many places it could be reasonably inserted.

If you do not read the description of a patent, and then read the claims, interpreting them in light of the description, you have NO CLUE what the patent covers. If you do read the description and claims, then you MIGHT have a good idea of what the patent covers. To fully understand it, you have to get a copy of the file wrapper, which contains the correspondence between the Patent Office and the applicant.

The file wrapper is important because if the applicant argues for a narrow interpretation of something in the patent in order to get the examiner to approve, that narrow interpretation is what will apply when the patentee tries to enforce the patent.

For those who want to read the patents, I recommend using pat2pdf.org to get them. You can give that site a patent number and it will give you a nice PDF of the patent. The links most people are citing (including the submitted article) are to the USPTO, which is not as nice. In particular the images are not available on some OS/browser combinations. A PDF from pat2pdf.org works everywhere.

I don't know if there is a way to get the file wrapper for free, but you can get the history for free from the patent office. To illustrate how important the file wrapper can be, of the patents in question:

5,778,372: it was initially rejected (a non-final rejection, which I believe means the examiner is open to hear more arguments).

6,339,780: it was rejected five times (3 non-final, 2 final which I believe means Microsoft had to convince someone to override the examiner but hopefully a patent attorney or agent will jump in and clarify).

5,889,522: rejected three times (2 non-final, 1 final).

6,891,551: two rejections (1 non-final, 1 final).

6,957,233: two rejections (1 non-final, 1 final).

PS: it looks like you can perhaps get the documents in the file wrapper free online here: <http://portal.uspto.gov/external/portal/pair>

</comment><comment><USER3> [http://www.geekwire.com/2011/microsoft-cites-new-patents- vs-...](http://www.geekwire.com/2011/microsoft-cites-new-patents-vs-android) \-- Here are the details about the patents. It's pretty childish stuff. Anyone with half a brain can innovate and come up with inventions. This is just bullying.

<comment><USER4> Lets look at these patents.

Remote retrieval and display management of electronic document with incorporated images -- this patent actually falls in the ballpark that it might be reasonable. It was granted in 1998 and filed in 1996. I don't know if there was prior art on this.

Loading status in a hypermedia browser having a limited available display area -- This is called a splash screen. Sure its a mobile device and getting data from the network rather than disk, but same concept. This shouldn't have passed the obviousness test.

System provided child window controls -- This one was filed in 1994, prior to the launch of Win95. This seems borderline, but in 1994 this might have been innovative.

Selection handles in editing electronic documents -- This one seems like maybe the only realy legit patent if limited to just text. But I think it has been well-established for graphsics. The odd thing is they didn't use this for Windows Mobile through 6.5.

Method and apparatus for capturing and rendering annotations for non- modifiable electronic content -- This one doesn't pass the non-obviousness test to me. I can't think of another way to do what they described. A little disappointing since Thacker is on the patent.

One problem with patents is that it's hard to really get back to the mental state of 17 years ago, when at least one of these patents was filed. At the very least I do think that the current bar of "clear and convincing" may be too high, since I think that makes it very difficult for BN to put together a strong case unless they can just outright find prior art.

<comment><USER5> > Remote retrieval and display management of electronic document with > incorporated images -- this patent actually falls in the ballpark that it > might be reasonable. It was granted in 1998 and filed in 1996. I don't know > if there was prior art on this.

How about this:

> Portable Document Format (PDF) is an open standard for document exchange. > The file format created by Adobe Systems in 1993 is used for representing > documents in a manner independent of the application software, hardware, and > operating system.[2] Each PDF file encapsulates a complete description of a > fixed-layout 2D document that includes the text, fonts, images, and 2D > vector graphics which compose the documents.

<comment><USER4> The part of the patent that is interesting is that they optimize downloading of the electronic document by first ignoring the background image (if there is one). And if there are embedded images in the document they first download those that would be visible on the screen. And it also creates additional connections to the server to download other resources in the document in the background on these additional connections.

AFAIK, PDF doesn't specify these things. And to be clear the patent isn't about a file format. It's about the method one uses to retrieve and display the document.

<comment><USER6> I'm quite sure that somehow, there was a web server or email system that has transferred, stored, and otherwise "managed" a PDF with graphics in it in 1995 or before. How on earth is that not prior art?

<comment><USER4> What does managing a PDF with graphics have to do with it? Is there something inherent in PDF files that capture this behavior?

</comment></comment></comment></comment></comment></comment><comment><USER7> Though this is clearly political wrangling, I think Microsoft should be careful about claiming publicly that anything patented by them is "natural"... Natural is very close to "obvious"... which is bad for patents:

"natural ways of interacting with devices by tabbing through various screens to find the information they need"

<comment><USER8> Good point. That that their lawyers are freely using the word "natural" just shows how egregious they are.

They don't really care if the claims have merit, all they care about is the legal expense and risk it imposes on the defendant.

<comment><AUTHOR> I doubt B&N can afford adequate defense, and that's why MS is after them with such obviously invalid claims.

I would love if B&N went all in, proved the claims are without merit and countersued with a vengeance.

<comment><USER8> MS is suing several Android device makers simultaneously. Along with Google, there's an obvious incentive for them to pool their resources.

Not to mention that Google has a few patents of its own of course.

<comment><AUTHOR> Google having few patents is not relevant in the case Microsoft's patents are invalid. And every manufacturer who is yet to be extorted should pool the resources they set aside for licensing Microsoft's IP to invalidate Microsoft's patents for less money than would otherwise be needed (and to reap profits from the inevitable countersuit).

<comment><USER9> Entirely relevant: It's way easier to threaten an opponent with an extremely long legal war that would be quite damaging to them (and then come up with a cross-licensing deal) than it is to engage in a long legal war to invalidate patents.

Sure, it's not the best thing to do, but it's better for all concerned.

<comment><AUTHOR> I'd cut Microsoft's access to Google. Let them try to function with only Bing results ;-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> This is Novell all over again. They settle for a couple million, and microsoft "buys" Hundreds of millions of dollars worth of "stuff" It is bribery to set a precedent; plain and simple. Despicable stuff.

</comment><comment><USER11> Is the EFF the most effective organization that accepts donations to fight this type of thing?

</comment><comment><USER12> Their message is clear: embed android in your product and we will sue you. Without indemnification from Google, people will be very hesitant to touch Android I think. Not good at all.

<comment><AUTHOR> That's why Google should help B&N in invalidating the said patents (something that doesn't look that difficult, provided you have the resources)

</comment></comment><comment><USER13> I think I'm going to patent the wheel and then randomly sue Mattel because of Hot Wheels.

<comment><USER14> You can't it's already patented

<http://news.bbc.co.uk/2/hi/asia-pacific/1418165.stm>

</comment></comment><comment><USER15> Microsoft: competing in the courts.

</comment><comment><USER16> Are they still not producing which patents these people infringe on? How anyone, especially techkies, could pat MS on the back at any point in history is beyond me. MS is _still_ at war with open source

</comment><comment><USER17> Here's what MSFT had to say about this:

[http://blogs.technet.com/b/microsoft_on_the_issues/archive/2...](http://blogs.technet.com/b/microsoft_on_the_issues/archive/2011/03/21/android- patent-infringement-licensing-is-the-solution.aspx)

<comment><USER18> Thanks, my BS meter just exploded.

[from another comment [http://www.geekwire.com/2011/microsoft-cites-new- patents-vs-...](http://www.geekwire.com/2011/microsoft-cites-new-patents-vs- android) ]</comment></comment>


New Job Board Launches - <AUTHOR> http://www.centernetworks.com/job-board-launch

<comment><USER2> and why exactly is this relevant at all?

<comment><USER3> just looking for the first 10 seconds, the front page says:

"Whether you are recruiting a Web developer, designer, Internet marketer, social media consultant or an executive team member, our job board will foster the connections."

seems relevant to many of the posters on YC.

<comment><USER2> I could flood news.yc with job boards that are made for this niche there are literally hundreds of them, why is this one special?</comment></comment></comment>


Stream(SQL) Event Processing with Esper - <AUTHOR> http://www.igvita.com/2011/05/27/streamsql-event-processing-with-esper/

<comment><USER2> I have been using Esper in the last 2 years to solve several problems requiring near real time latency with the same technologies uses in this article.From DSL router events to Business Activity Monitoring.The fact that you can go to production with the Open Source version is awesome and the community is really helpfull.

</comment><comment><USER3> Wow, that's incredibly simple! We've been looking at using ESPER at work to do correlative analysis and aggregation on telephony events that go through our system, but figured the configuration of that system would be fairly complex.

This is an incredible little demo of JRuby and ESPER, and shows how simple it can be to get up and running! I can't wait to show this to everyone and get a dev spike going.

</comment><comment><USER4> Look at active database research from the 90's. They all had event languages like this. My PhD research was in developing a domain independent event query language (EQL) that was very similar. This was 12 years ago.

<comment><USER5> and?

<comment><USER4> Just trying to add some context for the topic.</comment></comment></comment>


FOILing NYC's Taxi Trip Data - <AUTHOR> http://chriswhong.com/open-data/foil_nyc_taxi/

<comment><USER2> The post is from March 18th. Did Chris end up hosting the data somewhere?

Edit: Talked to Chris on Facebook. He is in the process of uploading it to someone who has volunteered to host and I have offered to host on Summon.com

If you can host/mirror this data please reply here.

<comment><USER2> Here are the torrents:

[http://chriswhong.com/wp- content/uploads/2014/06/nycTaxiTrip...](http://chriswhong.com/wp- content/uploads/2014/06/nycTaxiTripData2013.torrent)

[http://chriswhong.com/wp- content/uploads/2014/06/nycTaxiFare...](http://chriswhong.com/wp- content/uploads/2014/06/nycTaxiFareData2013.torrent)

<comment><USER3> Thank you!

</comment></comment></comment><comment><USER4> _You're not only required to provide a large enough hard drive, but it must be "brand new, still in the box and unopened", presumably for security reasons. This requirement is a bit silly in my opinion, and probably prevents a lot of would-be FOILers from getting this data,_

That's a completely sensible stipulation. It's imperfect like all security, but it's a legitimate reason rather than just a barrier.

<comment><USER5> If it's for security, it would be theater. How hard would it be for someone to open the package, put their spyware on it and repackage the drive? Even easier are OEM drives that come in unsealed boxes.

I'm guessing it's more to make sure the drive is in working order and clean of any data. This would limit liability for accidentally deleted data and broken drives. If the drive doesn't work, it's still under warranty. It also saves time on trying to make an old drive work.

A new drive equals zero hassle for them.

<comment><USER6> It also stops Joe Shmoe from coming in with the same drive he's been using for a few years already but has no clue is filled with all sorts of malware and viruses.

</comment></comment></comment><comment><USER7> Wow, I'm impressed with the responsiveness. It could be better, but honestly, if the other municipalities in New York state were up to at least this standard, I'd be very happy. In my experience, however, FOIL requests are often delayed, "forgotten", or ridiculously stored (on reams of paper, in ancient data formats, etc).

<comment><USER8> Processing issues are usually only a problem if the information implicates the government in criminal activity.

</comment></comment><comment><USER9> Am I the only one that sees some significant privacy issues with exact pickup/drop off times and location being released? It seems like singling out a single passenger's data (e.g. to/from home) would not be that difficult.

<comment><AUTHOR> Not many people take taxis from home to work every day, or even weekly. If you are the type, then likely, you are someone who lives in Manhattan (getting to work via cab in a borough is a tenuous situation) and in a dense enough area where you are one of dozens/hundreds of people who could conceivably be dropped off at your home spot (think of the density of high-rises).

<comment><USER9> The question is more inspired by someone I know who lives in Manhattan who has a psycho ex. This data would answer the question (if he were tech savvy enough to mine it) "Where does her new boyfriend live?" which is rather frightening IMO.

<comment><AUTHOR> OK...but how would this psycho-ex track the new boyfriend down?

Presumably, the ex knows where the girlfriend lives...and I guess, he also knows what the new boyfriend looks like? So he watches the apartment until the BF leaves by taxi. The ex then notes the taxi's time of pickup. And then...

The ex waits a full month before calling up the TLC, buying a new hard drive, transferring a couple of GB, and then doing the data analysis to find that particular taxi that made a pickup within the vicinity of the girlfriend's apartment, and finding where that taxi made a dropoff?

And then the ex goes to those coordinates and...then what? Barges into one of high-rises and knock on every door until he finds the new boyfriend?

I think that if the psycho-ex were to act like a psycho, he probably will not do it through this kind of data analysis.

<comment><USER10> Not just a full month. Up to six months it seems. The response from TLC made it sound like new data is only available twice a year.

</comment></comment></comment></comment></comment><comment><USER11> Very cool article! I'm torn on the "bring your own hard drive" issue. In one way it is very anachronistic given today's cloud technology but the flip side is that the OP was dealt zero procedural roadblocks along the way. Nobody at the city said "No." and they seemed helpful at every step. I'd tally that as a Win in today's bureaucratic and overly secretive world.

I find myself wanting to make a FOI request to my city. I have seen tricked out Parking Enforcement cars trolling the streets this year. They have license plate reading cameras mounted along the car's perimeter. I want to know if that information is stored, for how long, and who has access to it. Have any law enforcement agencies queried the database?

I would appreciate all the pointers I can get for proceeding with a FOI request. So far, I have been using MuckRock as my primary source of tutorial.

<comment><USER12> > who has access to it You can get the ANPR database under FOI > [https://github.com/johnschrom/Minneapolis-ALPR- > Data](https://github.com/johnschrom/Minneapolis-ALPR-Data)

</comment></comment><comment><USER13> Is he allowed to post the data online? If so maybe we just need to collectively do the FOIL requests and upload the data to a community managed site where it can be made available to anyone.

<comment><USER14> Isn't that muckrock?

<comment><USER13> Google doesn't know what mudrock is. Do you have a URL?

<comment><USER15> [https://www.muckrock.com/](https://www.muckrock.com/)

<comment><USER13> Did you edit a typo or was I just blind? I searched for mudrock, not muckrock. Thanks. :D

<comment><USER14> Yeah, I edited it. Sorry! :)

</comment></comment></comment></comment></comment></comment><comment><USER10> Medallion and hack license appear to be one way unsalted hash

<comment><USER16> That will make things interesting. I think people elsewhere in the thread really aren't grasping the privacy implications.

</comment></comment><comment><USER17> Can we get this put on S3? Would love to play around with it.

<comment><USER18> I think a torrent would be better. There will probably be lots of interest in this, so S3 can get expensive.

<comment><USER19> Useful tip, if you add "?torrent" to the end of the url for something stored in S3, you get a torrent. I think this only works for files < 5GB though.

<comment><USER20> Any idea of the reason for the size limit? That's a pretty weird limit to put on a torrent feature.

<comment><USER16> Reducing the incentive to host uncompressed DVDs / BluRay?

</comment></comment></comment></comment></comment><comment><USER21> Anybody got cool idea's how to visualize such a dataset? I have a similar set of data I collected, but haven't gotten beyond the "trips per day, length, etc" basics. I feel there is something beyond the most basic visualisation, on a more meta level, but am not sure what.

</comment><comment><USER22> Just a thought. You could do some interesting reporting on this data. What about finding all trips to a particular address e.g. a politician's house ? Or finding all taxis exiting a known crime sense.

<comment><USER23> Abortion clinics, drug clinics, psychiatrists, cancer specialists...

Now Manhattan may be dense enough it might not leak too much personal information but the same granularity of location data in a suburban or rural area may be very intrusive.

</comment></comment><comment><AUTHOR> Call me gobsmacked.

Since I've lived in NY, I've seen plenty of cool visualizations and stories...about where pickups happen, time of day, volume, etc., and I've periodically asked around, where does the data come from? Obviously I didn't ask well enough...because if all it took was an old-fashioned public request (and a brand new hard drive)...wow.

The trip data is interesting enough...but the _fare data_ is really mind blowing. Everytime I get out of a cab, I wonder, "should I have tipped that much?" The (crowd-based) answer is apparently not that hard to find...

<comment><USER24> There are 2 possibilities:

1\. People aren't tipping 2\. Cab drivers aren't reporting their tips.

Being a native new yorker, legality aside, I'd bet most _cash_ tips go unreported. Reporting a tip makes that tip taxable, so there is a very strong incentive to bury it if they think they can avoid trouble or suspicion.

<comment><USER10> Then you can filter the data to show only CC transactions. There might be some additional variance of CC vs cash tipping, but I think the overall trend will still be there in just the CC transactions.

</comment></comment></comment><comment><USER25> I'm curious how large the data is after gzipping it.</comment>


VC Evolution: Physician, Scale Thyself - Dave McClure - <AUTHOR> http://500hats.com/VC-evolution-geeks-got-next <comment><USER2> I think most investors would agree with this entire post... EXCEPT for one point. I think if you asked the top Valley investors what they thought of the "Scale up and out" point (tl;dr Dave is contending that the valley is getting comparatively less important, geographically speaking), I think they'd almost universally disagree. This is a big bet from Dave/500s. As someone who doesn't necessarily love living in the Valley, I hope he's right. :-)

<comment><USER3> we are still allocated 50-25-25 valley-restofUS-RestOfWorld, so at the moment 1/2 our deals are in California. but due to prices being somewhat overvalued here, as well as comparatively inexpensive in other places, along with potential for growth in emerging markets, yes we are planting seeds for the future we think will reap benefits 3-5+ years out. we think it's a pretty decent strategy, but only time will tell.

<comment><USER4> Dave, looking forward to see you soon in Croatia -- good to see that you're practising your own preaching! ;-)

</comment></comment></comment><comment><USER5> I think this is an excellent summary of the past few years and if you're Dave McClure or one of the other visionaries of this new model then you should run with it.

However, now that great success has been achieved the herd is following. Herds are contrary indicators. Folks who want to be part of the next set of visionaries need to figure out the deficiencies in McClure's model and create new models of VC/entrepreneurship that address those deficiencies just as McClure, pg, and others created new models to address the deficiencies of the old VC models.

This isn't saying that this new model is bad, it's just that it's becoming saturated with people following it and there's definitely a degree of myopia setting in. Again, not a bad thing, it's just human nature to try to replicate success based on past successes. The problem is everyone know nows what works and tries to do the same thing leading to hypercompetition which eliminates real profit opportunities.

<comment><USER3> agreed, difficult for new entrants to come in at this point... that's also what people told me 2 years ago, and we carved out our niche ok. so not impossible, just challenging.

</comment></comment><comment><USER6> Dave does a nice job of articulating some of the forces changing VC. We are a data company that sells data to many of the top VCs so here are some observations based on how we see them work.

First, there are a good # of VCs who are evolving. Not sure they are trying to scale in the way Dave talks about, but they're evolving how they run their business. We do see many using data in very interesting and systematic ways – analyzing industry trends including financing flows & exits, improving their deal flow management practices, understanding investment patterns of peer investors, etc. In many instances, they're taking data feeds from us and others and vacuuming them into their dealflow management systems to aid in day-to-day operations. That's suggestive of process which again suggests some desire to scale, make things repeatable.

But these investors are not the norm. I think Dave and his team have talked about Moneyball in investing, but a quantitative approach to venture capital may be difficult. Some of this difficulty is driven by data limitations, of course, in terms of sheer quantity vs. something like public markets, but a lot of the reasons that data is less used are structural or behavioral in nature. While there are many reasons data is not used by a lot of VCs, a couple of these reasons are detailed below. Pls note that these are generalizations. As mentioned above, we see and know many VCs taking a very progressive attitude towards the use of data, but they're the exception and not the rule.

First, VC is a long game – Unlike public markets or baseball where you have an immediate scorecard to tell you how you're doing, VC doesn't have that. As a result, the desire/need for data is less clear especially when you won't know for many years if your investment thesis was correct or crap.

Also, although there is a lot of talk about one's investment thesis, there are again, some firms who stake out a thesis and invest in it and many others who look to invest in similar companies invested in by Union Square or Andreessen Horowitz or Sequoia.

Next, despite investing in the next big thing and often being exposed to cutting edge innovation via their portfolio, the process VCs use to find deals is hopelessly antiquated. This myth of proprietary dealflow has been so ingrained into the VC ethos that using any type of scalable method (or attempting to) is almost anti-thetical to how "VC is supposed to be done." The secret, of course, is that outside of ~20 firms (I'm being generous), most VCs don't have real proprietary deal flow. But instead of using data, most would prefer to throw bodies at the problem expecting them to find hidden gems. Or they attend demo days of accelerator programs and the like which offer them no preferential, proprietary access to dealflow.

VCs often view their job as being good "pickers" of companies but the new model suggests that picking is important but ongoing support (recruiting, technical, etc) from investors can help change the outcome of their portfolio companies. Google Ventures adheres to this philosophy.

Again, the above are for the majority of firms. There are some who are quite progressive. And of course, there are new models a la 500 Startups in the micro-VC category which are trying very different things.

Ultimately, given the returns in the industry have been subpar and the decreasing allocations of LP money to the venture capital asset class overall, a rethink of process might be forced upon VCs as doing more of the same with the expectation of a different result defines insanity.

Another great discussion on this can be found on Matt Turck's (Bloomberg Ventures) blog here - <http://mattturck.com/2012/07/20/data-driven-venture- capital/> Many of my comments above I left on his post as well.

<comment><USER7> Are exits not extreme trailing indicators?

<comment><USER6> Great point. And for early stage investors, I'd say that exit is def a trailing indicator in terms of where to invest. That said, they still care about valuations, multiples, etc on exits as that helps them value their existing portfolio.

But there is of course a spectrum of investors so for some investors, exit activity can be a signal. This will be moreso for growth equity or mid-market PE variety of investors. I should have been clearer about that so apologies for any confusion. Thx.

</comment></comment></comment><comment><USER8> VC firms are becoming more like top-tier universities and less similar to private equity firms.

Hire luminaries in fields to become mentors. Invest in training, teaching, and mentorship. Create an alumni network of successful people.

</comment><comment><USER9> Dave's interpretation of the YC alumni network is quite interesting to me. I'm curious to those of you who are YC alumni: does it ring true to you? If you're thinking of raising a round, do you talk to YC alumni about it? Are they helpful?

As for his main thesis that VCs don't eat their own dog food, that strikes me as absolutely true. If the VC industry was any other industry, VCs would be trying their best to help a startup disrupt it.

<comment><USER10> I can only speak for myself, but if a YC or 500 founder I don't know emails me, I'll make helping them in any way I can my top priority.

I am not altruistic by nature, so this is done purely for self-serving reasons:

1\. Everyone I've met through YC or 500 is absolutely brilliant at something in their field. I usually end up gaining much more wisdom than I share.

2\. Top tier funds like YC or 500 are very selective, so I know anyone I meet with has a nontrivial chance of being one of the world's top entrepreneurs in a few years. It pays to get to know them before they are famous.

In short, meeting with someone endorsed by YC or 500 is guaranteed to be worthwhile. That removes a lot of risk in choosing to invest time to help them.

<comment><USER3> ilya, it's great to have folks like you in 500 and YC :)

<comment> simba-hiiipower ^ whoa!

a very nice read sir; great insights as always</comment></comment></comment></comment>


Ask HN: Are you rewarded for unit testing in your performance reviews? - <AUTHOR> <comment><USER2> When I was just getting started, in the late eighties, I was chastised for doing something that today I would call unit testing. The thought was that I should be knowledgeable and confident enough not to have to test these low level things, we already do integration and acceptance testing. I was wasting time.

<grinds dentures></comment>


EU proposes banning encryption backdoors - <AUTHOR> https://www.engadget.com/2017/06/19/eu-proposes-banning-encryption-backdoors <comment><USER2> Main discussion:

[https://news.ycombinator.com/item?id=14592745](https://news.ycombinator.com/item?id=14592745)

</comment><comment><USER3> Many people consider this discussion as personal privacy vs government. However most encrypted communication is done by corps. For instance FB-Chat, Whatsapp, and Gmail probably have more communication going on than any person could do.

So in the end it's a battle corp vs government. And in that regard I don't know, but I feel more trust towards a government agency to protect me than a corp. Corps are only nice until they dominate a market. Government is always on the edge between exploiting and protecting its people since they need to be open to some level and can be replaced.</comment>


Is Mathematics a Science? - <AUTHOR> http://andrewlias.blogspot.com/2004/08/is-mathematics-science.html

<comment><USER2> Yes. Because science is concerned epistomologically with that which is objectively true. Given certain axioms, certain statements can be shown to be objectively true, or "true" given those axioms. Math is "out there", meaning it can be discovered as objective truth by anyone regardless of cultural context. Does it always correspond to the natural world? Likely not. But it is still "true" in the sense of a coherent system of axioms.</comment>


Design & Build a Grid Based Web Design with CSS - <AUTHOR> http://line25.com/tutorials/design-build-a-grid-based-web-design-with-css

<comment><USER2> Design and build a grid based web design with CSS. The first thing we're going to do is open Adobe Photoshop.

</comment><comment><USER3> Does any one know if there is a hn/reddit style news board for UX/AI/Web- Design news and articles?</comment>