Hacker Newsnew | comments | show | ask | jobs | submit | film42's comments login

This is great! I'm not sure if it was discussed on HN or not, but Khan Academy recently released an MCAT course with "more than 900 videos and 2000 practice questions." This is incredible, because last summer my wife's online MCAT course cost us around $2,500. It was a good course, but Khan Academy's course seems extensive and thorough. I hope it gets more publicity among med-school applicants!

Link: https://www.khanacademy.org/test-prep/mcat

I'm getting ready to take the MCAT and that's pretty widely known already on premed forums. It helps that it's a partnership between AAMC and KA and was one of the first resources out there for the new edition of the MCAT. I see a lot of folks still taking courses and using other resources too, but yes - definitely somewhat of a moneysaver :)

The "Camera Roll" beta removes the "scarlet letter" of a purple bar, but I don't have the full update yet.

I'll be honest, their last update turned me from a power user into a once-a-month-at-most user, and I haven't uploaded a single picture since. I'm hoping this new update recaptures my interest, because the old flickr wasn't perfect, but it worked very well.


I came here to mention Armagetron, too. No other game stole my time quite like Armagetron did. If you many people out there want something new to try, give Armagetron a chance, you won't regret it!


Every time I am reminded of Armagetron I hear that low buzz sound of the lightcycles in my head. Right back in the saddle. Capture the flag Armagetron is awesome, going to have to reinstall it now!


The nice thing about Clojure development is that you really only need to start the JVM once, after that, you can eval anything you need instantly. And really, startup times aren't that bad. Here's Travis CI for a small project I made. Time to start the JVM and run tests? 2.76 seconds. The entire build completes in ~12 seconds.



How is three seconds to run tests on a "small project" "not that bad"?


well, it is not that bad because as part of the tests it also parse all the code of Javaparser and spring-jdbc (by no means small projects). Parsing it is an expensive operation also because the Java grammar is quite ambiguous


What kind of hardware are you running on?


This is awful! I just want to give a shoutout to the Buttercoin team. They really nailed the serive. I remember signing up and thinking, "well, I'll just look," but by the time it came to transfer money, it was so easy, I just had to continue. Everything after that followed a similar pattern. Even the order form was well done. I'll miss you guys!

Btw, their matching engine is on GitHub and it's a good read!


> Btw, their matching engine is on GitHub and it's a good read!

But it hasn't been updated in 2 years... They could definitely open source parts of their current stack if they want to help bitcoin, maybe seeking a "Docker effect". It would be an AWESOME farewell. Bitpay knows how important this is, they are opensourcing a lot of cool stuff...

Edit: I've just realised they open sourced a newer matching engine built with scala (I was looking at the old node-based)



I feel really bad for all other database startups out there. I'm sure this is sending a negative shockwave through every devops team out there to not use up-and-coming databases.


I use emacs for most of my daily development, but always rely on nano or vi in the terminal due to emacs startup time. I'm going to give mg a shot this week!


1. Tramp.

2. Emacs daemon - as many suggest, why would you ever quit emacs?

But if you do find you shut Emacs down...

3. Slimmed down alternative init eg. https://github.com/ocodo/.emacs.d/blob/master/emacsq & https://github.com/ocodo/.emacs.d/blob/master/emacsq.el (note this init could be even slimmer, but the start time is about 2.5 seconds, which is fast enough, and I get a very well configured environment)

Or just ...

4. emacs -Q - no init.

One of these are going to solve your issue, without having to interrupt your emacs flow.

You could also look at your init for bottlenecks and have a secondary script. Which you can optionally run when you want those features. Keep the real init minimal.

There's many strategies.


You could also run Emacs as a server.


I've actually looked into this, but it seemed like far too much overhead to simply open, edit and save a file; especially remotely.


Remotely, sure (though I usually use joe for that), but for local edits, I start emacs --daemon as part of my regular login procedure (along with creating multiple terminal windows) and thereafter use emacsclient (aliased to 'e') for almost all file editing.

Only annoying thing is the way it retains buffers for modified files when you exit, even if you choose not to save them.

emacs -q (or faster, -Q) could be used in a pinch, but I find default emacs almost unusable.


You can edit remote files directly in Emacs or simply use sshfs.


The gist of this is really the Backpropagation algorithm [1]. It appears as though everything else is a means to detect when to stop. One of the clearest walkthroughs I've seen online is a short series of very short videos by Stephen C Welch [2] [3]. If you're interested in this space, start with him.

[1]: http://en.wikipedia.org/wiki/Backpropagation

[2]: https://www.youtube.com/watch?v=bxe2T-V8XRs

[3]: http://nbviewer.ipython.org/github/stephencwelch/Neural-Netw...


Double exclamation marks force a true value, as opposed to a truthy one. For example:

    SomethingTruthy => TruthyThing
    !SomethingTruthy => False
    !!SomethingTruthy => True


I see what Shykes is getting at though. I mean, if you want to use the rocket, then use the rocket. If you want to use docker, then how does adding another runtime help a docker user, when they could simply switch to rocket? I can understand how their might be a "convenience" factor, but if you're already actively deploying with docker images, then why bother with a separate image type?

Don't get me wrong, I think it's great the coreos guys are trying to make a bridge between the two projects, but so far, I don't see a need for this.


Rocket != App Container. This PR is about the latter. There are already non-Rocket implementations of the App Container spec.

If I were a Docker user, and found some awesome app that only came packaged in App Container format, it'd be very valuable to have this compatibility.


Are there any such apps in reality? Will there ever be?


I'd like to use Rocket personally (I currently use Docker--while I think CoreOS's "containers everywhere" concept is a little misguided, I don't believe there's a good reason to have a permanent daemon, and if I need one I have Mesos) but make things I do easily available to Docker users.

(Docker's beefs here feel more like a company defending their turf than an open-source project, and that troubles me.)



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact