Hacker Newsnew | past | comments | ask | show | jobs | submit | danprager's commentslogin

I put it down to a limitation of the Aussie (and other) stock exchanges. The shares had dropped to $0.01, when their true value was negative, given the stapled obligations that they carried. Bolton should have been paid to take on the debt in the first place.

A whole lot of other people apparently made the same transaction unwittingly, without reading the fine print, as it were. The sellers of the $0.01 shares were paid a peppercorn and washed their hands of the debt.

I reckon this is a problem for the regulators. Once the shares dropped below the value of the remaining obligations (give or take) a fairer price would be negative. Alternatively, trading should be suspended because there's a fair argument that the company is insolvent at that point.

Instead, this fact was hidden behind a little "complexity" and inadequate rules.

Bolton just took advantage of a broken situation.


The stock exchange can take plenty of actions against a stock and from a lay perspective it sounds like they should have.


Good, but overly long article. I have reached the similar conclusions in favor of functional tests over the last decade or so.

Personally, I have worked seriously used DBC, TDD, and automated scenario testing, and hybrids in that order of learning.

My conclusions about the sweet-spot (and this may vary depending on your area):

1. Automated functional testing in the large, and DBC in the small is a winning combo.

2. Special techniques for graphics intensive programming: I get my scenario tests to show what's happening on the screen, and I can slow 'em down and step through 'em

3. I never got a lot of dependency injection / mocks (like the author) -- not sure if I don't get 'em or application area is wrong

4. You need special techniques for intensive algorithmic code where there's a combinatorial explosion of cases and line coverage won't do; e.g. randomly generated test cases + compute intensive sanity checks

Bottom-line: Automated scenario tests exercise the code; DBC pin-points illegal states.

DBC = Design by Contract = pre-conditions + post-conditions + invariants. In practice understanding the method (this takes work) and writing explicit pre-conditions gives ~70-80% of the benefit. To do invariants well needs language support.


Kent Beck's book: Test-Driven Development

Don't just read it: Work your way through it. You need to follow the recipe to develop the discipline/knack.

Fairly quick and reasonably easy.


Side-track: The Romans used IIII for 4, not IV, etc. which was introduced by early printers (not dot-matrixes ;-) to save space, so the original system was more additive.

Looked at in this light, you can see more easily how humanity progressed from tallying, to counting on fingers -- use fingers to tally up to four, take the thumb to represent five -- to the abacus and Roman numerals.


I had exactly the same thought as I started skimming this: uh oh, first decide what convention you are going to use. Or do you do that last?


They do work; they just don't integrate with the built-in types: Why should they?

Try instead:

  car(cons(1,2)) 
    -> 1

  cdr(cons(1,2)) 
    -> 2

  car(cons('a', cons(2, 3))) 
    -> 'a'


Well right now you are using an application -- Hacker News -- that is written in pg's Arc language which runs as an interpreter on MzScheme which is part of PLT Scheme.

Why don't more people use DrScheme, HTDP, etc.? This is a question about learning, culture, change, etc. more than any particular environment, method, etc.


In the spirit of FSJ, intended in part to satirize Australian governmental attempts to increase internet censorship.

Some of the tweets:

"Apparently LOL means 'Laugh Out Loud' and not 'Lots Of Love'. Now I'm going to have to re-read all those internet comments about me."

"about to board my flight to Melbourne .. nabbed seat 1B! a person in a wheelchair was going to get it .. lucky IM CONROY! Trump card played!"

"When I Googled for information on how to circumvent surrogacy laws in Victoria, I bookmarked the results so we could ban the sites later."

"The filter is a community service; it's not just about removing content, we can also repair content. We can make it truthier."

"I don't think it's unreasonable to compare the National Filter Network to a cure for Super-AIDS; both of them protect children."

"Dear journalists; please do not continue to report on my enormous penis and ability to please the ladies. My personal life is off-limits."

"Today I received an I-Phone. The IT people tell me that it is biometrically activated, but no matter how much I lick it, it won't turn on."


There have been a few attempts to methodologize a more "consultative approach" to Sales, notably SPIN Selling, Strategic Selling and Solution Selling.

The last of these has been the most successful, and interestingly it was cooked up by a tech. support guy, Mike Bosworth, who was "persuaded" to try his hand at Sales.

I have tried to summarize the essence of Solutions Selling here: http://dailykibitz.blogspot.com/2009/01/distillation-of-solu... and have just released a product, bSelling, intended to support this kind of approach: http://dailykibitz.blogspot.com/2009/03/first-web-based-prod...


An app store gives somewhere for vendors to hang up their shingle (like a mall), and -- depending on the barriers to entry -- gives some assurance to "shoppers" looking for apps.

We've just launched a new business app, bSelling - http://bcisive.austhink.com/solutions/bselling, on Salesforce.com's App Exchange for add-ons to Salesforce CRM, and wish that there were more such stores.

It's actually a bit like the Microsoft stranglehold on the old PC software market; there were certainly negative aspects, but the standardization effect was certainly market-making.


For our first web-based product we (Austhink software) decided to go straight for integration with the web-based Salesforce CRM, and put it up on Salesfore.com's AppExchange marketplace.

We've only just got it up there, but I thought that our experience may be of interest to those looking to play in the "Enterprise 2.0" (i.e. cloud-based, single-sign-on, Saas, mashed-together apps) space.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: