76 karma · joined February 12, 2008
Distribution of an app with source easily modified (no build step) encourages tinkering.
Androwish also has a cool mp4 casting mode which replaces the screen rendering, that lets you use your app inside a web browser. https://www.youtube.com/watch?v=2GBmB6JSDnQ
Here is how they actually work: 9 bar of pressure are generated between the pump and a flow constrictor which is placed before the boiler, pumping cold water into the boiler. This cold water then displaces the water in the boiler, which then gets pushed to the espresso.
Thus, the final pressure depends on the compressibility of the steam (or airspace) in the boiler. In practice, you get about half a bar less at the espresso than the pump got behind the boiler. But, the real numbers depends on lots of factors, many of which are invisible.
Its focus on asynchronous programming, rather than relying on threads, really helps, as does the small memory footprint (105mb of RAM used for my app).
Java-based apps on the same tablet that I supply with the espresso machine run at a crawl, whereas my Tcl app feels normal.
1) Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) https://www.ietf.org/rfc/rfc2324.txt
2) Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 https://tools.ietf.org/html/rfc2325
--- Especially amusing as I was thinking of adding SNMP support to my coffee machine, so the humorous RFC above might actually be relevent.
"Bio-Med Engineer Langhorne PA 13 hours ago I worked in an engineering design consultancy that was contracted early on to help productize the ZPM design, and as such am intimately familiar with their initial concepts. In my opinion, the founders were initially earnest and dedicated but also naive and lacking in engineering judgement. They confused the ability to raise money with the ability to make sound engineering and technical decisions. Falling in love with one's ideas is a trap into which many inventors fall, and ZPM fell hard.
Additionally, I believe that ZPM received a lot of questionable advice from people who did not have their best interests at heart, and were swayed by strong personalities.
But the early backers - particularly the engineers - should have had the sense to realize that open-source firmware that is intended to control a consumer product that delivers scalding hot water is a fundamentally BAD idea, and that using a PID loop to manage the process is totally unnecessary.
What this article highlights is that Mr. Polyakov's talent is in raising money and expectations. It is unfortunate that neither his ethics, nor his engineering abilities can match those talents."
-john
The hardest things for me are:
1) sometimes you come up with an idea that would make money at a certain scale (in my case, lots of shoutcast radio stations of Magnatune's music) but you can't do it because you don't have the money
2) I have to put a lot more time into making the software I write efficient and scalable, because I can't afford to buy lots of machines when the site grows. So, for instance, I tend to avoid doing a lot of SQL queries, which might be handy, because scaling that requires lots of SQL server machines.
3) In the old days (10 years ago, when I self-funded Lyris, which eventually became a success) a big problem I had was getting licenses to technology (C++ libraries, database servers) but these days open source replaces all that.
4) doing without employees. That's both a benefit in the near-term, as I have to learn how to do everything lean and well, but a disadvantage if there are rote tasks to do now as we scale. With BookMooch, I've managed to get volunteers to do those rote tasks, but with Magnatune, I got 3 not-very-well-paid part timers.
- John Buckman