FuzzyDunlop

I think the only mistake made with this patch release was merging in 250+ commits, ranging from last year to the present day. Maybe that's standard for such a large project, but it feels like a hell of a lot of tweaks for a minor release.

As for the rest - I think the issues in January has put Rails in the spotlight, and while scrutiny is certainly warranted, I think the extra pressure on the project over the past months to clear this stuff up has had its consequences.

> We also noticed that users dislike the NASCAR-style > plastering of branded login buttons.

This reminds me quite vividly of Stack Overflow's login page. I can never remember if I signed up direct, with OpenID, or Google, or whatever else is there.

I've been starting to dig Mozilla and Firefox again lately (the last week of developer tools news cemented that), so I'd love to see their idea take off and gain full adoption.

I think the OP in that thread wrote a pretty amazing post, in all honesty.

Unlike your typical "it doesn't work" or "this sucks", the frustrated individual still takes care to detail, step by step, exactly what felt wrong or what was missing. In doing so, they demonstrate exactly why it's so frustrating.

There's feedback not only on the quality of the documentation, but the experience of getting an Ember app up and running. While improving the former would make life a bit simpler, the setup seemingly being so involved - requiring you to manually resolve missing dependencies - still diminishes the initial experience.

All of this makes it surprising that someone would totally dismiss it in such an unceremonious manner, and for reasons that are totally at conflict with what doubles up as a support forum. Is that discussion board there as a flagship Discourse site, or for support?

I would hope or presume that Firefox's tools eventually do get this level of polish, though. Chrome (and even Safari) has had quite a bit of a head-start, and neither of those were shining examples of great UX at the beginning.

In spite of arguing about this 'objective' readability, it doesn't address the issue that CoffeeScript is no more readable than Javascript is, because it introduces its own plethora of quirks and crypticness. Given the choice between the two I would opt consistently for Javascript.

Hardly, considering its appearance in many programming languages. Although I would argue similarly that, if the ternary operator is terse and cryptic and needs to be changed to 'if ... then ... else ...'; then '->' and '=>' are equally terse and cryptic and should be kept as 'function'.

It says what it does then, doesn't it?

It's not an improvement though. I find it pointlessly verbose.

    isLargerThanSix = if x > 6 then yes else no

You don't need CoffeeScript to do something as redundant as that, since comparison operators return a boolean:

    var isLargerThanSix = x > 6

Of course, CoffeeScript doesn't even offer an improvement for the level of explicitness in the example, since it removed the ternary operator. This javascript is invalid CoffeeScript:

    var isLargerThanSix = x > 6 ? true : false

There are still things like the Raspberry Pi, and all the things you can wire into it, which obviate the need to spend a few hundred quid on a full on desktop PC.

After that forum post where the user claimed Dropbox had leaked their email to spammers, I have severe reservations about giving them the actual credentials to my email account, whether or not the allegations were correct.

This feels a bit sneaky: http://cl.ly/image/3c0A471T1K1X

My faith in this post continually diminished as I clicked to links I thought contained relevant facts. Instead, they were just image macros.

They could easily have been embedded direct, for what little value they offer. As it stands, it's just frustrating and really poor writing.

I actually think there's something more remarkable about figuring this out by hand, in the command line. And writing about it, just the fact that you can capture the exact steps taken with a simple copy and paste blows the GUI approach well out of the water.

This was the work of someone who knew what they were doing, of course. Had it been, say, me, then the effect and utility of the piece would have been considerably lacking.

There's a detailed write up from the author about how it all works at: http://blog.new-bamboo.co.uk/2013/02/26/full-text-search-in-...

This makes me think about why I've been receiving spam at my professional email, which I tend to use quite sparingly.

They're referring to the actual demo page: http://typeplate.com/demo.html

There was a post here a while ago about a language that didn't use 'super' inside subclassed methods, but instead had something used in the parent class method to call the same one in any subclass. I quite liked the idea of that.

Looks like Module#prepend is there to do a similar thing.

Does Apple own the word 'Mail'?

I was wondering about Native Client, and if it did catch on, if people would settle for just using JS as glue code between the DOM and your NaCl extension. It would open up the opportunity to use any language that can be embedded, but might be too much of a faff for not much gain.

Javascript is probably an excellent example of something written without any consideration of how it would work at scale (which is exactly what we tend to promote). The idea of it suddenly being used for writing single page applications and entire UIs, and now servers and god knows what else, was probably unthinkable at the time.

It wasn't that long ago when all JS did was put snowflakes on a page, or trails of fire behind your cursor, or annoying sequences of alerts and prompts. And it was called DHTML.

Were it possible - in the 90s - to anticipate the recent surge in popularity of JS, maybe we would have had a totally different language.

