joachimhs

I run a small makerspace for kids and teens in Norway, and we kept hitting the same wall: the 3D tools we tried were either too fiddly for a 9-year-old or locked behind installs and accounts. So I built Akse — a browser-based 3D modeller for beginners, where the path from idea to a printable STL is as short as I could make it.

It's deliberately limited, but with a rather powerfull 2D Blueprint mode where you draw an outline on millimetre paper and extrude it to 3D. You build by placing and combining primitive shapes (box, cylinder, sphere, cone, pyramid, wedge, torus), set any shape to "hole" mode to cut it out of another. Everything is in real millimetres, so what's on screen matches what comes off the printer. Output is a single STL. That's most of it — no parametric constraints, no assemblies, no fillets. For teaching beginners that's intentional, not a gap.

The obvious comparison is Tinkercad — same space (primitive-based, browser, education-oriented), and I'm not claiming Akse is better. The differences are that it's open source, embeddable as a Svelte component, works in Norwegian as well as English, and is even more stripped down. It mostly exists because I wanted something I could shape around how our workshop actually runs, and put in front of Norwegian-speaking kids without an account or install.

Under the hood it's a Svelte 5 component using Three.js for rendering and three-bvh-csg for the boolean operations; storage goes through a small port interface so it's backend-agnostic, and the standalone version just uses localStorage. It's early (v0.1) and has rough edges. I'd really value feedback on where it trips up first-time users, since that's the entire point of the thing.

Source (AGPL-3.0, with a commercial option): github.com/joachimhs/akse3d

This library provides a cache store for Svelte applications that simplifies fetching, creating, updating, and deleting items from a REST API that adheres to the simple-json-api specification. It also supports side-loading of related data and automatic cache management.

I find myself implementing similar backend APIs when I develop applications. These APis are more often than not based on REST principles with JSON payloads. As a result, I have publised the start of a simple JSON API spec at http://simple-json-api.com. This specification makes it easy to write both backend and frontend code to handle the data communication between the applications in a uniform manner. This approach makes it possible to write a fairly small amount of code to get advanced functionality on the frontend-data-layer.

While some good API specifications do exist, this project attempts to provide a common middle-ground being not too complex, while broad enough to not be too specific and too complex.

While, for instance, JSON:API is a thorough specification, Simple JSON API aims to provide a much simplified data-structure leaving the server-side specifics out of the specification. At the same time, while specifications such as JSON Web Key (JWK) is too narrow.

Not a screencast, but the first (free) chapter of Ember.js in Action do have an example that uses local storage: http://manning.com/skeie/

There is also a (non free) chapter about authentication with Mozilla Persona.

You may also find these screencasts useful, though I haven't watched them myself: http://www.embercasts.com

I am currently writing Ember.js in Action (http://manning.com/skeie). This book is, of course, through a traditional publishing company. Combined with the fact that this is my first technical book, my royalty rate is pretty low (10%). This is OK, as the book will reach a wider audience that I would on my own! So far, the book is approaching 2000 units in pre-sales (MEAP - Manning Early Access Programme), which make it the 5th most sold Manning MEAP of 2013 :)

I have started work on my next book project, which will be completely free and open sourced. This book will teach JavaScript programming to kids through building a Raspberry Pi powered remote controlled car (or or other vehicle). The content for this book is not yet available online and most of it will be created through a hands on 7-part course that I am teaching during the spring of 2014. You can find a bit more information about this book here: http://www.indiegogo.com/projects/open-source-programming-bo...

The way I see it, if the content is at all going to be approachable by children aged 11 and up, then that content needs to be well designed, typeset and proofread. While writing an open source book for professionals, pointing them to a set of markdownfiles would suffice if the content is good enough.

The idea is that the design and the content should facilitate children's learning as much as possible.

I could definitely go the publisher route with this, but then the whole project will change characteristics and be less dynamic.

Its not the open source code or project that is important in this project, its really the end result which is content that is easily approachable for the target audience.

Well, that perception assumes that there are only one correct solution, and that there are no grey areas...

Your perception is deterministic, while mine is probabilistic.

I'm sorry you read it that way, but I do not think that I have said, nor hinted, to that at all.

So, you would do most data-processing on the server side. But the data that your client-side application needs you will server to it, most likely via JSON.

You can definately go too far and implement too much on the client side, and this is generally a bad approach.

It's like with anything else. You need to figure out the balance between what you process on the server and what you process on the client.

Thank you for you comments. This is one of the goals that I am trying to achieve through my book-in-progress Ember.js in Action (Manning Publications).

And I do agree. Examples of large-scale applications built with any of the MVC-based frameworks is lacking.

Ember.js is a framework for writing web applications on the client side. This experience, and the end result will be a lot different that the type of web apps that you might be used to writing from the server-side.

I've created my share of Java-based server-side generated web applications, and when it comes to writing applications that run well on the web, JavaScript MVC frameworks are the way to go.

I can't comment on how it might affect your career on either the short of long term, though. That said, I expect that the demand for these types of rich webapps will become larger as we move forward.

I'm turned 22 ten years ago myself, but I think making that statement you made is unfair.

I'm sorry to hear that. The design and operation of InfoQ is out of my hands though :)

You can click to enlarge them, or you can click the link in the figure text to be taken to the correct GitHub revision of the file :)