d1plo1d

er.. sorry what? Squirt is using plain text HTTP. This is definitely a bad thing.

From Chrome Dev Tools:

"..was loaded over HTTPS, but ran insecure content from 'http://www.squirt.io/bm/squirt.js': this content should also be loaded over HTTPS."

WebGL strikes me as a much more likely and more open HTML5/Native hybridized future. I don't doubt there will be other hybrid technologies but I think WebGL is the first one that's here to stay.

To clarify: I mean open as in open web here; that is to say that the WebGL GLSL code that gets compiled to run on the GPU is human readable when embedded in a website. AFAIK this is not the the case with NaCL or PNaCL.

Moving back to adoption, NaCL has only currently been adoption by Chrome and Mozilla does not seem particularly interested in changing that.

Related:

* http://css.dzone.com/articles/mozilla-rejects-native-code

* http://news.ycombinator.com/item?id=4630057

Well they did say that they were working on fixing the speed of concurrent requests for rails on their platform. While that is vague it would point to them actively working on a solution.

Regardless, this is a problem of web applications at scale. Personally, I've never had to scale an app above 2 dynamos. So I will continue to use their service since it works as advertised for the domain of small startups that are not yet at scale. The work of porting from Heroku to AWS is work that I would have to put in anyways so I see no reason to waist that time any earlier in a project then I have to. Sure moving the db will be a pain but it's something I'm willing to live with.

The bit where they mention their working on concurrency:

Working to better support concurrent-request Rails apps on Cedar

There is however the problem that historically they have not keep a copy of the old docs online. So if you stick to 2.2.2 your probably going to be SOL when it comes to reference info.

Sure there is an archive somewhere of the old docs but that is a long way from ideal.

> JS MVC frameworks: MVC in JS is almost always overkill.

Unless your bread and butter is modern web apps (ie. json driven sites with websockets/long polling) which, at least in my neck of the woods, seem to be rapidly becoming the norm.

Without backbone.js it would not be possible for me to do any of my current client's projects on the timelines I'm doing them, simple as that.

That said, learning every client-side mvc is probably a mistake too. Just research them and learn the one that you feel is best.

To Stratasys $10k is probably already the Honda Civic of 3D printers.

To go with an entirely different analogy, Stratasys is the old, lumbering baron of 3d printing. Conversely, RepRap, Makerbot, Ultimaker, MakerGear, Type A and now Panda Robotics are all the agile, new kids who were raised on a healthy diet of open source. Having invaded the Barons lands they are now zipping around rearranging the Baron's fiefdom at 100km/h and generally trying every way of doing everything all at once. My bet is firmly on the new guys, how they'll divide the spoils once Stratasys has been finally overwhelmed by all this chaos is the bit I'm curious about.

The Prusa Mendel sells for $799 on Makergear and can print at 1/10 the layer height of a Replicator 2. Thats the same price as the Pandabot (well, give or take $1), the advantage of the Pandabot is that it auto-calibrates and is excessively easy to assemble.

Although the official spec lists a 100 micron layer height, technically, I see no reason why a Pandabot couldn't print at the same resolution as a Prusa Mendel. Having seen both a Pandabot and a Prusa Mendel in person the electronics and hot end are similar enough that there is really no reason they couldn't achieve the same 10 micron resolutions on the PandaBot.

Sources: - http://www.makergear.com/products/3d-printers - http://blog.reprap.org/2011/12/001-layer-height-on-prusa-men...

Exactly, this comment should really be higher up.

Liav, the designer of the PandaBot, was one of the first people in Canada to build a RepRap Darwin. The year Panda Robotics took to develop the Pandabot is the result of many years of prior 3D printer experience on Liav's part.

Responding to 2) in my experience as a web developer divs are generally no longer used to round corners because the market share of the browsers which don't support css3 rounded corners is increasingly negligible.

Personally I prefer CSS3 rounded corners because they do a better job of decoupling design, functionality and content (which in a perfect world would each fit completely into css, js and html respectively).

Most developers I know followed suit with Google after they dropped support for ie7 in Google Apps back in 2011: http://googleenterprise.blogspot.ca/2011/06/our-plans-to-sup...

EDIT: Looks like rounded corners only got added to ie9 so Google's ie7 stuff is irrelevant, my guess: a degraded experience on ie8 is generally taken as acceptable.

Thank you Paul for both of your replies, that was exactly the information I was looking for.

On that topic, I wasn't able to find any information on the security of Fabric or the sandboxing it uses. Short of going through the source code is there documentation on this topic?

NACL, which is only somewhat similar in that it runs native code via the browser, went to great lengths to demonstrate how their sandboxing worked to address the FUD of running native code in the browser. I have a very similar FUD about executing Fabric LLVM code from arbitrary websites.

To clarify where I'm coming from, I am a javascript / ruby dev and although I have worked in C I do not claim to understand the inner workings of LLVM or have ever worked with it. If there is an implicit reason why building on LLVM would sandbox code written in fabric it is not implicit to me. I doubt I am alone in this and would greatly appreciate an explanation of Fabric's sandboxing.

Basic Stamps are also simple to program however if you have the choice I would recommend the Arduino. The difference being that with an Arduino you are learning in the C programming language from day one which is a very useful and powerful language in use in a number of fields including Game Development. By comparison the Basic Stamps are programmed in PBasic which is not used outside of Basic Stamp programming (and similar Basic languages such as Visual Basic and QBasic are outdated / no longer in wide usage).

On a related note Hackerspaces tend to be great places to meet other programmers and many of them have quite active Adruino communities. http://hackerspaces.org/wiki/List_of_Hacker_Spaces

EDIT: grammer

What about sensible defaults? If the libraries you use are designed with reasonable defaults that have already anticipated your needs there should not be any need for anything but the most basic syntactic autocomplete functionality (closing brackets for example) because any code at that point is customization for your specific project which is not easily generalized (otherwise it would be a default in the library).

This doesn't seem to do justice to ruby. What about the huge string manipulation, array and hash standard libraries baked in to ruby that js simply doesn't have?

Taking into account a modern stack, a fairer comparison is Ruby + ActiveSupport vs. CS + Sugar.js. The closest thing to that is this one: http://sugarjs.com/libs/Ruby