Kjeldahl

Major studios (Nintendo, Disney ...) have spent hundred of millions, if not billions, trying to perfect the magic formula of fun games with educational value, with very little to show for it.

So why is it so hard? Many reasons I suspect. Money is one factor. The market for "edutainment" compared to "blowing stuff up" is significantly smaller. A kid wants to blow things up (metaphorically speaking), and like it or not, the kid gets what he wants.

The number of parents buying games to make their kids smarter is just insignificant in comparison. And when the market is a lot smaller, justifying significant production investments of a high quality game just does not make sense.

At the reverse end, there seems to be an endless number of "companies" making (really low-budget) edutainment making a lot of unsubstantiated claims (lying) about both the quality of their games, the fun factor and learning value.

Thankfully, there are a few notable exceptions but they are usually pretty specialized (Scrabble does wonders for spelling, DragonBox Algebra, things like Kerbal Space Program, Quiz stuff like Kahoot etc).

With some luck, government/municipal teaching material spending over time will transition from mostly books to books+training tools, which should help investments into new and better products like you mention.

Disregarding the obvious ignorant comment about "security" related to showing the html for the page, looks like there's some buggy cache server (Cloudflare?) serving the wrong content type or something. Add "?aa" to the url or similar and it seems to work fine.

So things like Homebrew will no longer work?? Wow, if true that's a serious issue.

