Xion

> What I find most fascinating about this is that our conscious minds are not very good at thinking about exponential growth.

I thought about it too, and come up with idea that some equivalent of Weber-Fechner law [1] might be working at it this level. So I have made a small write-up about this idea that you might find interesting [2].

[1] http://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law [2] http://xion.org.pl/2012/04/11/self-reinforcement-and-exponen...

This looks more like 4chan to me.

Bringing up quotes with game-specific terminology without proper context - like "I got deeper into assassination" - makes me wonder how you could twist the perception of, say, programming in a similar way.

Maybe "She puts children on a tree and removes their parents!".

You also need templates to make it possible to invoke a function on parameters of unrelated types.

Even with this addendum, there is a grey zone:

    reversed_string = string[::-1]

Is it just using the equivalent, or a new implementation?

He might be also alluding to recent (~few months) influx of Rails and Node.js related stories.

Precisely.

The Ruby solution author quotes as ideal and impressive seems way overblown to me. And I don't buy that ,,it would probably be dismissed as “overly complex” by younger programmers'' because it is exactly what I would consider perfect approach... few years ago. Since then I learned the value of simplicity, and abstractions with adequate flexibility.

That Ruby code exhibits neither.

> But he isn't going to go start a company tomorrow that will revolutionise the way we communicate.

Maybe he won't do that because he thinks he doesn't have enough time left to properly grow such a company, to see it flourish and observe the impact it would have on the world? Maybe he doesn't have enough physical endurance and health to endure the challenges of being an enterpreneur? Or maybe his wisdom allows him to see that all of his ideas of 'revolutionizing the way we communicate' (assuming he ponders that problem) would not fare well if realized, and he didn't have the one that could work yet?

There are many possibilities here and the postulated lack of curiosity is just one of them.

It creates just one jQuery object to wrap the entire array of DOM nodes. Afterwards, .html() is essentially innerHTML [1], provided jQuery can use it directly (otherwise it has to create DOM nodes by itself).

[1] https://github.com/jquery/jquery/blob/master/src/manipulatio...

It's absolutely brilliant.

And besides improving your code-typing speed, it's also a nice way to get a hang of all different languages you might want to delve into. Alternatively, you can also polish your muscle memory on all the thousands of function, classes and method names you can find in your typical language/framework of choice.

This is not a JSON parser, it's a tokenizer. From a parser I'd expect at least acknowledgement of the basic key-value association.

It doesn't say that it's not useful. It's just that for anything non-trivial, you'd need to supplement this library with quite a bit of your own code, e.g. a stack for tracking nesting levels.

Unfortunately, this doesn't take into account the fact that stuff you keep in your development repository is almost never identical to stuff you want on your deployment server. There are files you keep in the former but not necessarily want/need in the latter (unit tests, documentation, etc.). Similarly, there are stuff to be put on deployment server which don't want to clutter your dev repository, like compiled CSS/JS assets.

As other have said, deployment should really be done by continuous integration server, and preferably using a protocol that's designed for transmitting files, not version control.

> (...) the colors are different: the flashy red/yellow has been replaced by a classy green/black two years ago.

I believe it's the same case pretty much in whole Europe. In all countries I've been to for the last two years or so (Poland, Czech Rep., Germany, Netherlands, Switzerland), the McD branding involved dark green background rather than vivid red one.

> Food is quite tasty, meat is fairly good (...)

That's generally correct, too. I have no idea about U.S. but here it seems that most of the shady reputation fast food gets is not because of the quality of ingredients, but the way they are processed to make the meals, i.e. almost exclusively fried with lots of added fat.

Sometimes the logging is not enough, and you cannot isolate the case to prepare appropriate unit test.

Just few days ago I had a strange problem with the order of imports in Python at the border of my code and external library (Celery). There were import hooks involved but they didn't seem to be executed properly in certain conditions. I could reproduce them quite reliably but I needed to pinpoint the exact import (inside Celery itself, mind you) that was causing the problem. pdb (Python debugger) was indispensable while solving it.

On the other hand, though, it was probably the first time in many months that I used pdb for more than 5 minutes, and for something more complicated than checking why a particular test fails.

While the idea seems decent, it completely forgets about CSS preprocessors (LESS/SASS). When using one, the original 'source' stylesheets usually don't even make it into deployment server, for they are just used to build final CSS. Even if not minified, that CSS file would likely be pretty unreadable, not to mention that it wouldn't really reflect the original patterns and ideas used in source files.

> QuickCheck and JUnit have different purposes. QuickCheck is not a unit testing framework.

Indeed. What I meant was that basically:

    P(HaskellCodeCorrect|Compile+QC+UnitTest) =~= P(OtherCodeCorrect|Compile+UnitTest)

while the distribution of effort between compilation (if any) and unit tests in other languages are quite different than in Haskell, i.e. skewed towards tests in the former and getting code to compile in the latter case.

That's not very surprising; Haskell's type system is really that ridiculously powerful. But I suspect many hackers working with other languages would be able to state the equivalent: "I released a library which I only unit-tested, without writing any helper project that actually uses it".

While it doesn't cover all the relationship status changes, the Break-up Notifier (http://www.breakupnotifier.com/) provides part of that functionality. Arguably the most useful part :)

