codebeaker

Is this really HN worthy? It must be a pretty easy feature to implement with their slug/container workflow. With technologies such as Docker pushing them, Heroku ought to find a way to lower their prices. This at least adds value, but no magic here.

Tesla deserves to be the leader in the future of car manufacturing, they're a company that understands what it is to create a great product, execute well, and to care about their customers. It's almost impossible to believe it's from the same background as PayPal who have one of the worst (anecdotal) customer satisfaction records I have ever seen. But, great news for Tesla.

I was really hoping that someone would come up with a Go language "all-in-one" executable, including resources, etc, that could be started and bound to a port and would "just work" after Sameer Ajmani's video at GoogleIO about advances Go concurrency patterns, he implemented the collector side of a feed reader, and open sourced the code under a liberal licence. That together with a resource bundler such as https://github.com/jteeuwen/go-bindata to avoid even having to take care of the HTML/CSS assets seems like a potential big win for these middle-of-the-road complexity web apps.

No clouds over Europe... shame.

The phraseology "recharge your model S" leads me away from the notion that it's it's a swap, perhaps they've found some way to treat the batteries as super capacitors?

Also, there's a problem:

> cat /usr/share/dict/words | ./pipesock 2013/06/01 22:35:59 Read Line Error: EOF 2013/06/01 22:35:59 Read Line Error: EOF 2013/06/01 22:35:59 Read Line Error: EOF 2013/06/01 22:35:59 Read Line Error: EOF

This happened when trying to do "y | ./pipesock", amongst other things, perhaps you should silently ignore stuff that isn't streaming in line-based.

FWIW the websocket library now installed, I get a single reading in the html frontend, the first message I broadcast.

Nice idea, needs a lot more work!

Why does this start to work once the websocket library is "got" (sic) shouldn't go refuse to build this unless the library is there?

So no installation instructions, the ones here don't work (it's not compiled), and it doesn't seem to work (tailing a log file that is receiving new content once per second `while true.... date > mylog; done` - /buffer.json always empty, /flush does nothing except echo "Flushed" and the web interface apparently does nothing...

I always understood that the company receiving the money is supposed to pay it's own fees and use a lawyer that it trusts, without taking money from the VC on grounds that if you use the VC's money, to pay the VC's lawyer, on the VC's terms, you aren't necessarily getting a fair deal. I think paying your own legal fees to an impartial third party is a prudent investment. Perhaps I'm just naïve.

Plex and XBMC would be ideal candidates for this API, each user could easily maintain their own pointer to the data set, and their synchronisation would be faster and more efficient than it is right now.

There's also a provision with the API (for personal use, so far) which turns a filename (and metadata, if you have it) into a JSON hash (or msgpack, of course) of the episode, show and season, etc.

This is also a potential avenue for being more widely made available.

One would be able to look up a complete representation of the current known state of Mad Men, all known airing dates in all countries, places where it might be available to (legally.) steam in your jurisdiction, etc, etc.

These are all the features of a normal API. As well as access to the above, you could (selectively) register for updates to be pushed to a URL of your choosing when there are additions or amendments to the data held about the show. (or all shows, or all shows matching your criteria, etc)

A word to the critics (thanks!), the copy has been modified to be less rhetorical and to be absolutely gender neutral. I've also switched away from Raleway as a body font, it looked a lot better on a retina display than on something with a more widespread resolution.

The intention is to provide an API that requires little or no work on the part of the service relying on the data. Having had to work with thetvdb's API I can attest to having to download ~100 XML files (all languages…) in order to determine if anything is new, their API is often 2/3 days out of date, some internal caching problems and problems with scaling, they only deliver XML, poorly compressed (owing to key structure).

I believe services such as trakt.tv and similar should be able to do one thing, and do it well, offer a to-do list of shows you should watch, and summarise what you have watched. And they shouldn't have to write thousands of lines of code to interface with an API for what's actually quite simple.

In my (admittedly contrived, and not representative) benchmarks the JSON representing a typical TV series is 76% smaller, and parses 56% faster (that is probably representative of years of research and work into making fast XML parsers, and JSON being a relatively young format)

Also, I find it strange that they don't provide a notifications API or changes stream.

I don't want to call thetvdb specifically, many API and data providers make the same mistakes, if one can call a missing feature a mistake. (TradeDoubler, many financial APIs, etc)

