pierrebouchet

I'm convinced that e-ink displays will become ubiquitous in a not-so-far future.

A e-ink screen is a great idea for a workstation aimed at text editing, be it writing emails or programs or even using spreadsheet software.

I spend most of the day in front of a screen blasting light into my face and I find it very aggressive. I'd be ready to pay a good price for a 20"-ish e-ink display that i could plug into my PC.

Yes hardware startup are sexy, but most of them are also very software-intensive. Leap Motion needs a lot of processing power, even for a simple visualizer app, and I bet Myo does too.

Other examples: guidance of things like the Sphero or the Parrot AR Drone are very complex. Usually there's a lot of maths involved, which has to be translated into software.

This reminds me of VoiceBunny. For short texts you can get a voiceover within minutes, and their API allows you to automate the whole process.

See API flowchart: http://voicebunny.com/developers/get_read

I'm in the "99% mobile" case.

It seems Parse offers many nice features in addition to transparent-ish "cloud" persistence, e.g Push notifications, etc.

Heroku's approach is really interesting. The idea of building a db model from the CoreData model is (I think) really elegant, but: - I'll also need to write an Android app - AFIncrementalStore is more generic but Parse's specialized classes seem more "plug-and-play".

I'll try Parse first.

This looks like competition for Parse (and a few others I guess, but Parse was the first one I heard of). However I have tried neither. Is there anyone who's tried both? What are their pros/cons?

IIRC state-of-the-art reconfiguration times can get below 10ms when using partial reconfiguration.

In the field of sotfware-defined radio, the USRP hardware from the GNU Radio project has an onboard FPGA. It's a great project, lets you deploy most radio stacks with only a few clicks: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio....

There are solutions that do not need any pre-established magnetic field maps, because they simply derive velocity from local magnetic field disturbances and use magnometer measurements as an additional input for odometry calculations, using data fusion algorithms (e.g Kalman filtering). This allows to basically eliminate the drift induced by two successive integrations with low-cost IMUs.

And with enough sensors (4 magnetometers) you can reconstruct 3D trajectory.

The following thesis is fascinating and very instructive: http://pastel.archives-ouvertes.fr/docs/00/50/10/05/PDF/pdfV...

Chapter 5 is very instructive, in particular the section Measuring magnetic fields gradients to derive velocity.

Excerpts: If the body moves, then the sensed magnetic field must change according to Maxwell’s equations. If the magnetic measurements do not change significantly, then the solid body is not moving. This permits us to rule out velocity drifts in our estimation. Ultimately, this improves the position information obtained by integrating the velocity estimate.

Note that they don't use the raw magnetic field, but its gradients, i.e a physical quantity that is intrinsequely local. Filtering out the earth's magnetic fields becomes quite easy (I suppose..) since these gradients are fast-varying quantities in comparison. Kind of like when you use an accelerometer: gravity is low-frequency, motions are high-frequency.

To me "Pick a game, write a server emulator for it" is an excellent example of "What is it trusting? What is it trying to protect? How do I get around it?".

But on top of being "a great way to use all your skills up to this point" I think it can also be a strong motivation for picking up new ones.

I agree with you on the Arduino IDE limitations, but what I don't get is all the browser/cloud-based part. The mbed platform has all that online stuff, and that's precisely why it's a pain to use.

Using larger grids and combining this with the famous HashLife algorithm to "compress Space and Time" (http://www.drdobbs.com/jvm/184406478) would be awesome!

Bluetooth Low Energy would be well-suited too. And more and more smartphones have radio chips that support it (iPhone 4s, Droid Razor, ..)

A Wi-Fi module like the RN171 from Roving Networks which has a full TCP/IP stack embedded is less than $35.

There is also the HSM (hierarchical state machine) extension of this concept (by the same author, not sure it's in the same book) where a given state either handles an event or returns a pointer to a "superstate" that handles it. This kind of "behavioral inheritance" allows for a much more compact code.

Compact and efficient state machines are immensely useful when working with small microcontrollers that don't even run an OS.

My bad, I was being too vague - sorry for that.

I meant "any atypical property" instead of "any property".

An "atypical property" being a property that almost no sequence has, i.e the set of sequences which exhibit this propery is a measure-zero set.

I think one of the most widely accepted definitions of randomness in mathematics was given by Martin-Löf.

Basically it says that a process is random iff it doesn't exhibit any atypical property that you can test with an algorithm.

In other words: if there is no computable way of proving that it's not random, then it is random.

tell us more, do you have a link?

I'm sure right now someone somewhere is working on an FPGA implementation of the DCPU-16.

You've convinced me. I'm trying DDG right now!

It's funny how Excel allows non-programmers to end up programming without knowing it.

Reminds me of http://news.ycombinator.com/item?id=3374431