Tuesday, March 29, 2011

Stop lying about radiation!

My uncle recently posted:
Everyone should take a look at these forecasts (assembled from a number of meteorologist models) and act accordingly as best you can. We have no help whatsoever from our government. They are busy killing people in other lands, so,s'pose that explains their complete and utter silence.
This included a link to this youtube video: http://www.youtube.com/watch?v=3JDNJEW8MJs

Dutchsine seems intent on giving people sensational ideas. The primary ideas of that video are that there are PLUMES OF Iodine-131, Cesium-137 HEADED STRAIGHT FOR AMERICA! DUCK AND COVER! It even has a nice radiation siren in the background.

I responded flippantly saying:
Damn it... stop spreading misinformation. These things have a half-life measured in minutes. Maybe take a look at something not posted by an idiot: http://xkcd.com/radiation/
My uncle replied:
We're all trying to figure this one out, Jason. Thanks for the links. They do give some frames of reference, but obviously they can't address all the variables. I would, however recommend that people who try to call attention to potential problems should not be dismissed so readily as "idiots". If nothing else, they are calling attention to a rather alarming event, and expressing concerns which for a lot of us are valid concerns.

Unless you want to argue that we shouldn't be concerned, or that we should leave it all to the experts (such as the scientists who designed the reactors?, the owners of the reactors?, the governments and their "think tanks"?, those who do the cost/benefits analyses, etc.)

Funny, at first thought, I would have considered them to be the idiots. But, of course, they can't be expected to factor in worst case scenarios into the plan.

As well, among my first reactions was: Anyone who had any responsibility for the design, implementation, selling, operation and oversight of these facilities should be the first ones on site to clean up this mess. Yeah, all the non-idiots who sold us this package should have the responsibility to clean up the mess. They should "own" it ALL, in total. And they should be risking their lives to make it right.

But, then again, I stop myself and say: Wow, if all the smart guys who brought us the reactors have to then step in radioactive water to clean up their mess, because it's their responsibility and they own it, then, if they get sick and die in a month, we would be without all the "brilliant" people who know so much about this mysterious energy source. And, we would be without their compassionate and prescient leadership?

I'll be removing the post, because I'm skeptical. Do you still think nuclear energy is the best way to go?

So uncle, lets begin.

First, I do not expect you to listen to what our leaders have to say about this. I've never been an advocate of other people telling you what you should know. Unfortunately it seems that you want Dutchsine to do just that, and tell you what you need to know. The best part is he says, buried in there, that he doesn't want to tell you what to do. But unfortunately he only gives you half the information. It's up to you to determine if what he is worried about is actually a worry.

So how do you determine that? Well let's start at the top, is radiation bad for you?

As you might expect there are different answers to this, a lot of this has to do with some negative connotations we have. Marie Curie died of radiation! All of those people near Chernobyl got messed up or killed! What if I told you that right now you're exposed to radiation... and it's constant and never stops, and many of us strive hard to be even more exposed.

The problem is radiation isn't a scary word made up in the 50s to scare people about nuclear power. It's a scientific term meaning that something emits (Get it, radiates!) something else. Whenever the public gets a hold of a word that scientists use the miss the real meaning. Lots of things provide radiation, the one you're constantly exposed to is called the Sun! It's constantly sending down crazy radiation, and yet people still go out to tan.

This suggests that maybe not all radiation is dangerous, or at least there are different levels of dangerous. Sure you can still get skin cancer, but that doesn't stop days at the beach. Take a look at this fun chart from XKCD: http://xkcd.com/radiation/

Pay special attention to the amount of radiation you get from eating a banana, bananas are especially full of radiation, and yet oh so tasty. Handily it also indicates the danger levels for people working in radiation, and it's hundreds of times greater than the amount of bananas you can eat.

So, are Iodine-131 (I-131), Cesium-137(Ce-137), and Xenon-133 (Xe-133) dangerous. Let me ask you a question first, does drinking milk make you throw up? As always it's a question of how much you're getting.

