Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf] - <AUTHOR> https://pdfs.semanticscholar.org/c77e/fb40fa7ad307314e109b7f8fa7429cbacd4b.pdf <comment><USER2> Can't help but think we'd learn a lot if other industries were as mature in tracking these things as the safety critical ones.

<comment><USER3> I'm always surprised by how thoroughly uninterested the Haskell and Rust communities are in learning from the Ada/High Integrity Software community.

Here you have people who are actually doing what you purport to be interested in (creating defect-free code) who have a great deal of experience and a great many insights from actually putting their code into avionics bays knowing that thousands of lives are depending upon it.

But they're not valley programmers. They skew older. Heck most of them don't even live in California. And they don't "get" what's so amazing about category theory as a programming paradigm so obviously they're morons. Plus they seem to be process-obsessed and that process ain't agile.

Maybe eventually the valley bros will rediscover most of what the Ada programmers already know.

<comment><USER4> > I'm always surprised by how thoroughly uninterested the Haskell and Rust > communities are in learning from the Ada/High Integrity Software community.

If you read the paper you would find that the _VAST_ majority of issues were human communication or understanding of the problem. No programming language can fix that.

Rust was started with one overriding goal: make programming on Firefox manageable. And they identified a primary problem: uncontrolled sharing. And they killed it: Rust disallows sharing by default. Everything else in Rust stems from _that_. "category theory" or any other academic CS is used when it helps the primary mission--otherwise it gets deferred.

> Maybe eventually the valley bros will rediscover most of what the Ada > programmers already know.

And yet Ada exists practically nowhere that requires timely deliverables. Funny that.

Much like Lisp, if Ada were such a force multiplier, there would be _someone_ who would use it to make lots of money.

<comment><USER3> A few years ago, AdaCore's Robert Dewar observed that nobody has ever been killed by a flaw in Avonics software. That's perhaps not a good elevator pitch for a hockey stick startup but it's a good testament to the capabilities and skills of the people in the High Integrity community.

It's true that High Integrity development is not compatible with deadline or budget driven projects.

But there _is_ a lot to learn from the High Integrity community and I think it's a shame that people who claim to be interested in making software more reliable ignore a community with decades of experience doing just that.

<comment><USER4> > A few years ago, AdaCore's Robert Dewar observed that nobody has ever been > killed by a flaw in Avonics software.

