Josh On DesignArt, Design, and Usability for Software EngineersMon Sep 01 2014 23:40:10 GMT+0000 (UTC)\n60 sec review: The Art of Lego Design<b>The Art of LEGO Design: Creative Ways to Build Amazing Models</b> <p> <i>by Jordan Schwartz</i> </p> <p> </p> <p> <a href=''>No Starch Press</a> is really doubling down on their Lego books. Their latest is a stunner. <a href=''>The Art of Lego Design</a> by Jordan Schwartz is less of an art book and more of a hands on guide. It shows actual techniques used by the Lego artists featured in other No Starch books like Mike Doyle’s <a href=''>Beautiful Lego</a>. </p> <p> As one of the LEGO Group’s youngest staff designers; <a href=''>Jordan Schwartz</a> worked on a number of official LEGO sets. His attention to detail and gift for teaching really come through in the book. Many of the models that seem impossible at first, such as stained glass windows, are actually pretty simple once explained in the book. </p> <p> <i>The Art of Lego Design</i> is the perfect entry point to rabbit hole that is Lego sculpture. With Lego specific jargon like cheese slopes, SNOT (Studs Not On Top), and the Lowell sphere; it would be easy to get lost; but Jordan explains it all clearly, along with general design principles like texture and composition. </p> <p> The book takes the reader through many styles of construction and technical advantages of different pieces, with as dash of Lego history thrown in. I didn’t know there once was a Lego set with a fuzzy bear rug or a line of big Lego people for the Technic sets. </p> <p> </p> <p> Read or Read Not? <b>Read!</b> </p> <p> <a href=''>Get it from No Starch Press</a> </p>\nTypographic Programming: FontsApparently <a href=''>my last post</a> hit <a href=''>HackerNews</a> and I didn’t know it. That’s what I get for not checking my server logs. <p> Going through the comments I see that about 30% of people find it interesting and 70% think I’m an idiot. That’s much better than usual, so I'm going to tempt fate with another installment. The general interest in my post (and let’s face it, typography for source code is a pretty obscure topic of discussion), spurred me to write a follow up. </p> <p> In today’s episode we’ll tour the font themselves. If we want to reinvent computing it’s not enough to grab a typewriter font and call it a day. We have to plan this carefully, and that starts with a good selection of typefaces. </p> <p> </p> <p> Note that I am <i>not</i> going to use color or boxes or any other visual indicators in this post. Not that they aren’t useful, but today I want to see how far we could get with just font styling: typeface, size, weight, and style (italics, small caps, etc.). </p> <p> </p> <p> </p> <p> Since I'm formatting symbolic code, data, and comments; I need a range of typefaces that work well together. I’ve chosen the Source Pro family from Adobe. It is open source and freely redistributable, with a full set of weights and italics. More importantly, it has three main faces: a monospace font: Source Code Pro, a serif font: Source Serif Pro, and a sans-serif font: Source Sans Pro. All three are specifically designed to work together and have a range of advanced glyphs and features. We won't use many of these features today but they will be nice to have in the future. </p> <p> </p> <p> Lets start formatting some code. This will be a gradual process where we chose the basic formatting then build on top for different semantic chunks. </p> <p> For code itself we will stick with the monospace font: Source Code Pro. I would argue that a fixed width font is <i>not</i> actually essential for code, but that’s an argument for another day when we look at indentation. For today we’ll stick with fixed width. </p> <p> </p> <p> Code comments and documentation will use Source Serif Pro. Why? Well, comments don’t need the explicit alignment of a monospace font, so definitely not Source Code Pro. Comments are prose. The sans serif font would work okay but for some reason when I think "text" I think of serifs. It feels more like prose. More <i>texty</i>. </p> <p> So I won’t use Source Sans Pro today but I <i>will</i> save it for future use. Using the Source [x] Pro set gives us that option. </p> <p> Below is a simple JavaScript function set with the default weights of those two fonts. This is the base style we will work from. </p> <p> </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> So that’s a good start but.., I can immediately think of a few improvements. Code (at least in C derived languages) has five main elements: comments, keywords, symbols, literals, and miscellaneous — or what I like to call ‘extraneous cruft’. It’s mainly parenthesis and brackets for delimiting functions and procedure bodies. It is <i>possible</i> to design a language which uses ordering to reduce the need for delimiters, or to be rid of them completely with formatting conventions (as I talked about last week). However, today’s job is to just restyle without changing the code so let’s leave them unmolested for now. Instead we will minimize their appearance by setting them in a thin weight. (All text is still in black, though). </p> <p> Next up is symbols. Symbols the part of a program that the programmer can change. These are arguably the most important part of the program; the parts we spend the most time thinking about, so let’s make them stand out with a very heavy weight: bold 700. </p> <p> </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> </p> <p> Better, but I don’t like how the string literal blends in to with the rest of the code. String literals are almost like prose so let’s show them in serif type, this time with a bolder weight and shrunk a tiny bit (90% of normal). </p> <p> For compatibility I did the same with numeric literals. I’m not sure if ‘null’ is really a literal or a symbol, but you can assign values to it so I’ll call it a literal. </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> Next up is keywords. Keywords are the part of the language that the programmer <i>cannot</i> change. They are strictly defined by the language and completely reserved. Since they are immutable it doesn’t really matter how we render them. I could use a smiley face for the <code>function</code> keyword and the compiler wouldn’t care. It always evaluates to the same thing. However, unlike my 3yr old’s laptop, I don’t have a smiley face key on my computer; so let’s keep the same spelling. I do want to do something unorthodox though. Let’s put the keywords in <i>small caps</i>. </p> <p> </p> <p> Small caps are glyphs the size of lower case letters, but drawn like the upper case letters. To do small caps right you can’t just put your text in upper case and shrink it down. It would look strange. Small caps are actually different glyphs designed to have a similar (but not identical) width and a shorter height. They are hard to generate programmatically. This is one place where a human has to do the hard work. Fortunately we have small caps at our disposal thanks to the great contributions by <a href=''>Logos and type designer Marc Weymann</a>. Open source is a good thing. </p> <p> </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> </p> <p> Now we are getting somewhere. Now the code has a <b>dramatically</b> different feel. </p> <p> </p> <p> There’s one more thing to address: the variables. Are they symbols like function names? Yes, but it feels different than function names. They are also not usually prefixed with a parent object or namespace specifier. Really we have three cases. A fully qualified symbol like ‘baz’ in, the prefix part (, and standalone variables that aren’t qualified at all (like ‘x’). This distinction applies whether or not the symbol is a function or an object reference (it could actually be both in JavaScript). </p> <p> </p> <p> In the end I decided these cases are related but distinct. Standalone symbols have a weight of 400. Technically this is the default weight in CSS and shouldn’t appear to be ‘bold’, but since the base font is super light, regular will feel heavier against it. The symbol at the end of a qualifier chain will also be bold, but with a weight of 700. Finally the prefix part will be italics to further distinguish it. There really isn’t a right answer here; other combinations would work equally well, so I just played around until I found something that felt right. </p> <p> This is the final version: </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> </p> <p> I also shrunk the comments to 80%. Again it just felt right, and serifed fonts are easier to read in longer lines, so the comments can handle the smaller size. </p> <p> </p> <p> Here’s a <a href=''>link to the live mockup</a> in HTML and CSS. This design turned out much better than I originally thought it would. We can do a lot without color and spacing changes. Now imagine what we could do will our full palette of tools. But that will have to wait for next time. </p> <p> </p> <p> BTW, if you submit this to Hacker News or Reddit please let me know <a href=''>via Twitter</a> so I can answer questions. </p>\nTypographic Programming LanguageAllow me to present a simple thought experiment. Suppose we didn’t need to store our code as ASCII text on disk. Could we change the way we write -- and more importantly <i>read</i> -- symbolic code? Let’s assume we have a magic code editor which can read, edit, and write anything we can imagine. Furthermore, assume we have a magic compiler which can work with the same. What would the ideal code look like? <p> Well, first we could get rid of delimiters. Why do we even have them? Our sufficiently stupid compilers. </p> <p> Delimiters like quotes are there to let the compiler know when a symbol ends and a literal begins. That’s also why variables can’t start with a number; the compiler wouldn’t know if you meant a variable name or a numeric literal. What if we could distinguish between then using typography instead: </p> <p> Here’s an example. </p> <p> <img src='' alt='text'/> </p> <p> This example is semantically equivalent to: </p> <pre><code>print "The cats are hungry."; //no quotes or parens are needed</code></pre> <p> Rendering the literal inside a special colored box makes it more readable than the plain text version. We live in the 21st century. We have more typographic options than quotes! Let’s use them. A green box is but one simple option. </p> <p> Let’s take the string literal example further: </p> <p> <img src='' alt='text'/> </p> <p> Without worrying about delimiting the literals we don’t need extra operators for concatenation; just put them inline. In fact, there becomes no difference between string concatenation and variable interpolation. The only difference is how we choose to render them on screen. Number formatting can be shown inline as well, but visually separate by putting the format control in a gray box. </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> Also notice that comments are rendered in an entirely different font, and pushed to the side (with complete Unicode support, of course). </p> <p> Once we’ve gone down the road of showing string literals differently we could do the same with numbers. </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> </p> <p> Operators are still useful of course, but only when they represent a real mathematical operation. It turns out there is a separate glyph for multiplication, it’s not just an x, but it’s still visually confusing. Maybe a proper dot would be better. </p> <p> Since some numbers are actually units, this hypothetical language would need separate types for those units. They could be rendered as prose by using common metric abbreviations. </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> In a sense, a number with units really is a different thing than plain numbers. It’s nice for the programming language to recognize that. </p> <p> As long as we are going to have special support for numeric and string literals, why not go all the way: </p> <p> Color literals </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> Image literals </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> Byte arrays </p> <p> <img src='' alt='text'/> </p> <p> </p> <p> If our IDEs really understood the concepts represented in the language then we could write highly visual but still symbolic code. If only our compilers were <a href=' '>sufficiently smart</a>. </p> <p> </p> <p> I’m not saying we should actually code this way but thought experiments are a good way to find new ideas; ideas that we could then apply to our existing programming systems. </p>\nBuilding a Headline Viewer with AminoThis is part 3 of a series on <a href=''>Amino</a>, a JavaScript graphics library for OpenGL on the Raspberry PI. You can also read <a href=''>part 1</a> and <a href=''>part 2</a>. <p> Amino is built on <a href=''>Node JS</a>, a robust JavaScript runtime married to a powerful IO library. That’s nice and all, but the real magic of Node is the modules. For any file format you can think of someone has probably written a Node module to parse it. For any database you might want use, someone has made a module for it. <a href=''></a> lists nearly ninety thousand packages! That’s a lot of modules ready for you to use. </p> <p> For today’s demo we will build a nice rotating display of news headlines that could run in the lobby of an office using a flatscreen TV on the wall. It will look like this: </p> <p> <img src='' alt='image'/> </p> <p> </p> <p> We will fetch news headlines as RSS feeds. Feeds are easy to parse using Node streams and the <code>feedparser</code> module. Lets start by creating a <code>parseFeed</code> function. This function takes a url. It will load the feed from the url, extract the title of each article, then call the provided callback function with the list of headlines. </p> <pre><code>var FeedParser = require('feedparser'); var http = require('http'); function parseFeed(url, cb) { var headlines = []; http.get(url, function(res) { res.pipe(new FeedParser()) .on('meta',function(meta) { //console.log('the meta is',meta); }) .on('data',function(article) { console.log("title = ", article.title); headlines.push(article.title); }) .on('end',function() { console.log("ended"); cb(headlines); }) }); }</code></pre> <p> Node uses <i>streams</i>. Many functions, like the <code>http.get()</code> function, return a stream. You can pipe this stream through a filter or processor. In the code above we use the <code>FeedParser</code> object to filter the HTTP stream. This returns a new stream which will produce events. We can then listen to the events as the data flows through the system, picking up just the parts we want. In this case we will watch for the <code>data</code> event, which provides the article that was just parsed. Then we add just the title to the <code>headlines</code> array. When the <code>end</code> event happens we send the headlines array to the callback. This sort of streaming IO code is very common in Node programs. </p> <p> Now that we have a list of headlines lets make a display. We will hard code the size to 1280 x 720, a common HDTV resolution. Adjust this to fit your own TV if necessary. As before, the first thing we do is turn the titles into a CircularBuffer (see <a href=''>previous blog</a> ) and create a root group. </p> <pre><code>var amino = require('amino.js'); var sw = 1280; var sh = 720; parseFeed('',function(titles) { amino.start(function(core, stage) { var titles = new CircularBuffer(titles); var root = new amino.Group(); stage.setSize(sw,sh); stage.setRoot(root); …</code></pre> <p> The RSS feed will be shown as two lines of text, so let’s create a text group then two text objects. Also create a background group to use later. Shapes are drawn in the order they are added, so we have to add the <code>bg</code> group <b>before</b> the textgroup. </p> <pre><code> var bg = new amino.Group(); root.add(bg); var textgroup = new amino.Group(); root.add(textgroup); var line1 = new amino.Text().x(50).y(200).fill("#ffffff").text('foo').fontSize(80); var line2 = new amino.Text().x(50).y(300).fill("#ffffff").text('bar').fontSize(80); textgroup.add(line1,line2);</code></pre> <p> Each Text object has the same position, color, and size except that one is 100 pixels lower down on the screen than the other. Now we need to animate them. </p> <p> The animation consists of three sections: set the text to the current headline, rotate the text in from the side, then rotate the text back out after a delay. </p> <p> In the <code>setHeadlines</code> function; if the headline is longer than the max we support (currently set to 34 letters) then chop it into pieces. If we were really smart we’d be careful about not breaking words, but I’ll leave that as an exercise to the reader. </p> <pre><code> function setHeadlines(headline,t1,t2) { var max = 34; if(headline.length > max) { t1.text(headline.substring(0,max)); t2.text(headline.substring(max)); } else { t1.text(headline); t2.text(''); } }</code></pre> <p> The <code>rotateIn</code> function calls <code>setHeadlines</code> with the next title, then animates the Y rotation axis from 220 degrees to 360 over two seconds (2000 milliseconds). It also triggers <code>rotateOut</code> when it’s done. </p> <pre><code> function rotateIn() { setHeadlines(,line1,line2); textgroup.ry.anim().from(220).to(360).dur(2000).then(rotateOut).start(); }</code></pre> <p> A quick note on rotation. Amino is fully 3D so in theory you can rotate shapes in any direction, not just in the 2D plane. To keep things simple the <code>Group</code> object has three rotation properties: <code>rx</code>, <code>ry</code>, and <code>rz</code>. These each rotate <b>around</b> the x, y, and z axes. The x axis is horizontal and fixed to the top of the screen, so rotating around the x axis would flip the shape from top to bottom. The y axis is vertical and on the left side of the screen. Rotating around the y axis flips the shape left to right. If you want to do a rotation that looks like the standard 2D rotation, then you want to go around the Z axis with <code>rz</code>. Also note that all rotations are in <i>degrees</i>, not radians. </p> <p> The <code>rotateOut()</code> function rotates the text group back out from 0 to 140 over two seconds, then triggers <code>rotateIn</code> again. Since each function triggers the other they will continue to ping pong back and forth forever, pulling in a new headline each time. Notice the <code>delay()</code> call. This will make the animation wait five seconds before starting. </p> <pre><code> function rotateOut() { textgroup.ry.anim().delay(5000).from(0).to(140).dur(2000).then(rotateIn).start(); }</code></pre> <p> Finally we can start the whole shebang off back calling rotateIn the first time. </p> <pre><code> rotateIn();</code></pre> <p> What we have so far will work just fine but it’s a little boring because the background is pure black. Let’s add a few subtly moving rectangles in the background. </p> <p> First we will create the three rectangles. They are each fill the screen and are 50% translucent, in the colors red, green, and blue. </p> <pre><code> //three rects that fill the screen: red, green, blue. 50% translucent var rect1 = new amino.Rect().w(sw).h(sh).opacity(0.5).fill("#ff0000"); var rect2 = new amino.Rect().w(sw).h(sh).opacity(0.5).fill("#00ff00"); var rect3 = new amino.Rect().w(sw).h(sh).opacity(0.5).fill("#0000ff"); bg.add(rect1,rect2,rect3);</code></pre> <p> Now let’s move the two back rectangles off the left edge of the screen. </p> <pre><code> //animate the back two rects rect1.x(-1000); rect2.x(-1000);</code></pre> <p> Finally we can slide them from left to right and back. Notice that these animations set <code>loop</code> to -1 and <code>autoreverse</code> to 1. The loop count sets how many times the animation will run. Using <code>-1</code> makes it run forever. The autoreverse property makes the animation alternate direction each time. Rather than going from left to right and starting over at the left again, instead it will go left to right then right to left. Finally the second animation has a five second delay. This staggers the two animations so they will always be in different places. Since all three rectangles are translucent the colors will continually mix and change as the rectangles slide back and forth. </p> <pre><code> rect1.x.anim().from(-1000).to(1000).dur(5000) .loop(-1).autoreverse(true).start(); rect2.x.anim().from(-1000).to(1000).dur(3000) .loop(-1).autoreverse(true).delay(5000).start();</code></pre> <p> Here’s what it finally looks like. Of course a still picture can’t do justice to the real thing. </p> <p> <img src='' alt='image'/> </p> <p> </p> <p> <img src='' alt='image'/> </p>\nPhoto Slideshow in AminoThis is the second blog in a series about Amino, a Javascript OpenGL library for the Raspberry Pi. The first post is <a href=''>here</a>. <p> This week we will build a digital photo frame. A Raspberry PI is perfect for this task because it plugs directly into the back of a flat screen TV through HDMI. Just give it power and network and you are ready to go. </p> <p> Last week I talked about the new Amino API built around properties. Several people commented that I didn’t say how to actually get and run Amino. Very good point! Let’s kick things off with an install-fest. These instructions assume you are running Raspbian, though pretty much any Linux distro should work. </p> <p> Amino is fundamentally a Node JS library so first you’ll need Node itself. Fortunately, installing Node is far easier than it used to be. In brief, update your system with <code>apt-get</code>, download and unzip Node from <code></code>, and add <code>node</code> and <code>npm</code> to your path. Verify the installation with <code>npm —version</code>. I wrote full instructions <a href=''>here</a> </p> <p> Amino uses some native code, so you’ll need <b>Node Gyp</b> and <b>GCC</b>. Verify GCC is installed with <code>gcc —version</code>. Install node-gyp with <code>npm install -g node-gyp</code>. </p> <p> Now we can checkout and compile Amino. You’ll also need Git installed if you don’t have it. </p> <pre><code>git clone cd aminogfx node-gyp clean configure --OS=raspberrypi build npm install node build desktop export NODE_PATH=build/desktopnode tests/examples/simple.js</code></pre> <p> This will get the amino source, build the native parts, then build the Javascript parts. When you run <code>node tests/examples/simple.js</code> you should see this: </p> <p> <img src='' alt='image'/> </p> <p> </p> <p> </p> <p> Now let’s build a photo slideshow. The app will scan a directory for image, then loop through the photos on screen. It will slide the photos to the left using two ImageViews, one for the outgoing image and one for the incoming, then swap them. First we need to import the required modules. </p> <pre><code>var amino = require('amino.js'); var fs = require('fs'); var Group = require('amino').Group; var ImageView = require('amino').ImageView;</code></pre> <p> Technically you could call <code>amino.Group()</code> instead of importing <code>Group</code> separately, but it makes for less typing later on. </p> <p> Now let’s check that the user specified an input directory. If so, then we can get a list of images to load. </p> <pre><code>if(process.argv.length &lt; 3) { console.log("you must provide a directory to use"); return; } var dir = process.argv[2]; var filelist = fs.readdirSync(dir).map(function(file) { return dir+'/'+file; });</code></pre> <p> So far this is all straight forward Node stuff. Since we are going to loop through the photos over and over again we will need an index to increment through the array. When the index reaches the end it should wrap around to the beginning, and handle the case when new images are added to the array. Since this is a common operation I created a utility object with a single function: <code>next()</code>. Each time we call <code>next</code> it will return the next image, automatically wrapping around. </p> <pre><code>function CircularBuffer(arr) { this.arr = arr; this.index = -1; = function() { this.index = (this.index+1)%this.arr.length; return this.arr[this.index]; } } //wrap files in a circular buffer var files = new CircularBuffer(filelist);</code></pre> <p> Now lets set up a scene in Amino. To make sure the threading is handled properly you must always pass a setup function to <code>amino.start()</code>. It will set up the graphics system then give you a reference to the <code>core</code> object and a <code>stage</code>, which is the window you can draw in. (Technically it’s the contents of the window, not the window itself). </p> <pre><code>amino.start(function(core, stage) { stage.setSize(800,600); var root = new Group(); stage.setRoot(root); var sw = stage.getW(); var sh = stage.getH(); //create two image views var iv1 = new ImageView().x(0); var iv2 = new ImageView().x(1000); //add to the scene root.add(iv1,iv2); … };</code></pre> <p> The setup function above sets the size of the stage and creates a Group to use as the root of the scene. Within the root it adds two image views, <code>iv1</code> and <code>iv2</code>. </p> <p> The images may not be the same size as the screen so we must scale them. However, we can only scale once we know how big the images will be. Furthermore, the image view will hold different images as we loop through them, so we really want to recalculate the scale every time a new image is set. To do this, we will watch for changes to the image property of the image view like this. </p> <pre><code> //auto scale them with this function function scaleImage(img,prop,obj) { var scale = Math.min(sw/img.w,sh/img.h);; } // call scaleImage whenever the image property changes;; //load the first two images iv1.src(; iv2.src(;</code></pre> <p> Now that we have two images we can animate them. Sliding images to the left is as simple as animating their <code>x</code> property. This code will animate the x position of <code>iv1</code> over 3 seconds, starting at <code>0</code> and going to <code>-sw</code>. This will slide the image off the screen to the left. </p> <pre><code>iv1.x.anim().delay(1000).from(0).to(-sw).dur(3000).start();</code></pre> <p> To slide the next image onto the screen we do the same thing for iv2, </p> <pre><code>iv2.x.anim().delay(1000).from(sw).to(0).dur(3000)</code></pre> <p> However, once the animation is done we want to swap the images and move them back, so let’s add a <code>then(afterAnim)</code> function call. This will invoke <code>afterAnim</code> once the second animation is done. The final call in the chain is to the <code>start()</code> function. Until <code>start</code> is called nothing will actually be animated. </p> <pre><code> //animate out and in function swap() { iv1.x.anim().delay(1000).from(0).to(-sw).dur(3000).start(); iv2.x.anim().delay(1000).from(sw).to(0).dur(3000) .then(afterAnim).start(); } //kick off the loop swap();</code></pre> <p> The <code>afterAnim</code> function moves the ImageViews back to their original positions and moves the image from <code>iv2</code> to <code>iv1</code>. Since this happens between frames the viewer will never notice anything has changed. Finally it sets the source of <code>iv2</code> to the next image and calls the <code>swap()</code> function to loop again. </p> <pre><code> function afterAnim() { //swap images and move views back in place iv1.x(0); iv2.x(sw); iv1.image(iv2.image()); // load the next image iv2.src(; //recurse swap(); }</code></pre> <p> A note on something a bit subtle. The <code>src</code> of an image view is a string, either a url of file path, which refers to the image. The <code>image</code> property of an ImageView is the actual in memory image. When you set the <code>src</code> to a new value the ImageView will automatically load it, then set the <code>image</code> property. That’s why we added a watch function to the <code>iv1.image</code> not <code>iv1.src</code>. </p> <p> Now let’s run it, the last argument is the path to a directory containing some JPGs or PNGs. </p> <pre><code>node demos/slideshow/slideshow.js demos/slideshow/images</code></pre> <p> If everything goes well you should see something like this: </p> <p> <img src='' alt='image'/> </p> <p> By default, animations will use a cubic interpolator so the images will start moving slowly, speed up, then slow down again when they reach the end of the transition. This looks nicer than a straight linear interpolation. </p> <p> So that’s it. A nice smooth slideshow in about 80 lines of code. By removing comments and utility functions we could get it under 40, but this longer version is easier to read. </p> <p> Here is the final complete code. It is also in the git repo under demos/slideshow. </p> <pre><code>var amino = require('amino.js'); var fs = require('fs'); var Group = require('amino').Group; var ImageView = require('amino').ImageView; if(process.argv.length &lt; 3) { console.log("you must provide a directory to use"); return; } var dir = process.argv[2]; var filelist = fs.readdirSync(dir).map(function(file) { return dir+'/'+file; }); function CircularBuffer(arr) { this.arr = arr; this.index = -1; = function() { this.index = (this.index+1)%this.arr.length; return this.arr[this.index]; } } //wrap files in a circular buffer var files = new CircularBuffer(filelist); amino.start(function(core, stage) { stage.setSize(800,600); var root = new Group(); stage.setRoot(root); var sw = stage.getW(); var sh = stage.getH(); //create two image views var iv1 = new ImageView().x(0); var iv2 = new ImageView().x(1000); //add to the scene root.add(iv1,iv2); //auto scale them function scaleImage(img,prop,obj) { var scale = Math.min(sw/img.w,sh/img.h);; };; //load the first two images iv1.src(; iv2.src(; //animate out and in function swap() { iv1.x.anim().delay(1000).from(0).to(-sw).dur(3000).start(); iv2.x.anim().delay(1000).from(sw).to(0).dur(3000) .then(afterAnim).start(); } swap(); function afterAnim() { //swap images and move views back in place iv1.x(0); iv2.x(sw); iv1.image(iv2.image()); iv2.src(; //recurse swap(); } });</code></pre> <p> Thank you and stay tuned for more Amino examples on my blog. </p> <p> <a href=''>Amino repo</a> </p>\nAmino: RefactoredI’ve been working on <a href=''>Amino</a>, my graphics library, for several years now. I’ve ported it from pures Java, to JavaScript, to a complex custom-language generator system (I was really into code-gen two years ago), and back to JS. It has accreted features and bloat. And yet, through all that time, even with blog posts and the <a href=''></a> website, I don’t think anyone but me has ever used it. I had accepted this fact and continued tweaking it to meet my personal needs; satisfied that I was creating something that lets me build other useful things. Until earlier this year. <p> </p> <h3 id="id99617">OSCON</h3> <p> In January I thought to submit a session to OSCON entitled <a href=''>Data Dashboards with Amino, NodeJS, and the Raspberry Pi</a>. The concept was simple: Raspberry Pis are cheap but with a surprisingly powerful GPU. Flat screen TVs are also cheap. I can get a <a href=''>32in model at Costco</a> for 200$. Combine them with a wall mount and you have a cheap data dashboard. Much to my shock the talk was accepted. </p> <p> The session at OSCON was very well attended, proving there is clearly interest in Amino, at least on the Raspberry Pi. The demos I was able to pull off for the talk show that Amino is powerful enough to really push the Pi. My final example was an over the top futuristic dashboard for 'Awesomonium Levels', clearly at home in every super villain’s lair. If Amino can pull this off then it’s found it’s niche. X windows and browsers are so slow on the Pi that people are willing to use something different. </p> <p> <img src='' alt='globe'/> </p> <p> </p> <h3 id="id35359">Refactoring</h3> <p> However, Amino still needs some work. While putting the demos together for my session a noticed how inefficient the API is. I’ve been working on Amino in various forms for at least 3 years, so the API patterns were set quite a while ago. The objects full of getters and setters clearly reflect my previous Java background. Not only have I improved my Javascript skills since then, I have read a lot about functional programming styles lately (book reports coming soon). This let me finally see ways to improve the API. </p> <p> Much like any other UI toolkit, the core of the Amino API has always been a tree of nodes. Architecturally there are actually two trees, the Javascript one you interact with and the native one that actually makes the OpenGL calls; however the native one is generally hidden away. </p> <p> Since I came from a Java background I started with an object full of properties accessed with getters and setters. While this works, the syntax is annoying. You have to type the extra get/set words and remember to camel case the property names. Is the font name set with setFontName or setFontname? Because the getter and setter functions were just functions there was no place to access the property as a single object. This means other property functions have to be controlled with a separate API. To animate a property you must refer to it indirectly with a string, like this: </p> <pre><code>var rect = new amino.ProtoRect().setX(5); var anim = core.createPropAnim(rect,’x’,0,100,1000);</code></pre> <p> Not only is the animation configured through a separate object (core) but you have to remember the exact order of the various parameters for starting and end values, duration, and the property name. Amino needs a more fluent API. </p> <p> </p> <h3 id="id381">Enter Super Properties</h3> <p> After playing with Javascript native getters and setters for a bit (which I’ve determined have no real use) I started looking at the JQuery API. A property can be represented by a single function which both gets and sets depending on the arguments. Since functions in Javascript are also objects, we can attach extra functionality to the function itself. Magic behavior like binding and animation. The property itself becomes the natural place to put this behavior. I call these super properties. Here’s what they look like. </p> <p> </p> <p> To get the x property of a rectangle </p> <pre><code>rect.x()</code></pre> <p> to set the x property of a rectangle: </p> <pre><code>rect.x(5);</code></pre> <p> the setter returns a reference to the parent object, so super properties are chain able: </p> <pre><code>rect.x(5).y(5).w(5);</code></pre> <p> This syntax is already more compact than the old one: </p> <pre><code>rect.setX(5).setY(5).setWidth(5);</code></pre> <p> The property accessor is also an object with it’s own set of listeners. If I want to know when a property changes I can <i>watch</i> it like this: </p> <pre><code> { console.log(“x changed to “+val); });</code></pre> <p> Notice that I am referring to the accessor as an object <b>without</b> the parenthesis. </p> <p> Now that we can watch for variable changes we can also bind them together. </p> <pre><code>rect.x.bindto(otherRect.x);</code></pre> <p> If we combine binding with a modifier function, then properties become very powerful. To make rect.x always be the value of otherRect.x plus 10: </p> <pre><code>rect.x.bindto(otherRect.x, function(val) { return val + 10; });</code></pre> <p> Modifier functions can be used to convert types as well. Let’s format a string based on a number: </p> <pre><code>label.text.bindto(rect.x, function(val) { return “The value is “ + val; });</code></pre> <p> Since Javascript is a functional language we can improve this syntax with some meta-functions. This example creates a reusable string formatter. </p> <pre><code>function formatter(str) { return function(val) { return str.replace(‘%’,val); } } label1.text.bindto(rect.x, formatter(‘the x value is %’)); label2.text.bindto(rect.y, formatter(‘the y value is %’));</code></pre> <p> Taking a page out of JQuery’s book, I added a find function to the Group object. It returns a selection with proxies the properties to the underlying objects. This lets me manipulate multiple objects at once. </p> <p> Suppose I have a group with ten rectangles. Each has a different position but they should all be the same size and color: </p> <pre><code>group.find(‘Rect’).w(20).h(30).fill(‘#00FF00’);</code></pre> <p> Soon Amino will support searching by CSS class and ID selectors. </p> <p> </p> <h3 id="id96808">Animation</h3> <p> Lets get back to animation for a second. The old syntax was like this: </p> <pre><code>var rect = new amino.ProtoRect().setX(5); var anim = core.createPropAnim(rect,’x’,0,100,1000);</code></pre> <p> Here is the new syntax: </p> <pre><code>var rect = new Rect().x(5); rect.x.anim().from(0).to(100).dur(1000).start();</code></pre> <p> We don’t need to pass in the object and property because the <code>anim</code> function is already attached to the property itself. Chaining the functions makes the syntax more natural. The <code>from</code> and <code>dur</code> functions are optional. If you don’t specifiy them the animation will start with the current value of the property (which is usually what you wanted anyway) and a default duration (1/4 sec). Without those it looks like: </p> <pre><code>rect.x.anim().to(100).start();</code></pre> <p> Using a start function makes the animation behavior more explicit. If you don’t call <code>start</code> then the animation doesn’t start. This lets you set up and save a reference to the animation to be used later. </p> <pre><code>var anim = rect.x.anim().from(-100).to(100).dur(1000).loop(5); //some time later anim.start();</code></pre> <p> Delayed start also lets us add more complex animation control in the future, like chained or parallel animations: </p> <pre><code>Anim.parallel([ rect.x.anim().to(1000), circle.radius.anim().to(50), group.y.anim().from(50).to(100) ]).start();</code></pre> <p> I’m really happy with the new syntax. Simple functions built on a common pattern of objects and super properties. Not only does this make a nicer syntax, but the implementation is cleaner as well. I was able to deleted about a third of Amino’s JavaScript code! That’s an all-round win! </p> <p> Since this changes Amino so much I’ve started a new repo for it. The old amino is still available at: </p> <p> <a href=''></a> </p> <p> The new amino, the only one you should be using, is at: </p> <p> <a href=''></a> </p> <p> </p> <p> That’s it for today. Next time I’ll show you how to build a full screen photo slideshow with the new animation API and a circular buffer. After that we’ll dig into 3D geometry and make a cool spinning globe. </p>\nElectron 0.3 Released I’m happy to announce the release of Electron 0.3. While there are a few under the hood improvements, the big news is a <b>brand new user interface</b>. We’ve rewritten the UI <i>from scratch</i> using Angular JS. This will make Electron more stable and easier to improve in the future. <p> </p> <h3 id="id75785">New UI features:</h3> <p> </p> <ul><li>a proper file browser on the left, with collapsing folders</li> <li>collapsing resizable panels.</li> <li>New dialogs to search for boards and libraries</li> <li>new fonts (Source Sans Pro, Source Serif Pro, and Source Code Pro)</li> <li>proper multiple tabs for editing source files</li> </ul> <p> </p> <p> </p> <h3 id="id7301">Boards and Libs</h3> <p> The data repo has added support for </p> <p> </p> <ul><li>Adafruit Trinket & Gemma,</li> <li>Flora,</li> <li>timer libs</li> <li>Arduino Yun</li> <li>Esplora</li> <li>DigiSpark Tiny / Pro (buggy)</li> <li>Fio</li> </ul> <p> </p> <p> </p> <h3 id="id10467">Broken Stuff</h3> A few things that worked before are now broken, so be aware: <p> </p> <ul><li>serial console (filled with mockup text)</li> <li>docs viewer (filled with mockup text)</li> <li>'+'/'-' buttons for creating/deleting sketches</li> </ul> <p> </p> <h3 id="id56701">Thanks to contributors:</h3> <p> </p> <ul><li>Alan Holding</li> <li>Nick Oliver</li> <li>Walter Lapchynski</li> </ul> <p> The next release (in a few weeks, hopefully) will focus only on bug fixes and app-izing Electron to have only a single download (no git required). </p> <p> We need your help testing for the next release. <a href=''>Please file your kudos, bugs, and requests here</a>. </p> <p> Thanks, Josh </p>\n60s Book Review: TinkerCad <p> <a href=''>TinkerCad</a> is a free web based CAD program. It runs entirely in the browser using <a href=''>WebGL</a>, so you’ll probably want to use it with Chrome (I think Safari may work in Yosemite+). TinkerCad is meant for novice CAD users. So novice that you can know absolutely nothing about CAD and be able to make something after five minutes of their built in learning quests (tutorials). Then you an save your creation to their cloud or download it for 3D printing. </p> <p> TinkerCad isn’t full featured. You can’t add chamfered edges for example, but you can combine shapes with CSG operations, stretch and rotate them, and add useful prefab shapes like letters and stars. There is even a scripting language for building programmatic objects. The UI challenge of building a CAD for newbies is daunting, yet somehow they did it. TinkerCad almost went out of business since it turns out novice users are also unlikely to pay for CAD applications. Fortunately AutoDesk bought them and have made TinkerCad their free entry level offering. </p> <p> But this is a book review, right? <a href=''>3D Modeling and Printing with TinkerCad</a> is a new book by James Floyd Kelly. it walks you through the basics of navigation, creating shapes, merging and subtracting them, all the way to printing models and importing them into Minecraft. The book is very well written and easy to follow with lots of pictures. </p> <p> So should you buy it? That depends. TinkerCad’s own interactive tutorials are quite good. While I enjoyed the book I’d say 75% of it covers the same things you’ll learn in the tutorials. It really comes down to whether you are more comfortable learning on screen or by reading a paper book. If you learn by paper, then buy it. </p> <p> <a href=''>3D Modeling and Printing with Tinkercad: Create and Print Your Own 3D Models, James Floyd Kelly</a> </p> <p> </p>\nElectron Updates <p> Now that OSCON is over I can get back to working on Electron. That means a new version is coming, and by far the biggest change will be a brand new user interface. I had posted an early preview <a href=''>here</a> but that's now completely out of date. You see, I discovered a new framework. </p> <p> Currently Electron is built from two main components. The backend end is NodeJS code. This is the part that actually compiles and uploads your Arduino code. The front end is HTML and JavaScript. This is the part you actually interact with: editor, debugging, clicking the compile button, choosing boards, etc. Currently the UI is written in plain HTML with Bootstrap and JQuery. Sadly, this form of development won't scale. JQuery is great for manipulating a few DOM objects but it just doesn't scale up to a full app. I had considered a few UI frameworks like JQuery UI but several people at OSCON mentioned Angular JS. When I got home I bought a book from O'Reilly and built a few prototypes. I'm so glad that I did. </p> <p> Angular isn't a set of widgets. It's a JavaScript modules framework with data binding. With Angular I can break Electron up into proper reusable, testable components. It also handles much of the data update boilerplate I previously wrote by hand. </p> <p> After two days I've completely rewritten the UI in Angular. Almost everything that worked before works in the new UI. The switch over went smoothly thanks to the backend being done entirely with REST requests. I can actually run both the old and new UIs at the same time. </p> <p> Here is a screenshot of what the new version looks like. </p> <p> <img src='' alt='preview'/> </p> <p> Some time next week I should have v0.3 released. After that the focus will be entirely on integrating Atom-Shell so that you don't need the command line at all. You'll be able to just download a proper app binary like any other desktop program. </p> <p> Oh yeah, and we had a BOF at OSCON on Electron. I got lots of good feedback that will work it's way into the first post 1.0 release. </p> <p> And one more thing... </p> <p> If you live here in Eugene I'll be doing an Electron presentation at <a href=''>this week's Eugene Linux User's Group</a> . </p> <p> </p>\n60 Sec Book Review: Physics of the ImpossibleMichio Kaku, the science popularizer and theoretical physicist, is always a wonderful speaker. I’ve greatly enjoyed his TED talks. In <i>Physics of the Impossible</i> he takes on the many improbable technologies of science fiction to determine if they are in fact impossible. Surprisingly, few truly are. He divides technologies into three levels of impossible: likely today or in the next 20 years with existing science (ex: replicators), likely in the next hundred or so without violating any known laws of physics (shockingly, time travel is in this bunch), and the truly impossible without some new laws of physics. There are very few things in the last category. It’s an easy read and lots of fun. <p> Should you read it? <b>Yes!</b> </p> <p> <a href=''>Physics of the Impossible: A Scientific Exploration into the World of Phasers, Force Fields, Teleportation, and Time Travel, by Michio Kaku</a> </p> <p> </p> <p> <a href=''>Dr. Kaku on the Daily Show</a> </p> <p> </p> <p> </p> <p> </p>