Unfortunately there's not a good conversion from bq/m (the values purported in dutchsine's PLUMES of Ce-137) to Sv (the value in the handy XKCD chart). This is because they're measuring different things. Becquerel measures how much radioactive decay is happening, and Sievert measures the dose being absorbed into the matter (us, for instance). So we'll have some trouble with looking at his Ce-137 chart. Let me just say that bq/m indicates the number of decays from a single nucleus per meter, And since his chart never gets above 1, I don't see how that will be particularly dangerous.

So lets look at the chart for Xe-133 (that's the one that looks like a big cloud of radiation all over the US). Going to his source I found this interesting snippet:
The colour scale shows a total of 5 colours. The area marked „E“shows an area with estimated current equivalent dose rate of 10 mSv/h (in a 25x25 km2 square). The violet colour on the outer edge of contaminated areas (Area A) represents 0,3 μSv/h, which corresponds to the amount of the natural background radiation dose
I'm not sure what E is but I imagine it's the light blue or dark blue. Regardless lets look at the scary dark blue. If you look at the legend, exceptionally difficult to do as it doesn't scale at all, I believe this says the units are in 1 x 10-2 which corresponds to the text above of mSv/h. Excellent so lets look at what that is comparable to... HOLY COW that's like 3 flights to New York an hour! Crap man, we're so screwed.

Oh wait, did you say that's Xe-133? Wait a minute, wait a minute. How long is that stuff radioactive. http://en.wikipedia.org/wiki/Xenon-133... Wait, a half life of 5 days? How long until it reaches us, lets look at the chart. The chart starts on the 12th and it hits America's west coast on the 18th. Damn that's 6 days, how much radiation will be left, hrm... can't be as much as they show in the graph, they must not have accounted for decay. Maybe they're trying to scare people (Or more likely this graph wasn't intended to indicate RADIATION DAMAGE!, but rather a dispersal pattern). By the time it reaches the US much of it will have already decayed.

Looking at the indicators on I-131 make sure to look at the dispersal for the northern hemisphere. Looking at the units and we see the gray part indicates .02 (at maximum) which is the same as above, and we see that it has a similar half life of 8 days.

So I'm saying, listening to news sources who try to indicate sensationalist things like we're all going to be poisoned by radiation, is just as bad as blindly listening to governments saying don't look at it.

You can even take a look at the number of radiation poisoning cases:
http://www.deccanherald.com/content/145427/15-hospitalised-radiation-poisoning-japan.html
Man, more than a dozen... wait that's less than I'd expect if they were all dying of radiation. Heck Swine Flu was worse, and turned out to be little more than a cold for most of us. Also, look at the first comment... I was unable to find a first reference for this. I think there is a lot of fear mongering, people hungering for scary danger and pain.

The Fukushima reactors were rocked by an earthquake of unheard of proportions. The devastation was immense, and yet they still managed to keep people safe and protected. It was better than the houses that did not withstand the tsunami, and better than the roads that became impassable. So yes, I say I believe using nuclear energy is safe, and I think it's a far sight better than the devastating pollution put out by our coal and oil plants. It's amazing that you can count on one hand the number of large scale radiation accidents, and with the other hand you can count the number of large scale oil spills.

Wednesday, February 18, 2009

Please stop taking my money and giving it to the rich

I sent this in as a policy comment on whitehouse.gov:


So I was just reading your blog post: http://www.whitehouse.gov/blog/09/02/18/Help-for-homeowners/. It reminded me of when teachers would give an extension on homework because only a few people actually completed the assignment. I was always one of those people.

I did my homework and knew not to buy into a failing housing market. Now you are forcing me to pay for other people's failure. My money goes to help people who failed to understand the consequences of their actions. Why are you stealing my money to pay other people's mortgage? I'm struggling to pay my rent too, why are failed homeowners granted my money while I have to continue slaving to pay for my apartment, that I will never own? Why are you making rich people richer with my money?

Wednesday, February 11, 2009

Functional Objects

Rather than have a specific topic for this post I will present an idea that is still germinating in my head.

