skysight-inc/HackerNews huggingface dataset:
If HATEOAS implementation was more widespread the biggest advantage would be the ability to create standard libraries for API calls rather than thin wrappers for every language. Your API would also be more or less self-documented, hopefully making it easier to navigate for humans and machines alike.

I am curious as to why this can't be handled at a HTTP level with OPTIONS? Could I not OPTIONS query a URI, and receive a list of supported HTTP methods (GET, POST, PUT, etc) that are available on this resource?
We're working with a HATEOAS API on our current project. One area it really shines is in pagination. The API abstracts away both a MySQL and a CouchDB database. When paginating through SQL, the "next" and "prev" links are simply setting skip and limit parameters, but in Couch they're supplying keys and documents (because "skipping" 10,000 records in a b-tree is a really bad idea). The application no longer is exposed to implementation details; it simply follows the links.

Plus, when you can "surf" your API by following links in JSON documents, you start to twig how it's a pretty powerful thing. It takes client developers about a day to get over the strange feeling they get yielding state control to the back-end...
Fascinating HN thread. I work in the geoinformatics domain where many of the same comments apply. I agree scientists turned programmers are often poor software developers. Moreover, this group often belittles industry established best practices in software development. But in truth, the "pure" software engineer/computer scientist lacks sufficient domain expertise to accomplish something useful. Learning fluid dynamics requires many years of education. Ideally, you would like these two groups to work closely together and with mutual respect.
You wonder? They tell you every day. They want to show you ads and grow their network.
Looking forward to the book and hoping that it is short and to the point.
I always feel awkward reading these rants, mainly because I've burned my bridges before and it really wasn't worth it. Even if it is true, it's better to leave it and move on.

If you really feel strongly about something, write it dispassionately (normally some time after the event) and treat it like a dissertation, backed with case studies and citations.
i'm not into bio, but read articles on latest development. my sister also took bioinformatics but the scope in India is very less it seems.

have you checked out synthetic biology? will it be easy to understand when you have a degree in bioinformatics?
I'm not pretending to claim some sort of native ancestry, and being the result of colonialism doesn't preclude me from disapproving of policies and interests beyond my control.
Nothing. It is bad to not parse files but still changing content because you assume the file format mandates something when it doesn't.
If you're e-commerce and rely on the kinds of up-time numbers that the post you are responding to references, that is generally the answer, yes (Well, not a full data-center for most guys, but at least your own platform which you know down to the motherboard jumper settings or whatever).
"End-users couldn't care less what the code looks like."

This should be on a poster.

End-users don't care about any of the behind the scenes stuff that developers sometimes get completely distracted by — they care if it works. If it solves their problem and does what they want/need it to do, then it works ... if not, it doesn't. What goes on behind that? Irrelevant to them.
I think you answer the issue partly in your answer to me: discuss it on the talk page and get consensus.
Why Aren’t You Investing in The Most Important Thing?
It works just fine. And iterating through files is not rocket science, anyway; it's not hard to follow what is going on.
The Raspberry Pi strikes me as a particularly ill suited platform choice for a cluster. I'm not going to complain about using ARM, that's a fair enough choice. But couldn't they have at least chosen an ARM that actually has ethernet on board instead of connected by USB? There are Pogoplugs with a faster ARM processor and built in GigE for $16 or $22 on Amazon.
Nothing in the WebCryptoAPI has anything to do with locking down applications, but attempting to make them more secure (that is, making it more difficult to compromise their integrity). That said, it doesn't accomplish this; see my sister comment to yours.
> Open source projects can't pay royalties. But people who use them can be forced to.

That's right, and that's the reason to avoid any closed codecs.

> The idea that VP8/VP9 will gain traction and remain royalty free is laughable.

What's laughable? VP8 remains royalty free. VP9 will as well. In practice you can never guarantee that some submarine patent troll won't appear tomorrow to threaten you. But the same perfectly applies to H.264/H.265 so your argument is irrelevant, since such threat applies to virtually anything, but it doesn't mean one should stop innovating because of it.
There's no doubting gasset-glaser's (DarkShikari) knowledge in these matters, but he is hardly an objective party.

