"The principle that the majority have a right to rule the minority, practically resolves all government into a mere contest between two bodies of men, as to which of them shall be masters, and which of them slaves; a contest, that --- however bloody --- can, in the nature of things, never be finally closed, so long as man refuses to be a slave."

Sage advice, especially given the current rime-locked national discourse. I submit that the "two party" system is actually not two parties, but a binary tree of counterweighted factions.

View Larger Map

View Larger Map

Over the next three years to six months, oil will be the best investment you can make. Here's why.

An oil producer, "Party A", produces X number of barrels of oil per day, and places this supply on the local market. At this marketplace, buyers from the United States (population 301,139,947) line up beside buyers from China (population 1,321,851,888), India (population 1,129,866,154), Europe (population 490,426,060).

Party A decides to put the X barrels on the market at price P1. Conversely, the buyers from these respective populations place bids for Y barrels of oil at price P2. There can be a large gap between what people are willing to pay for oil, and what producers are willing to sell it for. In this case, no barrels of oil are sold.

However, in non-oil-producing nations, especially industrialized nations, there is no option but to consume oil, or face immediate starvation and collapse. Further, there are far more consumers than producers. In the past, when there were fewer consumers (the U.S. and Europe alone), the buyers had more leverage on the market. When there are only a handful of parties producing a commodity, it is called a production cartel.

In short, we need their oil more than they need our money. And China and India need the oil as well, because their economies are growing at rates that dwarf the economies of the U.S. and Europe.

Further, the U.S. Dollar is worth less every day than the day before. Our rate of monetary supply inflation is about 17% per year. This means that for every 100 dollars that exist in the world in 2007, there are $117 in 2008, $137 in 2009, $160 in 2010, $187 in 2011, and so forth. The Federal Reserve controls all aspects of monetary policy in the United States. It is not answerable to the United States Congress. The President has no control over it, aside from appointing the Fed Chairman.

Further still, in addition to there being more dollars in existence, there is declining supply of oil. There are very few discoveries of new oil fields in the world today. There are few new refineries being built. Because of well-intentioned environmental concerns, many known oil fields such as those off of the coast of Santa Barbara California and Anwar Alaska are being ignored.

Finally, consumers from industrialized nations are using more energy each year. In the United States, this equates to bigger vehicles, more air travel, bigger houses, fewer marriages (which imply the need for more dwellings and more heating requirements), more computers, big screen televisions, etc. One gulp of the atmosphere in Beijing is proof that China is quickly industrializing and using greater amounts of energy each year than the year before. Finally, especially in the United States and Europe, existing nuclear fission plants are being left to rot while no new fissile plants are being built, and there is little to no funding for serious research in advanced fission or groundbreaking (nonradioactive) fusion technologies such as that being conducted by Lawrenceville Plasma and Physics.

Wind and solar power do not have enough energy flux density to perform the heavy labor needed in the real world. Here are several examples:

1. Solar powered airplanes do not and will never exist.
2. Wind powered airplanes do not and will never exist.
3. Solar powered cars and trains are not viable technologies.
4. Solar power cells produce no energy at night.
5. Wind power doesn't work when there is no wind.
6. You cannot melt large quantities of steel with the electricity generated from solar panels.

How long does it take for a wind-power generator to generate the energy needed to replace the energy needed to mine the iron ore and cobalt needed to make the steel its made out of? How about the energy needed to smelt that ore, process it, shape it, and the sum combined energy needed to move the ore and the finished products to the generation site? Consider the same question for solar cells. Solar and wind power are net loss technologies.

Hydrogen fuel cells suffer from a related problem. Fuel cells are batteries. They do not produce power, but only store it in a chemical reaction. So, fuel cells are not the answer to the world's energy needs.

In other words, all forms of "clean energy" are actually just as filthy as burning oil and coal and using nuclear fission, because they all, without exception exist as derivatives of the real energy market. So, solar power isn't self supportive. Neither is wind power. They're nice ways to light up a home and provide widespread lightweight offsets to energy consumption, but they don't offset their requisite manufacturing cost. Industrial society is not currently possible without oil, coal and nuclear power. That's reality. The oil is running out, and every new dollar makes it more expensive. Every new mouth to feed in the world increases its price.

