jerluc

Depending on how much data you need to transfer between the two devices, I'd highly recommend a pair of ZigBee radios for low-bandwidth (<250k), super-low-power applications. Specifically using a pair of XBee (series 1) radios in "transparent" mode, you get what looks like a serial device on either end. When used with a USB dongle, you can simply write your code to use basic ioctl ops on the USB device file, which works well across most POSIX platforms.

As most of the comments in this thread seem to be about "smart" home technologies, I'm curious to hear what people think about the introduction of "smart" things into civic and industrial environments (e.g. dumpster/public trash sensors, Bluetooth beacons for indoor navigation, "smart" bus stops, field sensors on farms, etc)?

In my [limited] experience with CBIR and image based search, I found that using a color space with perceptual spatial qualities (such as one of the CIE LaB variants) to be more effective than a purely normalized geometric color space (such as RGB or HSV), as color similarities in the latter may not make much sense to a human.

Mind sharing some of that evidence? Having worked for a few online ad targeting companies previously with large advertisers and publishers, I gotta say, most of the data we saw coming from marketing campaigns were weak at best. Most of the conversations were around spending campaign budgets fully (which basically meant reducing the quality of targeting to a broad fishing net), and furthermore ROI tended to be measured against some insane advertiser goal not directly linked to conversions (sometimes this was charged via CPC or CPM, which advertisers supposedly obtained from their real conversion metrics). Also, if you're curious (though I can't find any links right now) you should look into the insane things that happen in brand advertising. I recall running a campaign with a very large brand that would pay us for showing users a YouTube video of their product. Their wasn't even a link to the product. They essentially were paying us for "influence".

Not knowing anything about the author's background, I can only assume he is not very technically knowledgeable, especially when I read:

> but how many people use Incognito for every search?

and then later:

> Likewise, it’s smart to turn off location history in Google Maps because once Google has that data, it's out of your control.

By providing inputs to either service mentioned (Google Search or Google Maps), you are already providing them with your "private data". That's the entire point: you give Google a set of keywords, and it gives you answers. If you didn't want Google to know what you're looking for, why would you tell them?

I've been building a very simple development "portable" PC using a 7" TFT display, wireless keyboard, and a Raspberry Pi. At the moment, it just boots into a Linux login shell, but you can program it to boot into a desktop environment if you want (and if you have the power luxuries!). Of course, the Linux environment may be too much for kids, but this might be close to what you want. Also a decent overall price: altogether so far, I've paid a little less than $100 for this whole setup ($30 for the display, $35 for the RPi, $25 for the keyboard), though you could get it for much cheaper using a Raspberry Pi Zero ($5!) and a cheaper keyboard.

I was certainly in a similar boat (though a later generation of computers) whereby I found around age 9 that "poking" at a computer (either plugging random things in, or clicking random buttons or keys) enough yielded some interesting/mildly entertaining results. Of course, many times, these results ended with being grounded for breaking something, but nonetheless, the endless possibilities of random keystrokes and mouse clicks seemed to exude some kind of strange primitive allure.

Also, K&R for kids ages 12-14?!

Ah that's a good point that both you and scottcha make regarding the typing strengths/weaknesses of children, which would make a typing-based approach maybe non-practical. I guess more generally what I was trying to better understand was whether or not the use of these fitted blocks (as I understand Scratch to do) has been studied enough to be considered more fruitful in developing an understanding of rudimentary programming rather than a more free-form way of doing so (maybe just blocks that can be combined in any way, even if they don't work as intended). Maybe said a slightly different way: why did MIT researchers choose to use a "coloring in the lines" method (which may hinder creativity and potentially interest)?

Does anyone know of any published research on the efficacy of this "block based programming" standard the author mentions? I can't seem to find anything on the subject in the Scratch website's "Research" section (https://scratch.mit.edu/info/research/), and in their early papers they simply list it as a "core feature" rather than explaining why they use blocks in the first place.

Every language that supports threads has "concurrent IO". That's what threads/processes are for.

However, threads will never help you in an IO-bound system (unless you own some kind of thousand-core CPU with an equal number of OS threads). Threads will simply block at the first waiting IO call until you eventually run out of threads. Node.js from the beginning was built for non-blocking IO, as are several Python frameworks (e.g. Twisted, or more recently, Tornado), thus the need for more than one thread of execution was typically unnecessary (again, provided the bottleneck was IO).

I'm a bit confused by this idea, maybe someone can clarify. AFAIK, genetic programming/algorithms themselves require some degree of tuning in order to be useful in a reasonable amount of time and for avoiding local minima each generation, via mutation rates, population size, randomized simulated catastrophe, etc. That being said, how does something like TPOT actually ease the pains of tuning the parameters of a different model, if it requires it's own tuning?

To others trying to use this demonstration: Be patient with the page, as it has to download quite a few JAR files in order to be ready to compile and run any test code. To verify that the javapoly is ready to run your code, open the web developer console and wait for it to say "Java Main started". Additionally, first-time compilation will also need to download additional JARs for the demo code to run. Generally speaking though, the compilation time is a good 5-10 seconds on my computer for the demo code, so be sure to not just spam the compile button like I did :)

  ----