While that may be _technically_ correct, I would consider the crash of Air France Flight 447 to be partially an avionics software failure.

Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state (alternate law) and throwing control over to the very surprised humans counts as a software failure in my book. Having a stall warning that tells you to do the wrong thing is a software failure in my book (the stall warning turned off when inputs were invalid, but then turned back on when the pilots actually made the correct maneuvers because the inputs weren't invalid anymore).

While ultimately the failure for that flight was human error, a smart reaction by the software at any point would have prevented that tragedy. The biggest "smart reaction" would have been to flag the invalid airspeed to humans but _don 't change anything_.

Whoever thought that dropping a suddenly dynamic system into the hands of surprised humans was a useful action should be shot. In reality, nobody thought it. Each individual subsystem had their own failure procedures, and nobody ever tested what happened when they interacted.

<comment><USER5> > partially an avionics software failure... Responding to an inconsistent > airspeed measurement by disconnecting the autopilot and then dropping into a > weird, modal operating state

You could write that software in rust to do exactly the same thing.

<comment><USER4> Quoting myself upthread:

> If you read the paper you would find that the VAST majority of issues were > human communication or understanding of the problem. No programming language > can fix that.

At no point did I argue that Rust would have prevented the Air France Flight 447 kind of failure. However, neither would Ada have prevented this kind of failure.

I _WAS_ however taking issue with the quoted "nobody has ever been killed by a flaw in Avonics software".

<comment><USER5> > Avonics software

It's not the software that killed people it's the spec.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.?

I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to things like formal provability.

I'm generally interested in the relationships/processes that mediate between design <-> specification <-> actual programming. In reality, there's a lot of feedback, and I want to create ways of radically improving these processes.

<comment><USER7> It looks like you are looking for the V-Model development process used in the industry (e.g. automotive).

A typical requirement in this model is handled like this: 1\. the high level specification define what is the change about (e.g. implement a hillholder function). 2\. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and you specify how they interface. 3\. detailed design phase: each part is formally specified, in the automotive industry we typically use Model based development (Simulink) to specify this phase. 4\. implementation: actual coding being done, if you use Simulink this is done by the Simulink/dSpace. A unit test is then performed to check that the detailed design from part 3 has been correctly done. 5\. Integration and test: all parts are collected and compiled, and we look that the interfaces are matching. 6\. System test: all parts are now tested together against the specifications done in the architecture phase (part 2) and part 1

In the automotive industry, each step can be done by a different person/team/company thus the documentation done in each phase is extremely important to avoid finger pointing in case a problem is detected after delivery.

<comment><USER6> Oh—also—do you know what software out there is already used for managing this complexity? Thanks again!

<comment><USER8> I've used DOORS. It was adequate, though not a pleasure to use. (It might have been a pleasure if the alternative was doing it manually...)

<comment><USER9> Having done it manually, DOORS is a dream.

I haven't used a recent incarnation of it though. It's UI circa 2008-2010 was entirely mediocre but sufficient for the task.

</comment></comment></comment></comment></comment><comment><USER10> Strange how whatever Adrian Colyer covers in his The Morning Paper makes its way here. People perfer posting the original paper rather than his blogs posts.

<comment><USER11> This happens because the HN submission guidelines at [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html) say:

"Please submit the original source. If a post reports on something found on another site, submit the latter."

The main objective is to highlight and share interesting research, and if a post on 'The Morning Paper' achieves that and promotes informative discussions like the ones in this thread, then I'm happy.

On a good day, I like to think there's enough in my posts that the commentary does qualify as an "original source." On a bad day, the post may be a more straightforward summary of the paper content (though I've occasionally tried passing the text of a paper through an auto-summariser for fun, and let's just say it doesn't look like I'm going to be out of a job anytime soon!).

For example, the post that presumably inspired this HN thread (the timing certainly suggests that) is more a straightforward summary: [https://blog.acolyer.org/2017/12/01/analyzing-software- requi...](https://blog.acolyer.org/2017/12/01/analyzing-software-requirements- errors-in-safety-critical-embedded-systems/). The post from the day before on a related topic is interwoven with much more personal commentary: [https://blog.acolyer.org/2017/11/30/the-role-of-software- in-...](https://blog.acolyer.org/2017/11/30/the-role-of-software-in- spacecraft-accidents/).

Even in the 'straightforward summary' case, I will typically have spent a couple of hours or more reading the original paper, trying to distil the key points and putting them across succinctly. (It's not for me to judge whether or not I succeed at that, but this is the aim!).

My hypothesis is that more people have time to read a long-ish slightly informal blog post than they do to scan a 12-20 page research paper. And it would be shame if when presented with only the link to the original paper pdf, they miss out on some of the key ideas within it because it feels like too much effort to read or scan the paper when presented like that. For one paper I'll be covering next week for example (and this is an outlier), I spent about 5 hours in total on reading, trying to understand, getting the background and context clear, and then writing it up.

In those cases when the original HN link is to the full paper pdf rather than to my post, then I guess an easy way to give readers the benefit of both is simply a comment in the thread pointing to the 'Morning Paper' summary... The main thing though, as I said at the top, is that interesting and thought- provoking research reaches a bigger audience.

<comment><USER10> Thanks for taking out the time to write such an elaborate clarification, Mr Colyer. I was unaware of the guidelines until you brought them to my attention. I myself am quite an avid reader of The Morning Paper, and was initially taken aback to see that people post the original paper after reading your blog, and don't mention you anywhere. It kind of didn't feel right to me. But now after reading your explaination, I am okay. Thanks again :)</comment></comment></comment>


Phoronix reviews ARM SBCs - <AUTHOR> http://www.phoronix.com/scan.php?page=article&item=march-2017-arm&num=1 <comment><USER2> No CHIP in there...</comment>


LibreSSL 2.3.3 - <AUTHOR> http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.3.3-relnotes.txt <comment><USER2> Wow, that's the simplest release notes page I've ever seen. Alright, well, good work to LibreSSL team on continuing to improve an important piece of software. :)</comment>


How To Build a Naive Bayes Classifier - <AUTHOR> http://bionicspirit.com/blog/2012/02/09/howto-build-naive-bayes-classifier.html

<comment><USER2> Years ago I wrote about this for Dr. Dobbs. That article is here: [http://drdobbs.com/article/print?articleId=184406064&sit...](http://drdobbs.com/article/print?articleId=184406064&siteSectionName=) The important differences are that the DDJ article used log probabilities instead of simple probabilities because underflow is a real problem.

The other thing is that simple thresholds aren't the only solution to using the output of naive Bayes for determining whether a message is ham or spam. Back in 2007 I looked at calibrating the output to deal especially with the problem of messages that have a probability near 0.5: [http://blog.jgc.org/2007/03/calibrating-machine-learning- bas...](http://blog.jgc.org/2007/03/calibrating-machine-learning-based- spam.html)

Also for spam filtering it's worth testing whether stop word removal and stemming are actually worthwhile: [http://blog.jgc.org/2007/03/so-how-much- difference-do-stopwo...](http://blog.jgc.org/2007/03/so-how-much-difference- do-stopwords.html)

<comment><USER3> You are right about log probabilities ... I added a note about it (I'm the author of the article).

Also on spam filtering, there's a note there about stemming not being optimal for spam, but the spam classifier was just an example, otherwise stemming is still useful when bootstrapping with a small dataset.

<comment><USER4> I found that note very interesting:

> consider "house" and "housing" ... the former is used less frequently in a > spammy context then the later.

The point is that stemming is valuable unless P(spam|root) is substantially different from P(spam|derivedWord). But that data is available to you through Bayes. Has anyone tried a 'conditional stemming' system where the word is stemmed iff

|P(spam|root) - P(spam|derivedWord)| < someThreshold

? I wonder if that would improve classification accuracy. I suppose it might be a big performance hit on the stemming algorithm though.

<comment><USER5> Interesting idea. I bet within some specific application domain, stemmed probabilities either diverge or don't across the board, so it wouldn't pay to conditionally stem term-by-term.

<comment><USER4> Yeah, probably. That's something that's fairly easy to measure for any given data set, so you can check to see if it's worthwhile before you do it.

</comment></comment></comment></comment></comment><comment><USER6> Nice article, but I suspect the implementation will not work. I did essentially the same for an AI-class exercise, and was thrilled to see that you could write a working Bayes classifier in 60 short lines of Python code. But later I landed a free-lance job that required writing a classifier that could be applied to real world data, and I soon realized that repeated multiplication of numbers between 0 and 1 sends you to zero too fast for the implementation to actually work. I might have missed it in the code, but I think he's doing the same mistake: you need to normalize or move to logarithms for the estimation of probabilities to work for medium or large datasets.

<comment><USER3> I'm the author of the article ...

Yes you are right, it's better to convert the whole thing to a sum of logs, otherwise you end up with floating-point underflow.

The article was getting already too long however, but I'll add a note about it because it is an important optimization that affects both speed and even correctness (because of the underlying limitations of floating point).

UPDATE: note added.

<comment><USER7> Is the sum of logs method mathematically equivalent to the multiplication of probabilities (i.e. will it always produce a monotonic ordering of class predictions)?

<comment><USER8> log(AB) = log(A) + log(B) for all A, B real numbers

<comment><USER9> Only for A, B > 0, but that's good enough for probabilities (except 0, I guess)

<comment><USER8> That was there to test you...

</comment></comment></comment></comment></comment></comment><comment><USER5> We wrote a Naive Bayes Classifier for <http://linktamer.com/> that learns what news articles you find interesting. It's in C and uses a cdb for the database of frequencies, so it's pretty darn fast. Maybe we'll throw it up on github one of these days.

Some resources and other reference implementations that were useful in building it:

<http://www.gigamonkeys.com/book/practical-a-spam-filter.html> \- Siebel's "Practical Common Lisp" book has a very readable implementation

<http://www.paulgraham.com/spam.html> \- pg's essay that revived interest in using NBC for spam classification

[http://spambayes.svn.sourceforge.net/viewvc/spambayes/trunk/...](http://spambayes.svn.sourceforge.net/viewvc/spambayes/trunk/spambayes/spambayes/classifier.py?revision=3270&view=markup) \- a Python implementation that's been out there in the real world for about 10 years

[https://github.com/WinnowTag/winnow/blob/master/src/classifi...](https://github.com/WinnowTag/winnow/blob/master/src/classifier.c) \- a C implementation used in another news classifier

<comment><USER10> _"We wrote a Naive Bayes Classifier for<http://linktamer.com/> that learns what news articles you find interesting."_

I did something similar using dbacl.[1]

Unfortunately, I never got around to releasing the code. However, it worked alright. The main problem was in the hassle it took to continuously train and retrain the classifier as my interests changed.

This is the main difference between articles you actually want to read and spam: spam is pretty much always going to remain spam. Your interests are never really going to change to the point that something you thought was spam one day would no longer be spam the next. But with articles, what you might have found uninteresting one day may become interesting the next. And what you thought was fascinating one day may become boring the next.

Thus, the need for continual training and re-training for spam is much less than it is for news articles and the like.

Because of this, the classification/reclassification process for news articles should be made as simple, quick and painless as possible. Otherwise it'll just be too much trouble to keep doing it day after day, week after week, month after month, and year after year.

[1] - <http://www.lbreyer.com/dbacl.html>

<comment><USER5> _But with articles, what you might have found uninteresting one day may become interesting the next. And what you thought was fascinating one day may become boring the next._

True. This is a real problem. Much better results can be obtained by partitioning the space of articles and predicting on more focused subsets. The partition can either be manual ("these documents are from my RSS feeds about Python programming") or automatic, via some clustering algorithm.

Ideally you identify subsets where your interests are less transient.

But the flipside of using a general purpose classifier is that you can train it to predict whatever you want. You're in the driver's seat. It doesn't have to be "interesting," it can be "most relevant to my primary area of research" or "most relevant to this book I'm writing" or "most relevant to my small business."

Communicating this capability to users is whole 'nother deal of course.

 _I did something similar using dbacl._

I remember looking at dbacl. There's some great information in the writeups, but I was disappointed that it coupled feature extraction to classification. For instance, what if you wanted to use stemmed terms as features? How good is the word tokenization for other languages? (compare to Xapian's tokenizer) Can it do named entity identification and use those as features? Can you toss in other features derived from external metadata? Etc.

We ended up doing all of these things, but our classifier itself remained a simple unix tool. For training you piped in (item,feature,category) tsv records. For classification, you piped in (item,feature) and it output (item,category,probability).

</comment></comment></comment><comment><USER11> Another useful toolkit for stuff like this (and anything to do with natural language), but only available for python at the moment is the Natural Language Toolkit: <http://code.google.com/p/nltk/>

It's a very powerfull toolkit, with a lot more functionality than is needed to write an NB classifier, but may be of interest to anyone looking at NLP!

</comment><comment><USER12> This is a good explanation, though like the Dr. Dobbs article linked on this page I prefer the exposition of logs. (Looks like the author updated for it.) I also have a personal displeasure of Venn diagram and set-based and event- based versions of probability, and non-conditional probabilities rearing their heads, but that attitude comes largely from reading Jaynes...

I wrote my own Naive Bayes function for helping me tag my blog posts back in January. I did a longish explanation and implementation (PHP), it'd be cool if someone wanted to check my math/intuition since while my button has worked out so far (that is, no really surprising results have crept to the top as most likely) I wouldn't be surprised if there's an error or justification for a better calculation of a particular probability term that I missed. [http://www.thejach.com/view/2012/1/an_explanation_and_exampl...](http://www.thejach.com/view/2012/1/an_explanation_and_example_of_naive_bayes)

</comment><comment><USER13> Really enjoyed that read. I'm looking at implementing some simple spam detection for personal messages that are sent between users of my application. (They are enquiries for sales and users are billed per enquiry so it's important to make sure that they don't get billed for spam), do you think Akismet would be suitable for this kind of thing? Any alternatives that you could recommend, I will probably get around to building my own at some point, but as a proof of concept I'd like to just get something running.

<comment><USER14> A few months ago I tried to apply what is basically the same code (written in C#) to Twitter to see if I could filter the spam messages I receive. It's a great exercise for those interested in playing with the algorithm.

</comment></comment><comment><USER15> Pretty good explanation - my only gripe is that all bayes classifier tutorials like this build the 'spam detector' type that's specialized to text. Though it's a common use case, that isn't the only thing that the classifier can do - you can use it for raster classification, other types of predictions, etc: and building a non-specialized version would make this point more clear.

</comment><comment><USER16> In response to some of the comments:

In my experience, all variables are important, but on testing, using only the ones (i.e., the words) observed in the text to test yields the best effectiveness rates, following the implementation from Manning, Raghavan and Schütze (2008).

In addition, the considered Laplace smoothing is of utmost importance to deal with out-of-vocabulary words, thus avoiding the annoying 0's.

My implementation:

[https://github.com/atrilla/nlptools/blob/master/core/classif...](https://github.com/atrilla/nlptools/blob/master/core/classification/MultinomialNaiveBayes.php)

</comment><comment><USER17> Here are the basics of putting together a Naive Bayes sentiment classifier with NLTK <https://gist.github.com/1266556>

Here is a full project I started to to the same backed by redis adn built to scale for large applications: <http://github.com/tawlk/synt>

</comment><comment><USER18> One thing which is missing from this implementation is the use of lemmas. Rather than treating words like "house", "houses", "housing" all as separate terms, they all get reduced to the stem "house". <http://lemmatise.ijs.si/> is a good resource for this.

<comment><USER19> He covers this in some detail, under the term stemming (which I've heard more often in this context). He even makes a library recommendation.

<comment><USER20> Lemmatizing and stemming are similar, but not the same.

Example for possible results:

Lemmatizing: indices -> index

Stemming: indices -> indi

[http://en.wikipedia.org/wiki/Stemming#Lemmatisation_algorith...](http://en.wikipedia.org/wiki/Stemming#Lemmatisation_algorithms)

<comment><USER21> It's probably worth noting that in this context stemming is probably most appropriate. Lemmatizing is unlikely to give better results and in most implementations you suffer a significant performance hit.

</comment></comment></comment></comment><comment><USER22> Thanks. It's refreshing to see algorithms written using real variable names and your tutorial is made much better because of this.

</comment><comment><USER23> Great article, all these Bayes articles have really piqued my interest in Machine Learning. Love it! Good stuff!

</comment><comment><USER24> can you build one to dig for interesting stuff in: <http://pastebin.com/D7sR4zhT> ?

<comment><USER4> The algorithm needs training data. In this example you have a load of emails where you've explicitly tagged each one as either spam or ham.

So you could perhaps do what you're suggesting, if you have a big database of emails tagged as 'interesting' or 'not interesting'.</comment></comment>


Email manager that makes your life easy - <AUTHOR> https://www.sanebox.com/signup/3fb1a8691a <comment><AUTHOR> awesome product, have been using it for a while</comment>


Kubernetes's days may be numbered as open source changes - <AUTHOR> http://www.infoworld.com/article/3204597/open-source-tools/kubernetes-days-may-be-numbered-as-open-source-changes.html?idg_eid=ea621681ab512cec8d9e451279fa812d&email_SHA1_lc=8f05fa03a5aba1cbe0b9f0b29d54217c367b39ba&cid=ifw_nlt_infoworld_daily_2017-07-05&utm_term=infoworld_daily&utm_content=buffer22512&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> Kubernetes is here to stay. Google could vanish tomorrow and most of the longterm impact on Kubernetes would be programmers adjusting to Bing's interface when are searching for particular information. Red Hat would pick up the ball and carry it themselves, if they had to, because OpenShift is as existential to them as GCP may become to Google.

The article glosses quickly past the fact that Collison is talking his own book here, because Apcera has struggled to build a large-scale business on closed source.

Meanwhile the project he helped to launch, Cloud Foundry, is the basis of ... uh ... shall we say I am aware of _many dollars_ going to my employers and our major competitors. We also work very closely with Google on stuff that _isn 't_ Kubernetes and stuff that _is based on_ Kubernetes. They like both equally. Why? It brings in customers.

Opensource has won the CaaS space. That phase is over. No F500 is prepared to buy something with no escape hatch from vendor lockin. Neither is any F5,000,000.

All that's left is to answer: which opensource?

Disclosure: I work for Pivotal, we're the leading contributor to Cloud Foundry. Don't base any decisions on anything I write, I'm just a line engineer with an overactive keyboard.</comment>


Government Hankers for Hackers - <AUTHOR> http://www.nytimes.com/reuters/2011/08/02/technology/tech-us-usa-hackers.html?hp <comment><USER2> Hm. I don't know much about American government positions, but I do know that here in the UK the government positions tend not to be very attractive. On top of working in a very constrained environment (can't use any of your own hardware, can't buy tools that are not vetted by security and IT, ridiculously out-of-date technology and low standards for development and achievements), the salary is bobbins compared to private enterprise and things take an age to get done.

Almost certainly, you do not choose to take a government job to do with technology - it's the only thing that you can get. All the interesting projects seem to be outsourced to external consultancies, which can charge a fortune for a poorly-implemented system that gets delivered behind schedule.

Is it any different across the Atlantic?

<comment><USER3> _the salary is bobbins compared to private enterprise_

Not true, public sector workers are better paid than private sector, and have absolute job security and generous, gold-plated pensions: [http://business.timesonline.co.uk/tol/business/industry_sect...](http://business.timesonline.co.uk/tol/business/industry_sectors/public_sector/article6974029.ece)

<comment><USER2> Not in technology! If you can code C++ or Java, you can get a job in a bank. If you can make electronics, look to Siemens or a multitude of smaller tech companies. The same sort of persons are sought by DSTL or Qinetiq, or even AWE. The bank may offer £40k-£80k for someone with no prior experience. The tech company may offer £40k. The government-run companies offer £20k-£35k.

I know this, because I am currently looking to find a new position somewhere and I have been looking around. That Times article refers to all public sector workers, including teachers, nurses and administrators. In these professions, I believe the article. In research and development, I do not.

</comment></comment></comment><comment><USER4> I don't know how the NSA plans to fight its public image of wiretaps and general malfeasance. It might be in their interest to cordon off a particular area for unclassified work and invite hackers over to get a sense of what they actually do.

<comment><USER5> we shouldn't underestimate the number of hackers (job applicants) who think _wiretaps and general malfeasance_ are okay.

</comment></comment><comment><USER6> Are they looking for Lisp hackers? <http://cryptome.org/0005/dod-lisp-sol.htm>

</comment><comment><USER7> Anyone have direct experience with how sharp NSA guys are?

Versus an average quant? Versus an average googler?

<comment><USER8> It's a government organization, working on a political logic. So likely, they won't be able to attract consistent quality applicants (to the extent a big tech company could). They may however be able to get ideologically-driven people (those who believe in the goodness of NSA's purpose), who are prepared to work for lower wages.

</comment></comment><comment><USER9> Maybe we can use this to help the government bring the sentencing of website defacing crimes back down to Earth alongside well known crimes like physical stealing and vandalism.

If the government wants more top-flight hackers then maybe they should understand that defacing a website is evidence of a deficient company website rather than an evil person who needs to be punished 10x normal.

They will get what they want, because they will reach into your back pocket to compensate the good hackers in short supply.</comment>


Paul Irish talk on Tooling & The Webapp Development Stack - <AUTHOR> http://paulirish.com/2012/talk-tooling-the-webapp-development-stack/

<comment><USER2> I didn't see this one before, but happy I did now. Some great tools I didn't know :)

<comment><AUTHOR> Yeah, there is some great info abt tools for webapp development. It also speaks about different stages in webapp dev.</comment></comment>


Dating the ginormous MySpace breach - <AUTHOR> https://www.troyhunt.com/dating-the-ginormous-myspace-breach/ <comment><USER2> _" The passwords are stored as SHA1 hashes of the first 10 characters of the password converted to lowercase. That's right, truncated and case insensitive passwords stored without a salt"_

I'm surprised this fact is not getting more attention. In theory, this means that a MySpace account with a password of Welcome1234567 could be logged into with a password attempt using any of the following examples:

* Welcome123

* welcome123

* WeLcOMe123456789

* welcome123anythingafterthe10thcharacterdoesntmatter

In essence, case sensitivity and the 11th character onward are completely ignored. This vastly reduces the total key space. To compound the problem, SHA-1 has been used which is not suitable for password storage (salted or otherwise) because it's an intentionally fast algorithm. This means an attacker can more efficiently run all permutations through the hash function to find a hash match and hence the password. In fact, as I've described above, the attacker doesn't even need to retrieve the exact password to gain access to the account. They just need an input that will produce an identical SHA-1 hash (i.e. an input containing the same first 10 (case insensitive) characters as the original password).

Based on the work I've done reversing password hashes in bulk (legitimately for clients in penetration testing engagements), I'd suggest that at least 80% of the reported ~360 million hashes could be reversed within a few days with access to the full data set and $5k worth of commodity GPU hardware. And you can guarantee that these passwords will be used in future attacks against other web sites because of how common password reuse is. Frightening.

<comment><USER3> Not quite as frightening as the schemes some financial institutions use... one that immediately comes to mind is 6 digits, no more or less, and probably stored in plaintext. Then again, bruteforcing attempts are usually very easily noticed and kept from succeeding on such systems.

<comment><USER2> Sure. But it would be a stretch to find any financial institution with as many as 360 million customer records. Maybe one of the state-owned commercial banks in China being the exception.

And more to the point, the corresponding email addresses and/or usernames in the MySpace breach are leaked along with the password hashes. The same email address and password combinations will be tried on other web sites (e.g. Amazon, Facebook) with a reasonable chance of success. No brute force necessary.

</comment></comment></comment><comment><USER4> My MySpace account apparently predates my use of Gmail for my primary address[1], so I can't find the welcome email. I may try to sort through my old Maildirs later tonight to see if I can find it, but my hopes aren't high. That doesn't seem like something I would have saved. Maybe I can get close by finding the first MySpace-related email I did keep.

It's pretty amazing how much Gmail changed my habits. Prior to gmail, I had piles of arcane procmail rules, and I'd sort and prune mailboxes meticulously. Now I delete literally nothing (I just archive), and I barely even use labels. I just know that I can rely on search to find a message if I need it later.

1\. I signed up for an account shortly after Gmail launched, but I've been using my own domain for my email address since the late 90s. So I used that Gmail account only for experimentation, and moved my primary domain mail over after Google Apps for Your Domain had been around long enough that I trusted it.

</comment><comment><USER5> There are two kinds of companies in today's world: those who have been hacked, and those who don't know it yet.

</comment><comment><USER6> Pretty impressive that he managed to find people who joined MySpace in 2008. Unicorns!

</comment><comment><USER7> First, ask nicely for the breach's number.

Second, find a restaurant that the breach likes...

<comment><USER8> She has such a pretty face, and what a personality!

</comment></comment><comment><USER9> Just received this via email from 'Myspace Legal'.

Notice of Data Breach

You may have heard reports recently about a security incident involving Myspace. We would like to make sure you have the facts about what happened, what information was involved and the steps we are taking to protect your information. What Happened?

Shortly before the Memorial Day weekend, we became aware that stolen Myspace user login data was being made available in an online hacker forum. The data stolen included user login data from a portion of accounts that were created prior to June 11, 2013 on the old Myspace platform.

We believe the data breach is attributed to Russian Cyberhacker 'Peace.' This same individual is responsible for other recent criminal attacks such as those on LinkedIn and Tumblr, and has claimed on the paid hacker search engine LeakedSource that the data is from a past breach. This is an ongoing investigation, and we will share more information as it becomes available. What Information Was Involved?

Email addresses, Myspace usernames, and Myspace passwords for the affected Myspace accounts created prior to June 11, 2013 on the old Myspace platform are at risk. As you know, Myspace does not collect, use or store any credit card information or user financial information of any kind. No user financial information was therefore involved in this incident; the only information exposed was users' email address and Myspace username and password. What We Are Doing

In order to protect our users, we have invalidated all user passwords for the affected accounts created prior to June 11, 2013 on the old Myspace platform. These users returning to Myspace will be prompted to authenticate their account and to reset their password by following instructions at [https://myspace.com/forgotpassword](https://myspace.com/forgotpassword)

Myspace is also using automated tools to attempt to identify and block any suspicious activity that might occur on Myspace accounts.

We have also reported the incident to law enforcement authorities and are cooperating to investigate and pursue this criminal act. As part of the major site re-launch in the summer of 2013, Myspace took significant steps to strengthen account security. The compromised data is related to the period before those measures were implemented. We are currently utilizing advanced protocols including double salted hashes (random data that is used as an additional input to a one-way function that "hashes" a password or passphrase) to store passwords. Myspace has taken additional security steps in light of the recent report. What You Can Do

We have several dedicated teams working diligently to ensure that the information our members entrust to Myspace remains secure. Importantly, if you use passwords that are the same or similar to your Myspace password on other online services, we recommend you set new passwords on those accounts immediately. For More Information

If you have any questions, please feel free to contact our Data Security & Protection team at firstname.lastname@example.com or visit our blog at [https://myspace.com/pages/blog](https://myspace.com/pages/blog).

<comment><USER2> _" We are currently utilizing advanced protocols including double salted hashes"_

Shudder. Whenever someone starts talking about double salting, triple salting or even just salting, it's usually a sign that they are doing password storage all wrong.

Salting only thwarts attacks against pre-computed lookup (i.e rainbow) tables and most attackers don't use rainbow tables nowadays to reverse hashes. Increases in GPU power have meant that it's more practical to just enumerate through all password permutations on-the-fly than do a lookup in an enormous file.

If a company is using a modern hashing algorithm purposefully designed for password storage (e.g. PBKDF2, bycrypt or scrypt), they need not even consider salts because they are automatically incorporated into the algorithm and are transparent to the implementor.

In my opinion, the best article describing the current state of play with respect to password storage is the following:

[https://www.nccgroup.trust/us/about-us/newsroom-and- events/b...](https://www.nccgroup.trust/us/about-us/newsroom-and- events/blog/2015/march/enough-with-the-salts-updates-on-secure-password- schemes/)</comment></comment>


What Do You Do When You've Got Tons of Ideas But You're Not Executing? - <AUTHOR> http://www.jasonshen.com/2011/tons-of-ideas-not-executing/

<comment><USER2> The label "scanner" seems kind of derogatory to me. From the perspective of a startup I would want one on the team only if they were a true generalist. The real problem is finding individuals who understand they like to explore different areas but have enough passion to focus long enough on something to learn it reasonably.

I guess the best term is a renaissance man or polymath.</comment>


Ask HN: How do large companies handle access to critical databases? - <AUTHOR> I've never worked in companies over, say 1000 people. Usually, there are one or two people who have full access to the database, hosting, Virtualization servers, etc. The lastest Marriott hack got me thinking: how do large organizations like these make sure employees don't mess with their precious data? In my case, one disgruntled employee could pose a HUGE risk because he/she would know the login/password combination of a lot of critical systems (I worked in healthcare back then). <comment> magic-chicken From my experience, regulated industries use a combination of the following techniques :

\- Dont use passwords for databases. Make services use integrated authentication to interact with the database.

\- Developers / operations dont have read / write access to production tables. It can be obtained momentarily for ad-hocs operations.

\- When the database needs to be modified, the script goes through a change management system and it is executed at a planned time, ideally by another person.

\- If you use private keys, ex for symmetric encryption, don't store them with the data it's used to encrypt.

\- Use database level encryption on sensitive data to prevent anyone with read access to snoop on PII.

\- Enable database level audit and change tracking.

\- Developers don't push their own changes to production.

<comment><USER2> Good list, I'd add

\- private networks, using bastion hosts to access when needed.

\- very robust and regularly tested backups in case someone screws up the data.

\- hardware tokens to access and authenticate any critical parts.

<comment><USER3> -we have our servers in house so we ship a hard disk with all the data and source code every month to other side of country.

</comment></comment></comment><comment><USER4> In my experience, poorly - the number of default passwords, copied-because-i- don't-know-what-it-does configurations, weird setups, lack of backups, backups to a local disk, backups to a mounted locally disk, etc. I've seen is shocking.

The fact that anything works has gotten way weirder to me as I've gotten older - I've seen a bunch of codebases and persistence setups, and it all seems so fragile.

</comment><comment><USER5> In large company I worked, everything critical go through active directory. Every user is assigned to group/role. Every Server application have it's own entry as well. Every authorisation is audited (app launch, document access, databases access...). The day someone leave badge goes off, mail and every access are freeze. On a day to day usage you could revoke some or all access of a user, even just block word or a database instance. I've seen friend blocked at the door one morning because an inquiry was in process on their computer usage (it last 2 weeks and the guy was innocent,it was someone from IT who manually installed/modify unknown system files on his computer). From security standpoint almost nobody have access to production database. Most of the people work on old snapshot or incomplete extract. In another company. If you do a request on sensitive database (select * from customer), a security guard come to your office ask you to stay away from keyboard. Then the office manager is called to ensure that your work is legit.

<comment><USER6> That sounds like a terrible work environment. On site security guards?

</comment></comment><comment><USER7> a lot of it comes down to a strong and well-supported Information Security Officer and team, with detailed policies and procedures and a least- privileges-required security model. Someone shares credentials? Fired. The CEO or another exec wants an exception to the P&P so their buddy can get access? Well they'll get reamed by the ISO and possibly written up. No exceptions, and a paranoia about breaches is what helps to prevent such breaches from happening. Note I say "help," because there are no measures that are 100%. It's defense in depth and defense in breadth that will keep you off the front page (at least this year).

</comment><comment><USER8> You have to look into a solution that can manage secrets easily, I think Hashicorp's Vault is an example of a product in this space.</comment>


Kodak SP360 Action Cam - <AUTHOR> http://kodakpixpro.com/Americas/cameras/activeCam/sp360.php

<comment><USER2> I recently purchased Kodak's SPZ1 camera as a waterproof and shockproof alternative to iPhone. I made few test videos and my conclusion is that the camera is mostly unusable due to the poor video quality that is a result of some poor choices in firmware settings (that cannot be adjusted by the user). The overall video quality (sharpness, colours, etc) is noticeably worse than iPhone's. I recorded the video in the same conditions using iPhone 4S and SPZ1 and noticed that the output video file is compressed by SPZ1 with really low bitrate. SPZ1 records a file at 10mbps, while iPhone does 21mbps in the same conditions, with the same resolution and framerate. 10mbps is way too low for the HD video.

The Fujitsu DSP chip that SPZ1 uses is normally capable of a wide range of output bitrates, including the higher ones. The bitrate could have been increased (and video quality improved) by simply releasing a new version of firmware, that utilizes the chip to its fuller capacity. On a positive side, SPZ1 is using H.264 High profile for the output video, whereas iPhone 4S uses just H.264 Baseline. My guess is that it's just the default setting in the Fujitsu chip and not a result of someone's good will.

Another note is about audio. SPZ has a great stereo microphone, but the audio stream is bundled uncompressed into a video stream, which means that of the 10mbps I mention above, 1.5mbps (15% of the total bitrate) is given to audio and only 8.5mbps to video. This is such a waste -- the same Fujitsu chip can easily compress audio as well. For comparison, iPhone 4S compresses the mono stream into AAC with 0.06mbps (0.3% of the total bitrate). This also could clearly have been made using another firmware settings, but it seems like Kodak does not care.

As a conclusion, I'm pretty sceptical about anything Kodak releases lately. They may understand hardware, but like Sony, their software choices are questionable.

<comment><USER3> > They may understand hardware, but like Sony, their software choices are > questionable.

Could you elaborate? I know some Sony phone is not well-made (late release, bug somewhere, laggy etc). But i don't knos about their other consumer device.

</comment></comment><comment><USER4> The expectation conceptually is so much greater than the results of this thing that I can't help but think that EVERYONE will be dissapointed...

Just look at their example "extreme" videos... the 360 video is disorienting and useless.

Is it just me? I clicked on the videos ready to be blown away... and I just wasn't.

Motorcycle [https://www.youtube.com/watch?v=kjybKOtJ9DE](https://www.youtube.com/watch?v=kjybKOtJ9DE)

Skydiving [https://www.youtube.com/watch?v=dItRHmvbSjI](https://www.youtube.com/watch?v=dItRHmvbSjI)

<comment><USER5> I kind of wonder what would happen if you coupled this camera with some software that let you virtually direct the shot in post-editing. The software would demangle the distortion, maybe smooth out the motion, and perform the pan/crop/etc.

I know that's not the goal here, they just wanted to one-up the GoPro. I agree that the distortion verges on nauseating.

<comment><USER6> Yes, 360 video is IMHO dumb. But the ability to select a "normal" shot after the fact - or in real time without a gimbal - would be really awesome. Great for capturing drone video for example.

<comment><USER5> Killer idea. Imagine one of those auto-follow drones mated with this camera...

</comment></comment></comment></comment><comment><USER7> Would this be useful for viewing pictures in the oculus?

Could it be combined with some kind of depth sensor like the kinect then you could actually move around in your pictures.

<comment><USER8> I don't see how this would work with an oculus. This gives a 360 view looking outward, but walking around something needs 360 looking inward. That said, an oculus could be a great "monitor" to sit and look around while this video is playing "around" you! You just can't move :)

</comment></comment><comment><USER9> Interesting device!

Weird/unexpected/innovative form factor for an action camera, a segment that is otherwise pretty much associated with the GoPro. The 360º thing is cool, although I guess it's less suitable to be mounted on a person and do point-of- view movies? Not sure, it does look pretty small so perhaps it's doable.

The specs sheet PDF ([http://kodakpixpro.com/docs/specsheets/actioncam/sp360/sp360...](http://kodakpixpro.com/docs/specsheets/actioncam/sp360/sp360-specsheet- en.pdf)) was very hard to load, but it does have the dimensions. It's 41.1 x 50.0 x 38.0 mm i.e. fairly tiny.

I wonder if nobody at Kodak runs Firefox in Windows; for me the main copy on the first image is black-on-black, i.e. unreadable unless I drag to select it. "Oops", I guess.

</comment><comment><USER10> If the optics and resolution is right, might this be Good Enough for crowdsourced StreetView?

<comment><USER11> While 16Mp seems to be a reasonable resolution for traditional images, basic pano resolution is usually (for instance, on 360cities.net) 6000x3000 for equirectangular images, that is 18Mp. Of course if you wish to allow zooming in even a little bit, that number is much, much larger.

A modern DSLR with a pano head and a super wideangle/fisheye lens typically enables shooting somewhere in the range of (depending on actual lens setup) 60-300Mp panos with little effort - but of course we're talking about an altogether different gear.

BTW, what's the purpose for a crowdsourced StreetView, when we have sites like 360cities.net?

</comment></comment><comment><USER12> It makes me think of [https://www.kickstarter.com/projects/giroptic/the- worlds-fir...](https://www.kickstarter.com/projects/giroptic/the-worlds-first- full-hd-360-camera)

</comment><comment><USER13> Nice - I once had a playsport from Kodak (no longer produced I believe) and really enjoyed it. If this is of the same quality it's certainly worth trying...

</comment><comment><USER14> I also noticed that there is a new model of the Ricoh Theta camera available since yesterday and it finally also does 360° video.

</comment><comment><USER15> I wonder if it is able to be used for astrophotography. If so, you can take my money.

<comment><USER16> My first thought also - might make a great all-sky camera.

</comment></comment><comment><USER17> Anyone know if this was produced internally or outsourced?

<comment><USER18> Outsourced. Kodak ditched its internal electronics development years ago. It is now just a brand slapped on whitebox designs from Chinese developers like Westinghouse or RCA or a host of other recycled domestic brands.

\-- Former Kodak employee

</comment></comment><comment><USER19> Waiting for the $50 chinese clones...</comment>


Freeman Dyson Takes on the Climate Establishment - <AUTHOR> http://www.e360.yale.edu/content/feature.msp?id=2151 <comment><USER2> Two great points : 1) the models are untestable, and contain, by necessity, a large number of fudge factors 2) not all change is necessarily bad or destructive

</comment><comment><USER3> A good, substantial interview that gives a lot of background on Dyson's views.</comment>


#WorkCanWait - <AUTHOR> https://37signals.com/remote/workcanwait <comment><USER2> We need to individually stand-up and set boundaries with our employers (even if we are running the company) so that we can enjoy life in general. This gradual encroachment on our personal time is insidious and if we don't choose to go another way we will soon end up like South Korea where people work from 9am to 10pm regularly. In my company we encourage people to be active, give 5 weeks vacation and don't expect people to answer emails at night and weekends. You can do this by setting just a couple of goals that move the needle each week. I see so many people waste their "working" hours on Facebook and other distractions. By eliminating these distractions we try to target a 35 hour work week.

</comment><comment><USER3> The snarky images are funny but I would be more interested to learn what 37 signals does to make sure their employees are well-rested and happy, and enjoy a proper work-life balance.

</comment><comment><USER4> I had the same feeling, while watching the Office ad, showing a guy who brought the work home. Instead of productivity, it looks like the lack of work-life balance</comment>


Whale sharks: Atomic tests solve age puzzle of world's largest fish - <AUTHOR> https://www.bbc.com/news/science-environment-52155008 <comment><USER2> In my experience, bony fishes are not easy to date by counting rings. I tried it and discarded the whole work. If you find 20 rings, you can assume that the fish would have 10 years (one opaque ring in summer and other hyaline ring for winter), but unfortunately there are also bifurcated rings, disease's rings, fused and duplicated rings so your animal could have several false duplicated rings, and have only 7 years. In 200 thin rings your error can be awful.

To know the sex of the animals is also important, because females will produce extra hyaline spawn rings starting somewhere in their adult phase. And males... well, nobody nows. They obviously do not get pregnant but do the male whale sharks fight and stop eating?. Not to mention than some fishes can change its sex perfectly.

This with bony fishes, that have true bones. Big sharks are cartilaginous fishes. Cartilaginous tissue dyes badly and rings in its vertebra are less clearly marked. This animals migrate (vertically and horizontally). This means that would probably starve for long periods and then feast and that their vertebras would be subject to a wide range of pressure that could erase rings.

> So any animal that was alive then incorporated that spike in Carbon-14 into > their hard parts

The key of the phrase is _hard_ parts. They are looking at cartilage, that is not hard and is a very slow growing and inert structure (what if most of all carbone went to the muscle instead?). The only hard part in whale sharks is the tooth (1-5 milimeters long if I remember correctly). Those teeth are lost and replaced continuously so can't be used to age the animal. Even more, they are releasing carbon-14 at a unknown rate. I would like to see how they address this fact as source of error in their models.

I remain still sceptical when I read this kind of results. Tagging or photoidentification could help, but our best chance is with captive animals.

<comment><USER3> > I tried it and discarded the whole work.

Why wouldn't you publish on how it can't be done reliably?

<comment><USER2> It just didn't pass the cut. I had plenty of other interesting questions to chew, and moved on. There is not reason anymore to revisit it. Most of those bones would be unreadable today in any case.

</comment></comment></comment><comment><USER4> A method like this was used to determine the age of the Greenland shark, a large shark living in cold waters.

"In 2016, a study based on 28 specimens that ranged from 81 to 502 cm (2.7–16.5 ft) in length determined by radiocarbon dating of crystals within the lens of their eyes, that the oldest of the animals that they sampled, which also was the largest, had lived for 392 ± 120 years and was consequently born between 1504 and 1744"

[https://en.wikipedia.org/wiki/Greenland_shark](https://en.wikipedia.org/wiki/Greenland_shark)

<comment><USER2> > had lived for 392 ± 120 years

Is the same problem, I personally (is just my opinion) wouldn't discard that where 392 solid meals instead, one seal or reindeer at a time boosting grow periods between nape and nape, minus an unknown number of pregnancy events.

Scientists are forced to publish something, anything, in short periods of time, so here we are. And is getting worse.

<comment><USER5> Radiocarbon dating wouldn't be affected by meal frequency, unless I'm missing something. It's just identifying the oldest material in the specimen.

<comment><USER2> We have two main different ways to attack the problem of age, and both have issues

> But as scientists know the rate at which this isotope decays, it is a very > useful marker in determining age... The older the creature, the less > Carbon-14 you'd expect to find.

They are registering decay in the level of carbon-14.

The clock is adjusted for bone (storing this isotope as a more or less permanent crystalline mix of carbone and calcium). This is cartilage.

And teeth in sharks last only for some period ranging between, lets say, two weeks and two years (100 days for a white shark or so). Somewhere inside this period, those pieces storing carbon-14 will fall and will need to be replaced in a few days. If the reserves are mobilised from vertebra to tooth, then you would expect to find much less carbon-14 than usual.

Therefore you could conclude than the fish is much older than it really is.

Counting the number and type of rings on vertebra is a different problem, and is affected by fasting and starving periods.

</comment></comment></comment></comment><comment><USER6> You can play a similar radiocarbon dating trick with the lenses of greenland sharks. They live to about 390 +/\- 120 years old, and are estimated to reach sexual maturity at 150 years old.

A specimen analysed in 2016 was born somewhere between 1500 and 1740.

[https://science.sciencemag.org/content/353/6300/702.full](https://science.sciencemag.org/content/353/6300/702.full)

</comment><comment><USER7> "Over time, every living thing on the planet has absorbed this extra Carbon-14 which still persists."

Is that as consistent in absorption? More so animals that feed upon different levels and maybe more so - do plankton absorb more or less and any animal feeding upon them would see a higher rate perhaps. I'm still looking into these aspects - fun google time. #1

Another train of thought I have from reading this is: We may well read in the future about plastic pollution being used to measure metrics in life forms. [EDIT ADD]

#1

[https://en.wikipedia.org/wiki/Carbon-14](https://en.wikipedia.org/wiki/Carbon-14)

It is naturally formed by cosmic rays, it has also been measured as highers in area's that atomic testing happened (so near Australia) and with that, Southern hemisphere. Given that, one would expect, any life form that was located near area's near the poles or southern oceans would be more exposed to the natural and atomic unnatural sources and whilst the unnatural sources would dissipate - anything exposed during the early times would also have higher levels than such a lifeform in those same area's today due to decay and dispersion.

<comment><USER8> I think you can assume they didn't change the diet too much, so before 1945, measuring the carbon in the bones(?) you should get a nice smooth exponential curve, and then a jump in 1945 [Is there a small delay?]. More details in [https://en.wikipedia.org/wiki/Bomb_pulse](https://en.wikipedia.org/wiki/Bomb_pulse)

<comment><USER7> Whilst their food would not of changed in source, the content would of had spikes above global average it periods of time due to the atomic spike, also how that dispersed and how long until equilibrium would all be factors that come into play. Let alone natural hotspots from solar radiation increase near the poles.

But then the error +/\- rate would seem to accommodate those kind of margins, but always nice if there is a way of narrowing those margins, so may be a field of research that has some headroom and also help learn many other tangents and maybe another data point for historical solar radiation.

</comment></comment></comment><comment><USER9> It is rather remarkable that nuclear weapons have left a legacy written at the atomic level in every living creature.

<comment><USER10> And not just in living creatures. Ships sunk before atomic tests are valuable source of "low-background steel".

[https://en.wikipedia.org/wiki/Low- background_steel](https://en.wikipedia.org/wiki/Low-background_steel)

</comment></comment><comment><USER11> 100-150 years old.</comment>


The truth about TDD - <AUTHOR> https://sdegutis.com/blog/2018-08-29-the-truth-about-tdd <comment><USER2> This is pretty far down the page. Possibly only a discussion between me an you ;-) I enjoyed your article. Thank you for writing it. However, I have a different point of view which you might find interesting.

There is a difference between TDD and testing. Testing is something you do to see if what you've done is correct. Quite frequently I work the way you described and it's very nice to feel confident that I have implemented what I set out to implement.

At that point, I often just throw the test away. Sometimes if I have a pair programming with me, they'll be shocked. "Why did you throw away that perfectly good test", they will ask. "Because I wrote it to find out if the code works and now I know that it works".

TDD is about something else. With TDD you aren't so much worried about the correctness of the behaviour, you're worried if the behaviour has changed since the last time you touched the code. Ideally, if it _has_ changed, it would be nice to know _what_ changed. Even better, it would be nice to know what assumption was violated that caused the change in behaviour.

Imagine that you have an application that you have tested inside and out. It works perfectly. Next imagine that you have a special magical device that tells you if the behaviour changes every time you modify the code. It doesn't tell you if the behaviour is _correct_ , it simply tells you that it changed, what the change was, and what caused it to change.

Now every time you add code, if the behaviour doesn't change, you know that it is still operating correctly -- because it was before and it hasn't changed. If the behaviour _does_ change, you can observe the behaviour and decide if the change is good or bad. If the change is good, then the code is _still_ operating correctly. If the change is bad, then the code is operating correctly except for the change. If your magic device also tells you where your assumptions are violated, then it becomes easy to decide how to make the behaviour good again.

There are a couple of really cool things about this magic device. It doesn't need to know if the system is operating correctly or not (which is difficult in most cases and impossible in the general case). It just needs to know if the behaviour is the _same_ as before (which is a much simpler problem). The other really cool thing is that if you make a change to the behaviour of the system and the magic device doesn't detect it, then you know the magic device is broken. Since the magic device is very useful, it is probably a good idea to fix it right away.

Of course the magic device is a test suite. But it's important to understand that it's a very special kind of test suite. It measures behaviour and detects if the behaviour changes -- not if the behaviour is correct (you can test that separately, either in a manual or automated fashion). Often in legacy code I'll write a whole bunch of "tests" by running functions with various inputs and recording the results. That's all I need. I don't need to know if the results are correct or not. As I modify the code and watch the differences, I can determine if the differences are good or not, and I may find bugs. But bugs are not my main worry with this style of test suite. I'm using the test suite to inform (and later confirm) my assumptions about the behaviour.

Second, this kind of test suite needs to tell you what is actually wrong. For example, you might have a test that determines if a particular result was produced. If the test "fails", you might say "the test fails". This is pretty useless, though. Now I have to go and debug the code. Instead, I want to be told exactly what is different between what I expected and what I received. I also want to be told what context the program was in when I got the result. So I need to be able to see at a glance the input, output and processing (big hint: fixtures, as convenient as they are, are usually bad because you can't see the input).

Thirdly, this kind of test suite needs to tell you _where_ in the code the code the problem is likely to be. If you change the behaviour in one place, then ideally a single test will fail. This underlies the difference between a test suite for testing correctness and a test suite for testing changes in behaviour. If you were testing correctness and you have the same behaviour in several different contexts, then you would expect to have several tests to ensure that the behaviour is correct in each context. With this kind of test suite, you actually want to test once and then simply ensure that the same code paths are followed in each context. Then when the behaviour changes, you only get a single failure -- in the tests related to the behaviour.

When writing these kinds of tests, you will find something a bit strange. In order to ensure that a test fails whenever behaviour changes, you need 100% test coverage and _also_ 100% branch coverage. This means that you need to be able to write tests that hit all of your code.

If you want to ensure that only one test fails whenever the behaviour changes, then you will have to break up your code so that you have access to just the functionality that you need.

What you will discover is that you are doing _white box testing_ and not _black box testing_. Because you actually want to see what the implementation is doing. The best analogy I've heard of is that it's like putting watch points in a debugger. Then when the code is running, you can inspect the state of the code to see what it's doing.

This is where the real kicker is: it forces you to expose state rather than hide it.

And I'll leave that in a paragraph by itself, because the implications are huge for design. Quite frequently we choose to abstract away state. Sometimes it is not even measurable. "As long as my function returns the correct value (no matter how complicated it is to generate), there is no need to see the inner workings. In fact I don't _want_ to see the inner workings because it will add complexity to the system. I want a simple API and I'll push all the complexity inside it". This is the antithesis of TDD, because then we can't inspect the running state of the system and pinpoint where behaviour changes (except in really large chunks).

Obviously, there are lots of really good advantages to abstraction and encapsulation. However, there are ways of providing that while exposing state (at every level) at the same time. Essentially, you are forced to create a many layered system and you are forced to think hard about those layers because...

There is another important result of TDD (or at least of the TDD I describe above). I mentioned that you have to be able to see at a glance the contexts that you are creating when you are writing the test. This means that it must simple (and concise) to create the collaborators that you need to create that context. This, in turn, means that you have to reduce the complexity of the inter-dependencies of collaborators and you especially need to be able construct the dependencies clearly. Things like global variables and singletons become big liabilities in this kind of environment.

The result of all of this is that you need to have collaborators with simple dependencies (low coupling), you need to have many layers, where the state of the system is always expressible, and you need to have simple interfaces on your systems.

The most important thing to understand is that TDD does _not_ design your code for you. Of course, you need to do that yourself. Rather it provides a series of constraints (as a result of always being informed of the behaviour of the system at all levels), which enforces certain good qualities in the resultant design.

Having said all that, I know many people who do not like designs that follow the constraints that TDD enforces. They prefer to have larger, more complicated interfaces. They prefer to have APIs that hide the inner behaviour and make it impossible to examine the state of the code (without actually running it in a debugger). This is clearly a choice. However, I'm bumping up to about 20 years of doing it the TDD way and my experience has been that a system designed in that fashion is more flexible, easier to read and reason about, and considerably easier to work with. As always YMMV.

I hope that provided some insight into a different way to look at TDD.</comment>


SymPy - Python library for symbolic mathematics - <AUTHOR> http://sympy.org/ <comment><USER2> This would be useful for teaching math or prototyping. From their FAQ it sounds like performance is way too slow for problems where speed is an issue.

If you're looking for a fast symbolic math library for python, check out Theano. On CPU, it can take advantage of whatever BLAS you use, and on GPU, it will convert your code to optimized C++ and compile via nvidia's cuda sdk.

SymPy does seem a lot more feature rich than theano, which relies on numpy

<comment><USER3> Looking at Theano, they seem pretty different.

Theano seems to be a beefed-up numpy (with compilation, symbolic differentiation, stability, and GPU use), while Sympy is a CAS framework.

That said, Theano looks really really really cool.

I wish I'd seen Theano before trying to force Sympy to do pretty much what Theano does (through Sympy's codegen).

<comment><USER4> Theano has an interesting description of the lay of the land as they see it, where they position themselves as a hybrid of numpy/MATLAB type numerical- computational tools and sympy/Mathematica-style CAS tools: [http://deeplearning.net/software/theano/introduction.html#wh...](http://deeplearning.net/software/theano/introduction.html#what- does-it-do-that-they-don-t)

<comment><USER2> From the link, they mention this:

 _The closest Python package to Theano is sympy. Theano focuses more on tensor expressions than Sympy, and has more machinery for compilation. Sympy has more sophisticated algebra rules and can handle a wider variety of mathematical operations (such as series, limits, and integrals)._

</comment></comment></comment></comment><comment> muuh-gnu Also check out Maxima [1], the GPL'ed version of the venerable computer algebra system DOE Macsyyma, which made the jump to PCs rather late and was therefore overtaken by Maple and Mathematica. Maxima is still under active development, has an community around it, and is available on Linux, Windows and Macs.

[1] <http://maxima.sourceforge.net/>

<comment><USER5> If you're going to mention Maxima, you should be aware that an actively developed open-source program collection called Sage (<http://www.sagemath.org/>) uses Maxima as well as many other open-source packages to create a rich mathematical environment that's becoming increasingly popular.

Sage uses Maxima internally to generate symbolic results, but Sage also has many other integrated math tools, and has a Web 2.0 interface -- a server- enabled front end.

My Sage tutorial: <http://arachnoid.com/sage>

</comment></comment><comment><USER6> This is cool. However, NumPy, SciPy, SymPy, Maxima and a whole lot of other tools are included in Sage, which is a competitor to Mathematica, Matlab, and Maple. It's free and open-source. You can try it here: <http://www.sagenb.org>

</comment><comment> i-blis Mathics (<http://www.mathics.org/>) is a pretty useful online algebra system (with MathJax display) for symbolic computing à la Mathematica, backed by SymPy for most tasks and Sage for advanced stuff. You can check gallery and docs at <http://www.mathics.net/>

<comment> i-blis and the guy who does that seems interesting and relying: <http://www.poeschko.com/>

</comment></comment><comment><USER7> sympy online interpreter : <http://pythonsympy.appspot.com/>

</comment><comment><USER8> SymPy is great. I've used it and read through the code (available open source). Also, my online calculator Encalc.com uses SymPy on the backend. For example: <http://www.encalc.com/#expr=integrate(sin(x)>)

<comment><USER8> Looks like the link cut off the closing parentheses.

</comment></comment><comment><USER9> This seems to be a ery cool and useful project. Code generation is a killer feature for me.

Also check out the Sympy Live Shell: <http://docs.sympy.org/dev/modules/utilities/codegen.html>

</comment><comment><USER10> See also, OpenOpt and the FuncDesigner package.

<http://openopt.org/Welcome>

<comment><USER11> Looks like powerful numeric software but the site is so astoundingly bad. It looks like a throwback to Geocities.

<comment><USER12> Site will be moved to new engine as soon as we will got possibilities to make it done.

</comment></comment></comment><comment><USER13> This also is worth a try: <http://live.sympy.org/>

</comment><comment><USER14> It would be amazing to have one for ruby, tho I'm definatly going to use this for calculus at uni.

<comment><USER15> I know of two very early stage systems in ruby: <https://github.com/jdleesmiller/rucas> (which I wrote) and <http://brainopia.github.com/symbolic/>

I don't think either is really very useful at this stage (certainly mine isn't), but ruby does provide some very nice metaprogramming support for encoding and manipulating symbolic expressions.</comment></comment>


Ask HN: Review my rapid AJAX idea - <AUTHOR>

I've started writing a Javascript library for rapidly implementing / prototyping AJAX on a web page. Here is how it works:
When you click a link, the foreign web page is DIFFed with the current page with a server script and the script returns what has changed on the current page in the JSON format. For example,

  [
    {
        "action" : "delete",
        "path" : "/p[1]"
    },
    {
        "action" : "modify",
        "path" : "/ul[1]/li[1]",
        "node" : {
            "innerHTML" : "modified 1st line",
            "attributes" : {
                "class" : "testClass"
            }
        }
    },
    {
        "action" : "insert",
        "parentPath" : "/ul[1]",
        "siblingPath" : "/li[3]",
        "node" : {
            "tagName" : "li",
            "innerHTML" : "should insert after 2nd item",
            "attributes" : []
        }
    }
  ]
 This would delete the first paragraph, modify the 1st list item in the 1s unordered list and insert a new list item before the 3rd list item in the first unordered list.
Of course, there are several limitations:
- innerHTML isn't a standard (actually, xmlhttp isn't either afaik)
- Dynamically modifying the DOM might interfere with other Javascript present on the page
However, this library could be used to unobtrusively implement AJAX without having to write a single line of Javascript (all you would have to do is embedded the script in the header).
A use case of this library could be for a blog where you have a link "Show comments". Instead of the browser loading the whole page with blog comments, the request is sent asynchronously to the server script which diffs the current page and the page with comments. It then returns the modifications to the current page and the Javascript then updates the DOM with the information sent by the server script.
I had a hard time putting this idea into words and I hope I made myself clear. So far, I've done the Javascript part and what remains is the server side diff script.
In a nutshell:
- Productivity boost VS writing AJAX by hand, unobtrusive
- May interfere with other Javascript code
I would appreciate some feedback on the idea!
EDIT: This idea came from my frustration of having to wait for the whole DOM to be rendered by web browsers when clicking links within a site. Often times, a big part of the DOM structure remains the same and yet, your browser has to render everything once again. Do you think this "concept" (DIFFing and only rendering what has changed) could be applied directly to the browser to make rendering faster ? The main limitation I see is compatibility problems with Javascript and if the DIFF process would be actually faster. <comment><USER2> Instead of actually doing the diff process on the client or server side, this may be useful as a method of returning Javascript events and transformations from the server side to the client side for rendering; i.e., instead of returning script fragments, or JSON detailing the data itself, as the result of an Ajax call to the server, the server script would return an abstract set of "changes" to perform in the DOM, potentially along with other data. Sort of a server-side "DOM diff" structured with JSON, allowing a higher level of description than just spurting out some Javascript or an array of data.

Wow, that was way too many tacky web 2.0 terms for one paragraph.. forgive me.

</comment><comment><USER3> It seems like what you're describing is DIFFing the page DOM, then using the delta to update the page. Sounds cool, but for something like your comments example, why wouldn't you just reload the data and have a client-side script alter the DOM (unless adding new comments changes the layout of the page, it's going to be easier to do that than to calculate the new HTML DOM with the new comments and apply it to the page).

<comment><AUTHOR> You`re right about this particular example. However, I wanted the library to be flexible enough to handle changes in the DOM (not only the content of some elements). Of course, if the DOM changes too heavily (completely different layout), this library wouldn't really make sense.

</comment></comment><comment><USER4> Easier than:

      $("#comments").load("/post/749744/comments #comments")

is kind of a high bar to clear.

<comment><AUTHOR> As mentioned in my reply to @profquail, the use case was just an example. Perhaps I should have chosen a better one.

<comment><USER4> I didn't mean to sound derisive, but I note that the process of diffing two pages is not _that much_ simpler than picking out new contents from a fully rendered page by CSS selector, which is something jQ does out of the box.

</comment></comment></comment><comment><USER5> This makes for an excellent academic challenge that may actually bear fruit. I'd do it and see where it takes you. The experience alone will be worth it.

I do silly stuff all the time (I'm not calling this idea silly!) and I always take something away from it. This is a much better idea than the stuff I usually come up with.

</comment><comment><USER6> rad idea. if you limited yourself to live events/even delegation, that could take away some of the headache of screwing with existing js on the page. it'd be a tough one to do though. don't get me wrong.

hurdles i see are browser pagination (which would need to be done by iframe state storage/hash tags), favouritable urls (hash tags again), and inline js execution. you could also run into major memory issues if the previous page wasn't dumped properly, but all in all, a real cool idea, whether or not it's practical.

</comment><comment><USER7> Sounds like an interesting idea for some scenarios. You should definitely give it a try. Assuming you do and it's open, drop a link to it on here.

</comment><comment><USER8> to me this sounds a lot more complex than just writing the javascript in the first place, I need to generate 2 pages and make sure they are virtually identical, I can see making a minor differences that suddenly invalidates a diff on an entire page and ends up generating 5x more data than a plain full page load would have

<comment><AUTHOR> That's right: if the diff takes more time then actually loading a new page, it doesn't make sense at all. However, I could see the diff script intelligent enough not to be slowed down by a minor difference. Anyways, this library would mostly make sense on pages with a very similar layout.</comment></comment>


Scientists Say They've Cooked Up an Endlessly Recyclable Plastic - <AUTHOR> https://earther.gizmodo.com/scientists-say-theyve-cooked-up-an-endlessly-recyclable-1834591910 <comment><USER2> Why can't we just stop manufacturing and using plastics ? Invention for the sake of invention ? Curious. The damage is already done, why keep insisting on using plastics ?

<comment><USER3> Well, take a look around you right now. Take special note of all the products and materials around you. How many of these contain plastic?

A lot? Thats why we cant "just stop manufacturing and using plastics".

So, instead of letting things continue the way they are (unsustainable) or just "stop manufacturing" (impossible considering how ubiquitous plastic is), we instead work on making the situation better (e.g., making them endlessly recyclable) while working towards phasing out plastics all-together in the long run.

It's not a switch that can be flipped. The road to a no-plastic world is through steps like this.</comment></comment>


Why you should build your infographics in HTML5 and CSS3. - <AUTHOR> http://paulrouget.com/e/infographicsInHTML5/

<comment><USER2> The infographics you see are made to order specifically to perform well on social sites and generate links for whoever commissioned it. Although it's _technically_ feasible to make them interactive and a lot more interesting that makes them non-portable and defeats the only purpose they were created for.

There's a great AMA on reddit about it -

[http://www.reddit.com/r/IAmA/comments/d7e24/my_job_was_to_ga...](http://www.reddit.com/r/IAmA/comments/d7e24/my_job_was_to_game_digg_using_infographics_voting/)</comment>


Facebook + Skype: Why video calling will not be enough - <AUTHOR> http://venturebeat.com/2011/07/18/facebook-skype-video-calling/

<comment><USER2> Interesting comment on the interactive element to get people more interested in a video call. You mention watching YouTube as the main use case for Mingleverse, a feature that Google Hangouts has incorporated. I wonder if having this extra element in Google+ gives it a big enough advantage over Facebook+Skype to get people to use Google+ as their goto video calling place.

</comment><comment><USER3> The technorati seem to be obsessed with video calling but most people run the other way from video in business / team applications -- turn off the camera and get on with the work I say.</comment>