static_typed

I feel sorry for the Gnome guys - they get crucified if they do or don't advance the platform, yet look across and see other fruit flavoured platforms pull worse on their user base yet their fan base not only approves of it, but they somehow justify in the most Stockholm syndrome walled garden kind of way.

So, nowadays if a tech community puts together an event, they had better call it a gathering, a tech meet, maybe coffee code & cookies, basically anything but conference.

Because once you have a conference you have to deal with feminist dogmatic gynosaurs, ducks, bloggers, community backlash, mainstream print filling their idle pages with judgement on your efforts, and basically a regret for even thinking of doing something good in the first place.

Sadly, whereas tech conferences should be about the tech and the cool, interesting and rewarding things we can do with it, it instead becomes dragged down into a drama, where one woman can do more damage to other women then all the men present (thinking about the pycon incident). As my colleague a female developer, often says "These gynosaurs ruin it for the rest of us".

Surely choice is good? I fail to see a single use for comments that dismiss the right of optionality for others.

I think there are many great comments already on the w3 site regarding EME, but it seems the main and strongest arguments are still:

1. Why should the w3 bend, kertow, or even care about the content business model and profitability? 2. Why should the w3 with a supposed focus on openness even consider adding in something like EME? 3. Who are these mystery users, apart from the content barons, who are apparently in full agreement that we really do need Digital Restrictions Management in the browser?

This whole thing stinks.

The author seems to make the simple mistake of convenient for him to watch DRM content in his browser == good for the web.

Someone develops for the Mac because thinking about cross platform and making it work in the browser is too hard, so we'll just bet the farm on letting Apple handle the hard stuff, and hope that performance doesn't later drop off, and then clients ask why it is no longer so good, and I say "but, I develop on this closed platform, and it should be good..." etc.

As you said above, "Rails Winter of Security Madness, it is be ready to patch at all times" -- sounds a lot less fun than the five minute blog or scaffolded apps that drew a lot of the Rails developers into the fold in the first place, not realizing that a short while down the road they would be spending all their time patching, monkey patching and crossing-fingers each time someone lifts the hood on the framework and discovers yet another parser-in-a-parser ready to exploit.

Give a developer a Ruby-based web framework, and they can run for a day without patching, but give them anything else - even Prolog on Punchcards - and they run for so much longer!

Stop today, and help recovering Ruby developers onto a better path!

Rails became worse than the frameworks and ecosystems it laughed at in it's younger days.

Remember - Rails is Omakase - meaning literally 'leave it to someeone else' - food for thought indeed.

^^ This is good advice. Maybe they should question their choice of platform - there are other options, some of which seem to have had a bit more forethought in their architecture and engineering.

Remember: Ruby/Rails to pose, Python for pros.

This is common in a lot of Rails shops - they are so proud of the extensive Cucumber tests, of the endless gems required just to run the tests, of the layer-upon-layer of crap, and look all the tests passed, it must be good right?

