skysight-inc/HackerNews huggingface dataset:
Its a combination of two separate problems- the skewed demographics of software engineers and the continued requirement of an intuitive understanding of the problem AI is being developed to solve. If you're building an AI system to help police predict crimes, you want to have a detailed enough understanding of the places its going to be applied to know what the impact of its predictions would be and how to shape the system to actually produce a desired result. Like with UX design, going from a specification to a logically valid implementation isn't necessarily going to produce results people actually want.

Its much the same way as, say, startups trying to market products to new mothers or highschool students have a hard time because they can't "eat their own dogfood" if they're all late-twenty-something white men. Huge markets lie unserved, I'm sure, because they're demographics that don't tend to produce software engineers or entrepreneurs.
Is there away to say your meaning, but without the ethnic slur for being cheated financially?
Takes me back seeing adverts for s100 cromenco and USCD Pascal - I once had to stay late to call Microsofts help desk with a tricky USCD Pascal query (that was when they where in new mexico I think)
It only applies to procedural knowledge, of course, but there’s a similarity here between “teaching it to a toddler” and writing a program that does it. I often find huge gaps in my domain knowledge and understanding, not while I’m composing a readme up front but while I’m writing code.
Wouldn't surprise me if they didn't.

That said I'd say hold for now until confirmed: 4C can have equally much fun trolling us by pretending they trolled them.
Also Java and C# developers often produce bad SQL procedures because they tend to think procedurally about problems.
The rush for Irish passports is to have UE citizenship
> Atheists frequently evangelize. It is a religious belief.

They evangelize, but its more of ideology that concerns religion rather than just a belief. The main problem with atheism is the definition: absence of religion, this is such a derogatory word as if believing in deities should be the norm. Agnostic is even worse seat: declaring that you have no clue but probably are somewhat spiritual. If you don't like religion say proudly that you are antitheist!
FYI "jipped" is actually spelled "gypped", which is a slur against Gypsies. I only raise this because I used to say it a lot, and was unaware of its etymology and connotations.
You can do both CPU and GPU, but time and power consumption are both order-of-magnitude worse than using dedicated hardware. The robotic arms are also used untethered in factories, where having a computer near them is inconvenient.

The article describes results for using a Xeon CPU. The linked paper cites other papers where a GPU was used.
> there are product differences that reduce prices but not quality (eg eggs and milk that don't require refrigeration, vastly less packaging, few advertisements)

Being aware of products on sale for cheaper does not help if they're on another continent. (Given that the EU is basically an agricultural-subsidy league, it's not surprising to see produce for cheaper, either, though it depends on local wages as well.)

But the real thing which drives down the prices isn't just savvy, it's that these customers care about the price and are wiling to go to additional efforts to pay less, whether by shopping at a less-traditional or inconvenient place, or by using coupons. Meanwhile the rich-white-single-programmer happily cruises down to a nearby Whole Foods because he really doesn't care about an extra few dollars on his grocery bill; he even buys the pre-sliced fresh fruit as a convenience.

With regards to milk, note that you can find boxed milk in the US (UHT milk, or even milk powder)... it's just not as common, and culturally is regarded as an inferior good. As for eggs, you'll have to blame the USDA for the mandate that they are washed before shipment (as opposed to by the customer).
They definitely missed the point about ugly fruit and vegetables. From speaking to some of the vendors of cheaper fruits and veggies at farmer's markets, some of them (but not all) buy the second dibs (what the supermarkets and their other obligations don't buy) as well as more irregular fruit and produce.

Now, of course there is a growing ugly fruit and vegetable movement[1]. It's becoming more mainstream and even Whole Foods is buying in[2]. There is an effort in Boston to provide good affordable ugly fruit and vegetables to underserved communities.

[1]http://www.eatingwell.com/food_news_origins/love_ugly_fruits...

[2]http://www.eater.com/2016/3/8/11178270/whole-foods-ugly-prod...
I don't like deletion very much either in general, although I've seen librarians defend themselves with 1. that they totally don't have room for stuff 2. for kids' stuff, at least, if it's science, our knowledge has grown so much that it's a disservice for them to read the old book without context. Or if it's fiction, it can be full of social norms and beliefs that we've grown beyond, where...we'd also want them to have context if they were going to read it.

But it sucks when you hear how they often don't have a good sense of the value (intellectual or otherwise) of what they cull. And it sucks if everyone makes the same judgment and all throw away our ephemera that we wish to look back, evoke memories, reveal something of our time.
I used to think that (1024 vs 1000), but not any more. There's ancient precedent for the other interpretation.

For example, when I was a kid growing up in NY, one of the local radio stations I listened to was WPLJ, 95.5 MHz. That's 95,500,000 cycles per second, not 100,139,008.

