Augh.

So as stated in my last post, I'm reading "The Watchman's Rattle" by Rebecca Costa, which, while it's hitting a lot of good psychological points, seems to be simply incoherent on energy issues.

I've gotten to Ms. Costa's story concerning space-based solar power, claiming that it's a fine example of what she calls "Silo Thinking".

Silo thinking, or bunkering, as I've called it at work, is essentially when the wall you have to throw ideas over to collaborate are a bit taller than your arm is strong.  It's what happens when you have territorial management.  It's a clear point, it happens fractally as you escalate the scope of organization, and it's something that restricts the ability of an organization to handle large and complex projects.

The problem isn't with the example, which, if true, would be a prime example of the issue.  The problem is, she's over-selling space-based solar.

I won't bother quoting the book.  Her explanation is pretty bad where it hits details, and pretty light on the details in general.

Space-based solar is a simple concept: you throw a satellite into geosynchronous orbit*, unfurl a PV or heat capturing device, convert the incoming energy into electricity, and fire a microwave laser at the earth's surface where, hopefully, there's an energy capture dish.

There are obvious potential safety issues with the concept, but they're entirely soluble with good engineering.  Meanwhile, materials science helps as well with potential efficiency.

However, Costa sells this as "unlimited free energy", which it isn't, at least, no more than rooftop solar is.  She also sells space-based solar as having efficiencies "magnitudes greater than what we achieve by laying solar panels on our roofs".

Solar flux is limited to about 450 watts / sq picoradian. That equates to about 1 kW / m^2 at the equator on a sunny day, or 1.4 kW / m^2 at geostationary orbit.  To convert this flux, we use either a heat engine or photovoltaics.  Neither solution has very high efficiencies: 33% for thermal, 25% for PV.  Both ground-based and geostationary solar is only active about 1/3 of every 24 hour cycle.  Ground-based has about a 50% duty cycle even from that, due to weather conditions.  Space based solar must then transmit the power down to earth, at an efficiency of about 84%.