So, let's review.

1. The price in dollars of oil is a function of:
   • international supply of oil
   • international demand for oil
   • the supply of dollars available with which to purchase the oil
   • the supply of other currencies available to purchase the oil
   • the availability of other forms of usable energy
2. The United States congress does not control the price of oil.
3. Hillary Clinton, Barack Obama and John McCain do not control the price of oil.
4. There is no conspiracy to hike up the price of oil.
5. In order to halt US Dollar price increases in energy in the U.S., we would need to either increase our own production of industrially usable energy by 17% per year, or reduce the rate of dollar inflation. In addition to this, we'd need to be 100% self-sufficient in energy AND either eliminate world economic growth, OR forbid energy exports.

What the United States as a technologically advanced society and a leader of the world should do is heavily invest in clean (non-radioactive) fusion technologies to replace aging nuclear fusion technologies such as the dense boron-hydrogen plasma fusion reactor, and move aggressively to render oil and fissile energy production obsolete. In the meantime, we should alter our weak dollar policy, make effective use of our native coal and oil resources, and probably invest in intermediary clean fission plants. We should build more railroads, get trucks off of the freeways, and live closer to where we work. More people should ride bicycles for jaunts around town. And we're going to have to do all of these things in concert in order to survive the energy reality of the 21st century. The 20th century is over, and we can't pretend otherwise or legislate our way out of our problem.

The parties most capable of making many of these needed advancements are "Big Oil" and "Big Corporations". Punishing these parties for helping keep us alive is suicidal. Solar and wind power are only a small part of the solution. We should get out of the way of U.S. energy companies and do what we can to help them move the ball forward. Foreign producers have the most to lose from a new energy revolution in the United States, and that would be sweet justice, wouldn't it?

So, I decided to wait and see. I have not been disappointed.

First of all, the improvements made last year to the building have been effective in reducing crime and improving quality of life for this resident, and I imagine others. I am filled with gratitude for the work of Jenny Carrier and her crew. There was not an abundance of obvious criminal activity this winter, no transients sleeping in the hallways, or any of that nonsense. Instead, we have a distinct and firm new ownership whose mettle I unfortunately had to test this winter.

In January, I noticed the distinct sound of a rodent in my ceiling. I figured it was a squirrel, based on the abundance of them in the neighborhood and their repeatedly proven ability to climb up the exterior walls. I did not, however, begin to panic, until I found an 8-inch mound of ceiling-stuff atop my refrigerator, and a clearly chewed hole in the ceiling.

I made several calls to the repair technicians, who over the course of about four weeks attempted to poison the squirrel, then decided to battle cold and icy conditions and effect repairs to the exterior of the building and to eventually patch and repaint my ceiling. Throughout the whole process the repair technicians (notably Kyler) and also the telephone operators at Mint Properties have been the modicum of professionalism and respect. In both cases that I needed to call the repair technician was on site within 30 minutes, which greatly eased my fears of having a remote management office. They've even gone so far as to call me at work in order to keep me appraised of the progress.

So, following my New Year's pledge to write about things I appreciate, here's my hat off to Mint Properties. Welcome to the neighborhood.

First of all, as always, a pattern is necessary to illustrate the problems I've seen. Consider the task of persisting a unit definition. Here are some examples of instances of a Unit object: kilogram, second, meter, candela.

Clearly these objects all would benefit from having a name, description and ID field. But consider these as well: joule, watt, newton. Now, the first three units were SI base units. The second three can be defined in terms of the first three. For example, a newton is equal to m∙kg∙s⁻². So it becomes clear that units need to be able to be defined according to an underlying terminology.

So, let's say we have a Term class, with a coefficient, a radix and an exponent. The newton Unit instance would now contain a List of three Term instances. The first term has a coefficient of 1, a radix of the "meter" instance, and an exponent of 1. The second term is much like the first, save for the fact that its radix is equal to the "kilogram" instance of the Unit class. The third follows a similar pattern, but in addition to referencing the "second" Unit instance, it also has an exponent of -2.

