alanctgardner2

Why, pray tell? Isn't the Google CDN:

- faster for people in different geographic areas

- at least as reliable as your infrastructure

- already cached (this would be nullified by your proposal)

I ask because normally I wouldn't think twice about using the Google CDN libraries.

I don't think energy efficiency is really so critical as the control system: how much steady-state error is there, and how quickly can it initially heat the room? Overheating the room is obviously a bit of a waste of power, but it's also uncomfortable.

> What they didn't say on the package WITH CAPITAL LETTERS was that it was a RAID0/JBOD of SSDs with zero redundancy

This really shouldn't matter to the consumer - there are lots of ways to couple components in a black box to increase the rate of failure. They don't disclose to you how the controller is built, or how they go about marking bad blocks, so why would they say in bold letters that under the covers they're striping across two disks?

The best advice I've ever heard about networking had to be "keep asking questions". If you want to initiate a conversation, try to learn about the other person. A lot of people (myself included) think, "Oh, I'll start with a hilarious anecdote about myself" (or a joke about the venue, comment about the event, etc.). This is terrible, and it gives the other person nowhere to go - either they agree and say yes, or they disagree and you're fucked. If you open the conversation by getting the other person to talk, you can pay attention and think about what they say. At this point they're either genuinely interesting, and you keep going, or you politely find an excuse and get the hell out. Let people talk about themselves, but don't get glued to a middle manager at a carpet factory for an hour because he has a million stories about accidentally delivering the wrong pile, or whatever.

I would actually contrast Fring, the bootstrapper, with Heisenberg, the VC-funded startup. It's clear in the fifth season that Fring had slow growth and scaled his operations gradually, while the newcomers just keep throwing money at the problems. They were agile, but they had very little runway, and they had to keep raising rounds (from Tuco, then Fring) to keep the lights on.

You're right! This single, reasonable opinion from one of the thousands of informed people who happen to work on a wide variety of products from this particular company threw the discussion way off! I'm glad we have your reasoned opinion to put things in perspective. Now, how about we go burn down Mountain View?

OK, to get this out of the way: the law in the jurisdiction he's being charged in explicitly considers this to be rape. It's not trumped up by the media, it's how the law is written.

> It's sad to see that the presumption now is that a man is guilty

The presumption is that he is accused, and he ran away and never had a trial. You can't really run away from the trial forever, hide behind the "presumed innocent" doctrine, and say it makes you a saint. It just means you haven't been convicted, because it was mechanically hard to get you to the right place to convict you.

> would you consider it rape and a crime if a woman said she was on the pill, and slept with you, and it turns out she was lying about it?

Condoms offer protection from STIs, as well as pregnancy. Lying about using a condom potentially exposes your partner to myriad health problems, in addition to unwanted pregnancy. So no, it isn't equivalent to lying about using the pill - lying about the pill doesn't change your risk of contracting HPV, HIV, etc.

If a woman lies about using birth control, and she does conceive, she's either going to have an abortion (which is physically and psychologically traumatic), or go through pregnancy and birth. The father has some obligation (which he could probably be free from if he can prove she lied), but there's not really any physical risk there. He's not going to catch a life-threatening disease from someone lying about the pill.

This is similar to slut shaming. How someone acts before, after, or any other time doesn't affects whether they wanted to have sex in that instance. You could walk around in bondage gear all day, it doesn't mean you're asking to be raped, or change the legitimacy of accusations of rape. If someone has sex with you against your will (or in this case, they don't use protection and claim they did), it is a crime. Full stop.

The FDA just wants to make sure that 23&Me's tests are accurate, which could actually lead doctors to trust them more rather than replicating them at the patient's expense.

CAP theorem can apply to any clustered system, it doesn't have to be multi-site. What happens if 6 of your 12 machines die? What if they get cut off from the other 6?

edit: There's a bit of discussion further down about the SQL implementation. That's something I was very curious about as well. The projects linked below spend a lot of time working on supporting full ANSI SQL, and reducing latency by pushing down as many operations as possible. The Overview page doesn't appear to mention how filtering, aggregation, windowing, etc. work in your system.

