Seven Percent -- is all that gets through: truncated discussion of technology and a secret surprise if you're in the know.
Updated: 4 years 23 weeks ago
I "broke down" and bought a 1996 Triumph Tiger that has some issues. Right now I'm looking at bad coils and possibly a bad igniter. Hoping the latter isn't true.
Colonel: So when you get back we'll get started on taking over the world
Colonel: We'll start by simply circumventing the line through the Ardennes. Then, it'll be a rout: worse than Sedan.
Greenbar: I say the Maginot line is just a line on a map.
Colonel: Antwerp will fall in but a few hours.
Greenbar: once we cut the internet lines
Greenbar: They're just a series of tubes, you know
Colonel: All those kids holed up in coffeshoppes in Brussels will have to go through us to get their pr0n!!
Colonel: We'll p0wn them!
Greenbar: ha ha ha! We'll be RICH!
Colonel: Now with his federal indictment
Greenbar: wait... we got no pr0n. How will we supply them before they revolt?
Colonel: you can tell Stevens: "Prison: it's not the Big House. More like a series of cubes!"
Colonel: Thought you'd appreciate
The python version of GAE SDK is 3.9 megs. The Java version is 20 megs. So obviously what this means is the Java version is 5x better than the python version. Not.
What You Should Know About How The Health Insurance Industry is Mobilizing to Control the Debate of the Health Care Reform Act
Health insurance companies are deeply mobilizing their own employees to fight against any single payer plan by encouraging them to attend "advocacy training" to lobby lawmakers as "citizens"! I can't say how I know this because I got the information from an inside source.
The inside source also made me away of a pharmacy program in a major health insurance provider which requires mail order patients to purchase a 90-day supply of medications even if they only need a 30-day supply. They will be required to pay 3x the co-pay and 3x for the drugs. This is just one example of how health insurance gouges people at every turn.
"We are raised to honor all the wrong explorers and discoverers -- thieves planting flags, murderers carrying crosses. Let us at last praise the colonizer of dreams."
"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."
I really should be coding, but this Kindle thing really bothers me. In a saner world the publishing industry would have created a consortium to develop and promote an electronic ink publishing and distribution technology that was standards-based and open. This way many hardware manufacturers would have been able to offer the devices in a competitive market and the manufacturers would even have offered some risk mitigation for the publishers. The open standards and open implementation would have also ensured that content wouldn't die on some strange device cut off by history, either. They would have done this because they would have realized they were an information industry, not a printing industry.
But instead we got the Kindle. A so thoroughly closed device where it turns out even after you buy something, you still don't own it because Amazon can routinely remotely delete your content from your device! The kindle is a disaster for openness and consumer protection not to mention a huge lost opportunity for the dying publishing industry as a whole.
There is still time, however. They can still set up the consortium and create the device that's open. Because the idea behind the Kindle is a good one: the idea is to update the book. Books are great because they don't crash and you can curl up with them and actually read the text they contain for hours at a time. These are 3 things you can't do with a computer. The notion of an Kindle-like device is that you can get most of the benefits of a book plus the addition of less weight, searchability, personal annotations as metadata with the ability to ostensibly get rid of everything that might be cluttering up your bookshelf today. All in one searchable, readable, sleek format. As a techie with too many books on my shelf for my work with the need for searchability, this is truly a boon.
There is some promise on that front with the Foxit's eSlick reader, an open device that appears to be made to the same specs as the Kindle 1, without the closedness (but without the content distribution backend to rival Amazon, either). There is also the Txtr (pictured) being built by a German company based in Berlin. This machine looks a lot like the Kindle 2.
Recently I read The Top Ten Lies of Engineers by Guy Kawasaki. In it, he expresses a list of lies engineers say over and over again. This one caught my eye: We'd save time if we'd just start the whole project over from scratch. This translates to,"We're in such deep shiitake that I don't even know which way is up." Generally, any time engineer (b) looks at work done by engineer (a), engineer (b) "knows" what engineer (a) did wrong. Unfortunately, this continues, that is, engineer (z) "knows" what engineer (y) did wrong. If an engineer ever tells you this, triple the cost of the project and add one year to her "pessimistic" ship date. This is actually a case you could make as an engineer very clearly. If the number of bugs in a given product are really 1000 (his assertion), and the fixing of those bugs results in X number of man-hours and Y number of man hours is what it is estimated it will take to rewrite with only Z number of bugs, then if X > Y + Z, then it does make sense to start over. This isn't a lie, it's a valid case to be made for a rewrite! I know because I've been there, there being where X > Y + Z. I think Guy hasn't seen a system with a zero-defect policy developed using TDD / XP before.
Turns out that any program running in the iPhone simulator that connects to a server has in its user agent string the name of the application (really the XCode project name). Like so: 'HTTP_USER_AGENT': 'BrowserPlay1.0 CFNetwork/438.12 Darwin/9.7.0 (i386) (MacBook3%2C1),gzip(gfe),gzip(gfe)',
So here I am. Jobless and dreading the next gig. Never happened before. I just quit a gig that paid well because I was literally dying on the job. I'd stopped sleeping. I'd gained 7 pounds in 3 months. I'd stopped caring about anything except how I was going to get out of the job and do something else until I finally realized it was such a toxic situation I just had to get out of the job and sort things out on the outside. This in the middle of the worst economy I've seen in my life. Way to go, man.
Granted the gig in question was one of the worst places to work in the area: Huge, crappy legacy system. Waterfall process. Trailing-edge engineering. Utter asshole boss. Stupid HR policies. Long commute. Ugly, windowless cube forest. Lotta fake smiles on your co workers, knowing that you know that they know that this place is ass.
But since leaving, I've found that while I've already lost 3 pounds, have gotten a few good nights' sleep in more than a fiscal quarter, have a few projects bubbling away, some that are ready to pay some cash, but not ready to replace my income: I still have an unanswered question. What the hell am I going to do now?
I came across this posting a bit ago. Go ahead, read that and come back. I posted a comment as follows:
Full disclosure: You will take TDD out of my cold, dead hands, buddy.
I have worked on both types of systems: those without or with less than 50% coverage and those with tests over 50% covered. I'll take the latter any day of the year. Of course either system is significantly worse if the tests were written after the code was written. Test First, man.
Certainly there are mountains of tests out there that are poorly written by people who where simply checking a box on a list of things they are supposed to do when they write code. This is not the fault of TDD, though. And when I look closely at the kind of testing you're doing, I'll notice that the practice of completely isolating the unit by mocking out all of its dependencies is one of the easiest patterns in unit testing to get wrong. The reason for this is that it's too easy to "bake in" to the test deep, questionable assumptions about your architecture. So maybe your problem is that you're just doing it wrong. Might I suggest at your next job (because this one is not long for this world, sorry to say), you begin by writing the tests first and you mock or fake at the logical or physical system boundary instead of directly up against the unit in question.
So, in summary, I think you might be saying "unit tests are bad" because you have crappy unit tests.
There are currently 0 users and 1 guest online.