Now, for consistency and convenience, we'll define base units in terms of themselves. So, a "meter" instance contains a list of one Term, with a coefficient of 1, a radix of the "meter" instance, and an exponent of 1.

Finally, we can also give the Unit class a boolean field, in order to distinguish between base units and derived units. This very basic definition of units and terms will suffice for what I'm trying to explain.

Now, so far, we have two entities, Unit and Term, and a very simple Many-to-Many relationship between them. But here's where the trouble starts.

Part of the purpose of capturing the concept of a Unit in an object-oriented manner is so that we can use them to create constraints on logical behavior that are more rich and efficient than we'd be able to accomplish were they mere text fields. We also want to capture, in some way, the relationships between different units.

To illustrate the first point, consider that you're writing an application where you want to add together a collection of units to determine their sum total. Now, imagine your assumption is that you're trying to get a combined measurement of mass. If you have an object that represents "3 kilograms" and another that represents "5 kilograms" you can easily accomplish this. But what if in addition to these, someone slipped in an object representing "4 seconds"? What is 3kg + 5kg + 4s?

Now we're dealing with dimensional analysis. There are rules that stipulate, you cannot add these together. It'll break your logic. So, what you want to do--what you need to do, is to somehow capture the idea that your "kilogram" units are tied to the concept of "mass", that your "second" objects are tied to the concept of "time", that your "tesla" objects are tied to the concept of "magnetic flux density", and so forth.

But what are these concepts "time", "mass", "magnetic flux density", "photoelastic work", "molar entropy", and so forth? Well, it turns out there is some fog in the answer to that question. Depending on which poorly written wikipedia article you find, these concepts are collectively called "quantities", "dimensions", "magnitudes" or even "quantitative properties of particles". It turns out there is no highly rigorous name for them, but since Object-Oriented programming is nothing if not nominalist and aristotelian in nature, they needed to be named. In order not to limit my future use of the above terms, I decided against adopting any of them and named these objects according to their relationship to the Unit. Since these concepts serve to limit the scope of what the unit can be used to quantify, I refer to them as the Quantitative Scopes of a unit. Please, if you're a physicist studying dimensional analysis, don't be upset.

Because, whatever these are called, we are now straying into trouble with Java. Case in point, how does one best represent a quantitative scope?

Well, generics give us one tantalizing option. I'd like to be able to create a new Unit<Mass>(), and keep it in a Set<Unit<Mass>>. I think this would afford me with the best and easiest way to constrain the use of these units. However, that leaves us with the difficult problem of how "Mass" is represented.

We have only two options here. Class or Interface. Class is problematic, because every instance of "Mass" would be identical to every other. So, it makes more sense to use Interfaces. Ah, but herein lies the rub, because our original goal was to make these objects persistent. And Interfaces, bless their bytecode, certainly do not fit this bill.

So, it seems objects are the only option. But this, once again, leaves us with the problem of instance control. I could rattle off 126 examples of a QuantitativeScope object, each differing from the other only in name. But if we define each as a class, then presumably we'd have 126 database tables filled with carbon copied records, which is just not going to happen. Thus, the quandary. Interfaces cannot be made persistent, but classes are the wrong instrument to accomplish the goal.

Well, what about enums? It's an idea--an enum would nicely solve the persistence problem, but it doesn't save us on the application layer because enum-valued objects cannot be used in generic fields. Furthermore, enum-valud objects cannot be given generic fields themselves. This makes sense, given what enums are for, but it leads us back to the same problem. How, given all three of these tools, are we to accomplish the goal of being able to discriminate easily between units of different quantitative scope while not abandoning the ability to persist the objects?

I came up with an ugly hack to solve this problem. The good news is that it makes the best use of the available technology that I'm able to determine. The bad news is that it's an ugly hack and it fills me with doubt about Java and JPA. But I'm invested in making this work, so here goes:

