I've never understood why the mind-body dichotomy is considered coherent.

The mind body dichotomy, quickly stated, is the idea that there is a nonphyiscal phenomena, called the mind, whose attributes and behavior are distinct from the body. A practical consequence on, say, a doctor is that he must determine whether a cause is physical or mental.

I suppose it all comes down to definitions - i never saw the mind as much more than software running on the brain, with the body as a host of attached peripherals. I'd built up this model long before I'd read anything about the MBD, and immediately thought, "why is it a dichotomy? The mind is the behavior of the brain. if it's mental, it's also physical. I can understand how that's a little unhelpful, but it's no big mystery."

What I find even a bit immature is this: the body, while distinct from the brain, is intimately integrated with the models the mind generates to interact with the world. that means that, fundametally, the mind _is_ the body - at least, in part.

so i suppose I'm taking issue with the word 'dichotomy'. the practical problem still stands - does a doctor treat the physical aspect, orr the mental?

since the two are intimately tied, I think the answer must be "both". a physical issue may have mental repercussions, and a mental issue can cause real physical problems.

for the former, think of amputees with phantom limbs. for the latter, consider someone who has phantom back pain, causing rsi's on his major joints from comensating for his pain.

in both cases, it's incumbent on a doctor to clear away the symptoms as best as he can before focusing on the real causes - it's best to have as much of the bullshit out of the way when getting down to business.

still, the concept of the mind is a tricky one, but i believe i can describe a theroetical emergence in a plausible manner:

the mind started out as a simple decision maker. this was the fish brain. all it could do is figure out: eat, kill, both, or run.

as we grew more complex, so did the mind. new featues included goal searching ("i'm hungry; let me look for one of those things that made me less hungry before"), prediction ("that thing over there looks as though it could eat me; i'd better stay clear"), agent detection, ("that odd shadowy thing over there could be a predator"), and feedback ("hey, here's a scenero that i've formed with my predictive models; what do you think?")

i believe that between feedback, predictivity, and agent detection, we form the basis for what we internally experience as 'mind'.

but i'm probably just imagining it ^_^

Simple: Energy companies have stated over and over that if coal were not cheaper, nuclear would be the destination. The EPA is in the process of forcing coal to pay for its pollution, making it significantly more expensive than nuclear. Right now it's working hard for current rules, but the new rules go into effect soon for an even bigger price hike.

