FuzzyDunlop

I agree, and it's easy to tell just in the way you can describe it. The first thing video/audio chat brings to mind to anyone is 'Skype in the browser'. That's still cool and there is definitely more potential than that, but just having an arbitrary connection is a lot more open ended and exciting.

Given this is ruby code, I think it's acceptable, and well-structured enough to be understandable.

While the implementation itself might be a bit 'eugh' because of the meta-programming involved, there was enough thought put into code organisation to allow you to grep `RowType` to find the module that namespaces all these dynamically instantiated classes.

Hell, if the code in the tree was arranged correctly, then `tree | grep row_type` would give you the folder where they all lived.

Are you basing this on how often the vulnerabilities get reported and upvoted on HN?

http://www.hnsearch.com/search#request/submissions&q=dja...

Django has had its fair share of patches. This is no reflection on the quality of the project, as it shouldn't be for any sufficiently complicated framework (like Rails).

I also think the vulnerabilities are similar enough to suggest that the first one gave valid reason to ensure the same issue doesn't occur elsewhere. Rather than dusting these issues under the rug or silently fixing them, they're being responsibly reported with patches and updates provided at the same time.

This doesn't seem like broken process to me.

    window.setInterval(function() { 
      $('img').mouseover(); 
    }, 500);

So you can catch the ones that haven't been created yet.

I really wanted to order a Nexus 4. I couldn't, so I got an iPhone 5 instead.

I'd consider that a failure on Google's part, for a total lack of communication, and for seeming conflicts of interest when the same device is offered subsidised by a network (defeating the point). It might as well be vapourware.

To someone from the UK, 'Tealeaf Academy' implies that it's a school for thieves.

Tealeaf being Cockney rhyming slang for 'thief'.

I think the example for that is bad, when you look at what it's trying to explain.

   def foo_matches?
     @foo == :bar
   end

It returns true if it does, and false if it doesn't, as opposed to true or nil. Which is miles better than any of those alternatives.

It also failed to consider that the naming of the method and the usage of Ruby naming conventions is just as important as what goes on in the body.

I've encountered it once with a form, although it was a while ago and if I saw the code again I might be able to identify what was wrong. In that case it was probably a poor choice of element to attach to that caused the callback to be fired independently multiple times on one click, and stopping the bubbling had no effect.

The other time was in a Rails app, where a script was added to a partial for a layout, and then added again later on (by a different developer) to the layout itself. That caused a particularly nasty bug since it used 'toggle', and thus the second callback negated the first.

Apparently nothing is sacred when it comes to trying to make a quick buck.

Or reference HTTParty from git, which has been fixed, in your Gemfile:

https://github.com/jnunemaker/httparty/commit/53a812426dd321...

Correction: Although this might not have much to do with multi_xml if that security risk isn't mitigated.

We have those quite a lot in the UK (along various motorways), although they're typically only turned on when congestion starts to build up.

> The code produced simply doesn't matter. Bitrot is accepted. Nobody cares.

It's a real bug-bear of mine that, in the profession as a whole, this attitude is rarely criticised, and sometimes even praised (especially on HN with the JUST SHIP IT startup mentality).

A lot of people are fine with this and can probably offer a lot of reasons pertaining to business interests, which is fine. Those can be measured, deliberate compromises backed by sound reasoning and opportunity cost. But there's this other school of thought that just thinks, "fuck it, it's just code innit."

And it seems that newcomers to programming (in PHP/on the web) are still being taught at that school.

To be fair, prepared statements have been a solved problem in PHP for a fair long time now, and so it's totally okay to call out the notion of "quickly learning from mistakes" when a subset of that community still doesn't use or encourage them.

When I use these things (and even pagination sometimes), I might find something I like, but it's so easy to browse ahead that I'll skip over it in the hope that I'll find something I like even more further on.

At that point, there's no easy way to get back to what I originally liked unless I had the forethought to open it in a tab or remember it exactly.

As for the metrics, it depends on how the business wants to position itself. It's evident from the quote that they care more about just the sales and would prefer to encourage more engagement with their site.

The distracting sound effect brings back vivid memories of saving my progress in Resident Evil.

Of course. My main point wasn't the use of querySelector per se, but the ability to access the exact DOM element(s) you need without crazy querying or traversal.

While the DOM API isn't perfect by any means, and jQuery fills that gap really well, there are still times where the OOP nature of the DOM gets you exactly what you want with minimal faff.

The other problem is the relative obscurity of it thanks to jQuery and crowd-sourced DOM documentation (via MDN).

> Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly.

Which is sort of a shame because there's stuff in there that totally obviates the need to haphazardly traverse the dom with jQuery.