Just a friendly note to the author of this page: The total download size of this page's underlying Java resources are much larger than I realized (maybe a collective 30-40MB). Given that I waited almost 5 minutes after clicking "Compile & Run!" for nothing to happen (because I had clicked it well before the runtime JARs had fully downloaded), I would suggest to at least add a progress bar or something to let users know when they can actually compile and run the demo code, in addition to some acknowledgement that the code is compiling. This is definitely an interesting project though.

@OP: FYI I'm getting mixed content errors with the example fetch because the AllOrigins page itself is served over HTTPS, but the backend call is going to HTTP. May be a good idea to swap that out.

It would help greatly to add the appropriate accents (aigus) to the title of this submission, as I misread this to refer to "resume in C" as in "resuming a suspended continuation in C" :)

I'm not sure if any of this is sarcastic, so sorry if I've completely missed the mark. But I think despite the opinion that one should have more choice (of which, don't get me wrong, I'm personally an advocate) the problem here goes well beyond the age-old Android vs. iOS debate. Sure, I wish iOS could have implemented features that align with Android and vice versa. But IMO the problem here actually comes from how the "web of apps" evolved separately from the WWW.

On a more concrete note, there are scenarios where neither DNS nor special HTML metadata work. A great example of this is Uber or Lyft. Both of these apps support mobile deeplinking, however there is no real concept of a "page" in these apps. These kinds of apps are more like utilities or services (ride sharing, making phone calls, starting a run, etc), rather than content to consume (reading the news, playing music, watching a video, etc).

This can be somewhat emulated with Android's support for vendor-specific MIME types in intent-filters: http://developer.android.com/guide/topics/manifest/data-elem...

Last I recall, this is how YouTube works to open the app when you try to play it from the web player on a mobile device.

Without pointing fingers at a specific app, there are several in particular that we have worked with who have "pretty URLs" for their website (e.g. "http://example.com/the-name-of-the-page") but their deeplinks are "ugly" (e.g. "example://page?id=123456"). There is no unified way here to derive the deeplink from the web URL or vice versa. As such, we cannot treat deeplinks and web URLs as always templatized; these are simply URIs whose identities should be considered arbitrary.

On another slightly relevant note, from the perspective of linked data and the semantic web, the <link> tag or "Link" header (both which are suggested by Google and URX) is meant precisely for this kind of reason: being able to link separate resources with a given relation (e.g. "alternate") who may have varying display/device/media qualities (e.g. media queries). Because semantic linkage is between two nodes of the web graph rather than DNS (which I guess would be a subgraph of the web?), one is able to use semantic metadata such as http://schema.org/docs/actions.html to describe not only how to access/consume a resource, but also alternate ways to do so (e.g. from an Android device instead of a desktop client).

Again the above isn't completely impossible to do with DNS, I'll give you that, but it simply is less tenable to assume template-like qualities of all URIs or to ignore the semantic implications of redefining how linked data has worked for the last decades.