Now, while that means that space-based solar can be as much as 3.1 times as efficient, that's only a single order of magnitude if you're using e (which I do endorse, as it's a more "natural" growth measure), but I believe the conventional wisdom is that a 10x improvement constitutes an order of magnitude.

Then there's the cost.  Even assuming the use of lightweight, thin-film solar panels, held out using a minimum scaffolding, you're still only talking about 300 W/kg, at ~$3/W for panel capacity alone ($9/W to accommodate the 33% duty cycle), and a cost to orbit of about $1200/kg.

In power generation, we talk about dollars per watt (Power cost).  The current prevailing limit of profitability for electricity production is at about $3/W.  SBSP, including just those factors, is $13/W.  That is not free.  That has to be re-spent every time the panels get too degraded by micrometeors, an estimated 10 years.  That's $0.14/kWh just for generation, without profit added - which is currently more than I pay for all electricity-related service.

It's no secret I'm a fan of nuclear power, and moreover of LFTR.  The reason for this is that I've looked into solar, wind, and even the lame "magnetic motor perpetual motion" self-delusions that people have, and have found them to be too diffuse, too expensive, too variable, or any combination of the three.  Nuclear power, well executed**, is an effective solution to climate change.

* Or use geosync sats as relays for giant SBSPs at the leading and trailing lagrange points of the earth.

** i.e., with reprocessing where it's needed, and with a focus on building reactors that continuously reprocess, such as LFTR.

I'm presently reading The Watchman's Rattle by Rebecca Costa.  It's a good read, so far, concerning largely the differences in the way we address about problems, the difficulties that come from complexity, and the way cognitive shortfalls can doom societies.

Unfortunately, she stepped on a pet peeve.  I'm not a nuclear engineer.  I'm not in the field.  But I have done quite a bit of study on the subject so as to elevate my knowledge on the subject past that of a layman.  So when I got to the bits about Costa's problems with nuclear energy, I just had to say something.

Although not widely known, nuclear power plants must shut down approximately every eighteen months to replace their fuel rods. The old fuel rods contain short-lived, low-level poisons as well as a highly toxic, radioactive material called Np-237, which has a half-life of more than two million years. Not counting nuclear facilities already on the drawing board, today we produce the “equivalent of one-hundred double-decker buses” of nuclear waste every year—waste that has to be stored somewhere.

The Watchman's Rattle, pg 42 

This is entirely true, if partial.  There's a lot more toxic, radioactive stuff in there than Neptunium.   Were we to reprocess our nuclear waste, as France does, the actinides - those elements that are heavier than Uranium - remain in the return fuel stream to be burned up.  Depending on the implementation, we may even exclude Np-237.

There's actually a market for Np-237: when NASA sends out satellites to explore deep space (which they have sadly not done recently), they use what are called radioisotope thermoelectric generators.  These run on Pu-238, a metal that, while not fissile like it's Highly Weaponable big brother, Pu-239 (of Demon Core and  Operation Crossroads fame), is nonetheless an alpha (high-energy helium atom) emitter that - well shielded - generates about 0.5W/g of material, with a half-life of 87.7 years (i.e., a 200W fueled RITE generator will only be producing 100W).   The primary production mode for Pu-238 is via the neutron bombardment of Np-237.

No, the nastiest isotope in the mix is Cs-137.  It can substitute itself for potassium in many biological processes - up to the point where it fails and causes problems; it's got a half-life of 30 years, giving it high radioactivity (@0.6MeV/beta decay) with a 300 year backgrounding time; it decays to Barium, which, depending on what it was bonded to at the time, can result in serious toxicity.

On the up side, nuclear waste is solid and stays where you put it.

It turns out that nuclear energy isn’t clean at all. We’re simply putting pollution into the ground instead of releasing it into the air.

The Watchman's Rattle, pg 42 

I'm not sure what planet you live on.  See, I live on Earth, a planet that has a core heated largely by nuclear decay.   But I was talking about reprocessing, wasn't I?

For the United States, producing roughly 810 TWh / year in 2008, it's true that we generate approximately 10,000 tonnes of spent nuclear fuel per year.  Of that spent fuel, only about 100 tonnes is actually unusable in the nuclear fuel cycle - the rest can be put right back into a reactor.

The cry I always hear about reprocessing is that it enables proliferation.  I haven't gotten that far in the book yet, but I wouldn't be surprised to see it show up.  To cut it off: the argument from proliferation screams ignorance about the problem of proliferation.  That is to say, if you're concerned about nuclear proliferation, you might care to know what is being proliferated aside from "nuclear material".

Little secret: anything that undergoes spontaneous nuclear reactions is nuclear material.  Think about that next time you inhale an atom of Carbon-14.

I'll scare you proper with the train of thought that normally shuts down conversations about nuclear reprocessing.

In spent fuel from any commercial light water reactor, the average breeding of plutonium isotopes for a 1% burn-up is about 0.6%.  The prevailing method of reprocessing, PUREX, separates this plutonium from the Uranium and fission product streams.

At this point you're meant to say, "OMG PLUTONIUM! T3H ENERGY COMPANIES ARE MAKIN' DEMON COR3Z!"

If you recall, above, I specifically called out Pu-239 as the isotope of choice for weapons.  Spent fuel plutonium - "reactor grade" - does contain Pu-239, but only at an average of about 50%.  The rest is a mix of Pu-240 and Pu-241.  Pu-240 has a high spontaneous fission rate - which means that if there's any appreciable quantity of it in a weapon core, it's likely that the weapon will prematurely detonate.  Pu-241 has a different problem: with its short half-life of 14 years, it decays quickly to Am-237, which is a heavy gamma emitter.

Gamma emitters are bad, especially if you need to, you know, control you nuclear weapon.  Gammas interfere with electronics and kill people.  High contamination of Pu-241 in a weapon core renders it deadly to the weapon's operator - and builder.

There is a trope going around that a weapon was made from "reactor grade plutonium" in the 1980's - but the fuel in question was right at the edge of what's called "reactor grade" - about 80% Pu-239.  Spent fuel from commercial reactors contains nowhere near those concentrations.

Then there's the argument that reactor grade plutonium can be enriched to the needed amounts.  To that, I say, "So what?"  As a nation or terrorist organization, you can enrich natural uranium to the 90% required to be considered "weapons grade" near as easily as plutonium (*SWU), but without the step of diverting it from bureaucratically monitored and well-secured channels.

So there it is: we should be reprocessing our nuclear fuel, working towards a fuel cycle that doesn't product so much of it (LWRs are terribly fuel inefficient, which is what leads to reprocessing being necessary), and simply burying the fission products for the 300 or so years it'll take them to background.

Not a typo.  I did say 300.  The quarter-million to several millions of years it takes to background our existing nuclear fuel stream is largely caused by neptunium and plutonium isotopes - which means that if we're just plowing those fissile and breedable materials back into  the fuel cycle, we're dealing with them on reasonable time scales.

We're not yet digging holes to bury our nuclear fuel; no one can yet agree on Yucca Mountain.  At the moment, most of our nuclear fuel is stored on-site at the power plants at which it's produced.  It's my suspicion that Yucca Mountain is meant to be a spring board for governmentally run reprocessing operation, and that there's serious political hand-wringing - gridlock, if I may - concerning the topic.  Honestly, I can think of no bigger waste than burying what is essentially 99% fuel and 1% hot trash, just because the hot trash is seriously neutron absorbent.

Chu smiled warmly and in a soft voice mentioned that if every roof and road were painted white, it would be the equivalent of taking eleven billion cars off the road for eleven years.

“It’s a cheapie,” he added.

Rather than build hundreds more nuclear power plants producing more radioactive waste, wouldn’t we rather paint our roofs and roads white? We could practically do it overnight, and the results would be immediate. Cars would remain cooler and use less energy. Cooler roads also mean less tire wear. The sun’s rays would be reflected rather than absorbed, so there would be an immediate temperature reduction around the globe. The demand for household air conditioning would drop 20 percent.

The Watchman's Rattle, pg 43 

I applaud efforts at conservation, but as you had mentioned just pages earlier:

When I show up at the local water board meetings and attempt to explain why conservation is not a permanent solution but rather a short-term mitigation, everyone’s eyes roll back in their heads. “Get rid of your grass and replace your landscaping with drought-tolerant plants,” they say.

The Watchman's Rattle, pg 17

Anyway, that's as far as I had gotten before electing to weigh in.  I'll continue reading, and likely comment as I see fit.  I have high hopes for the book, especially if it manages to nail down what you mean by "insight" as a process beyond the symptomatic "eureka" moment.

I really think you should rethink, or restudy nuclear.  When I did, the issue of climate change crystallized for me from feeling like an insoluble, murky, overwhelming issue of doom to being a simple matter of acting quickly on technology we'd not yet fully explored.  I found that conventional wisdom on nuclear energy is largely based on misunderstood statements and political wrangling.

I won't call it conspiracy - that would assume a level of subject-matter competency among anti-nuclear activism that just isn't there.  The problem is fear and ignorance.

*SWU: It's orders of magnitude easier to enrich to 50% than it is to enrich from 50%.  Why?  Say you have a box of red and white marbles, mostly white.  If you shake the box around, and grab at the patch that look the most white, you've just enriched your box's red content.  If, on the other hand, you've got lots of red and few white, you're going to have a harder time enriching your red.  Since the particles are macroscopic, you can pick them out - but for nuclear chemistry, it's not so easy.

As part of learning Flash development using Flixel as a springboard, I'm attempting to write a game with similar controls to the battle / side-view mode in "Zelda II: The Adventure of Link".  OddNo1IsHere will be doing the artwork and Fuquinn will be doing the music.  I may tap DaHimura for level design, but I haven't decided yet.

Anyway, I've got the control structure about half done (he can move left to right).  I need to implement a simple level and stage-level collision.  Once that's ready, I can add jumping (can't jump if you can't feel the ground, and can't have meaningful gravity if there's no ground to fall to).

Anyway, I'm excited about diving into a type of development I've never tried before.

As a side project, I'm presently working on an MVC framework for node.js, and I'm calling it (tentatively) nodule.  The following ideas are being used:

Controllers: simple exports object { target: method }.
View: Resig's simple templating engine, plus HTML helpers
Model: Based on concepts from my old PHPTableModel (which may or may not work at the moment), essentially it's a way to chain tuples, jQuery-like, before committing to a query.

Dispatcher: first, check the router table, then, for http://server/a/b/[...], execute controllerA.B([...].split('/'))

All model and view decisions are made by the controller.

Anyway, it's not that far along yet, but I'll keep everyone posted.

Nuclear power in the United States has the potential to reduce our carbon production by half. First, by supplanting electricity production. Right now, nuclear power has spent the last thirty years producing about 20% of our power, and hasn't had a single radiologically induced fatality, and very few injuries as a result. There's been only one significant release of radiation, and fast action by the plant owner and the surrounding community quickly saw to it that there was little harm, if any. If we were to increase our nuclear buildout to replace our coal generation industry, we would reduce our carbon production significantly.

There are other targets for nuclear energy. One is to ape the U.S. Navy. They have been running nuclear-powered ships for the last 50 years and have not suffered a radiation release. If we were to enable a move of our commercial fleet of ships to nuclear power, in addition to the gains from electricity, the United States would get an overall carbon reduction by around half.

There is a lot of fear surrounding nuclear power. One is that of coal unions; their opposition to nuclear power is that it eats into Coal's demand budget, thus putting a lot of people out of work. While I don't think that's a convincing argument from an energy perspective, I do think it may have teeth from an economic one. This post is an attempt to provide a path to avoid such job losses.

It is true that a greater dependence on coal for energy budget will reduce the generation demand for coal. If mining companies are smart, they will quickly move into alternate areas of coal consumption.

"Clean" coal
"Clean coal technology" refers to a mix of chemical tricks - the most important one being coal gasification. This is the process of converting coal into a mix of carbon monoxide and hydrogen, called "synthesis gas", or "syngas". While this is a good substitute for natural gas - reducing the need for fracking and oil drilling - there are other uses for syngas.

Further processing via Fischer–Tropsch synthesis yields diesel fuel. You can also convert syngas to methanol - a fine stand in or filler for gasoline. Syngas can be the source for plastics production. Generally, with the demand for electricity covered by nuclear power, coal companies can concentrate on replacing oil. This may not reduce carbon production from the coal industry, but we gain energy security benefits and reduce our dependence on foreign oil. Additionally, if we're never burning coal directly, we're not pouring SOx and NOx emissions into the air. If we're mining coal more smartly, using in situ processes - which we can do if we don't need it in solid chunks - we can reduce the water pollution that goes into coal mining.

Unfortunately, this plan does not solve mountaintop removal.

Overall, there are a lot of targets for coal without being our primary production avenue for electricity. The question is: does the coal industry have the wherewithal to eat the lunch of the oil companies?

The primary benefit to consumers, of course, is that without OPEC manipulating prices, there will be a natural reduction in the cost of diesel, gasoline, and natural gas. It's been a while since they had any real competition in the market for these three fuels, and it's about time we gave it to them.

The coal industry will eventually slow to a crawl - that is inevitable - but this path enables a smooth transition while reducing our carbon output. Moving to a syngas-based economy has other migratory advantages. You can also produce syngas via carbon sequestration, Sulfur-Ioidine hydrogen synthesis, and waste heat from high-temperature nuclear plants. You can start building cars that run on electricity, using direct methanol fuel cells, and get much higher efficiencies as a result. Betavoltaics built using Strontium-90 from spent nuclear fuel (present at ~6.5% in U-233 fission, ~6% in U-235 fission, and ~2% in Pu-239 fission) can later be dropped into the same electric vehicles, only requiring a "refueling" (or overall recycling) every 30 years or so.

But replacing coal-based electric consumption and diesel shipping with nuclear power should be our first-order goal as a nation. During that time we should finish development on LFTR and the IFR, so they can be deployed on greater scales.

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 ^_^

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

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.

 

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"