Finding the form an input element belongs to in jQuery:

    $('input').parents('form');

    // or probably
    $('input').parent().parent().parent().find('form');

Finding the same thing using the DOM API:

    document.querySelector('input').form;

You'd want to mix those two, in a real use case:

    $('input').on('click', function(evt) {
        var form = this.form;
    });

Then you don't even need jQuery to use the FormData API:

    // where `submit` uses XHR2 to make a request
    <input type="submit" onclick="submit(this.form)">

I totally disagree.

They weren't thorough enough to really bother with much of the text anywhere, given the amount of lorem ipsum and many-gendered John Smiths.

Content wasn't really top of the list of priorities, it seems, which I think is a bit of a mistake if you're trying to 're-design' something driven entirely by content.

Despite that, this concept is pretty much all about an in-your-face layout of pretty pictures that looks incredibly difficult to make any real sense of, and might as well be a collage of 2013's cargo-cult trends-to-come.

From the sounds of it, and in reference to everyone using the term 'patent troll' here, I think this particular instance could be more appropriately labelled as 'patent scamming'.

It seems easy to blame the magic finders for this (because they seem magic), or ActiveRecord alone, but really the problem is that 'secure by default' can trick you into thinking the framework will do it all for you.

It probably will most, if not all, of the time for you. But the complexity of such things understandably means there will be obscure vulnerabilities that are hard to track down.

Sanitising -- and even validating -- your params at the controller level is a nice way to stop some of these problems before they reach your models.

I think it's nice that you can basically document the expected response, in the form of creating a type with a struct.

In pseudo-code-ish:

    type FacebookUser struct {
        ProfileID int
        Name string
        ....
    }

    json.Unmarshal(response, FacebookUser)

Compare it to the implementations that just give you a hash:

    json_decode($response);

    json.parse response

Yeah, you can document it with comments, or visit the API documentation, but you can fix the code and let your comments go stale. You fix both your documentation and your implementation in one go in the first example.

It's certainly why I find it more appealing, anyway. Makes me feel more secure in my code.

If it was in the UK it'd never happen anyway, unless the kid buys fake ID and sends the info to the network to enable adult content.

"You must not use this phone to falsely identify yourself as an 18 year old."

I wouldn't be surprised if they were confusing to the smart kid who read them and found contradictory statements. Things like not using your phone in certain situations but also never ignoring calls from parents.

I wouldn't do it. It feels too authoritarian and there are a lot of things in there that are best learnt the hard way, or as and when it happens. And as has been said in other comments, this doesn't exactly seem like a present.

With the kid becoming a teen, it'd probably end up backfiring on the mother when he buys a burner to do all his sexting and banter.

Ignorance may certainly be bliss but dismissing something because it presumably didn't happen in America takes that idea a bit too far.

> Speaking for myself, I have no respect for authority that does not stem from experience, knowledge, wisdom, etc. Air hosts/hostesses have none of those attributes..

s/no respect for authority.../no respect/

Flight attendants have experience of being flight attendants, moreso than you I assume, and they're doing the job they're paid to do (which is in part to enforce those rules).

Ironically, the image at the top says 'replace by' when it should be 'replace with'.

You can also use Ctrl+T to get the status of a running command, instead of faffing about with pids and kill.

Unless you get that feeling because you, say, suffer from depression (as I do), where that might progress to "I don't even want to be alive."

But even before that, the feeling isn't one of having everything you need already. It's one of almost crippling apathy.

I don't like this, because then it means I have to change my repo to make a Github feature work, when Github has whole configuration UIs on their site for both my account and my repos.

Also I don't see the problem with opt-in. If your bot/plugin/service is worth its salt you'll be putting some effort into marketing it (which includes explaining how to use it).

The alternative is Github marketing the opt-out, which seems a bit strange if they're launching a feature and advising users how to not use it so they don't get spammed.

The thing I noticed about NoSQL is that, at least with Mongo, you just end up putting your schema in your app. You probably do it by saying a particular class has a bunch of fields or instance variables that you expect to be a certain type.

I wrote a portion of an app that relies on Redis, and despite the fact that it's really nice to work with, especially in Ruby (that practically mimics Redis' native API), it was incredibly difficult to remember the structure. What keys do I need? What type are they? Oh I'll have to do `KEYS *` and look I guess. Then I'll remember to document it (and thus create the schema).

Of course, the problem on my part was, in part, that I probably didn't need to use Redis. And when I needed to use Mongo, well, I wasn't storing things that look like documents. I think this is an easy mistake to make, but one you learn from quite easily once you've experienced it yourself.