Also, I noticed on your website that you compare InfiniSQL to Hadoop. How do you feel it compares to Impala (http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-t...) and Shark (https://amplab.cs.berkeley.edu/projects/shark-making-apache-...)?

Waterloo has been prestigious for at least 5 years (when I was applying it was among the hardest Canadian universities to get into, and it was already globally recognized). The only thing that has changed is more VC money, and more startup incubators, drawing the interest of progressively larger institutions.

I think the whole "meritocratic" argument is stupid. But it's worth pointing out that Waterloo is a self-fulfilling prophecy: a lot of startups are being founded because a lot of support and infrastructure is being thrown at the students. Whether the students are more suitable than others is anyone's guess, but they're in the right place at the right time (and they can afford the tuition).

I'm a little skeptical:

- a bunch of the novel components (the UPS aware persistence layer, for example) aren't actually built yet

- they're pushing for people to build businesses on it already. I would characterize it as "bleeding-edge with bits of glass glued on", so this doesn't seem entirely honest.

- there's mostly a lot of breathless talk about how great and fast and scalable it is, but no mention of CAP theorem. To boil down their feature set, it's an in-memory RDBMS using the Actor model.

I don't think she did it to be hip - I'm sure she had many doctors advising her, and she underwent many tests before making her decision. But it was heavily publicised, and it set a dangerous precedent that people with less access to medical resources will send away this $100 test, see "cancer risk", and start pushing for unnecessary surgery.

A TSV is typically referred to as a "flat file". You're going to get a lot of confused looks if you talk about a "TSV database".

That said, you can:

- create an external table in an RDBMS (any of the above will work), which allows you to work on a flat file in place: http://www.fromdual.com/csv-storage-engine

- import the TSV to an RDBMS, work with it, and export it again.

I'm sure someone has written what you're asking for, but I don't get the appeal. RDBMS aren't scary, you can install MySQL and work with it for free, and if you use the GUI tool you don't even have to touch SQL.

edit: Excel is a tool that can edit TSV files, and as a bonus it looks and works exactly like Excel. What exactly do you want?

That example is a bit severe, but I think the Warfarin compliance example is spot-on. You receive a prescription for a drug, but your magic internet test tells you to take a lower dose, because you're "sensitive". Then you die of an aneurysm because the test was wrong.

People are completely stupid when it comes to medical issues. I heard a woman complaining that she couldn't eat honey because she was allergic to fructose. I work with at least 3 "gluten-sensitive" people (it's pretty unlikely they all have Celiac disease, it's not a big office), because it's a hip thing to do. Hell, didn't Angelina Jolie have a prophylactic double mastectomy?

edit: Since everyone is jumping on the Angelina Jolie example. I don't think her decision was made based on a single spit test. And I think she had doctors advising her. But the amount of publicity it got makes me worry that it could become needlessly popular based on self-diagnosis (like not eating gluten).

Most databases have a companion GUI tool that will allow you to "edit" the database visually; what DB are you using?

pgAdmin (Postgres) - http://www.pgadmin.org/

MySQL Workbench (MySQL) - http://dev.mysql.com/downloads/tools/workbench/

SQL Developer (Oracle) - http://www.oracle.com/technetwork/developer-tools/sql-develo...

I strongly recommend learning some SQL though; this will give you the ability to bulk edit columns and apply formulae.

In my experience from debugging C programs:

- Use valgrind (or gdb)! Your segfault should be simpler to find than a memory leak, because you know what line the segfault happens on.

- If you have a value that's getting mangled (pointer getting overwritten by a write to another address) and you can't figure out why, use watchpoints to see when that address is getting touched. http://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.htm...

- Find a minimal program to reproduce the problem. It's gross, but I used to actually just take a copy of the code and cut things out until the bug stopped, then look at the last thing I cut. You can do this as a binary search - only run the first half, check for the bug, only run the second half, check for the bug, repeat on the buggy half.

As I said, segfaults are a lot easier than this kind of problem (not that they're easy when you start out). Don't be discouraged! I would help out too, but you'd need to send everything to reproduce the bug (client code, server code, server platform, etc.)

> Programming is the critical thinking aspects of developing software and a skill that everyone should master: starting with children.

That's pretty much the opposite of my point: programmers want everyone to think like programmers (per your definition). In my opinion, this kind of "critical" thinking is not necessarily a positive: there are other ways to think critically that don't map well to programming. This seems like the typical HN view that everyone should think like I do. Some people don't get math, or symbolic logic, and that's not stopping them being a value to society.

Looking at your profile, it seems like you have a horse in this race. Personally, Visual looks very slick, but I don't think visual representations are really appropriate for programming beyond toys (or maybe data modelling, but not procedural programming). It gets very hard to lay out a large program in 2D space, and the toolbox required to enumerate all the built-ins and libraries seems like a bit of a handicap compared to just typing them.

> Engineers seem to have a certain predilection to talk over people

That's overly general: a lot of programmers may be socially inept, but it's neither necessary nor sufficient. Both the examples from above are pretty anti-social, but they also don't happen to have these skills. Likewise, I know some very good programmers who are also good at requirements gathering and collecting domain knowledge, which entails learning from experts and listening to them.

> The tools we've created for computing are heavily dependent on symbolic logic.

The whole notion of computers, for better or worse, depends on symbolic logic. You'll have a hell of a time building a microprocessor whose instruction set is paintings or dance moves. The best case is that we build an interface from symbolic logic to this new, more approachable paradigm.

> They make amazing interactive art pieces.

How much logic can you put in an interactive art project? Can it model anything in the real world? The biggest problem with other paradigms is density: if you want to program via something other than symbolic logic, get ready for incredible fatigue as you try to turn a 10K LOC program into a 500MP painting. Or an 18 hour long dance.

I guess I should clarify: I don't think non-programmers are lesser beings, or that they can't model anything in their heads. But for the sake of programming, the only thing that matters is if you can model a computer. If you have other types of intelligence, that's fine, just know you're going to have a tough go of it when it comes to understanding the code you write.

People seem to think the difficulty in coding is the mechanical act of writing code. "If only you could draw code!", they cry, linking together a series of blocks to represent program flow. The thing is, even if you make a language where it's impossible to fail (every program does something, it's visually intuitive when a program isn't valid), it still doesn't necessarily do the right thing.

The difficulty in programming isn't the mechanical act of writing code; we have copy-paste for that. The problem is having a mental model of the program execution, and mapping it to the real-world problem. This is the difference between good and bad programmers, and it applies to the population at large.

Case in point: I'm working with some soon-to-be grads from a CS program. In Java, one of them instantiated a class, and set an attribute of that instance. Elsewhere they instantiated a new instance, and tried to read the value back. And they couldn't understand why the value wasn't set, Portal-style, in their new instance. This guy, who has been in school for 4 years for CS, also couldn't figure out why it made sense to make specific shapes (circle, square, triangle) children of an abstract Shape class. He could, very easily, add a Search bar to an Android app because he had seen a tutorial on how to do it - but making the bar do anything was a tremendous feat, because it wasn't just the mechanical repetition of some pattern.

Even with experienced (>5 years) programmers, I've seen some really terrible debugging where it was clear the person didn't have a mental model of the code. They never really got any benefit from GDB, because when they looked at the internal state of the program they just shrugged and said "Yeah, looks right". And they owned the codebase. This was their code, and they couldn't reason about it.

After all that ranting, my point is: you can make it easier to write some program, but you can't make it (appreciably) easier to write the program that you need.

What's a typical input size, if you don't mind me asking?

Why bring Hadoop into it? MR is a paradigm for parallel programming, and having it compiled into OpenCL for you is hugely convenient. But the best Hadoop use cases always leverage massive storage capacity: people who do ML on Hadoop are doing it because the data is already in Hadoop, not because it seemed like a nifty thing to do. Do you actually leverage HDFS and the Hadoop scheduling infrastructure to run ParallelX jobs? Or can you safely jettison them and just sell this as: "Write your ML/graph analysis/whatever code in Java, have it execute on a GPU"

Also, what are the limits like for input data sizes? I've done a little OpenCL, but I've never gone past the GPU RAM size.

Has anyone had an experience with KS where:

- the product shipped on time

- the product worked as advertised

- the founding team didn't go overboard

In all the Kickstarters I've seen, it seems like the founders lose interest in actually delivering a product after they get the money. They run up against the challenges of support and manufacturing, and they seem to just skip on to the next thing because that's what they enjoyed in the first place - having a cool idea and getting it funded. Sometimes the next cool idea is just scope creep for the current product ("Sorry we're 3 months behind on shipping, but now it can also mine Bitcoins and chop salads!").

My point being, I don't think KS will ever work for technology, because the funding comes at exactly the point where the project stops being fun. Besides the guilt of providing a product to backers, there's not a ton of incentive for a small team to keep building after they get funded, so they'll just delay and peter out, or punt on key objectives and move on.

The data still lives in HDFS, so Sqoop is the preferred way to export to RDBMS as far as I know.

In the same way that 20k a year and 100k a year are fairly close salaries ;)

Full time - Ottawa, ON. Remote OK.

We're trying to increase the effectiveness and availability of mental health services, and improve the lives of millions of people. We're looking for a CTO to establish our tech stack and build our engineering team. If you're interested, send your CV and GitHub to steven.daniel.andersson@gmail.com. Significant equity is available in addition to salary.

In a class I took on image processing, this was offered as the definitive way to do non-integer scaling. Apple certainly didn't invent it.

I think that's a very narrow view, and it leads to a situation where female applicants might use the school as a 'safety' - it isn't desirable, but it will definitely accept you to boost numbers and look "equal". A better approach, which I think the OP promotes, is to look at why you don't have as many female applicants as other schools. If your messaging is turning off the good female candidates, who know they can get into the school they want, then consequently you will either accept less-good female candidates (under a quota system), or have a significant imbalance.

Not necessarily, but they do have less women than the average French school, and the OP gave a bunch of serious reasons why this might be the case. They could try to eliminate those policies, and see if it increases female enrollment.

The stuff that I've mixed up (not real Soylent, but from the HackerSchool recipe) has a significant amount of flour, which makes it very thick. The way I mix it it's more like a milkshake, and it feels very hearty. Whether or not I get hungry after mostly depends on how bored I am - I would have snacked anyways.