There is a problem with reusability in programming. For a competent programmer code can be found in libraries that can be made to do what you want. But this limits innovation to a programmer with many years of experience. Dabbling tinkerers have a huge learning curve before being able to produce something viable. And even after producing viable work the resulting code base is usually difficult to manipulate.

I recently took a jaunt into Second Life where I was intrigued to see prims and scripts. A prim is a primitive object one that can be used together with other prims to create larger products. A script is a small snippet of code that allows a certain action on an object. Part of what intrigued me was in Second Life you collect these as physical objects. I entered IBM's lab and found scripts for rotating an object on touch and getting information on other sims. I accessed these objects and they were added to my inventory.

As far as I saw the code snippets being traded were only useful within Second Life in the animating of objects. But I wonder if code snippets could be packaged in similar ways.

Part of the problem with libraries is the snowballing of dependencies. One library depends on another and needs code from another until it is a large unweildy mass difficult to install and use. Even after you've installed it, you have a good mountain of documentation to read before you can begin playing with your new tool. Even after reading the documentation, you still don't have a whole picture of how the system really works (documentation is notoriously difficult to understand). It's like working a puzzle but you can't figure out where the pieces edges are. It's possible (often with a lot of trial and error), but difficult and you may force the pieces into configurations they shouldn't be.

Part of my vision for the future stems from my work with LISP. I was developing a webserver (for the fun of it) using an example I found on the web. I said to myself "now how can I code up a server system and configure it?" The answer presented itself simply, bolt a system called hunchentoot (yeah difficult to spell and remember) into your code and poof it does the webserver system. No configuration it just works. It is completely self-contained and just worked.

Not all LISP systems work this well, unfortunately it suffers from the minds of the programmers designing things for it. But it is more resistant to those problems because of the mantra of "Functional Programming". Part of functional programming defines that a function DOES NOT modify anything outside of the function itself. When I read this requirement first I couldn't help but think, "Who the heck can code a system with only functional functions, where does stuff get done?" It turns out if you code all your functions functionally (that's just weird to say) then the work gets done in the function you started out with. This is contrary to the opinion that you should call out to other functions to do the work you should be doing.

From functional programming you get so many tangible benefits that it is hard to ignore the system even if it is harder. You get functions that are completely contained so you can test every input into them and verify it works under all conditions (or at least all the ones you test). You can be certain then, that if your function sends data to a function and you don't get back what you want it's your function's problem. It simplfies all debugging. Also it allows you to define certainly

1) What your inputs are
2) What your outputs are (including the truth that there were no other changes)

