wldlyinaccurate

And a reply from an ex homeless outreach worker: http://imsorrythatimlikethis.wordpress.com/2014/06/07/the-sp...

I think the cherry-picking example borders on being too long and complex, but I'm hoping it still gives that "aha" moment when you realise that you've just done a rebase the hard way.

Great suggestion about --onto, thanks! That is a tough one to explain in a concise way, but I'll give it my best shot.

Author here. This is something I hear a lot, and I agree with it to a certain extent, but I purposely left out any mention of GUIs for a few reasons:

1. The guide is intended for people who want to take a look "under the hood". This is really difficult to do through GUIs, which tend to hide all of the implementation details.

2. As a child comment mentioned, even if I include GUIs in the guide, I can't possibly cover all of them. This just confuses things for people who use GUI X when the guide only talks about GUI Y and Z.

3. It's much easier to write the guide using CLI examples. I wrote this over the weekend; I don't think I would have completed anywhere near as much of it if I had to keep taking screenshots, cropping them, uploading them, etc.

Besides, there are already plenty of other guides that talk about "how to use Git", "how to use GUI X to do Git feature Y". I wouldn't want to detract from the main goal of this guide which is to give people who are already comfortable with Git that extra push to "get" how Git models and interacts with your repository.

It's extra work for website owners to build/test/maintain opt-out functionality. Have you considered offering a pre-built opt in/out widget which can be re-styled and integrated easily?

Or you could even just provide website owners with a "global opt-out" URL that they can stick in their footer.

The CrowdProcess team are doing some really interesting stuff. Essentially, they're making distributed computing more readily available than it has ever been -- if you can write JavaScript, you can dive into distributed computing.

And with browsers advancing so rapidly, I'm really excited about what will be possible on this front in a couple of years time. Imagine being able to run computations on thousands of GPUs without having to distribute any software (think Folding@home, SETI@home, etc).

> And how hard is it to embed SQL for a few specific queries even when using ORM

This is the thing that many people seem to forget. Every ORM I've used has allowed you to write your own SQL for those times where the DBAL is limited or not performing well. In my experiences, those times are rare. Some ORMs (like Doctrine) even have their own DSL so that you can write complex queries and still have the benefit of a DBAL.

I'm currently working with a team on a large project where all the SQL is written by hand, and results are hydrated into plain ol' arrays. The maintenance overhead for schema changes is huge due to the number of queries which need to be updated, and there are constant bugs caused by columns being left out of SELECT statements. On top of that, the testability of the entire app suffers because most methods talk directly to the DB. It's truly a nightmare. I've never experienced these problems with an ORM.

Is it just me, or does this not seem "tiny" at all? It seems to require a bunch of Closure modules, and on top of that the source itself is hundreds of lines (albeit with comments).

Nitpicking aside, it looks like an interesting approach to decoupling the DOM from your event handlers. Personally I'm happy sticking with the standard on{event} attributes for really simple stuff.

Usually that can be achieved with a cache like Varnish. One of the biggest benefits of static site generators is that the only software you need on your server is a web server. As soon as you want to start adding things like search and comments, you lose that benefit.

Currently using Postgres, but not utilising any of its more powerful features.

I only have some second-hand, anecdotal explanations. In my freelancing days (several years ago), I had clients who insisted that their websites work flawlessly without JavaScript -- some would even insist that there was no JavaScript at all. When I asked these clients why they wanted this, the answer would always be because they have disabled JavaScript in their browser, so why would they want any JavaScript on their website?

When I asked why they disabled JavaScript, it was rare to get any sort of coherent answer. Usually they would just mumble about viruses, or occasionally about privacy, but every single one of them cited "a friend" as the original source of whatever reason they had.

So my theory is that most people disable JavaScript "just because". Reminds me a bit of the five monkeys and a ladder experiment.

The major thing that ST has over Atom is that it's cross-platform. I develop on a Linux machine most of the time, so learning how to use Atom efficiently is completely out of the question for me until they bring out a Linux release.

What would replace the technical interview if we killed it?

When I'm hiring a contractor, I need to know that they really know their stuff and that they can hit the ground running if they join my team. So far, I have found a quick technical interview to be the best "bang for buck" way of doing this. People can have great CVs, active GitHub profiles, etc, but it's only when you speak to them that you realise they aren't what you need.

Phone and Skype interviews can be good, but more often than not I'd like a candidate to write up some code for me. Maybe there are some good remote pairing tools that I'm missing out on?