First, I created a "Scope" enum, with 126 different values in it. Scope.Mass, Scope.Time, etc. Then, I made 126 corresponding interfaces, "Mass", "Time", etc., that extend a base "QuantitativeScope" interface. Third, I made a generified "Graft" class that serves to bind one of these interfaces "Q extends QuantitativeScope" to one of these enum-valued objects. Finally, I defined a library class containing 126 public abstract final instances of this "Graft" class, each mapped to the appropriate "Scope" enum-valued object. With these graft instances, I was set.

Now, when defining a Unit, I can pass one of these "Graft" objects to the UnitFactory. It can get both the generic type from this Graft object, and assign the Graft.getScope() enum-valued object to a "scope" field in the Unit class. When I persist the Unit into JPA, the "scope" field, which is defined as @Enumerated(EnumType.STRING), goes into the database. When I get a collection of Unit objects back out of the database, I can run them through a seive and inspect each of their Unit.getScope() values in a switch statement, then place them into appropriately generified Set objects. This piece works sort of like a coin sorter, but when I'm done I can ask for the Set<Unit<Mass>> and know that my results are reliable.

The main problem with this workaround is that I had to duplicate a lot of data and encase it into interfaces, a large enum, and a graft object library in order to make it function. There are other lingering problems with this approach as well, and I'm sure that I'll uncover more and more of them as I continue.

What this has taught me is that enums and generics are exceedingly tricky to use. Although with generics, Types can now be used as compile-time constraints on behavior, they don't help you at runtime, and are therefore tough to work into a persistence application. This worsens the intrinsic impedence mismatch between the application layer and the persistence layer in application design. Further, enums in Java behave like pseudotypes, somewhere between Interfaces and Classes, but because they cannot be used as Generic Types, they even further aggravate the impedence mismatch when worked into a persistent application design. If I could have used the enum valued objects in the generic fields, this would be a non-problem.

Finally, the best solution for my particular problem might have nothing to do with enums or generics after all. What I'm trying to replicate through this design is actually Invariants, Preconditions and Postconditions on method behavior, class definitions, and collection compositions. There are languages such as VDM-SL and Eiffel that wonderfully exemplify this sort of language feature, and old tools such as iContract that might make it useful in Java, but it's a shame that these useful tools are not built into the language itself.

I'm very glad I've emphasized the creation of cascading behavior tests for CORM. I caught a potentially very tricky issue tonight while doing so, and it relates to standardized SI base units and derived units. Ideally, for the sake of maintainability on the database end of things, each of the SI base units would have a single row in an SIBASEUNIT table. There are very few of these base units. So few, in fact, that it might not even be necessary to add them to the database. It might be better to create them as an enum and represent them as a string-valued column in another table, perhaps TERM.

The problem with this approach is that Term objects can also be constructed with derived units. It shouldn't matter how people construct their Terms and Units, so long as the data is able to be kept around and made useful at a later time.

So, imagine this scenario: I create a class called "SI", and it contains several hundred units. These are all units the end user could create on their own. SI is just a convenience class that provides a giant collection of pre-built units, and maybe even a collection of conversion contexts. There is no reason end users could not reproduce every bit of functionality provided by this class.

Imagine also that I implement Unit.java in such a way that if you created two units with identical data, unit1.equals(unit2) would evaluate to true.

Furthermore, imagine that each Unit instance is an entity with its own ID field. Now, imagine you call:

Unit unit1 = SI.KILOGRAM;
Unit unit2 = UnitFactory.baseUnit(SI.mass, "kg");
// unit1.equals(unit2) == true

This is just a pre-built unit, provided for your convenience, right? Great. Now, use a JPA persistence manager to push unit1 into a database, then you'll find that unit1.getID() returns a nonzero value. Here comes the kicker--ready for it? what happens when you persist unit2?

Moreover, what happens if you refer to SI.KILOGRAM from other classes? Do they all now use the same object in the datastore? Probably not. But should they? Maybe. How do we tell? What's the correct way to build this?

It's a sticky problem. Equivalence on the logical tier might not imply equivalence in the datastore. If we have duplication of the same data across numerous rows in the datastore, what are the implications for table efficiency, sorting, and the like? Should I push for 3rd normal form? How far down should I disassemble these units?