That said, these 'gotchas' are just part of learning the language. Same with PHP really. With a sufficient level of experience you tend to forget they actually exist.

I've used HAML and Jade a fair bit, and I've also had the joy of converting them back to HTML. I've experience the opposite to you, where we've had a much easier time with plain HTML than a specific abstraction of it. I've also had the joy of taking HAML and turning it back into HTML. It's no fun.

To clarify the nested tag example, using an unordered list fails to take into account the other methods of nesting elements in HTML:

    %p This is a paragraph with
       %strong emphasis
       inline and maybe a
       %span dynamic portion of the text

    %p This is a paragraph with <strong>emphasis</strong> inline
       and maybe a <span>dynamic portion of the text</span>

I'd also add that the fact HAML auto-closes your tags is totally negated by the fact you have to keep track of indentation instead. If you nest something when you shouldn't or vice-versa, good luck tracking it down, because the markup won't be broken.

As for interpolation, I like to know when part of the template is evaluated as code, and when it isn't. PHP, ERB, etc. all keep the distinction between the markup and the language very clear. These don't.

This stuff clearly adds value for you. That's fine. For me, it doesn't, and I think using an abstraction like this on the basis that it stops you getting the markup wrong feels worse than using it because you just dont know HTML. If you need something like HAML or Jade or this thing to close your tags for you, then that says something about the structure of your document.

I agree, and it's also the reason I dislike HAML and all the other things that want to use significant whitespace.

Writing plain old HTML is fucking simple. Abstracting it out into another 'language' just means you have to deal with a whole load of quirks and workarounds you'd never see with HTML, and while it looks all purdy and shit to some, it's an absolute nightmare to maintain.

Want to nest elements? Either you can't, some syntax has been introduced to discourage it (the end of line pipe), or you're told to just... use plain HTML.

Want to interpolate variables? That's probably built in, which is great until you try changing it back to plain HTML, and then have to scan for all the interpolation, which is now plain text.

There's likely so much focus placed on "one-lining" everything that you have to do silly things just to actually make the template readable, when it wouldn't be a problem in HTML.

Never mind the total lack of portability and, especially these days, requiring a copy of Node just to run the damn things. Which is fine until you realise you shouldn't need to add a full on javascript VM to your development dependencies.

That so many of these attempts at 'HTML templating languages' exist is probably testament to the fact that no one agrees on what one should look like. They've actually been staring it in the face all along: plain old HTML.

I believe the same thing is happening with Play.com too, which has all the Rakuten branding applied.

I guess it's not quite as easy as whacking up something in HTML and CSS, which might justify the recent trend towards supporting that in as many things possible.

I also think that the attractiveness of one of these projects can vary quite heavily depending on whether you're a UI/UX designer or a programmer, and there's always the opportunity cost of giving up working on something new and fancy.

This isn't the BBC screwing people over. This is likely a constraint introduced by licensing American (or foreign) exports for broadcast over here. If the licensors want DRM as part of the agreement, then there's not much choice left for the BBC unless they want to reduce the diversity of their content.

I think that's an issue of moving from Objective-C (and pure C), to what is normally a dynamic language.

Using nil as a final argument (also called the 'sentinel') is fine for C to mark the end of a variable length array like it expects with 'strings' (so it doesn't stretch into the next unrelated block of memory), but you'd expect Ruby to handle that for you. Because in any other circumstance, it does.

The major concern I have with something like RubyMotion is that Objective-C - the language it stands in for - is not a difficult language. The Cocoa/CocoaTouch API and its verbosity is the real problem, and I think that trying to map the extensive documentation written in Objective-C to a Ruby equivalent runs the risk of adding too much mental overhead. That it requires a paid-for license means that Ruby specific documentation will be comparatively thin on the ground, and the same applies to the resources found on StackOverflow.

I'm a Ruby developer, and I find Obj-C a nice language to work with (though I do prefer the s-expression style in favour of the more recent dot notation). I still haven't managed to justify using Ruby in place of Objective-C.

The only major benefit I see is the REPL that ties into the simulator, and losing the dependency on X-Code, but again, I feel that the verbosity of the APIs is the fault for that.

Wire it up to your bedroom light and you've got an instant DDOS alert system. Or a disco before it gets to that point.

That didn't stop a bunch of services selling 'free phpBB' installs littered with malware advertisements, to people who didn't know how to deploy a PHP app.

Honestly, although phpBB's design leaves a hell of a lot to be desired (messy, table-based, complex, not pretty), the benefit I see from this as an open source competitor is that it's Rails and MVC.

This is a sight for sore eyes for someone who has to maintain a phpBB forum and its modifications (all of which, by design, require patching the source code with some bizarre XML-diff format).

Even with no formal plugin architecture, the decision to choose Rails is massively beneficial.