Another departure from typical API design is to accept that many movies, shows, books and so forth are provided simultaneously (or, close to simultaneously), world wide, in multiple languages.

Therefore any API that purports to represent them must acknowledge that English isn't the default language, but it may have been the language in which the media was authored, and that airing dates, shipping and printing dates are worthless without timezone and language information.

My goal is to make an API that is easy to use, and can open the creativity of the community up, by allowing something that is now rather difficult to become easy.

To call out some of the problems I've tried to solve: timezones; networks; outlets (web); airing dates vs. availability dates (locale specific); actors vs. hosts vs. cameos; returning series under the same name; specials vs. pilots vs. shows about a series; treating different languages with equal weight; encoding (utf-8 naturally); gzip; msgpack... I'm sure there are many more which I've forgotten, but that's the gist of it :-)

I'm keen for any media which is a) structured and b) is an essentially append-only dataset.

I fear that existing APIs, through design and coincidence fail to address the needs of flexibly covering media of all types.

Join the list, look me up, or feel free to contact me to discuss

I believe trakt.tv is the kind of service that might benefit from a simplified back-end system if it were to use openmedia.io. They likely use thetvdb, or epguides or similar now, or may even have their own integrations with EPGs.

Similar services: * Web: trakt.tv, watched.it, watched.li, gomiso.com, getglue.com * Android: TV Series, TV Show Favs, Twee, DroidSeries, MyEpisodes

I don't think that trakt.tv is really competing on an API level, but the data from openmedia.io would make building and maintaining a TV and movie tracker trivial.

@carbuncle - If TMDB's licence allows, I can absolutely imagine offering the webhooks, and changes stream and a Movie type backed by TMDB. It's something I'll have to take up with their moderators.

@theallan - It depends whether that would be a competing service under liberal interpretations of the law, when the legal chap has drawn up the API permission guidelines, I'll be sure to notify the mailing list. Under German law we have to be quite explicit about granting permission, but the beta list will be notified of the full terms of usage before the API opens. (My gut-feeling, no problem with using the data to back an app, that's sort-of what the data's for!)

I'm working on an API that doesn't suck that will represent TV, Movies, Podcasts, WebTV, and other forms of media.

A stack-overflow inspired reputation system will reward community members to contribute translations, new shows, movies and corrections.

Background workers interface with EPGs, other APIs and streams of data from other sources.<p>An image proxy server means openmedia.io will do the heavy lifting delivering images in the dimensions that you want, backed by a speedy CDN.

Doesn't this solution as soon as people come directly to the forum from a search engine, and asking bots to maintain a cookie jar is hardly challenging.

I believe that studies (which I cannot find citations for now) determined that this device makes the sutation worse, as it scatters metalic debris over a wider area, and that human mine clearance teams have to work an order of magnitude harder, cleaning up tiny bits of shrapnel. Before an area can be marked clear, it has to be devoid of all unidentified metalic shards, and of course, all mines of other materials. As a result, it was the determination of more than one agency that this device makes things worse.

With that said, props to the designer for working on a solution to a difficult problem, but perhaps more domain knowledge would have lead him to a more suitable solution

Congratulations to Jean-Baptiste, that's been an incredible arduous piece of work for him.

Stow seems to have a flavor of Mac homebrew about it (more likely the other way around) everything is compiled and installed into `/Library/Cellar` and then symlinked into the system path, you can `brew unlink readline`, for example and it goes away, link it back and it's available to the system again.

The `brew` executable knows about the correct flags to give to `--configure` within it's own context, so it rarely goes wrong.

> checkinstall

Thats a half-decent idea, nice smart move, and it looks like the authors motivations weren't dissimilar to my starting point for this query.

I do wonder however if it isn't slightly over-killed, `make install` must generate a list of commands to run, or there should have been some way to stream the output of `make install` to a text file, that it might be undoable ?

> I think there is no `uninstall` command included usually because most packages that are installed using `make install` are system libraries that other packages depend upon. And so just uninstalling that one package could result in a broken system. There may be some other historical reason, but that's my guess.

That's a good point, there is no dependency resolution at this low-level; and with that in mind, there's probably a good way to uninstall things by hand, if you really wanted to.. thanks for the thought.

I hope that Rails has the weight to push these kind of changes into Rack.

I think that Rack is one of the best things that happened to the Ruby web-application community, and I'm a little sad that Rails is getting a "vendor specific" implementation of what should be a wide reaching feature. As you said at @scotruby though, Rails is in a unique position to direct the development on both sides, front and back end of development. (I believe in Scotland you were referring specifically to pushing backend queue implementors to meet the new Rails queueing API.)