So, that's what I'm brooding over tonight.

While working on this package I learned a lot about dimensional analysis. In short, dimensional analysis is a fancy way to describe the algebraic manipulation of units of measurement. The best example I can conjure would be Google's unit conversion utility. Or:

1 watt / 1 joule = 1 hertz

Since "1 watt" equals "1m²∙kg∙s⁻³", and "1 joule" equals "1m²∙kg∙s⁻²", "1 watt / 1 joule" equals "1m²∙kg∙s⁻³ / 1m²∙kg∙s⁻²". Or, "1m²∙kg∙s⁻³ ∙1m^-2∙kg^-1∙s²". When you really think about it this way, it's no different from "aX²∙bY³ ... "

Each of these terms (1m^-2, for example) is composed of a coefficient, a radix, and an exponent, just like any other algebraic term. Once you have represented units as a name mapped to a list of these terms, you can perform simple and elegant conversions to create derivative units. In our example above, we could perform the following transformations:

1. Suppress all coefficients of "1", as they are redundant. i.e., don't print them.
2. Add the exponents of terms with the same radix.
3. Any term with an exponent of 1 and a coefficient of 0 reduces to a term of unity, and is removed.

These transformations would yield:
"m^2-2∙kg^1-1∙s^2-3", or
"m⁰∙kg⁰∙s^-1", or
"1∙1∙s^-1", or
"s^-1", which is the definition of
"1 hertz".

Now, the important part in all of this is that the transformation logic used to build and combine units is not part of the units themselves!. It can be implemented in any number of packages--an entire library of useful unit building packages and pre-built unit types could be designed. But, the bottom line is that each unit consists of the following elements:

1. A name
2. A description
3. A symbol
4. A list of terms.

Each term consists of:

1. A coefficient
2. A radix, which is another unit
3. An exponent

If the unit is a base unit, it contains exactly one term, which is self-referential. For example, a "meter" contains the term "1 meter¹". Thus, base units are self-defined. Derived units, on the other hand, are defined in terms of base units. Now, with only three entities, we can represent units of all kinds.

Almost.

I found, for the sake of unit conversion, that it were best for my purposes to represent the coefficient as a rational number. This helps reduce the risk of overflow during unit conversions. I struggled for a long time trying to determine the best way to implement this, including using Number and permitting users to retrieve the value using longValue(). However, this didn't work. Spectacularly. It has to do with the inability to distinguish between an integral type and a floating point type in Java. If I could create an "Integral" object, and reliably get int, long or short out of it, that'd be great. But with the ever-looming threat of precision loss because of floating-point multiplication, I gave up and fell back on rational representation using long numeric primitives. Remember--my most important goal is persistence with this package. So, is this the best way to get the job done? It depends. For my job, certainly. So I re-jiggered a Rational implementation to use longs and brought the entity count to four.

And my work was nearly complete. But for a few important considerations. First, unit conversion. I want to be able to represent a US pound as somehow related to a US ounce. Now, for many units, the relationship is fixed and will never change. However, for many other units, particularly those in a market context, the exchange ratio between units is in flux and subject to change. So, I used dimensional analysis for the simplest possible answer. I created the notion of a conversion context which is itself very similar to a unit. A conversion context is just a list of terms, from which arbitrary unit transforms can be made.

For example, if I define a unit of "gold" with the symbol "Au" as a base unit, and a second unit, "Thorium" with the symbol "Th" as a base unit, I could create a conversion context containing the terms "1 Au¹, 100 kg^-1, 1 Th^-1". This essentially represents 1Au/100 Kg Th" Now, if I multiply 200 Kg Th by this ratio, I get the result of "2 Au". The actual formulas that provide the conversion can be written by anyone capable of high-school algebra. The important part is that the units themselves, as well as the conversion definition, are all simple, small, and able to be persisted in an EJB3 system.

In order to illustrate these conversion formulas, I build a derived unit factory and provided a stub collection of SI units and simple utilities, as well as a smattering of US and British units. And at this point I was very nearly finished.