Go back nearly 100 years, the Chicago area got a radio station called WLS[1], one of the original clear channel stations. It broadcasts at 870 KHz. That's 870,000 cycles per second, not 890,880.

Much as computer people would like "kilo", "mega", "giga" etc to mean 1024^(whatever), there's a lot of precedent for doing things the old fashioned way!

As Wikipedia explains:
tera-, from Greek word "terastios"="huge, enormous", a prefix in the SI system of units denoting 10^12, or 1 000 000 000 000

SI is a well accepted standard. Just because it's more logical for chip designers to implement memory chips using powers of 1024 isn't a good enough reason to ignore SI.

[1] https://en.wikipedia.org/wiki/WLS_(AM)
To be fair, many educated and articulate people are totally unaware of this connotation.
This is a common myth. I've concluded Trader Joe's exists to give a veneer of guilt-free-ness to buying junk food. Avoid the cheese and meat at all costs.
I've admired Dominic's work since BeOS, but this was the first time I got to see him present. What a treat!
Hence the "effectively" qualifier. The physical force of running water is enough to wash off the top layers of microbes but even a small amount of bacteria can cause food borne illness so no matter what you do there will be a risk. If you dive deeper into the FDA recommendations there are toxicity reasons for not using soap or dish fluid and they actually recommend using a brush to clean firm vegetables and fruits because the abrasive movement is far more effective.

I recommend reading the CDC's studies of outbreaks which point out that in many instances the source is cross contamination of bacteria that can't be washed off due to specific molecules that adhere to the surface of produce. The CDC deals with crises and it's in a better position to study food borne illness than the FDA, which provides general advice with nearly a century of history tracing back to the progressive movement in the US. That advice is not necessarily up to date since our treatment of food has evolved to included irradiation, waxing, safety codes, etc. which get the vast majority of microbes to begin with.
Another way to look at it is checksumming is something that should be done at a generic lower level block layer, not the filesystem layer.

Do it in CoreStorage, not filesystem X.
Ok, I have only used Django's ORM and a little bit of SQLalchemy, but in both cases you are defining the database in a Python file. Django's models.py file usually maps directly to database tables, and is less verbose than writing SQL create statements.

Maybe I don't see any advantage in what your doing, as I treat the database model as the most important part of the application (or maybe thats the same as what you are saying). Get that correct, and code falls into place easily. Start hacking rules in at the application level and eventually it gets messy. Linux said something similar about bad programmers worrying about the code, and good ones worrying about the data and its relationships.
This is a fake story. The Petitions Comission know what they're doing and remove fraudulent signatures.

https://twitter.com/hocpetitions/status/747063424132255745
Cloud Data Centers Are Poised to Take the Spotlight
Really? connection.exec_, .map, .build – there's a lot more non-SQL going on in the second example than the first. The first may be syntactically far from SQL, but the use of familiar vocabulary makes it pretty understandable from a SQL point-of-view.
> If you're not using an ORM, then you ultimately end up writing one.

I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from your framework with an ORM). For convenient access you can roll 30 lines of Perl to wrap DBI or whatever (I use Perl for most web backends these days) and call your stored procedures in normal syntax with a little metaprogramming.

Maybe this sort of scheme (heavy usage of stored procedures and offload almost everything to the DB) doesn't work for everyone, but I like databases and it works for me.
Never seen a large enough project that relies on an ORM be anything other than a giant mess. I mean never. The conclusion is correct. From an application perspective the db is just another API and should be treated that way and the ORM should just be thought of as a convenient DSL for creating queries on top of that API.
I began programming in languages where SQL was a requirement in 1999; only in the past 3-4 years have I use ORMs. I often write a lot of raw SQL, but I find a well written ORM statement communicates intent more quickly.
The book sounds interesting, but how is it different from The Eight Day of Creation?
> re-enter my Apple ID password

I find it absolutely infuriating that this is necessary even when "purchasing" a free app.

The #1 reason I will not buy an app is because I do not want to deal with entering my Apple ID password yet another goddamn time.

If your phone shuts all the way down with any regularity, it's a nightmare.
Ok, I have only used Django's ORM and a little bit of SQLalchemy, but in both cases you are defining the database in a Python file. Django's models.py file maps directly to database tables, and is less verbose than writing SQL create statements.

Maybe I don't see any advantage in what your doing, as I treat the database model as the most important part of the application. Get that correct, and code falls into place easily. Start hacking rules in at the application level and eventually things start to get messy. Linux said something similar about bad coders worrying about the code, and good ones worrying about the data and their relationships.
Interestingly, Dominos pizza used to be pretty good (or at least, better than it is now) about 30 years ago. The dough was a simple recipe of flour, water, yeast, salt, and a little oil. They used real baking ovens at that time and each pie had to be monitored by a halfway skilled baker who would watch for and pop excessive bubbles in the dough, turn the pie so it would bake evenly, and pull out the pie when it was done but not burnt (a difference of about 30 seconds time span).