If people want to be messaged through GitHub, they'll put their email address on their profile.

Interesting, thanks. I had heard of Hibernate before but never actually looked into it. I can definitely see the similarities - especially between Doctrine's DQL and Hibernate's HQL.

From the very little I read of the documentation, it seems like a similar concept -- mapping the objects to the data is done outside of the objects.

I've used Doctrine 2 with PHP, and am yet to find another ORM like it in any language. It stands out as unique (to me) in that you just write plain old classes which don't need to know about the ORM. You write a separate schema which Doctrine reads and then uses proxy objects for the mapping.

Am I the only person that finds this preferable to coupling your objects with the ORM?

Stuff like this bleeds over into my "normal" life all the time, and it's starting to get really embarrassing. Correcting my mother's inaccurate typing on Facebook by replying with a sed substitute pattern only serves to make me look like a douche.

It confuses me as well. Either many more HNers than I'd expect have subscriptions to these sites, or they're being wrongly bumped to the front page by HN's algorithms.

As a kiwi, the brain drain is something that always bothered me. Right from the beginning of high school I knew that I would end up working overseas for several years, regardless of whether I really wanted to or not. And that's exactly what I'm doing right now -- I live in London, saving twice as much as I could in NZ. I don't enjoy the lifestyle here at all, and I want to go back to NZ as soon as possible to start a family, but the opportunities available in Europe (and the rest of the world) simply dwarf those available in NZ.

The good news is that immigration from Asia, India and the Pacific has given the country a significant population of people who culturally are more likely than Europeans to help with population growth. So who knows, maybe in 10-20 years the population will be large enough for the brain drain to sort itself out.

I'm curious, why do people treat Node.js and JavaScript as separate? I understand that the DOM API and Node's core libraries are different, but any good programmer can pick up new libraries and frameworks in a matter of weeks.

I just find it strange that as a JavaScript developer, many recruiters (and even some companies) won't even consider me for a Node position unless I explicitly state that I have Node experience.

No, non-encrypted passwords are an artefact of poor design and incompetent programmers. Cryptographic hashing has been around since the 70's, and cryptography itself pre-dates history.

There is no excuse --no excuse-- for storing passwords in plain text. Anybody who attempts to justify it deserves a swift thwack in the back of the head.

Is it just me or does HN appear to have had an influx of aviation enthusiasts?

Bulletproof coffee is a great breakfast (and snack) for anybody on a high fat diet like keto or Atkins. This is because while on these diets, your body has put itself in a state where it can more easily convert fat to energy. However, people on a regular high carb diet will not be able to make the most of all that fat and will just be hungry and tired after an hour.

Don't get me wrong, I think most people need more good fat in their diet. But if you're on a "regular" diet, the fat needs to be a supplement, not a replacement.

We put all of our web server config in the web server config - overrides like .htaccess need to be compiled/interpreted/whatever at the beginning of each request so they can add unnecessary latency.

Deployments are still easy. Either symlink the web server config, or (in our case) deploy an RPM which copies the config to The right location. Then it's just a matter of a graceful restart.

I hardly use stash any more. If I need to "stash" something, I just commit it. The reason this is okay is because we work on very small branches, with the aim of squashing everything into a single commit before merging it with master. So it doesn't matter if I commit half-baked code to my branch, since it's going to be squashed anyway.

This is precisely why the current "hacker culture" scares the hell out of me. The vast majority of new programmers don't understand the basics of software design; we are entering an era where software is written by whoever will work for the lowest wage.

I'm getting pretty tired of these mindless defamations of W3schools. I get it - sometimes their resources are incorrect and they almost always use bad practices. But seriously, while you're busy being an elitist asshole slamming their website, the people at W3schools are busy teaching people the basics of web development.

I wouldn't say that faster I/O is Digital Ocean's selling point - it's the price. If your bottleneck is I/O then you probably need more RAM, which Digital Ocean offers for 50% cheaper than Linode.

Regarding your other points, personally I'm not affected by the lack of IPv6 support (yet), and I don't know anybody else who is. I also think it's rich mentioning censorship and security considering Linode's history.

I've used https://www.blitz.io/ with some success

I'm gonna be "that guy" and complain again that developers (web developers in particular) really need to learn the basics of scaling. There is no point having your app publicly available if you're not prepared for small spikes like this.

Edit: At the time of posting, the service was 503ing.