spellboots

Mozilla Persona is basically this but better thought out. There is a good talk about it here: https://www.youtube.com/watch?v=nJff23UdNAI

Is the voiceover on that video computer synthesised speech? If so it must be the best I've ever heard...

I use both javascript and coffeescript extensively and regularly, and I just don't understand how this ever causes real problems to anyone - unless you're writing 5000 line long spaghetti code coffeescript files with ambiguous variable names, in which case lexical scoping is the least of your worries.

A related article from the author of the less-rails rubygem: http://metaskills.net/2012/02/27/too-less-should-you-be-usin...

I don't think the artifact approach is unambiguously better. Sure, "consistent deployments on two different Linux systems" is important but you can achieve that with rubygems along with the extra flexibility that distributing the packages as source provides.

Two approaches you can take:

1. bundle package will package up all of your installed gems, which you can then deploy with your project.

2. Your build server can install all of your gems, and then you can package up the resulting directory and deploy it - you could also build e.g. an rpm package.

You are not supposed to be able to hit the url in your browser. You are supposed to use it as a gem source in a Gemfile or with the gem command line tool.

There is also http://gems.gzruby.org/ if you happen to be behind the Great Firewall of China

Rubygems has at least one public mirror: http://stackoverflow.com/a/17150536/437888

There are also solutions such as https://github.com/pusewicz/rubygems-proxy allowing you to cache / proxy to rubygems.org

It would be completely out of character for him to pull out of the speech - far better for him to go along and mock them. I for one would love to see that.

On iOS this isn't necessarily true under certain constraints.

They can make it impossible given the device is not jailbroken. Sometimes there are versions of iOS that are un-jailbreakable. If you are not Apple, it could very well be impossible to figure out what an app is sending to a remote service if it gets its cryptography right.

Edit: thinking about it, although it may be impossible to MITM the connection, presumably one can inspect the compiled application to determine what it would send, so I think I was wrong about this

Is this not the entire point of Foursquare?

It used to be technically correct.

Today, it is technically incorrect, because society today acknowledges that women are full, living, breathing human beings and may in fact be referred to as such in polite conversation.

I use both for different purposes. It should be noted that Digital Ocean machines seem a lot slower. As a real world example, rake assets:precompile on my linode takes about a minute, whereas on a similarly specced digital ocean box it takes over 10 minutes. YMMV of course, but I was very disappointed by real world DO performance and only use it for lightweight stuff – it's great as a cheap VPN host for example.

As a programmer who feels I should spend at least some of my life in silicon valley, this is the primary reason I don't. American employment law is frankly barbarian.

Look at all the single first name usernames on the frontpage. Lots of early adopters right there.

Obligatory http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

I spent many years doing PHP. I am very glad that those years are behind me. Even if you allow for it being easy to setup - which is debatable - setup only happens once and is not very hard in any language. If you find it hard to install a programming language by following instructions, you are an amateur pretty much by definition.

Not true. Ruby is great for a lot of stuff, but a very poor choice for e.g. scientific computing (scipy/numpy are a far better choice than the very immature sciruby), and plenty of other use cases where there are other "general purpose languages" that are far more suited to certain problems.

IE9 is still awful unfortunately. IE10 is the first IE that doesn't suck.

How ridiculous. This post sounds like a pair of children fighting. And whilst your client seems very annoying, calling them terrorists for opting to exercise their perfectly valid rights to (a) engage you in legal proceedings and (b) write about their experience and publicise this writing make you look a lot less professional that they do.

Please use Persona, it's this idea but much more thoroughly thought out and tested.

Here is a great video about it: https://www.youtube.com/watch?v=nJff23UdNAI

If you have not heard of Persona, or have heard of it but don't see what the big deal is / why it's different to "Login with google", "Login with twitter" etc, then go watch this video. It is a very elegant, decentralised solution to the login problem.

Whilst indirectly, you can still purchase pretty much anything in BTC quickly and easily:

http://all4btc.com/ http://www.gyft.com/

This explains succinctly why almost no computers were sold in the 1990s.

I disagree, I think that opening an issue on github is a good way to start a discussion about a feature. Many projects accept feature requests this way and if anyone did the same for one of my projects, this would be the way I would prefer them to handle it.

You can 3d print springs on even the cheapest hobbyist 3d printers these days [1]. Some 3d printed springs exceed the performance of traditional designs of the same weight [2].

Battery chemistry is indeed a different kettle of fish however.

[1] http://www.thingiverse.com/thing:39963 [2] http://www.rapidreadytech.com/2012/04/3d-printed-spring-exce...

Apache rewrite rules, which isn't that surprising if you've seen as many abominations of config as I have:

http://olsner.se/2008/01/21/an-excursion-in-mod_rewrite/