I'm looking forward to seeing people building upon this for common use-cases such as streaming reports, CSV exports etc to clients, as well as the more `fun` stuff about live browser reloading (which guard-reload implements very nicely, actually, using a different technique)

And, I think it's fair to say that using a queue, and having a queue consumer (again, I think you demo'ed that in Scotland) isn't such a bad solution, at least as a more experienced developer I appreciate the moving parts, and it doesn't distract me too much from solving the problem at hand, and - most importantly it works.

That all said, I think this is a valuable change, and I thank you for your time in making it work, and coming up with an interesting test-case.

For what it's worth, my last word would be about a post on HN a few days ago, about streaming JPEGs, multi-frame streams often (apparently.) used for IP camera livestreams, that's quite an interesting case which could lead to this controller technique being used to do live image previews without page reloads in Rails with AJAX image upload.

I encouraged him to work on returning EXIT_SUCCESS or EXIT_FAILURE in order to better integrate with tools such as git-bisect (which can be used to binary-search the history for code passing a certain condition with a successful shell exit) - beyond that, I couldn't come up with any obvious improvements, what do you think?

After reading the "What Happens" section of the OP's article I can see that he's made the classical mistake of making many things do one small thing, but they're not independent.

The message queue to notify component X of changes to data in Y is endemic of badly designed systems; if system X cares about changes to data in Y it should be designed that (at scale) it caches the data for a suitably short time, otherwise reads-through to the canonical source.

This is a common anti-pattern, and I've seen it built by smart teams at epic scale (millions of uniques per day) and it is still un-manageable.

Feature toggles, hard and soft-failing, together with a baked-in assumption that APIs are asynchronous (that is, unreliable) at as many levels as is feasible is a good architectural move. (And does not necessitate an abundance of architecture over feature code)

Loosely coupled components that expect their counterparts to respond slowly, or not at all are easy to implement and even easier to test. (HTTP, if one wants to use HTTP as the transport medium, learned this, and offers 201 and 202 for CREATED and ACCEPTED).

In my own projects (and I work mostly on near-realtime billing APIs) we bake this assumption (and others) into every transaction, as try to be restful, and transmit the state, and a URL which can be used to get the canonical representation of any resource, at any given moment, and objects in all parts of the system are stateful, relying on the handshakes (accepted/created) (404, 406, 409) to avoid race conditions and to make sure our systems can handle downtime of any component (internal or external)

As a result, we have lightning quick tests, we are very confident in the system's ability to perform, and we have read-through caches which respect the transport medium's headers.

I suspect the OP is right, many do over-engineer the startup, but remember many startups appear to have an abundance of developer potential, until they don't. (Usually through bad design, not over engineering, the two ought not to be confused)

Perhaps I am biased by having seen it happening in a large company, completely unscalable architecture, and at a point as many "architects" as they had developers, desperately trying to keep the wheels turning.

There's a good chance you need to invest in your wildignore or ctrlp ignore settings. I run: https://gist.github.com/67de417c5c38f0ff8093 in the end of my ~/.vimrc to ignore the SCM directory, the tmp directory and my data-dirs (you can adapt as required) - this makes ctrlp really responsive for me. YMMV.

Website is still down, that's a shame - OP can't even get the homepage back online before showing HN.

30 minutes to bring back a homepage is pretty bad man, also your personal homepage http://paulbjensen.co.uk is returning NO CONTENT, is that on the same (bricked) server?

Your "formParams" link refers to the "dimensions" anchor, might want to fix that oversight.

I adore that you used literate style documentation for your source, as someone who is also learning to love programming efficient tools in C I very much appreciate that.

I question the need for yet-another-process-monitor, but I acknowledge that upstart, monit, etc are by and large overcomplicated and messy. They provide more features, of course, but they violate my interpretation of the unix philosophy.

I'm sure many people on HN will condemn you for writing this but, I for one am very excited to try it.

I had a similar idea of a daemon that would allow inter-process signaling for users to signal processes which shared their GID, to simplify web application deployment without relying on sudo privilege restrictions.

You may have just inspired me to take your lead, and just do it - a few hundred lines of C, and smart documentation have a lot of value as learning, experience, proof-of-concept and a discussion point; and that in itself is reason enough for this to exist!