lusr's comments

Whenever I see interesting events like this, my first thought is not "what would happen" but always "how could I profit from what would happen [or the uncertainty around it]".

Unfortunately I never know how to answer that question convincingly enough to put my money where my mouth is. Does anybody know if there's a place where people discuss these sorts of things, e.g. a "Hacker News for Financial Markets"? Any interesting ideas for coming out of this on top?

EDIT: Two answers have pointed to gold. Yup, I have already played with investing in gold ETFs, which generated a 20% return over the past 2 years, even after fees. However I was wondering if there were any more ideas specific to the present circumstances, and where, if anywhere, people discuss this sort of thing?

I was very keen on using TDD to lay out the design and technical specification of a solution to be implemented by our team (8 developers total).

Unfortunately, because the project has tight deadlines (regulatory project), despite minimal requirement clarity the team needed to get going and in the end every developer ended up with just a rough guideline of how to implement the various components.

Does anybody have ideas for integrating TDD with an Agile approach and a team around this size?

I think the following separates you from the average games player and makes your story (interesting as it is) out of place:

> In the late 1990's I wrote for websites strategies and even won several tournaments and won hundreds in cash and some perks. I even attended the first World Cybergames as a MVP.

That's a productive career and time well spent; it is a fact that not everybody can have that outcome. (This reminds me of all the guys at school obsessing over football; the effect under discussion is not limited to computer games.)

For the average game player, time spent playing games is time not spent working towards some other achievement. This is precisely why I pretty much stopped playing games years ago and focus on spending my free time on other goals.

He donated the product and kept the barcode.

Here's a guy who pretty much did it for free (and he wasn't the only one): http://www.dailyfinance.com/2013/02/28/credit-card-reward-po...

It's not really a "Show HN", though is it? It's an paid-for extension of an existing product. In that vein, while an informative post I did find the following statement a bit disingenuous:

"As Paul Buchheit, creator of Gmail and partner at Y Combinator, says, the correct order of operations is to “sell before you build.” When you launch, you want a whole list of people that you can tell to buy it. But more than that, you want to ensure that you’re investing all that time building something that people want to buy."

As far as I can tell, they built a product for 40,000 people over a certain period of time without generating a cent in profit or knowing in advance that any of those people would ever consider paying from the product. While some users did claim they wanted a team version they would pay for, this was only after the base product was built without knowing people would pay for it.

This bugs me a bit because I'm working on a project where I'd love to be able to sell before I build, as it's obviously a very sound principle, but in practice I just can't see how to go about it and I was hoping to learn something new from this post.

Another fun complication: database stored procedures implemented with non-SQL code. I worked on a project where the client's dedicated SQL ninjas managed to bring the time to process daily extracts from the data warehouse down to 2min from 45min by switching over to CLR (.NET) implementations of the calculations being performed on SQL Server 2005.

IIRC the issue was simply that MSSQL 2005 is just plain slow at doing calculations compared to C# code (the calculations were complex financial models involving large amounts of data and inter-dependencies between that data in calculations, so shipping the raw data to an application was not a viable option).

While I agree that immaculate attention to detail is important in documents you're creating for formal consumption (e.g. CVs/resumes), I don't see how the same extends to emails, websites and READMEs.

I'm a native English speaker and despite being well aware of homonym misuse, my brain doesn't always play the game and occasionally I find myself using the wrong word in my writing with no rational explanation.

Similarly, I often find myself leaving out words in my writing that I don't notice are missing even after re-reading a paragraph many times. (I fall for "PARIS IN THE THE SPRING" almost every time it comes up.)

Alternatively I'll change the wording in a sentence and not notice stray words are left over in the wrong order, again even after re-reading. Usually I have to do something else and look back at what I've written to read it with "fresh eyes". I imagine dyslexic people have similar problems.

Despite these issues I've been complimented many times on the quality of my technical writing and my code, so I don't consider my natural language issues as much of a disability when it comes to programming or technical work. That is, until I encounter somebody who holds your beliefs.

It seems obvious to me that there's a vast difference between somebody writing a CV using obviously incorrect spelling or random formatting, or inconsistent capitalisation, punctuation, tenses, etc., and somebody who makes one or two typos in a blog post on their personal home page.

You're missing the point. The question is about the legality of access without authorisation. Just because it's illegal to leave your car unlocked doesn't magically make it legal to steal from an unlocked car.

I still don't see the value. To me it's like proposing that in SQL we replace 'EXEC' with 'HEAD', 'PUT', 'DELETE'...

At the end of the day I still need to understand the contract of the stored procedure to have any hope of consuming a database API of meaningful complexity.

> There isn't much in the way of discoverable APIs that adhere to the data model suggestion in the HTTP spec

I don't even understand why this needs to be pointed out. If the precise usage of all web APIs could be inferred from the verb alone, presumably all web APIs are exactly the same. That's nonsensical. I challenge anybody to honestly claim they have consumed a 3rd party web API of material complexity without once referring to the documentation and solely relying on guessing HTTP verbs.

Once you're already reading the API documentation, I don't understand why you'd prefer "http.request('PUT', '/resource')" over "http.post('/resource/put'). Even better, you can choose a URI that makes the most sense to your domain model, e.g. '/resource/upload'. I don't understand why you'd want to have less expressive URIs AND more work. In even this simple example, the verb is unlikely to be adequate in any case - if you need to supply options or metadata the verb is even less significant as to the true meaning of the operation.