But not quite. There was one outstanding matter, and it was more difficult than either of the above. It involved what JScience referred to as "Quantity". Examples of this include "length", "area", "time". I did a lot of research on this in the "dimensional analysis" field, and basically boiled down the following observations:

1. There are a LOT of names for this thing--JScience called it "quantity". Others call it "dimension". Still others call instances of this concept "quantitative properties of matter", or "quantitative properties of things". I struggled between all of these names and was never satisfied until I realized that:
2. A unit is limited in the scope of what it can quantify. A "meter" cannot quantify radiation dose absorbed or weight. A "second" cannot quantify mass. So "quantitative scope" seemed like a more useful name for the object.
3. Each unit should have a reference to this quantitative scope, so that units can be sorted and more efficiently searched by this field.
4. In Java, it is particularly useful to be able to say "new Unit()", and deal units and their quantitative scope as generic types. This is especially useful in collections. Thus, each instance of these quantitative scopes could not be gathered into a Java enum.
5. The list of quantitative scopes is not conclusive or final. This supports the earlier conclusion not to represent these using a Java enum.
6. If the relationship between the unit and its quantitative scope is to persist, each type (area, length, time, etc.) cannot be interfaces. Interfaces cannot be persisted with JPA.
7. Thus, the only option is to represent each of these which is currently known as its own class object.
8. I found 48 of them by digging online.
9. Every instance of "area" or of "length", etc., should be identical to every other instance of the same type.
10. The best way to represent these objects is as a single table hierarchy with a discriminator column. It's efficient, and I can use a non-generated primary key, so application-defined primary key field.

These were my observations, so that's how I built the system. It isn't as perfect or elegant as I could have written in another language or if persistence were not a requirement. But it's pretty clean.

Now I can extrapolate from this and be able to represent prices of different quantitative scopes, including "money" and "product", and use it to implement a currency market or even a commodities market (or a combination of both!). For my needs, it's a better tool. Smaller, cleaner, JPA compatible, and it has a very clear separation between entity representation, systemization of units, and transformational logic. No funny business under the hood, either. Just a small, clean, OO solution for a commercial object relational model.

I'm going to finish some tests for it over the weekend, tag an interim release, and then write all of the JPA annotations and draft up a handful of persistence tests. Expect news of a release very shortly.

The ATHLETE (All-Terrain Hex-Legged Extra-Terrestrial Explorer) robot could play an essential role in new lunar bases.

According to NASA, the 15 ton lunar habitat would be mounted on top of the six-legged robot. The habitat could walk right off of the lunar lander, and then proceed to any desired location. Wheeled locomotion would be used for level ground; more challenging terrain could be negotiated with the full use of the flexible legs.

The ATHLETE-based habitat could then be controlled directly by astronauts; mission control could also direct the habitat from Earth. My favorite alternative, an autonomous robot habitat, is also slated for testing. It would use software developed for the Mars rovers Spirit and Opportunity.

The robot habitat would move around using power drawn from solar arrays; the maximum speed is about 10 km/hour. Although this seems slow, remember that the Moon's circumference is just 11,000 kilometers (compared to Earth's circumference of 40,000 km). Astronauts would live a nomadic existence, covering much more of the lunar surface.

The most significant problem I can see from this is solar arrays. The moon is constantly bombarded by a micrometeorite shower, with tiny flecks of metal and stone continuously bombarding the surface at speeds of 75 km/s. This is not a friendly environment for solar arrays. It's closer to the inside of a sand-blasting chamber, only with less sand traveling much more quickly. Over time, the solar arrays will be scarred and eroded, which will impact their performance.

While we're investing billions of dollars into robotics, why don't we float $10 million over to the dense boron-hydrogen plasma focus fusion project and revolutionize power production and propulsion systems? The robots will need to be fed.

Other significant problems include the high amounts of cosmic radiation the habitat will encounter--the moon is not your friend. Inhabitants will require a permanent structure, very likely one buried beneath the lunar regolith, in order to survive for any useful amount of time. A machine like ATHLETE would make a better exploration and utility vehicle for carrying fuel cells, regolithic samples, and passengers. It could be kept and maintained in a hangar between outings.