Apart from being one of the developers of open source GPL licenced x264 encoder, he and the other developers are also licencing it for proprietary use (nothing wrong with that, I think it's a great way of making money out of open source development). This means that a open source royalty free codec like VP8 (and later VP9) could cut into their revenue stream.

I'm not saying that this affected the outcome of his test, but it's still context. Also his test back then was also criticized for only using one clip, here's another test with a larger set of comparisons:

http://qpsnr.youlink.org/vp8_x264/VP8_vs_x264.html

I can't vouch for the validity of this anymore than the validity of any other test.
I can't find that critique with Google.

As I said, the style is very terse, and I have my suspicions that this is by design to minimize the number of less-qualified programmers trying to submit sub-standard code back to the project. (Edit: since it's been 10 minutes and I still can't reply to tomalsky's comment, I should point out that my "suspicions" are a joke; read the linked code sample and judge its quality for yourself.)

I have dived deep into the samtools code, rewritten chunks of file I/O inside it, messed with alternate formats, and my personal experience is that it's been easier for me to change, adapt, and understand it then any other open-source C project I've tried to dive into, such as, say, GNU join.

If anybody can point to where samtools is using many more cycles than it has to, please let me know! The worst part about it is that the compression and decompression is not multithreaded, but that is being worked out, I believe.
Are you connected to any TechStars mentors?
I don't see the difference. Could you perhaps explain it?
I have no interest in doing something like encoding all 28 HD test clips, since as a purely visual comparison, it would be incredibly exhausting.

Science is exhausting. If you're not working hard, then you're likely to miss the interesting (counter-intuitive) results. In fact, finding counter-intuitive results is the whole point of science. If the truth were intuitive, explanations wouldn't need testing.
... Which is an arcane way of saying "pointer / reference"; i.e., not a primitive or C-style struct.
I've never recommended MySQL for anything where the data is important, but I've had to help several businesses deal with existing installations. Here's a few teachable moments:

One customer who ran MySQL on windows experienced data loss after a historic MySQL crash left them with a corrupted MyISAM table, which caused mysqldump to SILENTLY exit before the dump was complete. Their dumps only had the tables up to the corrupted one. They had been saving those dumps for months, but never testing them. When the server eventually gave up the ghost they found that none of their dumps were good. Lesson: 1. ALWAYS test your dumps. 2. NEVER trust MyISAM.

Another customer, smart enough to use InnoDB but not smart enough to change the MySQL defaults let one database get too large and found they couldn't shrink any of their databases because unless you use innodb_file_per_table InnoDB won't ever relinquish space even if you delete all the rows in your tables even after "optimize table". Lesson: 1. ALWAYS use innodb_file_per_table if you plan to keep the database for a long time. 2. Periodically run mysqlcheck optimize or optimize table to actually reclaim deleted space.

I've also helped customers rewrite their applications to avoid the "Total number of locks exceeds lock table size" problem. What is that? Well, even if you use database level locks the number of rows a transaction can alter is still limited by the server's memory buffer pool size. Lesson: 1. Know your working set. Make sure your application checks the server's buffer pool size via SHOW VARIABLES and is smart enough to avoid large transaction updates. 2. Use a large buffer pool size whenever you can.

Coming from a PostgreSQL background, these came as total surprises to me. I've never been completely happy with PostgreSQL's transaction id wraparound issues but I have yet to experience anything like the problems I've observed with MySQL.
“Generation Rx” and “Generation XL” 
Our children have earned the title “Generation Rx” and “Generation XL” due to their escalating rates of obesity and these other conditions. This is so hard to hear. But we have to listen.
Apple has rejected every app that has anything to do with Bitcoin (aside from graphs and stats) thus far.

Examples:

http://www.bitpak.com/?p=34

https://blockchain.info/wallet/iphone-app

http://bitcoin.stackexchange.com/questions/5386/why-isnt-bit...

http://www.forbes.com/sites/jonmatonis/2012/06/13/why-apple-...
Marvelous quote, but what an odd thing to say about Shakespeare.
Free for all existing customers, which is a vast majority.
Scorernews
football news in greece
I love awk. I once had to search a multi-megabyte hunk of data that was made up of 25-bit data items packed into 32-bit words. Instead of doing bit packing and unpacking, I converted the words into 32 character strings of 1's and 0's. I ended up with a string 300,000,000 (that's three hundred million) characters long!!! Awk had no problems handling it.

To build the string, I had to concatenate 1024 of the 32 characters strings to an intermediate string, and then concatenate these into the final monster, because concatenate just the 32 character strings took too long - a reallocation after every concatenation.

That was fun.
samtools is among the better software in sequencing-data analysis. It is also great in defining formally the file format it uses. The same cannot be said of many other tools. For my recent work in RNA-Seq, samtools is the most robust and trustworthy tool I looked at and used, and I looked at almost every popular tool, the major exception being RSEM. If only all bioinformatics tools are more like samtools.
While I agree with the gist of this article, I think it's walking a razor's edge to differentiate between a "happy" life and a "meaningful" life. I could argue that perhaps there isn't more to life than being happy, and what a meaningful life brings is a more complex form of happiness, a lasting reprieve from the existential terror that envelopes us between acts of isolated pleasure-seeking. So yes, you may report higher life satisfaction with a meaningful life vs. a "happy" one, but if you're going to define happiness in such a narrow, superficial way, then you're kind of guaranteeing this conclusion.

I think a better title would've been "There's more to life than seeking selfish pleasure." But this is more linguistic nitpicking than anything else.
Great post! For those who know Python, this may be common knowledge, but for the uninitiated, this is a great showcase of some simple ways that Python makes coding more intuitive and enjoyable.

You might also consider mentioning both dictionary and set comprehensions along with list comprehensions, as they are the exact same concept, yet even a lot of intermediate Python programmers don't know about them!
The Coinbase app doesn't allow trading, so I don't really see the issue. That's what they've objected to in the past.
You disagree that a free, solid OS like android with a commercial marketplace like the google play store will become ubiquitous?

I mean we are reaching the point where a $20 device can just plug right into a hdmi port and you have a full blown pc with standardized wifi and bluetooth support. By 2018 they will be $10 and sold at gas stations.

When that happens you can have any codec upgrade you want as long as it can still decode on that hardware spec in realtime.
Aek
aekara
Dostoevsky wasn't particularly respectable when he got started, and Shakespeare was regarded as pop culture until the 19th century. These standards change over time. In fact, great art as often as not starts out as low and only gets deemed high culture once the prejudices of its time have worn off.
That line makes the whole article worth the read.
i totally disagree on Fred's negative view of Bioinformatics. as "software is eating the world", it's actually bioinformatics is eating biology. today's main-stream biology is dealing with exploding amount of data from modern instruments, images or clinical data collected every day and mostly machine readable. to stay up-to-date a modern biologist / bioinformatist need to think biological problems in a "big-data" (i know, cliche) way, then try to gain some insight from the data with (computational) tools. today it's the algorithms, mathematical models and software packages on top of databases to pinpoint cancer SNPs and drive drug discovery. and today it's these same algorithms and math models driving how web bench works are designed. if you think biological data are "shitty", i guess you never see other kind of unstructured data out there. so many scholars in other fields envy biologist and medical scientists for something called "PubMed". on the other hand, for those purely wet bench "biologists" who think computers are magic boxes to give answers, insights, models with one push of the button, i do feel sorry for them. they are so last-gen as they just don't have the essential techniques nowadays (just like a molecular biologist not knowing pcr).
Beautiful reasoning from that judge: Don't be a victim of a crime, as that distracts police from their work.
Big one recently: MEGA
Even though I use Coinbase for buying/selling, I would not trust them to store my moderate balance of Bitcoins.

Their hot-wallet dependency and my storage of coins at a central location simply does not give me enough assurance my coins will be safe there for a significant amount of time.
It's not, but it was traditionally regarded as a lower form than tragedy. For example, that's why Dante called his poem the "Comedy of Dante Alighieri" – he was doing something radical by taking the highest subject matter and putting it into the lowest form, vernacular comedy. (It didn't get called the "Divine" comedy until after he died.)
Hateoas would enable you to spider Apis and data. Seems like a useful concept.
Startups That Raised Funding in January 2013
I largely agree with Fred's opinion on the shortcomings of bioinformaticians and the general attitude in the industry, but my personal experience was actually pretty positive. My past research was on building visualizations of the complicated biochemical processes, for use in educating undergrads. It was certainly more interesting than slogging through mounds of crappy data.

Just another data point for someone contemplating a career in BINF, although some purists might say that my work did not really fall under the same category.
"Facebook, Apple and Google campus recruitment is about half and half state schools and half private schools. They don't even bother with some of the Ivies like Yale and Dartmouth."

You're wrong. They may spend more time at MIT and Stanford, but they spend plenty of time at Brown and Yale and Harvard and the other top schools with CS programs. I know for a fact that Facebook hires a ton of people from Harvard.

"Rich kids don't go into engineering."

You're thinking Paris Hilton, when you should be thinking Moderately Well-Off Kid From Berkeley. That's more than sufficiently "rich", for the purposes of my argument. There are huge numbers of kids living in the suburban midwest for whom a Berkeley CS degree is a financial pipe dream. Dad might be an insurance salesman, and mom a teacher, and they barely have enough money to send junior to State U., let alone a top-tier CS school.
FIFY:

"[Hyperlinks are] a solution aimed at solving the clients can't update problem. This was never really an issue since browsers (closest thing we have to a [Hyperlink-aware] client) always rolled out new upgrades, it's an even less of an issue now with todays auto-updating browsers. It was also born in the web's early document-centric era where every action requires a full loop-back to the server and entire page reload, which is why it will never be used to create engaging and interactive apps."

Which seems rather nonsensical. HATEOAS is just about about hyperlinks driving the application. Which is what the Web is, mostly, still, even though we have lots of crappy Flash restaurant sites.

There's two ways you might be correct: (a) REST API clients are complete silos and we no longer use hyperlinks to bridge across them or (b) JavaScript is more important than links.

(a) is sometimes true given the state of today's REST APIs, but not always - Google's APIs, Facebook's APIs, etc. all are fairly connected. Plus We still use Hyperlinks to bridge across "apps", of course, because of this proliferation of API silos still require URIs and even the browser as glue between them until more mature user agents evolve.

As for (B), REST always had Code-on-Demand (i.e. JavaScript) as an optional constraint alongside HATEOAS.

The point of HATEAOS is not about building individual apps, it's about building an ecosystem of integrated applications... i.e. the HTML web itself.

One area where I do agree with you: REST's constraints can and should be jettisoned if it makes sense for your use case. If you really want to make an app that's "engaging and interactive" and needs to be a silo by nature, then have at it.
You bring up a human-nature attitude and the proof is around us all the time, whether you are discussing gender, race, age, height, beauty, etc. All of this has been beaten to a dead horse.

Anecdote: I'm a white guy who grew up in the inner city, and one of the most important things I ever did for myself was ridding my ghetto accent. The difference in the way people perceived me over the years is very different.

The simple fact is that humans use short-cuts all the time. I may not like the short-cuts, but I can't blame people that heard my inner-city ("black") accent and assumed that I went to schools with lower education standards and that I am culturally different than they are. Bot assumptions are pretty spot-on, to be honest.
If Coulton had rights to create a derivative, he'd be getting legal advice that he has a great (legal) case against Fox, if he's willing to spend the money and time. Though it isn't likely to make anyone fantastically wealthy.

If Coulton had a compulsory mechanical license to the original work, and just happened to create a unique arrangement and inadvertently created the derivative (he's no lawyer; how would he know a cover is only a cover until it isn't?) he'd be getting advice to let it blow over, because any action he happened to win against Fox on the grounds of their infringing his derivative would leave him open to suit from the original rights holder for not having had a license to actually create a derivative.

As Coulton termed the advice he received as "I have no case" I'm guessing he's not put off by the practical concern of time/money but by bad legal prospects. Particularly considering he went on to mention that he's still looking into whether they actually mixed in his original audio. (which, if they did, he could use to bring a copyright action against them without claiming that he created a derivative work.)
An effective deterrent catches no one. An A/B test is needed, but...
I hope to god my doctor's office isn't using iOS to secure my medical data. Elcomsoft has a product out to bypass iOS encryption

These guys are releasing free software why the hell aren't they coding for android. Make your own stripped down android builds that are heavily focused on SECURITY then just port over all the medical billing tablet software. No telecom installed operating system should be trusted with holding confidential medical information when backdoors like carrierIQ were discovered.

Get android source for nexus tablets. Strip them down, include SEandroid modifications. Encrypt the device, write a small firewall program for it with notification should something go wrong (like bluetooth being turned on) and include other freely available foss that encrypts files and pics should somebody want to transfer them off the device securely.

It's much cheaper than any ipad or iphone too. What's the point of free software to 'change humanity' when you're making some guy in Nigeria get an iphone which probably costs 6x what it does here. Cheap Samsung older phones and Nexus tablets are everywhere in the world, you could buy them off wholesale from carriers who discontinued them, flash the android build with the software and ship it around the world or just provide the image for free and let doctor's flash their own devices. Tip: the new nexus tablets coming out will be $99-150

http://hothardware.com/News/Rumor-Next-Nexus-7-Price-Could-B...
> I wrote a post about why GATK - one of the most popular bioinformatic tools in Next Generation Sequencing should not be put into a clinical pipeline:

I've seen you link to your blog post a couple of times now, and I still think it's misleading. I do wonder whether your conflict of interest (selling competing software) has led you to come to a pretty unreasonable conclusion. (My conflict of interest is that I have a Broad affiliation, though I'm not a GATK developer.)

In your blog post, you received output from 23andme. The GATK was part of the processing pipeline that they used. What you received from 23andme indicated that you had a loss of function indel in a gene. However, it turns out that upon re-analysis, that was not present in your genome; it was just present in the genome of someone else processed at the same time as you.

Somehow, the conclusion that you draw is that the GATK should not be used in a clinical pipeline. This is hugely problematic:

1) It's not clear that there were any errors made by the GATK. Someone at 23andme said it was a GATK error, but the difference between "user error" and "software error" can be blurred for advantage. It's open source, so can someone demonstrate where this bug was fixed, if it ever existed?

2) Now let's assume that there was truly a bug. Is it not the job of the entity using the software to check it to ensure quality? An appropriate suite of test data would surely have caught this error yielding the wrong output. Wouldn't it be as fair, if not more so, to say that 23andme should not be used for clinical purposes since they don't do a good job of paying attention to their output?

Your blog post shows, for sure, a failure at 23andme. Depending on whether the erroneous output was purely due to 23andme or if the GATK had a bug in production code, your post shows an interesting system failure: an alignment of mistakes at 23andme and in the GATK. But I really don't think it remotely supports the argument that the GATK is unsuitable for use in a clinical sequencing pipeline.