If you have these two things. You can model them. Imagine seeing a block of code in a 3D space it has female connectors showing where you have to input data. It has a male connector showing what data it outputs. It might even have a TV screen rather than a male connector showing that it outputs data to a screen. Or a spinning world indicating that the output is a webpage. Imagine how you could plug those things together to create even bigger systems that (as long as the new peices you added do what they say... should work). Imagine creating new objects, writing code that you will eventually see tangibly. Imagine building standardized test frameworks that you can plug your object into and be certain it will get a barrage of standard tests done to it testing all boundaries of data. So you can be relatively certain that it will not fail under any conditions (it may not produce the result you wanted, but it's up to you to check that).

I see that world and would like to help it come about.

Tuesday, September 16, 2008

Don't feed the (Open Source) bears

Current open source structure requires donation of time and money by dedicated programmers. This isn't a tenable solution eventually the programmers will get tired and the donated money will lessen. But this is not the final stage for Open Source. The good place as I have discussed before is one where programmers all work on Open Source projects for paying companies.

You can help with that. Right now Open Source programmers are still waiting for handouts, because that's how it all started. It is time for them to grow up. The next time you're considering donating to an open source project, don't. Instead come up with 3 different problems you have with the software. They could be bugs, features you'd like to see, changing a picture you don't like. Then contact the software team and say, "Hey, I'll give you x dollars if you'll fix one of these 3 things". Et voila! You have just turned a handout into a business transaction.

The first thing this does is make it profitable to be an Open Source programmer. They can make money by making open source code! Right now it's just something they do out of love, but it could become a career. A real viable career option to do something that you believe in. From a programmer perspective closed source is idiotic, it's a cesspool of bugs and bloat and death-by-design-committee. If working on open source software is a possible job opportunity, not just something you do in your spare time it opens up new worlds. Worlds where code is reviewed by hundreds of eyes, where things are refactored and optimized dozens of times as new techniques become better, where applications become more focused on doing their job right, rather than doing every job. Paradise I tell ya! If I can do that, and put my kids through college at the same time, sign me up.

This leads to a shaping of the landscape. Programmers can't really live on the contract work they get from you and me. We're too unstable as a source of income, you can't pay a mortgage without a steady job. But you are conditioning programmers to the idea that there is money to be made in Open Source, and showing companies that you're willing to pay. Quickly the next thing that will happen is a small company will start up as an open source shop, or maybe a current closed source company will open up their shop. Then you've drawn companies who want the money available in the open source ecology, and that will make more robust code, which will draw more people to use the code. This slowly shapes into what programming should be, which is a payment to make an application (or make it better), not a payment for a "product".

Stop giving handouts. It doesn't help. Do give to the community, but ask for something in return. Don't look at Open Source programmers and think, "Oh, those poor hard-working guys, I'll donate so they'll know they're loved". Look at them and say "Good thing you've got the skills, because I have a business proposition for you".

Tuesday, August 5, 2008

A little time to think , please

So as you might imagine in any creative endeavor there are shades of gray in what is considered a finished product. For programming the "completeness" of a block of code can be examined and broken down in ways other artistic compositions cannot. Most examinations of code consist of test case examination, it's pass or fail, you do what you coded to or you don't. But there is an even more important and subtler test you should be looking for, elegance.

Elegance is difficult to define but you can see it's influence when a programmer comes out of a hectic hack-phase and announces "It's done, it's ugly but it's done". Looking through the code he feverishly produced he cringes at bad hacks and edge case problems. Still the cry echoes through the halls of his business "we don't have time to 'optimize' we have to beat the competition". So reluctantly he checks in the hacked code and turns to other projects. Like an artist churning out sculptures, hoping never to look back.

Life continues on, after all the code passed all the tests. But eventually the programmer (or more likely some other junior programmer *cringe*) will return to that block of code. Poring through it looks even worse than before like a fungus breeding the code embodied in that past hacked frenzy has spread throughout the rest of the code base, tarnishing everything it comes into contact with. The poor maintenance programmer finds a nice dirty fix that should work and, as he is needed to fight other fires, drops the fix in place and runs away. Glue still dripping out of the crevices of this ugly wart added to the already hideous code structure.

These two scenarios are constantly occurring, anywhere programming is happening. And the key factor is time, it takes time to make code elegant more time than just "making it". As Pascal writes,
"I apologize for the length of this letter, for I lacked the time to make it shorter."
He illustrates the goal of the extra time. It's not to add more functionality, or catch more edge cases, it's to shorten what you put in. To trim as much as possible out of the sculpture so only beauty is left. When code is shorter it automatically curtails many potential bugs. Take a look at this snippet (my own of course)

Date [] dates = getSomeDates();
Date special = getSpecialDay();
for(int i=0; i < dates.length; i++)
{

if( special.after(dates[i]) && special.before(dates[i+1]))
{
dates[i] = special;
}
}
For those syntactically challenge this bit of code takes an array of dates and then determines if the special day falls in between any of the two dates. If it does it sets the earlier date to the special day. So what's wrong with this code? I will tell you now it functions under most normal circumstances. If you've figured it out, think about how long it took you. Imagine how much harder it would be if you wrote the code and weren't looking for an error. The problem is that [i+1], at the very end of the array of dates you ask for the end +1 which doesn't exist. Java doesn't mind because normally you'll get back a null and before() handles a null just fine. But if for some reason java had to put something next to your array... you could get back any kind of random thing. Making a fun intermittent bug. It took me a good while after having written that code to see the problem. Maybe a reviewer would have caught it, if he were lucky or super competent, as long as he wasn't overloaded with reviews.

My point here is I was able to catch the bug (and actually rewrite the whole thing to increase it's elegance and cut out a few potential bugs) because I had spare time. I wasn't running headlong for a goal spraying crappy code willy-nilly. This was not because my employer didn't wish me to, it's just my bug load happened to be low so I took my time. So I'm begging you, future employers, please give us a little time to think. Give us time to create elegance, you'll be better off in the long run.

Thursday, July 17, 2008

Code Reviews are your friend

I recently had a discussion revolving around the usefulness of mandatory code reviews. My coworkers were of the opinion that code reviews take too much time especially if they're mandatory for every bug fix. The point out that we already have a QA team who verifies that bugs are fixed. I tried to explain that they weren't looking at code reviews correctly, I'm not sure how many listened. During the course of the discussion I wrote down how I view code reviews and why I was excited that we were requiring them.

A code review is not QA validation, it is not for checking that the bug is really fixed. You should not even have to update your system with the code you are reviewing to test it out.

A code review is:

A second set of eyes. This is someone else who can see that you had a copy and paste error that will persist in the system, even if it doesn't cause bugs right now. This is someone else looking at the names of your variables and making sure they make sense. This is someone making sure you didn't get too close to the problem and miss something.

A search for alternative solutions. Your reviewer should be looking at different ways to solve the problem. He should see how you solved things and point out other methods that might have been simpler or cleaner or even more concise. Heck it's even possible your reviewer will question the need for the fix at all (this happens more often when your reviewer is more familiar with the system).He should bring these concerns to you even if there's no change to the code, so that you can have the knowledge for later, or so he can learn why you did things more complicated that necessary.

A look for unintended consequences. As the fixer of the bug you pored through the code making sure your change didn't break anything else, but having a second person who has different areas of expertise will help find more. Also your reviewer might look at the change and realize it has to be put in other parts of the system that suffer the same problem.

More edge case examination. The problem with all programming is what happens in the edge cases. What if that integer is negative? What if the array doesn't contain anything. As the fixer you try to imagine and test as many edge cases as you can. But again having a second set of eyes, one specifically looking for edge cases to break your fix helps alot.

Most importantly, it is a chance to learn new tricks. For both the reviewer and the fixer it is a chance to learn tricks from the other. When reviewing code look at how they solved the problem pick little gems of simplicity and elegance and put them in your own toolbox. As the fixer note when your reviewer talks about simplification or clarification learn how to be better together.

The last argument is why I also suggested that senior programmers should have their reviews performed by the newer employees. All I received were eye rolls at this point, because obviously having newer employees review would take longer (because more explanation is necessary) and defeats the point of the review which is to point out corrections. I think one is the solution for the other. When you take some time to explain your code you see your code as someone else sees it, and often you see its problems. Or the new employee questions will lead you down paths that you wouldn't have explored on your own. That plus the advantage it gives in sharing tricks makes this experience too valuable to pass up.

So take some time, use code reviews in this new light rather than as a verification process. Make sure your code changes are small enough that reviews are meaningful. Step up your new employees by expanding their minds with what you're working on. Keep learning, even from those new guys.

Friday, May 16, 2008

Problems with going dark

So as I said in my previous article I wanted to try going dark. Here are some of the problems I encountered

1) Tor is slow... I like my internet instantaneous. Having time to get up and make tea while waiting for my websites to load just isn't going to cut it. Also because my IP address comes from a random location every time google tries to guess what language I speak. I was unable to determine how to assure google that I speak english... American english specifically. So I just had to deal with google being in Chinese, German, Dutch, and Italian. Poor show I feel.

2) PGP has a fundamental flaw. You see PGP uses a public key-private key combo. I left my public key on my blog and kept my generated private key hidden on my Ubuntu Linux laptop at home. The trouble is that private key isn't something you can really carry around with you. (Because it's private). I spend more than half my waking hours at work... on a computer where they probably track my keystrokes and other terrible things. So even if I brought my private key encrypted (which it is by default thank goodness... with a passphrase...) that's totally not useful if you worry that someone has placed a keylogger on your system. So I can't use my private key to encrypt anything when I'm at work... which is almost always.