Still, I like to see this sort of work being done. JAXA and NASA have a bright future on Luna, if they want it. If not, perhaps Google.

Paulson's plan would intensify the hands-off philosophy that invited the credit crunch. He would make the Federal Reserve a superagency to monitor large financial firms and provide emergency bailouts. He would reshuffle some federal agencies - but actual regulation would be weakened. The plan proposes, "The Federal Reserve's authority to require corrective actions should be limited to instances where overall financial market stability was threatened." Other regulatory agencies are to defer to the Fed, and to "streamline" - translation: water down - existing rules.

Now, let's dig into this. As any free market scholar would tell you, Paulson's plan to give more power to the Federal Reserve runs entirely contrary to the wishes of the Free Market's most ardent supporters. For those of you who missed the memo, the Free Market powerhouse and poster-boy Ron Paul ran for president in 2008, amassing millions in record-setting fundraising extravaganzas by promising to abolish the Federal Reserve. So, let's keep one thing clear. The Federal Reserve obstructs the Free Market. It is an impediment to and the primary obstacle standing in the way of the Free Market.

The Federal Reserve caused the market collapse you are witnessing right now, by artificially lowering interest rates in 2002-2004 in order to prop up the side-winding stock markets and to spur on perceived GDP growth in advance of the 2004 elections. They were under tremendous political pressure to do so, just as they were under tremendous political pressure to arbitrarily increase the prime lending rate in 2006, due to public fears over inflation caused by the skyrocketing supply of US Dollars in the market resulting from their easy-money policies in 2002-2004. When the money dried up as a result of this increase in the interest rates, housing and mortgage-backed security bubble collapsed.

Robert Kuttner needs to get it through his head--the government interferes with the markets. The Fed enables financial firms to borrow money at low-risk premiums, make risky gambles with it, and all with the promise that if the gambles turn out well, these firms can keep the profits. If the gambles fail, the Fed will bail them out, as it bailed out Bear Stern. It's like going to the casino and knowing that if you win at slots, you keep your earnings. If you lose, the Fed will bail you out.

A real Free Market Solution would look like the following:

If someone makes a bad investment, they should take the pain. If they can't handle the pain, they'll learn not to take risks they cannot afford. Caution and wise investment has for too long been denied its place at this nation's dinner table. Cautious investors, more discerning and careful participants in the market deserve to be rewarded for their diligence and held up as examples of the gravity of real adult financial interactions. Daredevils who try to exploit conditions to flip homes and drive up the prices in the market are contributing to holding back an entire generation of Americans from home ownership and raising a family. Now the Congress wants to inject itself into contract agreements and destroy any incentive lenders have left to enable young people to buy homes. It has to stop.

When the Fed comes rushing in to prop up a sagging economy, it assumes it has the capability of doing this. In fact, it does not. Its interactions as the "invisible hand" are more visible now than ever. So, if Kuttner is going to speak up about the Free Market on the pages of a respected newspaper before a global audience, he should take care not to mischaracterize the Free Market's stance on this issue. Many people claim to be "in favor of free market capitalism", but the system we have right now is nowhere even close to that system. The constant meddling of our government and the Federal Reserve in the markets more closely approximates socialist governments they so readily scathe.

Nothing personal against Kuttner, but he shouldn't mischaracterize Free Market thought, or somehow try to lay the blame on precisely they who have not been listened to during this entire fiasco. He invites even more interference and meddling by doing so, and aggravates the wound.

About five weeks ago I hit a major roadblock with my development effort on the CORM project. JScience was not built with persistence in mind. Now, don't get me wrong. JScience is a pretty cool project, and I was certainly excited to find it last autumn. However, you should always pick the tools appropriate for your task.

My task is threefold:

1. Represent arbitrary quantitative units and their relationships in a JPA compatible way.


2. Represent product instances, product types, and money as quantitative units.


