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?
Decide what you think would replace assets in Central Bank balance sheets to allow world trade to continue - ie: what would settle world trade deficits.
Yuan, gold, silver or bitcoin?
Hint: Bitcoin and silver are not held by central banks as assets. Yuan's value is subject to the policy of China's politburo. Fool me once on the USD...
World trade does not need any central bank to continue. People only need freedom to do transactions without constant interference. If gov currencies are to collapse, there are only to choices: private IOUs in private banks backed or not by gold (either way, a huge amount of trust is needed to be placed in the banks, almost no one is going to move gold across the world all the time); or bitcoin - which enables world trade without necessary placing trust in intermediaries.
Gold doesn't need to move, only the name under which it is stored needs to change.
Bitcoin - a four year old currency invented by a pseudonym - is not going to be used to clear trades at a sovereign level.
Arabs are not going to ship oil in the ground for bitcoin.
If gold is not moved, it's as good as a promise of the vault owner that holds it for you. History shows that this promise was constantly broken before and after invention of central banking.
To own either bitcoin or gold you need to move it in your personal vault. But in case of bitcoin, it's many times cheaper to move it and have many vaults with extra protections.
Arabs will happily ship oil for bitcoin when both buyers and sellers of oil will no longer be able to use USD or trust banks standing in the way. And, of course, when they learn about bitcoin and we have better infrastructure to support secure storage and trade.
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've done Extreme Programming (cf. _Extreme Programming Explained_ et al) approaches on a team of about that size and it worked okay, but the deadlines weren't as hard. The pair-programming aspects helped keep everyone informed about what sort of implementation decisions and tools were being made (quite useful on a team of eight) without bogging things down with meetings, and it also helped keep people very focused... and also honest about actually being TDD, as in "don't write a single line of code which isn't necessary to make some test pass", which helps keep you from overengineering some part of the code and helps you meet deadlines.
But it's hard to say whether it'd work, because (a) your problem is described very vaguely, and (b) your team might not be up for it (the classic problem), and (c) even if they were up for it, it's a process they likely haven't practiced much, so that makes it harder
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.
They quickly banned buying coins and money after figuring this out, but the program still had many aspects which allowed quick multiplication of rewards, bonuses, etc. I also achieved 1mln miles using the Starwood card and just made it before my airline decided to no longer allow CC earned miles to count towards lifetime status.
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.
That comment jarred with me too, in reality what they did is the total antithesis of what Paul's quote embodies.
There are a few options for seeing if people will buy before you build. The often quoted one here (and it's also used in the Lean Startup as an example) is have a sales site, have a 'buy now button', but go through to a 'we're currently in beta, email me when it's ready'.
Then buy google ads or whatever your sales pipeline is and see if people click 'buy now'. If no-one does, you've got a problem.
If you've got a big ticket item, you can do something similar but be upfront that it's not built. Talk to clients, see if they want what you're thinking of making and suggest a price to see if they say yes. Again, if you can't find anyone to say yes, you've got a problem.
And for some projects, Kickstarter is another obvious method.
Sell before you build: you go through what you could automate by doing it by hand. Automation is optional. If you actually sell automation then that is of course impossible but if you sell a product that you could create by hand just as well as through a computer program then you can sell right away.
When we launched our company, we spent quite a bit of time identifying, based on the concept, who are the top 100-companies that we would like to do business with, who in the organization would buy this and how do we get to that person.
From there, we cold called / emailed like maniacs - 'here is what we are working on, here is the problem it will solve, here is why you need it, can we have 20-minutes of time to walk you through this?' We leveraged every possible network connection that we had.
When we got people on the phone, we actually showed them mocks of what their site would look like with our platform (lots of Photoshop). Explained that about how we wanted to get them in a beta program, and how much would they pay?
It was a ton of hustle, but we had 10-customers when we launched that were generating a little bit of revenue and willing to give us quotes in the press or get on stage at events.
It is more of a larger, enterprise sale, so it won't work for all companies, but we were essentially selling something that we were building in parallel and wouldn't accept free for an answer.
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.
It is almost impossible to proof read a document you wrote yourself for typos, specifically repeated/replaced words, immediately (while you can still remember writing it.) I don't know if this is true in all languages, but it's definitely true in English.
This is because your brain subvocalises (reads back) what you meant to say, not what you actually wrote, when you re-read and can still remember the sentence in your head.
I know of at least one example of a Deputy Headmaster, who was also my maths teacher, accidentally typing in a swearword to a school report. My Dad (the IT manager, whose job it was to check all the reports before they were posted) got him to read it back aloud (a day or so after he wrote it) and he read out the sanitised/corrected version, aloud, from a piece of paper with the swearword staring him in the face. He was very embarrassed when my dad pointed it out.
In cases like that, you wish you could define a specialised dictionary without the swearwords, so that dangerous typos jump out at you!
to GP: tooling can only get you so far, and you're battling against your own brain the rest of the way. A 2AM README typo is forgivable; a CV/cover letter issue (where you were supposed to be concentrating, and/or getting someone to proof read for you) less so.
Typos are one thing, misuse of homonyms or lack of subject/verb agreement is another entirely. I wouldn't begrudge someone a "teh" in a readme THAT much (though, again: where the fuck is your spellcheck?), but a misuse of "your" for "you're" immediately makes me start to question if they have a clue what they're doing.
> somebody who makes one or two typos in a blog post on their personal home page.
You'll note that the best bloggers/essayists (e.g. pg) have other people proof things before they post them for public consumption.
I didn't say it doesn't have false negatives. I just said that it's a good proxy for attention to detail and diligence. Life isn't a warm-up round or a first draft.
MVPs aside, when you release something for public consumption, it should be as high-quality as you can possibly make it.
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.
> 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.
Ideally, a REST API would only require consulting the documentation on media types and the location of the root endpoint, but the kind of media-type heavy, hyperlink driven driven specification that would support that is rare.
Though specifications aimed at improving at least the hypermedia part of that are starting to gain traction.
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.
The value is loose coupling and composability; each media-type is its own contract, and hypermedia provides a common mechanism for discovering the location of endpoints.
This allows different APIs (and their clients) to share common components rather than every large API being a special snowflake.
> To me it's like proposing that in SQL we replace 'EXEC' with 'HEAD', 'PUT', 'DELETE'...
A better SQL equivalent is proposing that you expose to each consumer an appropriate set of relations (likely views) as the application's interface to the database rather than stored procs (the data description of the view is the analog of the media type of the REST resource.)
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?