Perhaps you haven't seen it work, I have seen it work many times, and like I said, it is about tradeoffs. You trade increased development time for higher quality software.

I think it's quite bizarre to be arguing that TDD is not agile when it is an explicitly agile methodology. Kent Beck, the inventor of TDD, is an author of the agile manifesto that you quote. The authors of the document clearly disagree with your interpretation of it.

>You should first try stuff out and discuss it rather than working out how to machine test it before its been tried by a human. Having tests first is clearly having a plan first.

This is a strawman argument. TDD does not imply working out how to machine test something before it's been discussed and planned by a human. If you need to try it agile has a concept of spikes. This is not an argument against TDD because this does not describe TDD.

>It's hard-enough to welcome changing requirements when you have to rewrite software without having to rewrite all the tests too. Why write tests for code you don't keep?

Tests are part of the code. Why write code you don't keep? Yes, you have to throw away tests if you throw away code but this is not a TDD issue. The issue is you're throwing away the code (of which the tests are a part).

> Changing and adapting is harder when you are encumbered by tests. Tests should be written once you've agreed that what you have now is what you are going to keep.

No, changing and adapting is easier when you have tests because you can be sure that you haven't broken anything. If tests fail when you change things, either the requirements have changed so you change the tests, or you've accidentally broken something and the tests have caught it. Tests should be written at the same time as the code to validate that the assumptions of the developer at the time the code is written remain true.

> Working software is the principal measure of progress

The working part is important - if comprehensive tests reduce defects in software - which is a pretty uncontroversial statement, if you disagree with this statement you are at odds with all the published research on the matter I have seen - then writing tests helps your progress by helping to deliver working software.

> TDD brings overhead: tests that needn't ever have been written; tests that needn't ever have been re-written. They hamper iteration and flexible response as they make it more costly to change plans.

And again, I repeat, this is an engineering tradeoff. Is speed more important that quality for your business case? Then TDD is a bad fit.

> But to be truly agile (and I'm not talking about some written methodology here — I mean agile as in nimble) you need to work quickly, try things out and make mistakes. Writing your tests first is a encumbrance.

Perhaps it makes sense to be explicit about this when talking about it, as "agile" has a commonly accepted meaning in software development terms and this is not it.

> This is what everyone says the moment their dogma is questioned.

You have said "TDD is that it, fundamentally, isn't agile" and have asserted that you can't use it to be agile. I have stated (in a sibling comment) that TDD is a business decision, where you trade increased development time for higher software quality, and cited a study on the matter that is non-anecdotal. Your position is the dogmatic one by the commonly accepted definition of "dogmatic".

It's not true to say that TDD isn't agile. They are orthoganal - you can be agile and do TDD and you can do waterfall development and not do TDD. The fact that you need to change tests to change the software is the whole point - if you change the functionality, you change the tests. In fact, it's not wanting to change the tests that causes the problem here.

Perhaps you have been on bad projects where TDD has been used improperly. However every single agile development team I have worked with has used TDD, and it certainly does not limit things in the way you suggest.

Ironically, Extreme Programming [1], one of the first of the agile methodologies, and many other agile methodologies since, include TDD as a core tenet. So in fact by saying "TDD isn't agile" you are perhaps demonstrating a misunderstanding of what "agile" development was designed to be.

[1] https://en.wikipedia.org/wiki/Extreme_Programming

It seems like there are a sea of absolute assertions with few facts backing them up - people seem to love either saying that TDD is better or TDD is worse, and it seems that the only data ever really offered on the subject is anecdotal opinion.

We can do better than this. This study[1] at Microsoft reveals that TDD results in a defect reduction rate of between 40% and 90%, at a cost of 15%-35% increased development time. So, what's the best approach? It now becomes a business question. If speed of delivery is crucial and quality less so, don't use TDD. If quality is more important that speed, use TDD.

And finally, everyone involved in building software owes it to themselves to take an hour to go and watch this excellent video by Greg Wilson entitled "What We Actually Know About Software Development, and Why We Believe It's True" [2], and then perhaps dive in to the list of references from it [3], because you will find yourself more actually informed than anecdote and opinion will ever get you.

[1] http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.... [2] http://vimeo.com/9270320 [3] http://www.gdb.me/computing/citations-greg-wilson-cusec.html

In fact, using a document fragment is actually faster at least in some cases: http://jsperf.com/svg-fragment-test

Here is an introduction. They are not SVG specific but you can build SVG elements in a document fragment, which is a lot faster than appending to the DOM, then append the fragment to the DOM all in one go.

See http://ejohn.org/blog/dom-documentfragments/ or google for an introduction.

Building strings and using innerHTML is a very ugly way to get performance, you should definitely try to using the document fragment approach as it has similar performance characteristics.