3. Perform conversions via dimensional analysis using an external conversion context, such that each unit is unaware of its relationship to other units.

All three points are very important to the success of my project. JScience is geared toward real-time computing, not toward a simple and elegant JPA/EJB compatible object model. It performs some dark arts regarding memory access and garbage collection under the hood that I do not completely understand and cannot trust in a distributed environment. It does not decompose cleanly. Its classes are often not extensible. In short, it is not the correct tool for my needs. It might be for yours, though. And the developers seemed very professional.

So, I built a quantitative library for CORM. I'll be showcasing it as soon as I iron out one more problem with its implementation, involving interfaces. JPA is downright hostile toward interfaces, and why not? They are abstract, so have nothing to persist. The error is my own for abusing generics in lieu of a less elegant field to represent which quantitative property is measured by a given unit. For example, the candela measures the quantitative property called "luminous intensity".

A thorough description is beyond the scope of this entry, especially because this in this neighborhood of the physical sciences, words tend to lose their distinction. What exactly is the difference between a "metric" and a "measure", and "measurement"? What's the difference between a "quantity" and a "measurement"? Non-trivial question, that.

Anyway, code is forthcoming. Possibly over the weekend if I can get done with my VDM-SL homework done.

Instead of this tinlike expression, use "If I were younger", "If I were home", "Wish you were here", etc.

If you're ever in doubt, invert the expression to test its grammatical correctness. "Were I younger, I would...", "Were I home, I would... ", "Were you here, we could..." and so forth. "Was I younger, I would ... " just rings leaden in the ear and illustrates how ugly the misuse of "If I was younger" types of expressions in absence of the subjunctive really are.

Finally, the subjunctive opens the door to an even more poetic grammatical device, which I would see spent into common circulation again in the next century: the optative. It is exemplarized by John Keat's

Bright Star! Would I were steadfast as thou art

"Would I were younger" is more than just a description of a hope or dream, but an explicit statement-act of hoping or dreaming. "Would I this nation were at peace". Now that's beautiful. Try saying the same thing using the ugly non-grammatical English from above.

"I wish this nation was at peace."

Guess what? It was! So your wish came true. Try again.

"I wish this nation was at peace again"

We have been at peace many times. Try again.

"I wish this nation would be at peace"

We undoubtedly will at some distant point in the future. Try again. Hopefully I've expressed the practical utility of using these proper grammatical forms. Dream big. Conjure the subjunctive and optative in your writing.

I haven't fully spoken my peace over the incident at the Boiler Room Cafe in Minneapolis this morning. I work in the service industry. I help paying customers for a living. So I know how to treat them. One thing you should never do is swear at them or tell them to go elsewhere, because customers owe you nothing.

You might think you've got them right where you want them--they already payed, right? So why treat them well? That seems to be the attitude. The fact of the matter is that you work for them. Without the customers, you don't have a business. That doesn't mean you need to put up with abuse from customers, but it does mean that there are appropriate ways to deal with potential conflicts.

People don't go to coffee shops for the coffee. I know that sounds strange, but the fact of the matter is that coffee is cheap and people can just stay home if they want a good cup of coffee. I certainly would never go to a coffee shop if I wanted a reliably high-quality cup. I can roast my own beans at home in my popcorn popper and have the best light roast in the state in 20 minutes if I really want to. No, there are two things that people purchase from coffee shops.

1. Proximity (it's a close and convenient place to get out and have a drink)
2. Atmosphere
3. Friendly Service

The first item--proximity--has the weakest claim to our patronage. Coffee shops are a dime a dozen, especially in a city like Minneapolis. The second and third items in the list make up the bulk of the reason people go to coffee shops. If you have bad or uncomfortable atmosphere it cancels out the motivation to leave the home in the first place. If you have rude customer service on top of it, don't plan on being in business for too long.

Cafes provide a service--not a product. People who don't like to provide good service should choose a different career path. The Boiler Room Cafe has terrible and hostile service, which defeats the point of going out for coffee instead of enjoying a better cup at home. I'd rather see a Dunn Brothers in the neighborhood--they have better coffee and they know how to treat customers.