Renewables are not cost competitive with nuclear. They're not cost-competitive with fossil fuels. There has been no "Historic Crossover," unless you are wont to believe a sociologist's bad math (and I wouldn't blame you - The NYT believes it).

Energy companies are investing in nuclear power at unprecedented rates, and so it the US government. The renaissance is happening, whether Pope likes it or not. It'd be really nice if the Sierra Club got back to its sane roots, rather than trying to shoehorn environmentalism and anti-nuclear woo into the same basket as it's been doing since the 70's - but if not, fuck 'em. There's a reason I no longer donate to that idiot.

I wanted to help out Suzie Hobbs at PopAtomic get nice open-sourcable images for her 'rocks' campaign.  So... uh... here ^_^.

Thumbnails are images, links are in SVG format. If you're using a browser that doesn't suck, you'll be able to view them natively. They're Suzie's stuff, so respect her authoritay.

Additionally, I created a couple of my own inventions in similar veins. They are protected by Creative Commons.

In response to the vapid republican presidential orders I've been hearing: "Mr. President, Do your Job", "Mr. President, Finish the Dang Fence", I've been thinking: Why aren't the republicans telling him to do something, oh, I dunno, useful?

For example, we have a political monster that rears its ugly head from time to time: storage of nuclear waste.  It's an artificial problem, really; Part of Carter's various obsessions as President was the prevention of nuclear weapons proliferation.  In his zeal in this regard, he made probably the most disastrous move for the United States' energy economy that any president has, ever.

On April 7, 1977, President Jimmy Carter banned the reprocessing of commercial reactor spent nuclear fuel.

Reprocessing is a neat trick. When you burn low-enriched uranium (95% 238-U, 5% 235-U) in a light water reactor, two major things happen:

1. About half of the 235-U fissions, producing a melange of mid-periodic isotopes called "fission products"



1. 90% of fission products decay to background radiation within a year
2. 97% decay to background in 10 years
3. 100% decays to background in 300 years.



2. 238-U breeds to 239-Pu



1. 239-Pu is an excellent reactor fuel
2. 239-Pu is no more weaponizable than the 235-U that is normally present in nuclear fuel
3. 239-Pu burned in a light water reactor is more valuable as energy than as weapons.

The fission products end up causing problems: they absorb neutrons that could be put towards fission, fouling up your reactivity controls, and eventually turning off your reactor.  As a result, you can only fission about 1% of your input mass - the rest becomes spent fuel.

Reprocessing is the act of removing the fission products from your fuel pellets, and recasting them into new fuel elements.  There's no need to remove the 239-Pu - in fact, you wouldn't want to.  239-Pu is an excellent fuel for light water reactors.

If we permit reprocessing, three things happen:

1. The cost of running a nuclear plant goes marginally down; you can re-fission the same fuel over a hundred times.  
2. The sustainability of nuclear power goes up - from 6 years at full burn to over 600
3. Long-term storage of nuclear waste ceases to be an issue, as all of your input fuel eventually becomes fission products - most of which can be sold as industrial materials after just 1 year.

So, when I say, "Mr. President, close the Cycle", I mean permit reprocessing.  Close the loop; help get us off of foreign energy.

Blueberry Pancakes recipe, engineer style, made for 3"x5" card, in raw HTML:

Blueberry Pancakes
Electric or stovetop griddle	1/2 tb unslt butter	1 c AP flour	1 t baking powder	1/2 t baking soda	1/4 t kosher salt	4 t sugar	1 lightly beaten egg	1 1/2 c buttermilk	2 tb melted sweet butter	1/2 c blueberries
Preheat griddle to 375°F, or over medium-high heat
		Whisk together in medium bowl
		Whisk just to combine. Do not overmix.
Sprinkle water, if the droplets bounce, it's ready.
Brush butter onto hot griddle.
Pour batter onto griddle, 4oz drops, 2" apart
Drop blueberries in cooking batter
Cook for 1 minute, or until underside is golden brown
Flip and repeat

Adapted from Smitten Kitchen's Pancakes 101

Concept shamelessly stolen from Cooking for Engineers

If you really need something to rally your base on, pick energy. We could be developing the next gen in nuclear power technology. Senator Hatch is out front on this: he's backing tech that can end nuclear waste storage and proliferation as problems, end the danger of nuclear reactors as terrorist targets, and solve a number of other energy-related problems in one stroke.
This technology is called LFTR (pronounced 'Lifter', short for Liquid Fluoride Thorium Reactor), and before I tell you about the technical specs, let me explain the political implications if republicans were to rally on board:

• Politically speaking, you can poach the following democratic talking-topics:
  
  
  • environmentalism (1)
  • nuclear waste management (2)
  • nuclear weapons proliferation (3)
  • nuclear power safety (4)
  • climate change (1)
  • the energy crisis (5)
• You can also bolster the following conservative topics, such as:
  
  
  • jobs (6)
  • national security (4)
  • benefits to industry (6&7)
  • lower prices for the individual (7)

1. LFTR, being a nuclear reactor, produces no CO2. It produces no output whatsoever, aside from heat. Nuclear waste is an easily containable solid. Given that 41% of the US's CO2 emissions are from electricity generation, for climate change, there is no better solution than nuclear.
   
2. LFTR produces 1% of the waste conventional reactors do. Because it's a continually reprocessing system, all of the input fuel is burned (in conventional reactors, 99% of the input fuel is left over).
   Because of the fuel used, a LFTR produces a fraction of the long-lived isotopes that conventional reactors do. Most of what remains will be stable after just 10 years; the rest, 300 years. This is not nearly the waste storage problem we have now - which is on the order of hundreds of thousands of years.
   
3. LFTR uses Thorium as fuel, which breeds to a non-weaponable fisslie isotope of Uranium (U-233). If the US develops, builds and sells these, weapons proliferation dies slowly. You can also run the reactor happily on weapons material. By selling mass-produced LFTRs to other countries, we discourage their endeavors into nuclear research, while making nuclear material more valuable as energy than as weapons, thereby further discouraging weapons proliferation.
   
4. LFTR reactors do not require a large containment vessel, and are completely proof against meltdown conditions. Because of this, small reactors of this type can be mass produced and housed in thick, poured concrete facilities - proof against attack by virtue of being large, solid mass.
   In a loss of coolant accident, LFTRs don't just shut down, the core pours out into a container made specifically for the purpose. Once the coolant system is repaired, the reactor can be inspected and, in most cases, turned back on.
   
5. By mass producing LFTRs and selling them to other countries, we invoke the rising tide analogy; terrorists are created not just by extremism, but by poor conditions. By helping to provide a resource like electricity at very low cost, we are increasing the quality of life of our neighbors. We are also reducing the power of extremists by removing the grip they have on other nations via oil. Every other country has thorium as readily available to them as we do - and Thorium is four times as abundant as Uranium.
   
6. Of course, mass production and on-site construction means jobs for all involved. Of course, while it might seem that readily available nuclear energy would dampen the coal industry, they need not be at odds: Thorium is available at 12ppm in most rock. If you're mining for coal, you can mine just as well for thorium - except that now, the rock your mining helps provide 40 times the energy it used to. Meanwhile, because mining companies need not stick to coal seams, they can mine in places less prone to collapse or explode.
   LFTR will not hurt the mining industry - it will transform it into a cleaner, safer institution.
   
7. LFTR also means lower prices for the consumer; if the NRC can approve a mass-produced reactor, most of the regulatory costs associated with site and design approval just melt away. The site either meets the requirement for the model or it doesn't - a set of requirements that can be worked out before an energy company even worries about the cost.
   LFTR's estimated mass-production cost is on the order of $2 million dollars each for a 100MW generating station meant to operate 40 years. Add the price of 40 years of fuel based on current Thorium cost (~$250,000), and you have a plant that costs $0.0225 / W and $0.07 / MWh.
   That's seven cents a megawatt-hour, or about a thousandth of current residential electricity cost.
   

---

The political challenge is, of course, to allay people's fears about new nuclear tech. It will require the ability to boil down hard-core engineering to laymens terms without losing so much as to seem dishonest. That's up to you, but the science is clear on the advantages of LFTR - and where science goes, you can expect most voters to follow.
The LFTR is the natural progression from the Molten Salt Reactor Experiment from Oak Ridge National Labs in the 1970s. All the components that would allow this reactor to operate have been tested, and only a couple million dollars of research is needed to combine the parts and work out any safety or engineering concerns. This is what Orin Hatch is attempting to do, but he's not popularizing it like its implications imply.
For more information on LFTR, please visit any of the following websites:

• Energy from Thorium
• Thorium Energy Alliance
• International Thorium Energy Organization

Added a neat little trick to the site: Now, when you come here having searched from Google, the site automagically notices and calls out the words you were searching for within its content.

Simple trick, I know. I'm going to add similar functionality for other engines soon; this was just a proof of concept. Anyway, test it out; search for "Code Monkey Bryan" on google and check the call-outs.

I also added support for my Twitter status to be in the nav bar area of the About section.

Lastly, I migrated the blog to Blogger, with the site being populated by its RSS feed. Saves me the trouble of actually implementing a blog.

Meanwhile, I still have to break off the time to improve IE support. It's presently not there.

I've finally gotten around to building my portfolio site. It's only been seven years.

A chronic problem, I think with developers, is that we don't usually think that a portfolio site is necessary - and this is probably true. I think, however, that if on my next interview, this site is visible and available, I will be far more likely to be asked, "What was your role in Project X", rather than, "What projects have you worked on?"

I find the former to be an easier question to address, as it's a specific description of things I like to do, rather than a nebulous inquiry into the haze of past accomplishments.

It says very little about a company dedicated to interactive web development when they farm out the development of their own website.  Like they have no confidence in their own talent, or faith in the value of their work.

A problem I've come across more than once is scheduling of QA during the initial development cycle.

It's not that I don't think QA isn't useful - QA generally will catch many, many things that we developers skim across in an effort to get from one test condition to the next.

Honestly, I'm not even saying that if QA is scheduled, they shouldn't be testing; hey, go for it.  The thing is, I don't want to hear anything QA has to say until after we, the developers, have been over the first pass.  That is to say, bugs in pre-alpha code are not only to be expected, but generally just an artifact of yet-to-be-implemented stuff.

The fact is, though, if you have QA scheduled well before the first pass is over - say your manager thinks it might be "streamlined" to break the project into phases, each of which is QA'd after your team has had at it - you should push back hard.  QA will complain about bugs, and your team will be expected to break off resources to deal with them.  This will cripple you as you strive to meet your timeline for an Alpha RC.

This will be difficult.  Your project managers are pressured to deliver projects ahead of time; they want to earn a reputation for being efficient; they want brownie points from the next man up the ladder, who has the same incentives as he.  Your job, in this case, is to explain carefully why this model will not work - that preemptive QA is, at best, a needless distraction - and at worst, a labor vampire.  Explain that it's better to actually schedule out time, post-alpha, for the QA <-> Dev cycle to occur.  This, along with an honest assessment of the normal expected environmental difficulties, and an allowance for unforseen events*,  makes the initial timeline realistic - and any overtime inevitably result in the coveted early delivery.

Now, I understand that it's not always possible to get the deadline you're after.  We've all been in a situation where the expected completion date is reported as March, and the PM, or their boss, or the client demands something earlier, say November.


First, as a freelancer, I never stood for this; the client can demand any date she wants, but the site described by the resultant SLA would be far less than the client wanted.  When the client noticed this (as they usually would), I would explain that the more complete site carries with it the deadline I had originally proposed, and that if you want it sooner, you will get less.

Second, if a PM agrees to a date that is significantly earlier than the dev team estimates, that PM should not be allowed to retain their position: a manager who flatly ignores the advice of their primary resource is, failing any better word, incompetent.

Third, if you find you are a developer in a position such as this, craigslist has many, many open positions.  Look into them.

 

crakbot wrote:
"Who do you think is going to make movies when they are no longer profitable?"

My response:
The reason half the movies and music out there are already a profit sink is that the respective industries aren't able to scout and screen content as efficiently as when there was less of it out there. It's a fundamental economic problem with centralized production: it doesn't scale efficiently. I'll walk you through it.

As technology improves, and generation of content becomes more accessible to the common man, generation of content increases at O(t^c), while generation of quality content increases at O(t*log(t)). Because of this, filtering of content increases in difficulty by a factor of t^(c-1)/log(t). As this progress progresses, more money is involved in the scouting and filtering of content, until the model becomes unsustainable, and the central organization collapses. As a result, the cost of media from the centralized filtering source is artificially inflated.

The methods used, in this case, by the Recording and Movie industries thus far has been all about marketing. They can only scout so much quality stuff before they have to fall back on shit to keep the profit margins up, so they've been polishing more and more turds as time has progressed.

Meanwhile, more democratic means of content filtering (MySpace Music, theSixtyOne, even iTunes to a limited degree) that use the consumer's own resources have been flourishing.

Meanwhile, the artificial inflation of music and video pricing has given us a new paradigm to look at; we, as humans, crave entertainment. With an available means of spreading out the artificially inflated costs of media, a good portion of us will take it, regardless of legality or actionability - it turns out, the average cost of getting caught is pretty far below the cost of purchase over time (when was the last time the RIAA or MPAA sued over someone's WHOLE collection, rather than a few cherry-picked songs?).

It's a very bad sign for the content industries' business models. Without allowing for an alternative model - ad-supported, responsibility tracking (origin tracking through compresion-resistant steganography), or tiered price/quality - and using consumers' own resources to find and promote new content, their centralized model of content filtering will inevitably fail, and their companies along with it.

In short: he content industry may still be here in 10 years - but it will be ruled by a new brood, and will look remarkably different from the content industry of today.

I had to laugh.

While trolling Digg, I came across an article with no less than 750 diggs that said, rather briefly, to sanitize your database inputs, and mentioned mysql_real_escape_string() as his method.

Well, duh. You have that drilled into your head in tutorials and classes that deal with database interaction in programming: "if you're going to be using a database, find out how to sanitize your inputs *before* you figure out how to interface with the database"

That's a no brainer. Any programmer who's worth their salt knows to sanitize their input - and has, at one point or another forgotten to do so, or said, "Eh, I'll do it later; it looks cleaner this way while I'm developing it."

The real secret here is not to make sure you sanitize your inputs, but to build your application so that you don't *have* to.

Now, ideally, you'd be pretty far removed from the database itself - in fact, ideally, you'd be able to query your table rows via a class tailored for them.

I've never written a DB layer for that level of abstraction, but I have an idea for a new side-project now.

And if anyone is curious about what happened for my grand designs for this blog: I got a very time-consuming job. I'll keep on it, but for now, I have work to do.

I came across this site today. It's an educational research blog concerning liquid-flouride reactors that can burn Thorium-232, and produce very little radioactive product in its waste stream, and no trans-uranic nucleides whatsoever. What does that mean? No Yucca mountain, and finally, a *clean* energy source.

read more | digg story

An Object in Javascript is similar to that of other languages - it's essentially a way of structuring information and code in named subvariables of a single variable.

For example, the Math object has chilren like floor(), abs() and sin(), which should have obvious definitions by their names.

What most people don't realize, however, is that Javascript functions are also objects. So are Arrays. And Strings. In fact, anything that's not just a number is an Object.

Another thing they don't often notice is that they can make their own with relative ease. The simplest way is to use Javascript's immediate Object notation:
var myObject = {'myString':new String(), 'immediateString':'A little text', 'aNumber':2.71};

This creates an Object, named 'myObject', with three members: 'myString', 'immediateString', and 'aNumber'. Now, for example, to get a the 'myString' member, you can reference it in any of two ways:
myObject.myString="Lorem ipsum dolor sit";
alert(myObject['myString']);

Now, if you're pretty experienced as a programmer, you'll notice that the first is standard object reference notation, while the second is 'hash table' or 'associative array' notation - which exposes a nice little quirk of Javascript: Objects are little more than associative arrays. The fact that they can hold both scalar and complex variables is inherited from the ability of Javascript to handle both types in ANY variable.

Continuing on, we'll move to procedural notation:
var myObject = new Object();
myObject.myString = new String();
myObject.immediateString = 'A little text';
myObject.aNumber = 2.71;

This defines the same object as before, except does it by defining each variable one at a time. It's more to type, but more human-readable.

Lastly, we'll implement a pseudoclass. What we try to do with pseudoclasses is to implement features of C++ classes using Javascript Objects.

The below class is nothing more than a shell; a good starting point for building, for example, DHTML widgets.

function myClass() {
//Constructor code goes here
//Something I do if Timeouts are going to be involved:
this.instance=myClass.instances.push(this);
//which allows me to use setTimeout thusly:
this.timeout = setTimeout("myClass.instances["+this.instance+"].doSomething();", 5000);
//the below doesn't work right, as 'this' from the calling context of setTimeout is thw window object
this.timeout = setTimeout("this.doSomething();", 5000);
}
myClass.instances=new Array();
myClass.prototypes.doSomething = function () {
//This is the format for your basic non-static function
}

myClass.calculateSomething = function () {
//This is the format for static functions
}

myClass.eventHandlers = Object();
myClass.eventHandlers.documentLoad = function (e) {
/* I like using this paradigm for storing all my event handlers
Usually, before attaching a function to an element, I'll
set element.myClass.control to this, capture any relevant data from
the event object, then call a nonstatic function to deal with
the event.

Quick quirk: The best way I've found to get the source
element of an event:
*/
var src = this;
if (window.event) src=window.event.srcElement;
/* Please note that that is definately not 'one-size-fits-all' code;
testing for window.event is a way to determine if you're using
IE. you should find a way to use that as the only condition
to determine how you retrieve your event's information
*/
}


Note: If anyone knows how to gather the name of a non-anonymous function from within its own constructor, please tell me.

cool stuff you can do, and stupid stuff you shouldn't

So, this word, AJAX, has been thrown around for the past couple of years, but what is it? Most people will invoke the acronym at this point, 'Asynchronous Javascript And XML', but that's not more explanatory than saying GNU's Not Unix.

Essentially, AJAX is a programming technique. It utilizes a combination of technologies - wait, scratch that. Enough explaining buzzwords with buzzwords; I might as well be telling you it's Web 2.0.

AJAX is a way of writing interface code for an application that resides on a webserver (buzzword: Web 2.0 Application), using the old standard of Javascript-controlled HTML (buzzword: DHTML) in combination with the relatively-new-but-already-ubiquitous XMLHttpRequest object. The 'Asynchrounous' part comes from the fact that, if you don't feel like making your users wait on a request to be fulfilled, you can have the XMLHttpRequest object start, and run a callback when the request either completes or fails.

AJAX is NOT, on the other hand, a magic programming language or server-side technology that allows a web application to be amazing with little work. If anything, it's HARDER to write AJAX-enabled code than a regular application.

Why use it? Glad you asked.

The major complaint people have with doing things online, for example, in checking webmail, is that it's slow and feels clunky. Programming via an AJAX method, however, allows your application to gather new data without refreshing the page - something that solves a number of asthetic and usability headaches you'd only understand if you've been writing webpages since, say, 2000.

Meanwhile, it's not explicitly mentioned anywhere in the Web 2.0 buzz, but I like to think that AJAX, as a technique, benefits from the kind of organization that comes from an object-oriented programming model. Now, while JS doesn't have an explicitly defined class structure, you can create pseudo-classes that behave, by and large, like real ones - thus obtaining all the benefits (reduced namespace impact, making for fewer script collisions and shorter variable lookup times, confined scopes, the ability to abandon the global namespace in favor of thread-safety, and the 'this.' object) and headaches (rediculous variable names like imageCache.library[25].width) that come with object orientation.

You'll note I said thread-safety. Ok, while a Javascript app will rarely bring your system to its knees or cause memory leaks (they are possible), one thing it can't avoid is race conditions (for example, if two timed bits of script want access to the same variable). A simple mutex lock is easy to implement in Javascript, and can be shared by your classes.

Still, that's MUCH later.

The next few posts here will be:
Javascript Objects: immediate and procedural, and an intro to pseudoclasses
A Simple AJAX Class
A More Complex AJAX Class
DOM Level 1 v. DOM Level 0: Quirks and Quibbles
CSS: Accessing the Sheets

Welcome to less-than-mad science. The idea of this site is to perhaps explain some of the mysteries of more advanced areas of Javascript programming (for example, bringing your JS code up to the level where it could actually be refered to as 'programming').

Just to start, I expect that if you're reading this, you are somewhat comfortable with the basics of a C-syntaxed language, that is: how to use 'if', 'for', 'while', the 'this.' object; some of the core concepts in Javascript, that is, when to use 'var' and 'new'. I also expect that you be familiar with the integral objects found in Javascript, ie: String; Object; Array; Math; window; document; etc.

If you are unfamiliar with the basics of JavaScript, I can suggest a couple of sites, as well as a book:

Quirksmode - This site, by Peter-Paul Koch, is a combination of a lead-you-in-by-the-nose tutorial on HTML, CSS and ECMAScript, as well as a set of well-done object lessons on how to compensate for browser quirks. It's a useful resource for both the novice and the expert. You will essentially benefit at all levels from this guy's extensive exerience.

W3Schools - While it doesn't have the most complete tutorials on the internet, it does contain a complete object reference for ECMA Script, as well as nice little 'try-it' examples that allow you to write and test code right in your browser.

O'Reilly's Pocket Javascript Reference - This book is an essential resource for anyone who's even vaguely serious about web application development. Buy it.

The next post starts the first lesson: "AJAX: What it is, what it isn't, and what it can do"