Weird stuff. On my laptop (which is about as identically set up as I've managed) the Xcode update arrived as expected automatically.

Usually I've received Xcode updates as regular updates from App Store, but this time around I'm seeing nothing (I've got 7.3 installed already). IIRC I think I've downloaded Xcode releases through the developer program before, but if this now has changed does it mean I need to install it as a regular App Store package to receive updates etc automatically from now on?

So which browser extension was needed again? There was a brief message first time I looked at the link, now nothing. Anything I save with the "Save to Google Drive" extension seems to go elsewhere, so I'm guessing that's not the one.

OSX and iOS need to converge into something new and unified. Touch and pen(cils) is becoming standard for new computers in the near future, and tablets with keyboards also need to support touchpad and mouse. It may not have been necessary earlier, but with Surface and iPad Pro it's becoming obvious that these are not completely separate platforms any longer.

Sure, but how would you know? Sacrificing officers in chess is a typical example. Negative expected value short term, but typically long term positive when done intentionally. But generally, if you can come up with a robust fitness function, genetic algorithm is one method, although typically there are better alternatives giving faster results. In my experience, genetic algorithms can be a great start to get something but typically slow. Which matters if you need to simulate a few billion games... Interesting article anyway, thanks.

So you've now moved the computational complexity to the fitness function, which needs to consider future moves as well?

Good post. There's one other challenge though and that is access to native GUI widgets. Just having an app icon and appearing in the task switcher simply isn't enough. It's one of the problems React Native tries to solve, although I have to admit I'm not impressed with it so far. With the momentum Javascript is having I wouldn't be surprised if most vendors will release "native" javascript bindings to their platforms anyway, which hopefully will remove the last missing piece for "native experiences" using Javascript on iOS and Android (and for that sake, Windows 10 and OSX).

AFAIK, Gimp and Inkscape (like most gfx software from Linux) doesn't support retina resolutions either (on Mac OS X at least), leading to all kinds of problems.

From the announcement:

Complete Emacs-compatible Elisp implementation

Thanks to the work of BT Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love.

So where's my guile-based emacs build? Not holding my breath, but it certainly would be a very nice christmas present (not sure about the year though)!

(yeah, I know emacs is a lot more than just it's elisp implementation...)

eslisp-fancy-function looks great. One standard package with a lot of sensible defaults - based on learnings from ES6, Coffeescript etc - sounds like a great idea. Again, great work!

Looks great. At the very least it needs a built-in function shortcut; people are already used to ES6/Coffeescript shortcuts. Yes, I understand I can probably macro it myself, but that doesn't mean it's not needed in core. Anyway, looks like a great piece of work!

Another alternative (to non-existing BLE sensors) is hooking up a cheap USB software defined radio stick (like RTL2832) to an Android phone using a USB OTG cable supporting simultaneous charging. That's my current plan anyway.

Not really, but since the app requires WebSQL support, support is already limited to Chrome and Safari. You need prefixes for Safari. I love flexbox.

I use flexbox for http://killermatch.com/ (the app part, that runs in the browser, and on iOS and Android as a Cordova app).

If you're on OSX and want a good Emacs, go to https://github.com/railwaycat/emacs-mac-port and read the installation instructions under the Homebrew section. It follows the official Emacs repo pretty closely, but has useful OSX additions (smooth scrolling, gesture support [font size e.g] and more).

Author of article here. This is a link to a blog post about the technologies used in Killermatch (http://www.killermatch.com/?cid=hn), a racket sports match diary and details which technologies were used, and why. I know many startups are struggling with similar questions, so maybe there is something to be learned. I'll try to answer whatever questions I get here as well.

Do you need App/Play Store distribution, or offline support? If so, you usually need to go native or use something like Cordova to package into a native app. From the GUI building side of things, responsive and Cordova can be considered the same technology, although with some special considerations when running under Cordova (webviews might be a bit different than bleeding edge browsers, native access etc). If you do decide to go responsive/Cordova, do yourself a favour and get to know CSS Flex (great for layout on screens etc). Responsive/Cordova also allow you to use other great stuff like React+Flux.

The one thing that will haunt you if you do not go native is the "feel" of you app, compared to the native apps on the same platforms. Most games solve this problem by having their own "immersive" GUI which often works because GUIs in games are fairly limited. Usually a responsive/Cordova type app will either select one of the native "styles" and mimic that, OR select to mimic a "website" type interaction, but regardless, it will never feel quite native on mobiles/tablets.

From another point of view, if you have to build everything yourself, going native means it's going to be a looong time until you cover all platforms (Android, iOS, responsive web). Depending on your app, doing cross platform first, THEN invest in native when you've got a hit under your belt.

You're right, I'm wrong. An cycle needs to complete before another action can be dispatched (against the same store I believe). I think I need some rest. :-)

This we agree on. But if you're doing your async stuff in your store, is this where you want to create your "setErrorAction", essentially creating actions inside your stores? The times I've done this it has ended painfully, and that pain went away if I kept these kind of state updates in actions.

Update: I was probably wrong in disagreeing; actions from actions works if they are on different stores, but to stay away from trouble you're probably better off creating "followup async actions" from stores rather than other actions.

Original comment:

I'm not sure I agree with the first point. Let's say your store's HTTP requests fails and you want to inform the user (through the view component). You want to listen to yet another event from the same store to catch this? An alternative is to do exactly what you say you shouldn't do in step 1; basically have a "loadDataAction" that you fire off when your component gets mounted, using some unique id or something. Prior to this action, the store will return whatever it has (synchronously, similar to what you describe). The action then handles the HTTP request. If it succeeds, it updates the store, and the listener will get the updated data (yes, I agree, the component should always have a listener to the store). If it fails, the same "loadDataAction" will fire off a "showMessageAction" which also alters some store that your component listens to that will display the error message. Typically this would be caught by some higher-up global "show message" component. Like most people, I'm pretty new to a lot of this as well, but I have found that trying to keep most async stuff in the actions works a lot better than async everywhere. YMMV.

Very annoying that the latest versions on the release channel 31.5.0 still shows nothing on standard calendar invites. Yes, I might install a big ass plugin, but what about just showing me the stuff that is actually in the email (that can easily be verified with "view source")? It's been like this for ages as well. Not very promising unfortunately.

Also worth mentioning; The card companies provided the 3DS specification, not the actual implementations or operating the aervices. You can pick provider from a very short list of approved providers due to the shitty standard made to keep the XML pushers fed.

It's quite common for these companies to push their transactions through their US subsidiaries. If a company can convince their bank there will be little or no fraud they can convince their bank to avoid 3DS as well. E.g. if you have lots of transactions and other attributes keeping fraud low, like airlines who check your identity later anyway.

Card fraud was a huge problem in Europe/Russia/Asia etc, but less so in the US (probably related to US's dependency on credit and "credit history"). The internet was taking off and magnified this problem exponentially. To counter this the card companies decided they needed more security in all/most markets outside of the US.

In the "Amazon" type of model, Amazon collects card details and more or less keeps it on file. When a customer wants to buy something, the card companies and Amazon's bank more or less trust that Amazon will keep fraud to a minimum by looking at usage patterns, doing proper card authorizations etc.

They allowed this in the US, but decided to forbid this model more or less everywhere else. Everybody else had to start using 3DSecure.

With 3DSecure the purchaser's bank gets a say in each and every transaction. So you've now got Amazon, Amazon's bank, the customers AND the customer's bank. So when a purchase gets done, the card companies now demands that the customers bank (who know their customers) guarantees that it is the actual customer who is at the other end. The customer's bank can decide not to do any checks, but then if there IS fraud, that's the customer's bank's problem.

So most customer's bank require that the customer - at the time of purchase - identifies himself. Very often this is done by throwing the customer back to the customer's web-based banking solution (which already has identification procedures in place), or something similar, where the customer's bank can authenticate the customer (with passwords/2-factor etc).

The technical details of how 3DSecure actually works sucks bigtime. At least when it was launched it involved using encryption and signing xml-based documents. To make this work those documents had to be "normalized" etc - a huge mess.

Because of the mess, there probably is very little competition in implementing solutions for 3DSecure. Which again is probably why most 3DSecure feels like a throwback into the "Web 1.0" area, with the customer being thrown back and forth between the store and his own bank, typically with a user interface reminiscent of the "CGI" area.

Another consequence is that the US have had a huge advantage (and probably still do) when it comes to everything related to internet e-commerce, simply because the card companies and banks do not allow deviations from 3DSecure anywhere (mostly) but the US.

That article reads like an average teenager preaching the true meaning of life.

Wow, a blue login page and a registration form! How impressive!

On the desktop side, a good UI on OS X compensates for a mish-mash of inefficient and insecure technology on the backend side of things (legacy tech, mix of ..ix/Mach/Next/MacOS).

On Linux/FreeBSD it's typically the other way around; no matter how optimized and clean the back end is (relative to OS X), nobody seems to be able to put together a great working desktop standard UI supporting modern hardware.

Hopefully somebody will be able to provide a good free desktop on top good *ix platforms like Linux/FreeBSD etc, but all the people who held their breath died a long time ago.

The OS X packages like Homebrew and MacPorts make it very easy to run most of the standard backend stuff on OS X while developing, which means many developers prefers to work on modern proper functioning hardware while still deploying on standard Linux servers and similar.

In addition technologies like virtualization, Chef/Puppet/Docker etc support additional workflows which allow testing server work locally on OS X before deploying on Linux or similar.