The idea seems pretty redundant (Last.fm anyone?) but the landing page is just awesome!

Even without the question of ATLAS vs. CMS, awarding a Nobel Prize for this will be rather challenging. At most three people can share it according to the rules, and there were literally hundreds of scientists involved in this discovery.

This is probably yet another argument in favor of the claim that Nobel Prize in its current form is antiquated and not matching the reality of modern science (especially particle physics).

The self-signed SSL certificate causes Firefox to scream security issue. You might want to fix that.

The proponents of tau that cite the ubiquity of the 2pi factor in maths seem to forget that it's an exceedingly huge swath of knowledge and thus any notion of ubiquity might as well be moot, or totally dependent on the region of maths this person frequents. I wouldn't be surprised if there are some domains of maths where even natural numbers are used rarely or almost never (formal logic springs to mind). That's why it's possible to cherry-pick favourable examples which support either side of pi-tau debate.

But you might say, of course, that those fields of mathematics which tau makes "easier" are the ones important in early math education (especially below the university level). Hence adopting tau would make them substantially friendlier and more intuitive to many people. While the idea of "fixing" math concept to make them more bearable to laymen should not be dismissed automatically, I would like to point out that the question of tau vs. 2pi is by no means the only issue of this kind. Indeed, there are a couple of more "warts" in everyday maths that could also warrant "fixing". Consider:

* The direction in which positive and negative angles on two-dimensional, Cartesian plane are measured [1]. Counter-intuitively, the measure increases when going counterclockwise, while going clockwise decreases it.

* The main diagonal [2] of a matrix goes from upper-left to lower-right corner, which coincides with the shape of backslash character.

* The established order of indices for matrix' elements is row-column, so that A_xy refers to element in x-th row and y-th column of matrix A. This goes against the habit of specifying the horizontal coordinate before the vertical coordinate when talking about XY planes [3].

* Definition of convex [4] and concave [5] functions (for R->R ones) do not agree with the intuitive associations based on plots of those functions. Clearly, the convex one looks like a valley, and the concave one resembles a hill or mountain.

I'm sure there are many more examples of such unreasonable, counter-intuitive conventions, so we really have a lot of work ahead of us. So, anyone fancies writing the Slash Diagonal Manifesto?...

[1] http://en.wikipedia.org/wiki/Angle#Positive_and_negative_ang... [2] http://en.wikipedia.org/wiki/Main_diagonal [3] http://en.wikipedia.org/wiki/Cartesian_coordinate_system#Car... [4] http://en.wikipedia.org/wiki/Convex_function [5] http://en.wikipedia.org/wiki/Concave_function

Looks like the author has partially succumbed to Hello World Fallacy. His first extremely simple experiment (I'm reluctant to call it 'app') was successful and he is extrapolating this in slightly too optimistic direction.

> It's far easier to make a cut at "no logic apart from boolean checks" and then use a proper client-side framework such as backbone (...)

That works if you are fine with offsetting all (or most) of your presentation logic to client side. But not every web application is the glorified single-page web app, or has significant amount of on-page interaction that would warrant employing a full stack MVC framework on the client side.

> Templates should be about how things look like.

But also what elements are those things built from. Despite attempts at logic-less templates, the presentation layer still must contain some logic and I see no reason to not apply normal coding principles - most notably DRY - to that logic. That's why I consider it very important for a templating engine to allow for reusing things, and splitting things into parts. Here's where some engines really shine (Jinja immediately comes to mind, followed by Underscore or jQuery templates) and others... not so much.

Python has lambdas and functions as first-order values since the beginning.

The best strategy seems to be incremental editing. Post a short and to-the-point answer first and then edit it to expand and add finer points. This way your answer is already competing with others even as you write it (properly).

It feels slightly weird to be forced to employ such a tactic, but at SO's scale it might just be necessary.

I couldn't agree more with what this guy is saying.

But, mobile applications aren't actually the worst offenders here. At the very least, both platforms have their guidelines for developers to follow if they want to make their apps consistent with the rest of system. And I wouldn't be so sure this is not important: snazzy looks might gain you more installs, but UX that silently and subtly uses established patterns fits more firmly into users' minds and may noticeably increase retention (and thus number of positive reviews).

The bigger culprits in terms of violating UI consistency are, I think, web applications. As far as I know, you don't even _have_ any definite guidelines there to begin with, which is of course due to decentralized nature of the web ecosystem. There are some effort that encourage consistency as a side effect (Twitter Bootstrap comes to mind) but the decade-old habits of designing every website completely from scratch do not seem to be dying anytime soon.

As a relative newcomer to the software industry (~2 years), I hope the grumpiness caused by shifting requirements decreases over time. That after you gather enough experience, you are able to predict more and more accurately what the requirements _should_ describe and act accordingly by preparing some hooks, dangling bits and all other kinds of flexibility so that you can leverage it quickly once the change kicks in.

A more experienced friend of mine (10+ years) says that it is indeed more or less possible, but to do so consistently one has to be quite exceptional engineer - and psychologist. Well, if he's right, then at least I have something to strive for :)

I wholeheartedly agree. TDD as Test-Driven Debugging is the way to go. :)

I've found '1234678', 'password', 'qwerty', 'linkedin' and few other common phrases (already 00000'd, obviously), so it doesn't look like a list of just the hard ones.