While I agree with the premise of this article, the fact remains poor design is poor design.
I'm recoding a web query tool write now that was written horribly. It actually worked, but the efficiency problems it had would have made the site choke when exposed to real users. Prototyping is one thing, but if you're application / site / whatever is going to be hit by lots of people, there's a minimum level of efficiency that has to be in the code or else the thing's gonna tank.
At that time, they only made tyres, galoshes and toilet paper.
Eh? I don't think that's true. Nokia, just like Ericsson, made telephone switches and was involved in NMT, back in the 80s, when they started to make phones.
We are working on a Facebook application that socializes online storefronts to drive word-of-mouth marketing. High-concept pitch: Blippy for storefronts.
There's several central ideas in CS that most people know. (Not everyone knows every single of them, but most people know many of them). One of them is the idea of finite-state automata. If you have a finite set of strings, or a regular language, you can build a DFA to recognize that.
Once you know know about DFAs, and you realize that there are only finitely many words that have a Levenshtein distance of less than k, it's just a question of (i) practicality and (ii) technical details. But when you have the idea to combine concepts X and Y, you know what terms to search for and what papers you want to look at.
As to practicality, there's potentially many words that have a Levenshtein distance of at most two for some word, but you don't care about the bits that are different, so the automaton is much smaller.
Part of being a successful CS background is to know all the kinds of hammers that are around and having a feel for the right hammer to use given a particular nail.
In this case, the hammers are abstractions. Algorithms are fundamentally driven by abstractions into which you then fill necessary technical detail - getting the technical details wrong may leave you with a correct but inefficient algorithm at worst (but enable you to recognize a more efficient way when you come across it), whereas you're bound to reinvent a new duct-taped makeshift wheel wherever you go when you don't know the right abstractions.
There's nothing special about sharps and flats in that regard. Depending on your tuning system C could be different in every scale. That doesn't make it something you want to encode in your notation.
Nokia lost the way a couple of years ago. From rock solid software and physically neigh indestructible phones we've gone to phones that take 5 minutes to switch on, frequently crash and drop calls and explode in to a variety of parts (cover plates, batteries, main boards, buttons and so on) with normal use.
What's with the Nokia doesn't get it part? The market repositioning from smart-phone to mid-range consumer phone and delayed launch of the N8 would seem to suggest that Nokia definitely does get that the N97 was a disaster.
People were laughing at Nokia when they said they wanted to start making mobile phones. At that time, they only made tyres, galoshes and toilet paper.
Now, if Nokia keeps this quality and price on their mobile phones (if this really is what you get), I myself would recommend them to either fire their hackers or go back to the rubber production.
Hopefully though, they see that this is not going to work and that they have to do something about it.
Foxes spread a horrible smell, most people don't know because they've never been next to a fox and they think they will smell like a cat or a dog(wich also smell but it isn't comparable)
Why should I have a voting ring? If the situation would have been reversed would it be ok with you if I accused you of having a voting ring? I don't think so.
If there is anybody on HN that has an aversion against voting rings it probably is me, and I wouldn't ever stoop so low as to cheat on something as silly as a conversation on a website (or anywhere else for that matter).
Whoever voted for me is free to step forward, I swear I haven't a clue who voted me up and you down.
edit: This sort of ticks me off by the way, within two days I first get this character calling me a troll: http://news.ycombinator.com/item?id=1556756 , now I have a voting ring? Way to go).
Both the framework and no framework approaches have merit.
Choosing a framework limits your choices. If I'm using Django, it won't work (or work well) with a non-rel backend. If I'm using jQuery and I need to update one of the libraries (say jQuery UI) I might have to update jQuery as well, etc.
What you think saves oodles of times doesn't always. The odd bug, the odd crash etc that keeps popping up may have roots in the framework that you chose and that you're using without having knowledge of its internals. The framework might make your app much slower and cost you in terms of hardware.
Not using a framework is harder work initially, but with the right libraries it isn't that big of a leap. Picking up a smaller framework with libraries can be a surprisingly easy and a lot more flexible when your needs end up being different from what the framework intended.
Ofcourse, there is a flip side to it all and I understand your point :) Micro-frameworks are the best IMO, not the beasts that Rails/Django are.
[ EDIT: Make sure you take node.js out for a little spin, you might like it :) ]
I agree with the general sentiment of playing it safe when your income is on the line, pecially because there's a lot of fanboyish hype around these projects.
However, its not just about "new tech", its about tech that works the way your mind works. Some things mature quickly and have the right mindset (Django, clojure, node.js, couchdb for me) and others have a longer/more painful learning cycle where the community struggles along with the leaders (rails (again, this is just my very personal understanding!)). Some things mature but don't align with what you think is right (php, java).
I've found node.js to be special. It has gained maturity relatively quickly, the libraries seem to be lightweight, good quality, its a language that will run both on the server and the browser (hello code reuse).
This completely ignores the fact that the chromatic note relationships in different keys are not the same. F# is not the same pitch as Gb. In fact, I find thinking about notes in terms of a moveable do solfege (not as static names at all) to be by far the most effective system, since it really manifests the relationships in the key that you're playing in. When you realize those functional relationships, along with the requisite tensions in pitch, which you can emphasize on a non-justified instrument, music making becomes a lot more fun and easy.
It there no way to quickly add a default set of monitors? Because it seems quite tedious to add them one at a time just to get an idea of how the service works.
But HFT dealers stopped trading that day is not entirely true. Some HFT traders (not dealers) stopped at the flash crash, but others stayed in, partly because they were obligated to due to their liquidity agreements with the exchanges, and partly in retrospect to make bags and bags of money. If the latter were not in the market, you would not have seen the flash-uncrash that was the recovery, and it would have been 1987 all over again.
On the contrary, I think laying the bricks is plenty difficult in and of itself. But it's like wanting a share of the rent as a bricklayer of the apartment building that you are putting up.
I can do both (lay bricks and code), and I think there is a distinct parallel between laying bricks and writing code. Both use simple, re-usable building blocks to create very complex systems that need to be built to high standards if they are expected to stand the test of time.
The equivalent between the architecture and the algorithm designer is a similar one.
To demand a share of the cake just for laying the bricks tells me that you should not be doing work for hire but that you should be working as an independent contractor or as a starter-upper. You can't expect 'none of the risks and some of the gains' in a position like that.
A 'mere' programmer, just like a 'mere' bricklayer can be replaced by another programmer or bricklayer.
An architect or an algorithm designer contributes something uniquely theirs without which an endeavour might not happen at all.
Programmers are a rare profession in that they seem to think that somehow their contribution to a project is unique enough that they by the simple act of transcribing a specification to a working prototype have become co-owners, no other discipline suffers from this misconception.
If you want a slice of the action put up your money, but don't just put in your time, expect a paycheck and a slice of the cake if all you do is code, you are more than likely to be found 'expendable'.
I definitely agree with this, especially since they've listed the domain for 2k. I think it's worth spending on this if this is a serious long term project.
Certain trades are obvious winners- index funds available for less than the sum of their component parts for example. Everyone on the street knows they are obvious winners, so usually the trade isn't available for long. Firms have computers set up to constantly scan the markets for these opportunities. Whoever sees the trade first and gets to the exchange first ends up making all the money.
I tried to add a cell number for getting SMS alerts. The "save and test notification" prompted me with "Notification sent!", but several minutes later I've yet to see a message.