Now they use a conveyor belt convection oven which requires very little skill but it's like baking the pizza under a big hair dryer. It dries out the crust more, and they had to change the dough with additives to reduce bubbles. The result was a lower quality pizza, less flavorful crust, that required less skill to bake. For them a win, I guess.
Does not eliminate room noise. If you have worked sound on a film or TV set I'm sure you are familiar with capturing room noise on a quiet set to mix in during post.
Why do you consider RMS to be your enemy?
Again, for Dublin only. A quick search of all properties for rent in Dublin on the market leading website (daft.ie) comes up with 1,437 properties, and that's without any limitations to the search. A quick search on AirBnB for just the next weekend (in the middle of tourist season) finds "300+" listings. That's a very rough snapshot of course (e.g. there might be many double listings), but it hints at the potentially large portion of properties that could be off the long-term market thanks to AirBnB (and their competitors, for what it's worth).
No, they don't. There's clearly more than 70000 fraudulent signatures if there are 30000 from Vatican alone.
You're assuming they used a consultant. I doubt it.
Pardon me, but...

Holy shit, NPR's fascination with sound effects. Yes, I want to listen to 15 fucking seconds of someone chewing loudly between paragraphs. Sirens, crowd noises, people talking about something undoubtedly unrelated in Urdu.

Dear god, NPR's signature sounds are why I don't listen to it.
Well I've met people who've worked on the app, and I doubt that both these folks and a GDS team would miss the major hostile use case of the app.
There were a few NTFS drivers for Linux. The native ones didn't support writing, but the ntfs-3g drivers I recommended do. ntfs-3g runs on FUSE, so it's not a native kernel driver, but honestly the slowdown from running in FUSE is hardly noticeable and they've been stable for at least 10 years. So you shouldn't have any issues running ntfs-3g.

I don't know the answers to your other questions. Sorry.
You can write well written modular SQL that supports changes and can be read by a competent developer.
APFS is slated for a 2017 release, yet development started as recently as 2014. By comparison, development on Btrfs started all the way back in 2007, yet many still consider it to be unsuitable for widespread deployment, particularly in mission-critical settings.

If Apple can actually pull off this turnover so quickly, does that suggest the complaints about Apple's declining software engineering quality were overblown?

Edit: Ted T'so in this talk(1) (at the 8 min mark) discusses the taskforce that birthed Ext4 and Btrfs and its estimate (based on Sun's experience with ZFS, Digital's with AdvFS) of 5-7 years at a minimum for a new file system to be enterprise ready--an estimate which definitely proved optimistic with regard to Btrfs. Will APFS be different?

1: https://www.youtube.com/watch?v=2mYDFr5T4tY
> Is this not a blatant layer violation?

This is the one of the areas a recording engineer's problems are different than a software engineer's intuition.

In software, we have a lot of problems that can ultimately be traced back to not having good "visibility" into the software or its state. This has various far-reaching consequences, from specialized tools to examine software (such as debuggers) to cultural values ("one job per component") that help us reason about complex systems we cannot see.

But in the case of audio, we have a multiple sensory organs to directly perceive sound. A bad audio engineer would be able to push a few buttons to move his headphones around in the signal chain and know in seconds where the EQ is occurring. A good one would simply know the U87 rolloff "by sound" and would not have to conduct any investigation at all.

There are some cases where more detailed analysis is done with fancy tools–mastering song recordings, for example. But in live sound, an audio engineer's primary concern is UX, because good UX is the difference between solving a problem quickly and annoying pops or worse. One button that engages a good EQ is much, much better than something like this: http://adn.harmanpro.com/product_attachments/product_attachm.... And epoxying the single button to the correct position is even better still!
The much bigger problem is that copyright doesn't allow people to scan books/magazins and distribute the scans. As DanBC writes "Climate controlled storage [...] is expensive". On the other hand: Disk space is very cheap (even if you want high redundancy).
Painting math on the wall
In Hawai'i produce shipped from the mainland can come shrink wrapped, such as cabbage. But also there is a lot of local produce here, so it's easy to avoid that. I think mostly it's also the "Western" style to ship something all the way to Hawai'i when it is growing not too far from the store itself.. a lot of local people shop at stores like Safeway that stock shipped produce.. it's unfortunate but it seems to be cheaper.
What about Trader Joe's? Good quality at more reasonable prices.
By that reasoning, "Democrap" is a signifier for an exclusionary (and thus anti-democratic) line of thought.
> An ORM provides type checking at your application layer

This. When composing complex queries, we really want type checking and SQL injection safety.
While I agree that the article raises an important point, I don't really see how more diverse development teams would have fixed any of the problems raised.
Not in my experience. Please show me actual examples of "well-written modular SQL" in a real application.
>Why does the "confirm password" field exist anyway? It exists to remove the risk of input error. They want to avoid you locking into a mistyped password and not being able to recover.

It seems silly to force everybody to doubly enter their password, when I'd guess at most ~10% of people might enter an incorrect password on their first try at which point those unfortunate ones are only a few minutes away from a password reset... where they would be sure to get the password right that second time.
Not yet. I have had a quick look at ldns (https://www.nlnetlabs.nl/projects/ldns/) which supports parsing DNS packets from wire. I will probably replace the DNS implementation with either libldns or c-ares.
Appealing to emotion is such a poor rhetorical device.
Respectfully, please color me unsurprised that two traditionally marginalized groups in American culture just happen to have problematic "styles of speaking, learned to conform to a peer group, relatively easily changed".

I agree with what Alex Goldman from Reply All has to say about this phenomenon.

What reading I've done about this suggests that to the extent the phenomenon is empirically grounded at all, it applies both to men and women, while complaints about it are almost entirely gendered.
It's obvious. You are either in the Pacific Ocean or the Atlantic Ocean!
I wouldn't say the ORM is Djangos strongest point. Its great for simple stuff, but not great for any moderately complex queries (e.g. extra conditions on a join, subqueries, conditional aggregates - though I think that last one may be solved in the most recent version).

I don't think they have done a bad job with the ORM, but you really ought to know SQL as well.
Hilarious Graduation Speech Inspired by Gucci Mane
You are talking about fraud (I'm assuming wire fraud, chargebacks, stolen accounts, etc.) which I would put in a different category of risk for a financial institution than money laundering. These activities would lead to direct losses, whereas money laundering would not.

I assume allowing laundered money through your institution is of less concern, since it would not lead to a direct loss to the institution. This is assuming you are not knowingly allowing the laundering to occur and you are following all AML and KYC regulations meant to prevent money laundering. If these standards are not met, it may lead to fines and having regulators watch your institution more closely.
Oh Wow!

They have Byte, too... https://archive.org/details/byte-magazine-rescans
Looks about right, the circle around Columbia is not shaded inside - that is, the center of the circle is on the other side of globe. So Virginia lies in the most heavily shaded region.
> I've always said: "ORMs are for people who don't know SQL!"

False. To use an ORM you must know and understand data modelling and the Entity/Relationship model. I'd say, people who don't like ORMs are often those who don't understand that model.

If you do understand it, then you know that relationships can be represented 100% by code in an OO language, thus completely automated.

Why bother writing your own hydrators for each entity when you can model them directly in a library? it doesn't make a codebase more maintainable or readable.

Furthermore you could have an ORM that uses SQL directly for queries, and still eagerly resolve relationships. It's just not practical, that's why ORMs often come query builders.

That is the thing that abstracts SQL, not an ORM per say. ORMs only deal with relationships between entities. Query Builders build SQL queries.
Easy, there. Librarians aren't the bad guys in this story.
{"name":"Vatican City","code":"VA","signature_count":58} Where did you get 30000 from?
Dunno about then, but there don't appear to be anymore: {"name":"Vatican City","code":"VA","signature_count":58} See for yourself: https://petition.parliament.uk/petitions/131215.json

It's entirely plausible that whoever wrote the script intentionally designed it to submit a large chunk of votes from "Vatican City" to try and discredit the petition, especially given /pol/'s political leanings.
But having their own software still gives them an edge - that's why some companies are actually going the other way entirely - like Weta writing Manuka renderer and Animal Logic writing their Glimpse renderer. It allows them to iterate extremely quickly on-depand for shows that have issues and design things properly, instead of shoe-horning existing (and often badly designed and implemented) open source software that can do simple stuff, but wasn't designed with full flexibility in mind.

Different pipelines work in completely different ways, and what works for one studio doesn't necessarily work well for another.

However, I do agree in principle that given a clean start (Which is never going to happen given the hundreds of thousands of lines of code VFX studios have in plugins for proprietary systems) it would make sense for all VFX studios to share a loose framework application that very flexible and advanced plugins can be written for. Image Engine's Gaffer is probably the best fit currently.
In some respects it looks like Fabric Engine might at some point fit this bill, however it's not open.
Also Records for Python: https://github.com/kennethreitz/records
Requiring input twice as input validation has a fair amount of use already, like with email addresses, so it doesn't seem super unreasonable to think that's a motivation for this limitation.

Also, while it sounds silly, disabling copy doesn't mean a user can't type the PW somewhere else and paste it in. I've totally done that before and suspect it's not super uncommon.