3) IM encryption can't work one way. There is a nice and easy PGP-like encryption plugin for Pidgin called pidgin-encryption, I just added the addon and was immediately able to chat encrypted. The problem is you can't chat encrypted to people who don't use the same encryption. I tested it out with my wife and it worked great. I even checked out my google chat logfiles to see what it looks like going across the wire. Here's a sample:

me: ** Encrypted with the Gaim-Encryption plugin : Send Key
Kelly: ** Encrypted with the Gaim-Encryption plugin : Key: Prot NSS 1.0: Len 249:Odw+YVVO3fV7d3cD/LISGDkAMIJDLFg8,MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEEAQhm477bt1KnprVlD/5nWH+deYoF2IjUxt/5sUOnJezCpWsqRgRoDUxOUEBWkEpWSWJVV8yjPRr7i2nnkWjpe3a+fQ+20pkIdI6qJqRFSU5P2gJLXWl3p38rET6W8i7tE8F20m4Msk57jF4URSqAWjHtsZ0g4bjwpANXlLXkwIDAQAB
me: ** Encrypted with the Gaim-Encryption plugin : Msg:Sf01f547677:R2687548b16: Len 512:N6DFKd+PciYkREHlpv1/EzLYJ3HY2VCo/T30KU48Rqws0CqMPWaAqU4z1dpTUYQWr81Uv3jakPfuB+0tmyW1gVORQscW+SY84uAaovAZpjM0HdtWT762jciqfUfmHs+9iT9mlczvXSk1kFyfUUhKk8h6GPgPxxhUPAWxFFRr5iW8wkMJ+ltUz+u9NsyUfTz8i4x4CqAu3ZUQxGt1vYYzRn3ruzVhlw+mJkGMQA51FsmN68bcUEq01d9fU/Q0cQJmADs6l1N0l+RA5SZOrMDGJixCqrFLzDLQ8Tuv8SK8UDvWS9x20zNIwop3KnJi+DUtk+u1I2VoCSFYPe4qfhDfspXKDtuYc1vBg/aSy+4mA8gLngOMwvCPwxNCEBzs1uVrtYFwL2A630Ah+v2/cJP4qpWH2i7hMISnBXTcDFnQSEj0kVzeqN8FCR/h8iq0yPHMYUM6P7ejKaQW46I+S5X0QxxTr9Md3J4aimu374cI93VUps9zRGe6TE1ImbtFAo48
Super sexy huh? But for it to work generally I need all my friends to encrypt as well. I'll try to always allow encryption on my chats (just in case you're feeling like hiding your talks with me) since it doesn't affect anything else.

4) Everyone uses cookies. I tried turning off cookies and I was immediately making exceptions. Google uses cookies for everything (which is dumb). My work website uses cookies. My comic slurper uses a cookie and that's all. Del.icio.us uses cookies. It's crazy. It's like turning off javascript for how many ill-concieved websites just shove crap on your harddrive. But I don't want to do without those sites so cookies are back on the menu.

5) Https works great. I found that google was especially competent at running SSL. Hotmail fails at it by the way. Even though you can go to the login page on SSL it redirects you to a non-SSL page after login. And you can't even switch to SSL yourself... EPIC FAIL. I'm going to continue to use https on gmail and my google homepage, because I like imagining my communications with those places are only between me and them... regardless of how often they sell my communications to other companies and the government. Though I just checked and blogger fails its https check, though it does redirect you to the regular http, which is better than hotmail. I guess they want to make sure that everyone can watch what you type as you write your blog.

Conclusion
The interwebs are not ready for people to go dark. They still want to hook in and track you and prevent you from hiding. That's really a sad statement, I think that the internet foremost promoter of "anonymity=equality" should allow me to be anonymous. I know that after this experiment I will try to be more conscious of how I design my websites, just in case an uber-paranoid friend needs to contact me.