The fact is you can always embed the verb of your choice into the URI - thereby making a GET/POST/HEAD world no more or less expressive than a Verbtopia world. All that extra verbs do is cause consumers of the API to have to remember two pieces of information (VERB + URI) rather than one (URI). At least URIs can be constructed to make as much semantic sense as possible within a given domain model - VERBs, on the other hand, end up as square pegs in round holes, making them far less memorable.

I'm mostly a back-end developer and I don't have much experience with rich front-end interfaces other than my own little side projects and a WPF project from about a year back - however, I do believe the same principles apply to both front- and back-end design.

Specifically, you should be following the SRP - duplicated code is a symptom that you are not. Without seeing your code that you feel doesn't pay off, it's difficult to answer your question more directly.

I will say there's no reason you can't design your server-side services to be consumed directly by the view, in which case I wouldn't see a problem referencing the service directly from the view (e.g. the UserService exposed by the server implements (a) normal login, (b) login as part of checkout and (c) registration).

Alternatively, you could build a client-side service to wrap the server-side service and reference that directly from your views (e.g. a UserController that wraps the UserService and is consumed by (a) the omnipresent login view, (b) a login/signup view, and (c) the registration view).

Over and above this, there is some middle-ground where you reuse structures. For example, a User structure (with IsAuthenticated, UserName, FullName etc.) would be assigned to a $scope.CurrentUser property for the views. Consequently you don't reimplement the User object the service implements, and you don't vaguely depend on the entire UserService, but the data contract the view does depend on from the controller is still explicit by looking at the $scope definition in the controller. Similarly, the operation contract is defined by the controller functions. This improves maintainability and readability IMO.

The problem is that the types in Javascript + dependency injected AngularJS services are hidden. If you forget that "auth.loggedIn" is a value-type, you might unconsciously assume it's a reference type. This is one reason I prefer statically-typed languages -- it's much more difficult to make this sort of mistake since the type information is always visible even if you have the most basic IDE.

1. This tightly couples the service to the view. Changes in the view and/or service will potentially result in nasty surprises and spaghetti code. For instance, what happens if the business processes change one day and "login" needs to return "logged in but email address unconfirmed"? You want the rules to deal with that scenario confined to a LoginController, not scattered around through each view (consider: an omnipresent login box view vs. a login/signup form view used when a user performs an action that potentially requires login, e.g. "Checkout")

2. In reality, this simple sample obscures what happens in the real world when you add an input for the user key & password:

a. you will need to pass the parameters to the auth service. At that point hopefully you will won't do anything crazy and will simply e.g. bind the user key & password to $scope properties, and pass the scope properties through to the auth service.

b. As stated in (1), your login & logout controller functions need to consider the result of their auth calls and map that result back to a meaningful state for the view -- in the simplest case, it'll just be "logged in" or "logged out", but it can also be e.g. "logged in but email address unconfirmed", which could require a message to be displayed to the user. The best place for this state is again a $scope property.

So, in practice you would just use a $scope.loggedIn or $scope.user property maintained by the controller login() and logout() functions to resolve this issue.

These people are using Facebook with the expectation it works like email. Why do you feel the two are so different? In my experience, the average computer user doesn't like fiddling with email addresses - Facebook is far more friendly (opportunity for a new email client?).

Email is not immune to these issues, either. This scenario is the equivalent to sending an email and having it end up in your friend's spam folder (although arguably Facebook should be more heavily invested in getting this right!)

Is this not a short-sighted view?

A middle class salary they can survive on for how long? When that source of income dries up they'll be unable to continue working on their passion without spending time and effort finding an additional source of income.

Alternatively, if they open themselves up to a strategy enabling a greater income they could potentially retire in a very short time with indefinite financial security and the option to pursue their passion as long as they like.

My machine is always on. Subjectively, having 24GB of RAM made far more of a performance difference than my Plextor PX-256M3P, presumably because with 24GB of RAM pretty much everything of importance ends up being cached in RAM sooner or later.

Why a contractor?

I'm a contractor for two reasons: (1) money and (2) because I don't buy into the corporate PR. People who work in these places have to buy into the corporate values system.

I look at corporate values with great skepticism; perhaps I'm just cynical but in big companies it always seems to end up (in performance reviews) as being a way for the company to come back and justify why your bonus, increase, etc. will fall short of expectations this year.

"CRI is not a good indicator for use in visual assessment, especially for sources below 5000 kelvin (K)."

Bulbs in question are 2700K and 5000K. Does your conclusion still hold?

[1] http://en.wikipedia.org/wiki/Color_rendering_index

Let's dig into these numbers. Assuming the R40m value is correct over 3 years, then:

- since there are 248 working days in a South African year on average, the average daily cost ran to ~R53,763 or ~R6,720 per hour

- at the banks I've worked at, that'll buy you 10 intermediate on-site contract developers, or 6 senior developers, from an average consulting house which factors in all of these overhead expenses (including travel, etc.) you mention... and that's doing skilled development; this is WordPress work, but let's be generous and say they bill the same

It's hard to believe they required anywhere near that many developers (designers are much cheaper and I can't imagine they hired more than 1 or 2), or that hardware/service contracts would have cost much more.