tag:blogger.com,1999:blog-16773179369464997012024-02-03T09:49:49.514+13:00NusquamNobody blogging nowhere…Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1677317936946499701.post-26292592413327752802016-06-23T09:32:00.000+12:002016-06-23T09:32:56.807+12:00Random Idea #1: P2P Postal Service<p>Cryptographically secure P2P postal service.</p>
<p>This originally came out of a random idea I had while heading home today:
cryptographically authenticated location tracking. I thought this would be a
required technology for implementing a secure P2P postal service. It would
mostly consist of a way to generate a proof that you were at a specific location
(+/- specified accuracy) at a specific time. It could either be built on top of
a central system like GPS, or, for maximum liberal sharing economy status on top
of a “mesh-based, cryptographically secure (and private), web of trust (WoT)
authenticated” location tracking service<sup id="fnref:mesh-location"><a href="#fn:mesh-location" class="footnote">1</a></sup>.</p>
<p>While trying to sketch out an actual implementation I realised that you wouldn’t
actually need the authenticated location tracking. The package itself already
has to do enough crypto and network work to ensure it’s delivered reliably that
integrating the location tracking into the package itself would be a simple
enough step and mean it can just trust itself (assuming the actual tracking
system is secure).</p>
<p>The other major piece required would be a smart contract system like
Ethereum<sup id="fnref:ethereum"><a href="#fn:ethereum" class="footnote">2</a></sup> to handle the contract and payments side. You would just
need to:</p>
<ul>
<li>grab one of the proven standard contracts<sup id="fnref:standard"><a href="#fn:standard" class="footnote">3</a></sup></li>
<li>package your item with a postal tracker</li>
<li>mutually authenticate the tracker and contract to each other</li>
<li>seed the contract with the final location and funds to pay deliverers</li>
<li>leave it somewhere it’s likely to get picked up</li>
</ul>
<p>The postal tracker would be a very simple IoT module containing a few
chips/cores connected together with a very basic firmware:</p>
<ul>
<li>secure cryptoprocessor<sup id="fnref:tpm"><a href="#fn:tpm" class="footnote">4</a></sup></li>
<li>tamper detection</li>
<li>NFC I/O</li>
<li>BTLE beacon</li>
<li>location tracker</li>
<li>mesh network access module</li>
</ul>
<p>The BTLE beacon will advertise that this is a package + the associated contracts
public key. If you’re part of the delivery network then you would be running an
application listening for these beacons, if the delivery location is in the
direction you’re heading and the price meets your minimum<sup id="fnref:price"><a href="#fn:price" class="footnote">5</a></sup> then the
application would pop up a notification informing you of it. You’d then go to
the package and interface with it via NFC to prove you’re actually there before
taking it. You carry it for a while to either its final
destination<sup id="fnref:destination"><a href="#fn:destination" class="footnote">6</a></sup> or somewhere that your client has determined is the
optimal location for you to leave it. There’d be a brief conversation between
the package, your client and the smart contract, and your account would be
credited with whatever portion of the delivery fee you’d earned.</p>
<p>Obviously there are many places in here that could be smarter. One big one is
the initial pickup, rather than just having a flat % fee for how much closer you
get the package there could be a much larger negotiation between your client and
the contract for the package. Depending on how much you trust your client it
could automatically negotiate a complex contract with many different potential
fees based on speed of delivery, once negotiations with the contract are done
they would instantiate a new smart contract encoding these potential payments,
the package’s contract would fund this new contract and it would be let loose to
oversee this part of the package’s journey. This could also be done as some sort
of auction system, which would require the contract to have some way to decide
on how to value speed of delivery versus cost (with any remaining funds being
sent back to the sender at the end).</p>
<p>Actually, this talk of negotiation made me realise that the controlling entity
of the package would not have to be a contract. In the simple case it probably
makes sense to just have a single contract controlling throughout the lifetime
of the package, but if you have complicated negotiation and reverse auctions to
run you probably just want a self-governing agent running it. If you don’t care
about the package being tied to (one of) your public identity(ies) then just
(one of) your general purpose public agent(s), otherwise a specialised agent
instantiated and funded for this specific package. This agent would then be
negotiate and instantiate smart contracts with the deliverers for the purpose of
getting this package to its destination.</p>
<p>Another place to add more smarts would be a reputation system, this could be
built into the smart contract governing payment, as well as paying out currency
it would payout reputation as well. Reputation would have to be more complicated
than a simple balance though, for the purposes of negotiation it would have to
differentiate between things like actual failure to deliver, consistent late
delivery and occasional damage during transport.</p>
<p>The reputation system could include things such as having the deliverer create a
bond contract before being able to pickup their first few packages. As their
reputation improves the agents in charge of the packages will start lowering the
bond, and even potentially for very high priority packages being delivered by
very high reputation deliverers offer a partial pre-payment as funds to perform
the delivery with (although that would be better done by the deliverers client
securing very good terms on a loan by showing the contract for delivery +
reputation to an automated loan broker).</p>
<p></random brain dump><sup id="fnref:memes"><a href="#fn:memes" class="footnote">7</a></sup></p>
<hr width="80%" />
<div class="footnotes">
<ol>
<li id="fn:mesh-location">
<p>Something like:</p>
<ul>
<li>a set of stable nodes that you trust that don’t move</li>
<li>a mesh network spreading proofs of relative distances</li>
<li>strong confirmations from mobile devices within a few mesh hops within
your WoT</li>
<li>weak confirmations from mobile devices within a few mesh hops that are
close to your WoT, some low number of WoT hops should be provable,
preferably without leaking knowledge of the identities along the link,
just that there is a link of x hops</li>
</ul>
<p>Spreading all those proofs seems like it might be a bit data-heavy,
especially the proof of devices close to your WoT. <a href="#fnref:mesh-location" class="reversefootnote">↩</a></p>
</li>
<li id="fn:ethereum">
<p>Or an actually secure/provable successor to it. <a href="#fnref:ethereum" class="reversefootnote">↩</a></p>
</li>
<li id="fn:standard">
<p>So deliverers won’t need to validate that your custom contract will
actually pay them. <a href="#fnref:standard" class="reversefootnote">↩</a></p>
</li>
<li id="fn:tpm">
<p>I really just want to say <a href="https://en.wikipedia.org/wiki/Trusted_Platform_Module" title="Trusted Platform Module">TPM</a> here, but that’s a standard rather than a
generic term, the closest general category seems to be “<a href="https://en.wikipedia.org/wiki/Secure_cryptoprocessor" title="Secure cryptoprocessor">Secure
cryptoprocessor</a>”, but that doesn’t have any TLA for it.</p>
<p>This seems common to me in crypto, <a href="https://en.wikipedia.org/wiki/Digital_Signature_Algorithm" title="Digital Signature Algorithm">DSA</a> (Digital Signature Algorithm) is
the first acronym I thought of when wanting to refer to the category of
digital signatures, but it is also a standard, the best TLA I could think of
for the category of algorithms that implement digital signatures is DSS
(Digital Signature Scheme), but what makes it a scheme rather than an
algorithm? <a href="#fnref:tpm" class="reversefootnote">↩</a></p>
</li>
<li id="fn:price">
<p>This would be a little more complicated that just matching the minimum, it
would have to take into account a lot of variables like how much of the
packages journey you can actually do, how far out of your way you would have
to go to maximise your payment/hour etc. Luckily that’s purely a client
feature and nothing to do with the basic system. <a href="#fnref:price" class="reversefootnote">↩</a></p>
</li>
<li id="fn:destination">
<p>Probably just dropping it at a location near its recipient, they would then
be notified by the contract that it’s ready for pickup. For urgent packages
they would probably have an extra bonus for in-person delivery since
finding actual buildings and the correct person to give it to is much more
difficult than just dropping it somewhere within a 500 m<sup>2</sup> circle. <a href="#fnref:destination" class="reversefootnote">↩</a></p>
</li>
<li id="fn:memes">
<p>Major relevant memes infesting my head:</p>
<ul>
<li>news about the DAO being hacked on HN</li>
<li>secure cryptoprocessors, BTLE beacons and sensor (not quite mesh)
networks for work</li>
<li>currently reading the second story in <a href="https://www.goodreads.com/book/show/9107759-metatropolis" title="METAtropolis: The Dawn of Uncivilization">METAtropolis</a> which mentioned
p2p postal service</li>
<li>just finished reading <a href="https://www.goodreads.com/book/show/19168622-lady-of-mazes" title="Lady of Mazes">Lady of Mazes</a> which (like a lot of Karl
Schroeder books) involves a lot of ideas about self-organizing
distributed societies and cryptography, (Karl Schroeder, Hannu Rajaniemi
and about half of Charles Stross should be required reading for anyone
working on any p2p crypto system intended to be integrated into everyday
society).</li>
</ul>
<p><a href="#fnref:memes" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>
Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.com1tag:blogger.com,1999:blog-1677317936946499701.post-16625061103612538282014-07-14T09:42:00.000+12:002014-07-14T09:42:01.342+12:00TypeScript and npm modules<p>The new big thing at work is
<a href="http://typescriptlang.org">TypeScript</a><sup id="fnref:big_new_thing"><a href="#fn:big_new_thing" class="footnote">1</a></sup>. I like the idea of
bringing more potential for compile time checking and better tooling to
JavaScript, and with all these new fangled features like type inference it
should hopefully not bring too much of overhead to the code.</p>
<p>Recently I’ve also been looking at doing some better integrationy stuff at home.
We got a new flatmate who brought along a
<a href="https://encrypted.google.com/intl/en/chrome/devices/chromecast/">Chromecast</a>
and have since switched to using <a href="https://plex.tv">Plex</a> as our main media
server. The Plex web UI and mobile apps both allow streaming videos/music
directly from Plex to the Chromecast. One integration area this is currently
lacking compared to the old setup was being able to see which tv/movies are
available and start them playing in <a href="http://xbmc.org/">XBMC</a> directly from the
<a href="https://trakt.tv">trakt</a> web site<sup id="fnref:xbmc_trakt_remote"><a href="#fn:xbmc_trakt_remote" class="footnote">2</a></sup>.</p>
<p>After a quick look at the Plex API I decided that this shouldn’t be too hard to
implement myself<sup id="fnref:lack_docs"><a href="#fn:lack_docs" class="footnote">3</a></sup>, and while I’m at it I may as well learn about
writing code in TypeScript. Learning the infrastructural areas around TypeScript
will be especially important as getting them right the first time once my team
actually starts using TypeScript at work will save a lot of hassle in the
future. Looking round at tools I’d heard mentioned by co-workers I thought it
should be easy enough to write a Plex API client library in TypeScript, using
npm modules like <a href="https://github.com/cujojs/rest">rest</a> as a base, pulling in
.d.ts<sup id="fnref:d_ts"><a href="#fn:d_ts" class="footnote">4</a></sup> files from the <a href="http://definitelytyped.org/">DefinitelyTyped</a>
repository using <a href="http://definitelytyped.org/tsd/">tsd</a> and publishing the
client as an npm module including compiled .js files along with the .d.ts files
so it can be consumed by other TypeScript libraries easily. With this client in
place creating the small amount of UI for the trakt integration would be a
cinch.</p>
<p>Once I actually started to build this base api client I quickly started running
into issues that made it not very nice to work with. The very first one was the
lack of and quality of .d.ts files available on DefinitelyTyped, this is sort of
expected since TypeScript is a relatively new language and is easy enough to fix
by writing these .d.ts files and contributing them back. The second issue was
how to actually bring these .d.ts files into the client. The recommended method
is to add a reference line to your code to pull in these definitions e.g. if you
have some source file <code>lib/client.ts</code> and have installed your .d.ts files into
the default <code>typings</code> folder with a top-level <code>tsd.d.ts</code> to reference them you
would need to add</p>
<pre><code>/// <reference path="../typings/tsd.d.ts" />
</code></pre>
<p>to <code>lib/client.ts</code>. Straight away this seems wrong to me, why are you having to
manually include type definitions when doing something as simple as loading a
module you use? Why is this not taking care of automatically by the compiler?</p>
<p>It gets even worse once you look at using a node module written in TypeScript by
another library written in TypeScript. For this example lets say I’d finished
the Plex API client with the following source file structure<sup id="fnref:lib_tree"><a href="#fn:lib_tree" class="footnote">5</a></sup>:</p>
<pre><code>plex-api
├── index.ts
├── lib
│ └── client.ts
├── package.json
├── tsd.json
└── typings
├── rest
│ └── rest.d.ts
└── tsd.d.ts
</code></pre>
<p>Prior to publishing this would be compiled to .js files by tsc, this will allow
consumption by normal JavaScript libraries. At the same time the .d.ts files can
be generated and added to the module to provide the necessary type annotations
for any TypeScript libraries consuming this module. This would result in the
following module file structure:</p>
<pre><code>plex-api
├── index.d.ts
├── index.js
├── lib
│ ├── client.d.ts
│ └── client.js
├── package.json
└── typings
├── rest
│ └── rest.d.ts
└── tsd.d.ts
</code></pre>
<p>Now, any normal JavaScript consumers of this library can simply </p>
<pre><code>var plexApi = require('plex-api');
</code></pre>
<p>as usual. For any TypeScript consumers however it seems
like they’d need to</p>
<pre><code>/// <reference path="../node_modules/plex-api/index.d.ts" />
import plexApi = require('plex-api');
</code></pre>
<p>Except that won’t actually work. The .d.ts files generated by tsc are source
files that define an <strong>external module</strong> (<a href="http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf">§11.1</a>). These
sorts of module definitions only work when the compiler’s pull type resolution
resolves an external module reference to the file directly<sup id="fnref:dont_ask"><a href="#fn:dont_ask" class="footnote">6</a></sup>. This
doesn’t occur when they’re pulled in by a <code>reference</code> directive, although I can
find very little information on what exactly should happen when a <code>reference</code>
directive is encountered, <a href="http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf">§11.1.1</a> contains the only
reference to it I can find and simply says</p>
<blockquote>
<p>A comment of the form <code>/// <reference path="…"/></code> adds a dependency on the
source file specified in the path argument. The path is resolved relative to
the directory of the containing source file.</p>
</blockquote>
<p>Anyway, the only sorts of .d.ts files that seem to work well in <code>reference</code>
directives are ones that contain Ambient External Module Declarations
(<a href="http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf">§12.1.6</a>). These declarations do not cause the source
file to be considered an <strong>external module</strong> and instead allow it to be a part
of the <strong>global module</strong> (<a href="http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf">§11.1</a>). When the compiler
later attempts to resolve a top-level external module name (like when resolving
<code>import plexApi = require('plex-api');</code>) then if there is an ambient external
module declaration that matches it will be preferentially returned before
attempting to find a file defining the module (<a href="http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf">§11.2.1</a>).</p>
<p>This works well for definitions pulled in by DefinitelyTyped, since they’re
being handwritten for the modules it’s easy enough to write them as ambient
external module declarations<sup id="fnref:disappointing"><a href="#fn:disappointing" class="footnote">7</a></sup>. For modules generated from .ts
files though this is a problem. It’s a non-trivial conversion to take all the
output .d.ts files and generate them correctly as ambient external module
declarations.</p>
<p>There is still another issue however. Even if you convert the definition files
into ambient external module definitions you start running into dependency
issues. Lets say you are writing another module that depends on the fixed up
plex-api module (which also happens to minify all its JavaScript into index.js).
This module also has to access another ReST service, but it’s such a small
access that they decided not to create a separate client library for this
service and instead write it directly into the module. So as well as depending
on the plex-api module they depend directly on the rest module. The file layout
for this situation would be something like:</p>
<pre><code>my-cool-module
├── node_modules
│ ├── plex-api
│ │ ├── index.d.ts
│ │ ├── index.js
│ │ ├── node_modules
│ │ │ └── rest
│ │ │ ├── index.js
│ │ │ └── package.json
│ │ ├── package.json
│ │ └── typings
│ │ ├── rest
│ │ │ └── rest.d.ts
│ │ └── tsd.d.ts
│ └── rest
│ ├── index.js
│ └── package.json
├── index.ts
└── typings
├── rest
│ └── rest.d.ts
└── tsd.d.ts
</code></pre>
<p>With file contents:</p>
<p><strong><code>my-cool-module/node_modules/plex-api/typings/rest/rest.d.ts</code></strong>: <br />
<strong><code>my-cool-module/typings/rest/rest.d.ts</code></strong>:</p>
<pre><code>declare module "rest" {
// Module declarations
}
</code></pre>
<p><strong><code>my-cool-module/node_modules/plex-api/index.d.ts</code></strong>:</p>
<pre><code>/// <reference path="./typings/tsd.d.ts" />
declare module "plex-api" {
// Module declarations
}
</code></pre>
<p><strong><code>my-cool-module/index.ts</code></strong>:</p>
<pre><code>/// <reference path="./typings/tsd.d.ts" />
/// <reference path="./node_modules/plex-api/index.d.ts" />
// All the cool codes.
</code></pre>
<p>The issue with this is that the two modules will be referencing different files
that both declare the ambient external module “rest”. As soon as the second one
is loaded the compiler will emit a duplicate declaration warning. If instead the
plex-api module were to not distribute its dependency typings you’d get the
opposite issue, any library that uses plex-api would have to include all the
dependencies in its own typings folder.</p>
<p>My next post should have a proposed solution to this issue. For a preview take a
look at <a href="https://github.com/Nemo157/test-d-ts-references">this test github repo</a> and <a href="http://typescript.codeplex.com/SourceControl/network/forks/kayahr/typescript/contribution/6570">this TypeScript pull request</a>.</p>
<hr width="80%" />
<div class="footnotes">
<ol>
<li id="fn:big_new_thing">
<p>Well, at least one of the big new things, and it’s not really that big or
that new, I guess it’s really just a thing. <a href="#fnref:big_new_thing" class="reversefootnote">↩</a></p>
</li>
<li id="fn:xbmc_trakt_remote">
<p>Provided by the <a href="https://chrome.google.com/webstore/detail/xbmc-trakttv-remote/jbdeandglnddkbdnoihonaealomihnkf">XBMC Trakt.TV Remote</a> Chrome extension. <a href="#fnref:xbmc_trakt_remote" class="reversefootnote">↩</a></p>
</li>
<li id="fn:lack_docs">
<p>Other than a complete lack of documentation for the Plex API. <a href="#fnref:lack_docs" class="reversefootnote">↩</a></p>
</li>
<li id="fn:d_ts">
<p>TypeScript Definition files, these allow using node modules written in pure
JavaScript while still retaining type information. <a href="#fnref:d_ts" class="reversefootnote">↩</a></p>
</li>
<li id="fn:lib_tree">
<p>Pretend there’s a whole tree of files under lib, just putting a single file
there makes this example easier. Also likely to be many more typings than
just the rest one. <a href="#fnref:lib_tree" class="reversefootnote">↩</a></p>
</li>
<li id="fn:dont_ask">
<p>Don’t ask me to explain what this means, it’s just based on the source file
and method names that needed changing to workaround this limitation. I might
have more details by the time I post about the solution. <a href="#fnref:dont_ask" class="reversefootnote">↩</a></p>
</li>
<li id="fn:disappointing">
<p>Disappointingly there’s a lot of definitions available that don’t follow
this standard however… <a href="#fnref:disappointing" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>
Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.com1tag:blogger.com,1999:blog-1677317936946499701.post-64631324326542272482013-08-04T12:14:00.000+12:002013-08-04T12:14:58.161+12:00Cocktail Maker: Software Architecture<p>As mentioned earlier the hardware side of the cocktail maker will be controlled
by a Raspberry Pi with a user interface running on an Android tablet. The
Raspberry Pi will make interacting with the valves simple via it’s builtin GPIO
ports while the Android interface will mean we can have a nice touchscreen based
client.</p>
<p>For ease of development the two devices will likely communicate with a RESTlike
API. Luckily enough I’ve recently been working on a major plan at work
involving a substantial bit of work to do with RESTifying our current API. In
both cases this will probably be the popular conception of REST, ignoring the
Hypertext As The Engine Of Application State (HATEOAS) constraint.</p>
<p>There is actually two mostly distinct sets of resources that the server will
have to provide for the client. The majority of the resources will be a generic
collection of cocktails with pictures, descriptions, recipes etc. Then there
will also be the resources specific to the cocktail maker, list of available
ingredients to allow filtering the cocktails, calibration
information<sup id="fnref:viscosity"><a href="#fn:viscosity" class="footnote">1</a></sup>, current processing state, starting and canceling the
current task. The first of these sets is also very widely applicable, anyone
and everyone<sup id="fnref:legal-age"><a href="#fn:legal-age" class="footnote">2</a></sup> could be interested, including other people building
automated cocktail makers.</p>
<p>For that reason I’ve decided to separate the cocktail database from the main
cocktail maker server. I haven’t been able to find any appropriate databases
existing so I’ve taken it upon myself to create the first online crowd-sourced
cocktail database. I’m hoping to have a very basic version up within a few
months, the work on it will obviously be sporadic seeing as it is a part-time
after work project. Actual time frame will probably depend a lot on how much
stuff I get up to in America, if I find there’s not really that much to do in
Austin I may end up spending a large part of most evenings working on
it.<sup id="fnref:music-capital"><a href="#fn:music-capital" class="footnote">3</a></sup></p>
<p>As part of developing this database I do want to experiment with HATEOAS,
especially HATEOAS as implemented via JSON. There are some really good examples
of how to implement it in XML using the <em>rel</em> attribute for metadata about the
resource. There are also a few libraries that do attempt to implement it with
JSON, but just from what little I’ve seen of the libraries something seems off
with them. Once I get some time to research the current libraries, I’ll try and
write a post about what it is that bugs me about them and how I’m going to try
and avoid the issues in my implementation.</p>
<p>In the meantime we’ll probably have a simple hardcoded list of cocktails to use.
Worst case we’ll just be stuck drinking <a href="https://en.wikipedia.org/wiki/Tom_Collins" title="Tom Collins - Wikipedia, the free encyclopedia">Tom Collins</a>’
continuously.<sup id="fnref:could-be-worse"><a href="#fn:could-be-worse" class="footnote">4</a></sup></p>
<hr width="80%" />
<div class="footnotes">
<ol>
<li id="fn:viscosity">
<p>Especially if the pipes flow rate is affected by viscosity, sugar syrup can
be <a href="http://www.vikingpump.com/liquid-list.asp?name=sugar%20syrup" title="sugar syrup - Liquid List \| Viking Pump.com">a few hundred to over a thousand times as viscous as water</a>. <a href="#fnref:viscosity" class="reversefootnote">↩</a></p>
</li>
<li id="fn:legal-age">
<p>Above the legal age for alcohol consumption in their country. <a href="#fnref:legal-age" class="reversefootnote">↩</a></p>
</li>
<li id="fn:music-capital">
<p>What’s the chance of that in The Live Music Capital of the World. <a href="#fnref:music-capital" class="reversefootnote">↩</a></p>
</li>
<li id="fn:could-be-worse">
<p>I could think of much worse things in life than a nigh unlimited supply of
automatically prepared Tom Collins’
<span style="font-size:xx-small">
<a href="http://www.drinksmixer.com/drink2993.html" title="Corkscrew recipe"><em>*Cough*</em>kscrew</a>
</span>. <a href="#fnref:could-be-worse" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>
Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.com2tag:blogger.com,1999:blog-1677317936946499701.post-52490706350786977902013-08-01T20:00:00.000+12:002013-08-01T20:00:48.807+12:00Cocktail Maker: Overview<p>So far these are the components we have:</p>
<div style="margin-left:auto;margin-right:auto;width:516px;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg36JFk455A_7uxjGgJDCBcTNmbirqdxt3YdzNxglvGT0Vp2Vp6IXGWwmGBtLBgYGAnz5NBG5JRuwmcncQlJpZfVBqwqvukZb-_MoAgcz8K7J3c7JCxiGQhUEEEuJvJTNfO2dVXWf-yX_4/s1600/opifex_vocatuum_tubing.jpg"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg36JFk455A_7uxjGgJDCBcTNmbirqdxt3YdzNxglvGT0Vp2Vp6IXGWwmGBtLBgYGAnz5NBG5JRuwmcncQlJpZfVBqwqvukZb-_MoAgcz8K7J3c7JCxiGQhUEEEuJvJTNfO2dVXWf-yX_4/s320/opifex_vocatuum_tubing.jpg" alt="tubing small" /></a>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-k5FLW9FTbnweqGeN32vXey1XDJP9PtioVNsLewaGtT0DZZtbuXeHxO3fR0ckYsFlcZcsU796uSVC-RIAS8rM-R9kVcrY0PIUXyYqnfjU4QUnebXnI0VHXssGw5Hns50B1a-J9YO7lLY/s1600/opifex_vocatuum_valves.jpg"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-k5FLW9FTbnweqGeN32vXey1XDJP9PtioVNsLewaGtT0DZZtbuXeHxO3fR0ckYsFlcZcsU796uSVC-RIAS8rM-R9kVcrY0PIUXyYqnfjU4QUnebXnI0VHXssGw5Hns50B1a-J9YO7lLY/s320/opifex_vocatuum_valves.jpg" alt="valves small" /></a>
</div>
<p>Ten metres of 10mm silicon piping (food grade<sup id="fnref:supposedly"><a href="#fn:supposedly" class="footnote">1</a></sup>) and fifteen solenoid
valves.</p>
<p>The current plan is to have all the spirits and mixers in upside down bottles
above a bench, tubes will come down from these bottles, pass through the valves
then all come together in some form of tap above where you place your glass.
The valves will be controlled by a Raspberry Pi with an Android tablet hooked up
to allow selection of which drink you want.</p>
<div style="margin-left:auto;margin-right:auto;width:518px;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_4LsjcyCjA7wk9ebv59PEf3YM3EQninmIg1i4z3i8Vtc1QaY5ZPJYUXmOfe9n2lNCZK9dDYeAwcwtCPPBUgWAAF5yBlbcLhfnDFg54OAAVlfiCHfR-o-C0r2Q5SPbt7Xmkn78LlFrfa8/s1600/opifex_vocatuum_sketch.jpg"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_4LsjcyCjA7wk9ebv59PEf3YM3EQninmIg1i4z3i8Vtc1QaY5ZPJYUXmOfe9n2lNCZK9dDYeAwcwtCPPBUgWAAF5yBlbcLhfnDFg54OAAVlfiCHfR-o-C0r2Q5SPbt7Xmkn78LlFrfa8/s640/opifex_vocatuum_sketch.jpg" alt="sketch small" /></a>
</div>
<p>It will of course look much fancier than this sketch, personally I’m thinking
some nice dark stained wood with brass fixtures, some form of laser cut drip
tray grate with an icon representing the limitless potential of this device, and
of course only top shelf liquors allowed.</p>
<p>Designing it this way means there is very little mechanical design that needs
doing, really the most complicated part will be ensuring the bottles are held
securely while being easy to replace as they get empty.<sup id="fnref:detect_empty"><a href="#fn:detect_empty" class="footnote">2</a></sup> Which is
all for the best, while we have 3 mechatronics engineers on the project only one
has done any hardware work since leaving uni.</p>
<p>The biggest disadvantage of this is the limitation of only working with liquids.
It would be amazing if we could have ice and garnishes added automatically, but
(at least for the first iteration) we are going to require the user to manually
add these.</p>
<p>Since we won’t have much mechanical design to do we can instead spend longer on
the software side. If we get a really nice client designed for the Android
tablet, complete with all the background info about cocktails and the ability
for the user to adjust the strength on the fly, then this will be re-usable if
(once) we build a version 2 with more capabilities.</p>
<hr width="80%" />
<div class="footnotes">
<ol>
<li id="fn:supposedly">
<p>Supposedly. Not really sure how much you can trust that sort of claim from
cheap online stores. <a href="#fnref:supposedly" class="reversefootnote">↩</a></p>
</li>
<li id="fn:detect_empty">
<p>Although it would be nice if it detected the bottles getting empty and
warned the user of this, or even hook it up to an online store and get it to
order new bottles automatically. <a href="#fnref:detect_empty" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>
Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.com2tag:blogger.com,1999:blog-1677317936946499701.post-34118581444765631162013-07-30T00:03:00.001+12:002013-07-31T23:43:13.770+12:00Opifex Vocatuum<p>So I’ve finally started another project (along with <a href="https://www.facebook.com/daniel.bentall.7">Daniel Bentall</a>, <a href="https://plus.google.com/116522036295292826504/posts">Simon
Richards</a>, and <a href="https://plus.google.com/105587082350852481881/posts">Joshua Jordan</a>) that I’ll attempt to use to kickstart me
actually blogging.<sup id="fnref:third"><a href="#fn:third" class="footnote">1</a></sup> Bet you can’t guess what it is from the
title.<sup id="fnref:declining"><a href="#fn:declining" class="footnote">2</a></sup></p>
<p><span class="spoiler">A cocktail maker!</span> I’ve been wanting to make one of
these for years, ever since I saw one posted somewhere on the interwebs; I want
to say it was on reddit, but I think this was before I’d even discovered
reddit. The only example of a similar device that I can find at the moment is
<a href="https://www.youtube.com/watch?v=hJIkJ9x0-JQ" title="The Inebriator - Arduino Cocktail Machine - Dispensing Signature Cocktail - YouTube">The Inebriator</a>, but that’s a lot more commercialised than what we’re planning
on.</p>
<p>I’m currently planning on posting every 2 or 3 days about this, hopefully it
will promote me to actually keep on working on this steadily. The posts will
generally be quite short,<sup id="fnref:length"><a href="#fn:length" class="footnote">3</a></sup> both so I don’t get too distracted when trying to
finish one and so I have enough material to keep posting with regularly.<sup id="fnref:spree"><a href="#fn:spree" class="footnote">4</a></sup> Coming
up next will be a few posts detailing a broad overview of the system, followed
by the initial section that I’m planning to work on.
<span style="display:none"><sup id="fnref:footnoting"><a href="#fn:footnoting" class="footnote">5</a></sup></span></p>
<hr width="80%" />
<div class="footnotes">
<ol>
<li id="fn:third">
<p>Third time’s the charm, right?<sup id="fnref:footnoting:1"><a href="#fn:footnoting" class="footnote">5</a></sup> <a href="#fnref:third" class="reversefootnote">↩</a></p>
</li>
<li id="fn:declining">
<p>Declining those Latin nouns took far longer than it should, I really need to learn Latin properly someday. <a href="#fnref:declining" class="reversefootnote">↩</a></p>
</li>
<li id="fn:length">
<p>Although probably longer than this one. <a href="#fnref:length" class="reversefootnote">↩</a></p>
</li>
<li id="fn:spree">
<p>How long will my posting spree last this time? Can I beat my current record of one post before dropping a topic. <a href="#fnref:spree" class="reversefootnote">↩</a></p>
</li>
<li id="fn:footnoting">
<p>Shout out to Lauren Wayne for an <a href="http://www.laurenwayne.com/2011/08/how-to-create-footnotes-in-blogger.html" title="How to create footnotes in Blogger">easy way to do footnoting in
Blogger</a>, I’m going to be using this all the time
from now. Adapted it a bit to use an ordered list for nicer formatting of
larger footnotes, but all the essentials are stolen from there. I don’t
think I’m going to last very long doing this by hand though, I should try
and find some way to get Markdown to do it for me. <a href="#fnref:footnoting" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>
Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.com1tag:blogger.com,1999:blog-1677317936946499701.post-83319915936044978502012-07-12T02:01:00.000+12:002012-07-12T02:02:17.576+12:00A history lessonYASL (Yet Another Systems Language) is a language I started quite a while ago, its had some issues actually getting started (my eternal procrastination being a major one) and has been through quite a few transitions from its original design. To try and increase my motivation and actually get some workable designs I’ve decided to start blogging about the design process.<br />
<br />
Because of the way I work this is likely to be a very rambling series of posts, some of my initial thoughts on topics are the polymorphic aspects (including compile and runtime polymorphism), AST macro based design and the work I’ve done on getting a very bare-bones REPL using LLVM and a custom lexer and parser.<br />
<br />
First though I should describe the top level design thoughts behind the language, these are very much open to change as you’ll see from where they were in the original design through to now.<br />
<br />
<h4>
Ancient history</h4>
I first started thinking about YASL around the beginning of the year, according to GitHub Jan 16 was when I committed the first version of my design doc, then Jan 17 I committed some example code to work towards. At this point the main goal of the language was for bare-metal embedded development, a nicer language to use for my home automation projects. This meant that initially one of the aims was to make the language entirely stack-based, when you’re working with a massive 128 bytes of SRAM then you really can’t afford to spend any on heap management. One of the main decisions from this time to survive till now is using LLVM as the backend code generation.<br />
<br />
<h4>
Now</h4>
Since then the goal of the language has definitely changed. There were quite a few reasons behind this; I realised I’m almost certainly not skilled enough in language development to come up with a language that’s nice to write while still being highly optimised for a stack based architecture, I have nowhere near enough experience with LLVM to try to bypass its built in stack management and try to roll my own and LLVM doesn’t yet have good support for any embedded devices instruction set.<br />
<br />
Instead modern YASL is more focused on just being an exploration into a better general purpose language. Hopefully through what I learn doing this I can make another attempt at a beautiful, svelte language specifically optimised for the special challenges of ultra low power embedded development.<br />
<br />
Probably the overriding goal for YASL is to create a language that can support as many nice features as languages such as Ruby, while being as performant in the general case as languages such as C/C#. This will involve ensuring that 90%+ of the language commonly used can be fully reconciled and optimised at compile time, whilst making it possible to easily optimise the remaining 10% at runtime. Unfortunately this will probably mean a big runtime size issue, similar to the pain felt when opening the first .NET application since a restart, hopefully it will be possible to come up with some solutions for this as well. <span id="internal-source-marker_0.4357461387556001"><br />
</span>Anonymoushttp://www.blogger.com/profile/14767550370136403098noreply@blogger.com0