Wrong. The worst code I have ever seen. Written to pass tests, unmaintainable, fragile as hell due to the turtles-all-the-way-down architecture of relying on a thousand-and-one third party gems (and the checkins showing how frequently that very same code barfed and broke 'vital' things').

Agile is a pox upon software development, but hey, it sells books, provides employment for otherwise unemployable 'project managers' and finally putting to rest any semblance of engineering in software and systems today.

Standups are a symptom of a failing software engineering disease called 'Agile', which is the real toxin to the system of all healthy developers.

Hey - they were slapped down in the US and the EU for good reason. Every day I have to use an IE only intranet portal I am reminded of muppets who question why we should remember the judgement against M$.

The article is good, to the point, highlighting tangible points well. However, I do worry it is wasted a little. The bulk of Ruby on Fails developers are too enamoured with Magic and the promise of the five-minute-blog to really think about security or software engineering.

You are now in the place I was recently -- the decision we tool was to migrate onto Python and their web ecosystem.

We haven't looked back since -- well, we have given an glance or two back since, and viewing the slow-motion car crash that is Rails today, we just feel sorry for those left behind that are discovering 'The Rails Way'.

Ironically, given DHH's comment on Rails about it being 'Omakase', I should point out that it translates as "I'll leave it to you" -- security, I'll leave it to you, software engineering, I'll leave it to you.

Food for thought indeed.

Remember -- Ruby to pose, Python for Pros.

Well, if it ran any faster all those Rails sites would get compromised even quicker, so surely this is a good thing? Brogrammer security through performance woes.

Rails and security. Again. Sigh.

If this will help the brogrammers and fauxgrammers in the ruby world to take security and software engineering seriously, then it is a good thing.

I sat with a newbie programmer the other day. We sat there and made good use of third-party libraries, frameworks and code to get things moving, and concentrate on the core problem at hand.

Now, we had to Google a bit to install the third-party and dependency stuff, and tinker with configuration to get it all ready.

Eventually we delivered the GUI version of 'Hello World', and the newbie programmer had already progressed several steps when he remarked: "So, modern programming is basically building my code on top of other people's code, without really knowing how it all works, if it is really any good, and hoping it all works well enough to make the whole thing work".

Any he was right. Long gone is the time when we understood all the components and code for our entire domain.

And we are often the poorer for it.

Yes, Django took a solid step to properly fix the underlying issue, rather than apply many small sticky-plasters over several days instead, leaving the same basic vector open in the meantime. In fact, the Django issue reported was posted on HN yesterday and the comments on that posting underline what I just said here.

Remember - Python for Pros, Ruby to pose.

If you love constant patching for the daily critical security holes, stick with Rails. If you love worrying where they have stuck yet another Yaml parser, and where else they are eval-ing user supplied data, stick with Rails.

If you prefer a bit of an easier, less-stressful life, there is hope with many of the Perl, Python and PHP frameworks.

Cheapshot: Rails HAS turned into Java, in so much both are riddled with security holes.

Longer-term view: Rails mocked the Java web eco-system in the early days because it was 'Enterprise', and Rails was the scrappy upstart with magic commands to scaffold a blog in 5 mins and show screencasts to the world. This sold a lot of books (without it would Pragmatic Programmer have even had a book store?). Slowly, the rot set it, and the once light and nimble Rails become bloated as everyone added their pet features, their design pattersn (even though they would never call them that - that is so Java!), and the too-many-cooks-in-the-code-kitchen sprinkling so much magic and syntactic sugar around the codebase it practically causes diabetes.

Rails solved a problem for the company that wrote it. Since then people have been trying to shoe-horn it work with their business problem, and then found once they now have two problems.

The rest of us moved on.

I can't believe how many apology-niks are on here trotting out the old merde about how we need DRM, and won't somebody please think of the rights-holders. Here in the UK we pay the TV license fee. Now, granted most of the output it funds is utter crap, but hey, we paid for it. There should be no reason for DRM to be applied at all, but especially not if delivered via the web.

If the standards wonks permit this, we really need to fork the standards, and avoid this.

If the open web does not support your intended business model then go away and change the model.

Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.

One particular surgeon was not too old, his glasses corrected mild myopia and a slight astigmatism. When I actually put him on the spot about the laser surgery question, his reply, which was reasonable and honest, was that surgery is a personal choice, and he personally appreciated the advances and refinements in the techniques employed, but still preferred to wait and see re: long term effects in patients.

Having gotten a new pair of glasses just this week, and having worn a variety of glasses and contact lens over the past 25 years, I consider laser surgery every now and then, discuss it with the eye surgeons, but then stop when I consider one point - they are willing to perform the surgery, and are happy to recommend it, yet they wore glasses - they did not seem willing to have it done on their own eyes.

Always struck me as a bit odd - like a pub landlord who refuses to even taste any of his beers. Not the best indicator for trust and confidence.

That said, I have two friends who opted to have it done, one had perfect results, the other has a persistant issue with halo/floater artifacts in one eye.

This is one of my pet peeves of late - so many tools and tutorials advise the user to curl and pipe some script of the net to install and make it work. Why aren't we teaching people to be a little cautious - to download, review and then install? How did developers become so lazy, and so coddled that we desire convenience over security or forethought? Or worse, is it really due to an increasing number of developers who are unable rather than unwilling to review scripts, tools or libraries before use. Do we need a new movement for 'the literate programmer', that emphasises the need to learn than just the core language or framework or ecosystem that they are using?

Given the constant flood of Ruby and Rails security problems of late, it would seem better to start new projects with something a bit better engineered.

At the end of the day, it is a trade-off: do I stick with a current framework full of security holes, indicative of poor design and keep the daily patch cycle fingers-crossed, or do I draw a line, migrate to a less magic less shiny but more secure better engineered framework and focus my time on building my apps instead of spending it all on patching. Tough call.