[Full disclosure, I'm a current employee at URX] We had actually briefly discussed potentially using DNS to help resolve the linkage between a given host/domain and its corresponding mobile apps. However, the problem lies in that we need to discover the linkage from HTTP URL => deeplink URI, which means we need page-level mappings, something that can't exactly be done with TXT records at the domain-level alone.

Android has IMO done a good job of supporting deeplinks to some apps "just work" by allowing apps to handle HTTP URLs with specific host + path patterns (though it is noteworthy that this can lead to security problems!), but iOS does not support this same functionality.

I do, however, agree with the author in that a more seamless integration pattern that can use existing infrastructure would be ideal, but it seems that for now, the pattern of using metadata, HEAD requests, or Link headers in responses is as good as it gets.

These experiments look very similar in concept to many of Google's material design animation principles (http://www.google.com/design/spec/animation/responsive-inter... and http://www.google.com/design/spec/animation/meaningful-trans...)

Ligatures shouldn't affect search engines, as they will index the text of the pages, not the fonts/visual representation themselves.

Myself being a college dropout (though not from some prestigious university), this all sounds a bit foolish to me:

> Before the crowd of technology enthusiasts, he sketched out his plan: grants of up to $100,000 each for up to 20 people under the age of 20 to "stop out of school" and pursue their passion.

Maybe I'm just being sore and jealous, but my decision to drop out was not for the prospects of pursuing my passions. Rather, it was based purely upon economic and temporal constraints: in order to go to school, I needed a ton of money; in order to get money I needed to work full-time; in order to work full-time, I needed to take less and less classes. The fact that I later ended up pursuing my passions was basically out of necessity, not because some investor said he'd been thinking about it for a year and thought it might be better to leave, and oh by the way here's $100K.

For those of you interested in this subject, there is a library called LIRE (http://www.semanticmetadata.net/lire/) that's been around for a long time which will index various color and textures features into a feature vector compatible with Lucene. It does end up with the interesting scenario of requiring the search query itself to be an image, but if you are looking for a solution whereby for a given image you can find other images most similar to it (and ranked, of course), this does the job surprisingly well.

Coming from a background of not much computer science and having dropped out of college, I found learning theory to be too lengthy and dull for my novice mindset at the time I started programming (in, quite fittingly, HTML+CSS+JS+PHP on LAMP). I was in the same shoes as your friend, as whenever I would see an open-source project or library, I would be quick to modify it to suit my needs, but would end up with massive if clauses and without much modularization. Of course, after about a year or so of doing this same bad practice, I came to ask "Truly there must be a better way than this, right?" It was at that point, after already becoming completely addicted to programming (yes, in the ugly, somehow-working kind of way) that I gained enough patience and interest to learn more theoretical concepts about computer science and its applications to programming (lambda calculus and functional programming in particular). I agree with you, being that this ultimately ended up helping me greatly, but I disagree that CS theory should be the very first thing a novice programmer approaches.

I think it probably has a lot to do with the fact that the author, Bertrand Meyer, invented Eiffel (http://en.wikipedia.org/wiki/Bertrand_Meyer#Computer_languag...).

You've clearly never tried to implement a REST API using any flavor of Lisp before. Guess what: most clients of web services understand JSON and XML, not S-expressions.

It was hard to really see the author as being objective on the subject after reading the experiment that pitted Perl/Python programs against Java/C++ programs in an application requiring "string manipulation and searching against a dictionary". I'm all for trying to prove this point empirically (though I disagree with the author's stance), but in the least you've got to eliminate as many of these variables as possible (e.g. choosing typed languages that have similar string manipulation and sane collection libraries rather than pretending like working with Java HashMaps is anything near a Python dict).

Other than that, I'd say skip the over dramatized dogma and just pick the tool that suits your problem space best.

Couldn't agree more with this. IMO Dropwizard (with help from JAX-RS) has greatly simplified the process of spinning up a basic REST web service: embedded Jetty by default, Jersey support, Logback (talk about simplifying the world of mess known as Java logging), Jackson-based JSON support, etc. Not to mention (despite my many gripes with Maven) being able to simply build this thing as a fat JAR and go.

This new framework, Civilian, on the other hand seems to be going back to over-complicating everything: requires servlet container by default, a shiny new templating language, HTML forms processing, etc.

I'd agree with some of the other commentors' sentiments voicing that you should start out with Objective-C, but less so because of immature tooling.

For me personally, I'd be more concerned about someone in your position trying to learn Swift now because it's an incredibly immature language. Core language-level changes IMO are the hardest to cope with, as they can have a severe impact on code written in a previous version of the language, not to forget how much of a mental cluster-f!#@ it can cause.

I entirely disagree. As most all open source projects, Ruby has a set of core contributors, but is clearly open to community contribution, as can be seen from their Git repo's history (https://github.com/ruby/ruby/network). And no, core communication and decisions are NOT opaque to outsiders, as is the usual case with most open source software (Google groups, mailing lists, IRC channels, etc). And lastly, language features and design is a product of the RubySpec, which is itself a Git repo for people to contribute to possible language design/syntax/core libraries for Ruby VM implementors to introduce (https://github.com/rubyspec/rubyspec/).

I could be wrong, but I believe the parent is referring to the inability for a "vibrant community" to maintain Swift as a language implementation (instead of Apple), which is very different than Ruby. There's no doubt in my mind that there will be swarms of people developing with the language, but AFAICT, we'll mostly only see Apple developers working on the language itself.