In which MPOE-PR offers free options contracts.
January 31, 2014
Updated to be more sensible.
- open (private) bet that the Dow/SP/whatever closes above some arbitrary number today
- wait for bet approval
- place the same amount of btc on each side
- let bet close, collect cleaned coins at your specified receipt address
Your bet will resolve, Bitbet will take their 1%, and your receipt address will be filled with coins from the Bitbet war chest, unconnected to your original dirty coins.
Also, you can just place a badbet and catch the "mixed" refund, although MP promises to raise the fee to 5% if you start doing this on a regular basis.
There are other ways to effect the same thing, but they'd require you to actually calculate the parimutuel odds on a live bet. Not a thing I know how to do, so if you'd rather take that approach go figure it out yourself.
Mircea Popescu holds that Bitbet is killing off mixing services in this fashion, but since some people still use mixing services to clean up their booty it's probably worth bringing to your attention that there is a robust, reliably, trustworthy service that you can trivially repurpose to mix your dirty coins for a tiny fee.
Some aren't lazy and stupid. Some are smart and work hard.
The tinfoil hat anarchist brigade has little to lose and the advantage of tough talk from behind tor or at least a proxy. Unlike all but a very few forum members I am a merchant with a physical location. Whatever the Governments impression of the Bitcoin- I'm at the front of the line to be held accountable for it.
Madams. Always on the frontier.
January 30, 2014
A Dojo is a place of practice, first and foremost. We spar before and with our masters and each other, honing our skills and studying the important forms. This can play out in many ways, depending on your technical community.
For instance, there is the Intel-style CodeRetreat, wherein everyone forms into teams of two and hammers at an implementation of the Game of Life. Participants are invited to impose constraints upon their process such as:
- Ping-pong TDD
Wherein one player writes tests and the second makes them pass. This model can lead to some interesting and amusing interactions between the test-writer and the code-writer1, 2.
Red/Green/Refactor is a commonly exhorted pattern in ye giant software shops (and XP fanatics). Ones tests start off red, one must write code to make the tests pass, and then refactor the code so produced to fit with local standards/conventions or quality controls.
- short methods
Disallowing methods (or for me, functions) of a greater length than 4 or 5 lines (arbitrary and chosen at team discretion)
- no class-based systems
In an London style Dojo, participants (guided by a facilitator, for nothing happens without leadership in this world) generate for themselves a list of topics or specific exercises to attack in groups of 4-6. Group size is important in this model, as we want to copy knowledge from the black belts down the ladder of experience. Furthermore, it's unconscionable to keep master practicioners at the keyboard, increasing their RSI exposure while there are novice practictioners at hand to channel their designs into code and mayhap learn a bit in the process.
With both of these approaches, a fundamental tenet is that we are all present to engage in a spot of deliberate practice. Not merely to run through the same forms again and again, practicing the same problems, implementing the same solutions, reaching for higher levels of abstraction and learning about hidden corners of the computation space; but to do all of the above a critical eye on our own performance and shortcomings. Much better, actually, to have several eyes on our work at all times - hence the code review when shipping product, and the dojo for deliberate practice.
We also strive to study excellence! We can deform a trite pop psychology phrase into one applicable to our situation: "you are the average of the 5 programmers who teach you and critique your work the most loudly". Those who learn and study are doomed to a dismally shallow learning curve, as they struggle with basic and then more advanced concepts, as they develop internal paradigms ever-so-minutely wrong whose wrongness will compound with all of the other mistakes to subtly undermine their worldview. A Dojo is a place to come and study excellence; to ask questions and recieve wisdom. To present ones work (as one does it) to those who've been around the block a few times and can offer feedback on our performance. In this manner, we can accelerate our learning process, encounter excellence and learn from it.
Just as important as studying excellence is practicing excellence. My favorite method for getting around the coding team/testing team dynamic is to whip programmers until they write their own tests for things. I kid, I kid! While no test-obsessed Python fanatic, writing tests is the best way to constrain and ensure the performance of my and my teams' code3. To that end, we all write tests! We write our own tests! But! Learning to write tests can be a painful and apparently pointless process when taken on in isolation, as the novice programmer is wont to do when imitating the behaviors of professionals in the field. The Dojo provides these novices an opportunity to write tests under the watchful eye of someone familiar with the 'arrange, act, assert' pattern who can provide meaningful feedback in real time4. Testing ones own code is one pattern among many the Dojo gives its students the opportunity to practice. Exposure (studying) and implementation (practice) are two sides of the same coin. One cannot practice that which one is ignorant of, and one can rarely progress rapidly while practicing with only oneself for coach and exhorter to higher levels of performance.
Practicing excellence also means mastering your toolchain of choice. For those of us who like the battle-hardened solutions, that's Emacs. For those of us who simply want to lay down lines of Lisp without wasting time getting to know our environment and shaping it to our will, that'd be something like Sublime or Lighttable. It also means figuring out a good workflow for our tests - do we keep a test-runner going in a window separate from our editor? Do we load our tests into the REPL at which we're hacking, and expect our testing toolchain to inform us when we've broken everything? These are all engineering tradeoffs that must be considered carefully, tested and played. Nothing in the mastery of toolchain comes quickly or is perfect - there is always much tweaking and changing of setup5. The Dojo provides a place where people with different configuration philosophies can come together, argue about the merits of different approaches and share those philosophies along with concrete implementations with individuals new to the environment-configuration game.
Undergirding all of the above is the notion of learning from others. We are all humans, prone to making bad decisions and biased towards thinking our own decisions the pinnacle of amazing. Bike polo players practice against each other in a culture of heckling - this drives quality, as everyone learns from one another. Stellar tennis players hire coaches to instruct them on improving their performance - few can both throw themselves into a game and monitor their performance well on the fly. The skills and knowledge we build our careers on can be grown in isolation from others, and even grown well in a corporate setting. Far more effective, though, to come together as a group interested in learning from each other and share our knowledge. "He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me", as Jefferson said.
Critically important, binding all of the above together, is that we all have a good time! We all know the fun and joy of building things; the amazing dopamine surge of imagining a thing and then building it. Too frequently though the creative process is held hostage by the harsh mistress of economics6. We sit through meetings, participate in all sorts of non-value-added work, and are under constant pressure to ship functional software7. The Dojo is a place to recreate that feeling of flow - that pure joy that comes from understanding a problem space and addressing it well.
Dojo: a place to study; to deliberately practice; to learn ones tools; to understand excellence and practice those habits; to share knowledge and absorb it from others. A place to recreate the child's joy in building. A place for practitioners of great skill to achieve new heights.
Isn't it interesting how splitting the roles apart immediately leads to a judgement of the different kinds of work in your mind? There have been some legendary testing teams who built out legendarily error-resistant software pushing similarly legendary hardware clean into orbit (most of the time), but in the instances of software organizations large enough to have grown testing organizations within themselves I've been privileged to witness the groups are invariantly on entirely different planes of existence and play entirely different roles in the corporate structure. Programmers are always paid more and sought after more than the testers.
People and teams who can build across multiple computing interfaces are rare jewels - and none of them arrive at that state plodding along in a job gradually gaining experience in things. Far more likely a path is the one of struggle and hard work, continually pushing against the bounds of what is possible with capital and skills always in search of the next big hustle and squaring each previous job off keeping all stakeholders satisfied with price paid and value delivered. Along that path is technical excellence built and insightful humans grown.
If you want to really understand the intellectual shitshow that is object oriented programming, use the ping-pong approach to teach someone a functional language (preferrably Lisp) and then use the same approach to teach them OOP. If the difference in the speed at which your pupil learns and becomes useful with Lisp and an OOP system is not apparent, you're either using Smalltalk (you smarty pants) or shouldn't be allowed near computation machinery.
Sometimes I say that tests are the constraints upon my code. Code that works without tests is fine and fantastic and great, and its author probably saved untold amounts of time writing it without tests. A well-engineered beam is designed with the use of a set of equations that describe its constraints and its loadings. The equations are arranged into a set of equations, the whole of which must be true at all times for the building to remain upright under its specified loading conditions.
Code with no tests is an under-constrained set of equations. The engineer knows the strength of materials involved, the ways in which the parts are connected to each other, but has not specified the loadings or vibrational environment and so can make no claims as to the performance of the system under load. Code with no tests is a machine that works today in some entirely unspecified ways. It takes unknown inputs and produces unknown outputs. Code with tests on the other hand, while not a completely constrained system, is constrained to produce certain outputs when fed other certain inputs. There may be a whole other space of behaviors through which the system can move, but the job of tests is to mark out a subset of that higher-dimensional space and ensure that the machine always behaves properly in that space of inputs.
Temporal proximity of feedback to actions is critical for deliberate practice. Critique of a thing completed two days ago is near-useless, compared to critique in real-time.
This drives my partner insane. He comes from the land of MSFT and APPL, who deliver Integrated Development Environments just about adequate to the task of working well both for people who have no idea what they're doing and also power users at the same time. Conservation of quality implies that these Environments will never be well-suited for either the novice or the expert, but forever be an entirely adequate and yet disappointing experience for both. At least with an environment that you've built out and customized yourself you're not dependent on a publically-traded company in cahoots with the Tyrant and furthermore you only have yourself to blame for inadequacies in your toolchain.
Although now that I think about it, people hate blaming themselves for inadequacies in their toolchain, and will probably always rather offload that responsibility to some massive corporation.
We loll at her feet and obey her every whim.
What, after all, is a job?
January 29, 2014
Zero Hedge writes:
Following the quiet update that HSBC had decided to withhold large cash withdrawals from some if its clients - demanding to know the purpose of the withdrawal before handing over the customers' money - it appears the anger among the over 60 thousand readers who found out about HSBC's implied capital shortfall just on this website, has forced HSBC's hands.
Unless you have at least a full million US in the bank (and even that's an unlikely lower bound) your bank does not work for you. The bank works for people who borrow huge sums of money and pay interest on them, and your local government to keep an eye on your weed purchases.
Fiat banks are going to implement more and more of these sorts of regulations. Large cash withdrawals will be considered suspicious because why would you not trust the bank with your cash? Why would you not simply send money through the (buggy, legacy, slow, shitty) international payment system where the Tyrant can inspect yourself and your recipients finances for things that could imply misbehavior and land you in the slammer?
Bitcoin is here to fix this. Nobody can interdict your Bitcoins, short of thermo-rectal cryptanalysis (and you can even reduce the risk of TRC with various smart multisig transactions). Nobody can even inspect your payments if you know what you're doing.
In short, Bitcoin is here to fuck up fiat institutions. It starts by breaking the banks of such bad behavior as called out above.