Wind setdown is the drop in water level caused by wind stress acting on the surface of a body of water for an extended period of time. As the wind blows, water recedes from the upwind shore and exposes terrain that was formerly underwater. Previous researchers have suggested wind setdown as a possible hydrodynamic explanation for Moses crossing the Red Sea, as described in Exodus 14.

Since the paper is about dynamics instead of biblical history, the contents focus on fluid mechanics instead of on Moses and the Hebrew refugees. But for those readers who are interested in the Exodus, Point B in Figure 8 is Pi-hahiroth. The famous crossing is from Point B across to Tell Kedua. My Tanis hypothesis suggests where and how Moses crossed the yam suf. When remains a thorny issue. As with any new hypothesis, scholars from many disciplines will have to consider the proposal from all angles (history, linguistics, military science, archaeology, meteorology, refugee movement, sociology, oceanography, etc.).

What Open Access means for me

PLoS ONE is an Open Access journal, meaning in a general sense that access to the publications is not restricted. You don’t have to pay a download fee or a subscription fee to download and read the articles. It’s free Free FREE! For what Open Access means for the world of science at large, Google for the term and do some reading. Go ahead and peruse some of the debates. I’ll describe here what it means for me.

It means that my co-author and I paid a publication fee to cover the cost of reviewing and preparing the document for on-line publication. Some journals (Open Access or not) are free to publish in, and others require certain page charges. PLoS ONE follows the “author pays” model.

The “Dynamics of Wind Setdown” article is of general interest. I want oceanographers to read it, I want journalists to read it, I want high school students to read it. I want teachers, gardeners, Norwegians, mechanics, historians, kids, pastors, marketing directors, software engineers, physicists, Australians, poor people, airline pilots, retired people, shepherds, and checkout clerks to read it. I want you to read about the parting of the Red Sea. Skip right to Figure 8 if you want! I don’t want any barriers to readership. I want the paper’s exposure to be as wide as possible. And I can achieve that goal by opening up access.

Peer-reviewed articles are read by scholars, who cite previous research when they publish a subsequent study. The citation count is a measure of the impact of a paper – the importance that a paper has on its field. Open Access papers are supposed to have higher citation counts, so this publishing model will presumably be better for my career.

What Open Access means for you

Open Access means that you can make use of the material that we published. The content at PLoS ONE is licensed under a Creative Commons Attribution License. This means that you can use the article in ways described by the license, so long as you properly cite the authors and the journal. The idea behind the CCA license is that scholars’ work should be used and extended, with due credit given to the original publication. You don’t have to get our written permission. Please refer to the Creative Commons web site for further information.

Open Access means that you don’t have to pay $30 or even $15 to download the paper and read it. Your institution or library doesn’t have to pay thousands of dollar$ in subscription fees to get the document. You just have to click. That’s right, you simply have to click on this link. What are you waiting for? Click! Download and read it now!

I read Gary Taubes “What It It’s all Been a Big Fat Lie” in the New York Times in 2002 and it completely changed my perspective on dieting.  He came out with “Good Calories, Bad Calories” in 2008, and I recently re-read it to help me recommit to a low carb regimen. On page 454 he offers what he calls his “inescapable conclusions” based on fifteen years of research:

1. Dietary fat, whether saturated or not, is not a cause of obesity, heart disease or any other chronic disease of civilization.
2. The problem is the carbohydrates in the diet, their effect on insulin secretion, and thus the hormonal regulation of homeostasis—the entire harmonic ensemble of the human body. The more easily digestible and refined the carbohydrates, the greater the effect on your health, weight and well-being.
3. Sugars—sucrose and high-fructose corn syrup specifically—are particularly harmful, probably because the combination of fructose and glucose simultaneously elevates insulin levels while overloading the liver with carbohydrates.
4. Through their direct effect on insulin and blood sugar, refined carbohydrates, starches and sugars are the dietary cause of coronary heart disease and diabetes. They are most likely dietary causes of cancer, Alzheimer’s disease, and the other chronic diseases of civilization.
5. Obesity is a disorder of excess fat accumulation, not overeating, and not sedentary behavior.
6. Consuming excess calories does not cause us to grow fatter, any more than it causes a child to grow taller. Expending more energy than we consume does not lead to long-term weight loss; it leads to hunger.
7. Fattening and obesity are caused by an imbalance—a disequilibrium—in the hormonal regulation of adipose tissue and fat metabolism. Fat synthesis and storage exceed the mobilization of fat from the adipose tissue and its subsequent oxidation. We become leaner when the hormonal regulation of fat tissue reverses this balance.
8. Insulin is the primary regulator of fat storage. When insulin levels are elevated—either chronically or after a meal—we accumulate fat in our fat tissue. When insulin levels fall, we release fat from our fat tissue and use it for fuel.
9. By stimulating insulin secretion, carbohydrates make us fat and ultimately cause obesity. The fewer carbohydrates we consume, the leaner we will be.
10. By driving fat accumulation, carbohydrates also increase hunger and decrease the amount of energy we expend in metabolism and physical activity.

Imagine that the President proposes new legislation targeted at the problem of engineering safety in deepwater drilling.  Imagine his legislation contains five provisions:

1. Require that all deepwater wells have a relief well in place before production begins.
2. Mandate requirements for double piping and a list of other industry engineering best practices.  The prior best practice for engineering safety becomes the legally mandated minimum.
3. Mandate that each deepwater drilling operation be insured for at least $20 B of environmental damage before production can begin.  Insurers will therefore require further engineering stringency to protect themselves.
4. Raise the legal liability cap for any drilling platform to $50 B, just to be safe.
5. All new wells must meet all of the above requirements, and all existing wells must cease production until they meet them.  (The details here might need some work.)

He makes this suggestion after offering the following analysis of current energy consumption usage patterns and the limits of battery technology:

If you are focused on carbon emissions, then oil, coal, and natural gas naturally group together as “fossil fuels” and are the combined source of the problem.  If you are focused on energy, then oil is one issue (transportation), and coal and natural gas are another (electric power).

We use almost no oil to produce power in the U.S., and electricity powers only a tiny fraction of our transportation, despite recent increases in hybrid and natural gas vehicles.  Yes, they’re growing at a rapid rate.  But the overlap between oil as one type of energy source vs. coal and natural gas as another is vanishingly small.

Someday when battery technologies improve, the fuel and power worlds will blend in the U.S., and there will be strong and direct economic relationships between the production of electric power and the use of oil.  Until that day, from an energy perspective, “fossil fuels” conflates oil with coal and natural gas in a way that is at best confusing and at worst misleading.  Substituting biofuels for oil or making vehicles more fuel efficient has almost no effect on the amount of coal or natural gas we use.  “Produc[ing] wind turbines,” “installing energy-efficient windows, and small businesses making solar panels” are quantitatively irrelevant to our use and production of oil.  All the windmills and solar panels you could imagine will not reduce our dependence on oil as a transportation fuel.

He has a great chart and more details, go read the whole post.

This is a good move for Colorado. The Pac-10 is a great conference! In college football, the Pac-10 has a lot of great west coast teams, with exciting offenses and tough defensive squads. UC-Berkeley was always a great game, UCLA is tough to get by, Washington usually has lots of talent, and the Arizona fans in Sun Devil Stadium made for a deafening contest whenever Stanford played there. USC was always tough (sometime too tough), but Stanford football has earned some wins and ties against Southern California. The other athletic programs provide worthy competition, too – baseball, basketball, water polo, tennis, and so on. It will also be good for CU to join the stellar academics of the Pac-10 schools (Stanford, Berkeley, University of Washington, UCLA, etc.).

For Colorado sports fans, the Pac-10 schools are wonderful places to visit. Oregon is the most beautiful state in the country when the sun’s out. Seattle is a kick! Southern California is a fun place to spend a few extra days visiting Disneyland or going surfing. When in the Bay Area during fall, head to San Francisco and on to the wine country! San Francisco is the first big city I ever enjoyed.

During my senior year at Stanford, before I had ever visited Boulder, I remember a guy from the Stanford radio station telling me what an amazing place Boulder is when he traveled here for a rare Stanford-CU football game. So I came. I’m still here.

I don’t even know who I should root for! Undergraduate ties to the school’s athletic program are usually stronger, but I have been steeped in local football enthusiasm for decades now. I’ll go to the first Boulder game and just let the competitive juices flow where they will.

To all those Pac-10 students, fans, and alumni I have this to say: Come out and see us! Boulder is a great place to visit in the fall. Spend a few extra days in the mountains, hang out on the Pearl Street Mall, drive over the Trail Ridge Road before the snow flies, go skiing after the snow flies, have a meal at the Dushanbe Tea House and ask some local to tell you the real history of the place, or bag a Fourteener!

We’ll give you a good football game and send you on home, tired but happy.

They noticed that the water coming into their little lake was murky with silt, while the water seeping out through the gravel was clear and clean. “Yep, you guys have built a sediment trap“, I explained. “The fast-flowing river water carries dirt with it, but in the calm lake water the dirt drops out to the bottom. That’s why it’s called a sediment trap, because the river sediment can’t get past the lake.” “Wow! We built a sediment trap!” they exulted. “Sediment trapping is a big problem for silty rivers like the Colorado and the Nile“, I elaborated. “The Glen Canyon Dam and the Aswan High Dam trap the river silt and prevent it from flowing downstream. That’s why the Grand Canyon and the Nile Delta are losing their sand.” [Yes, sometimes I talk in html.] The boys were thrilled to hear the world-wide implications of their little experiment.

After the rain we put the gravel back around the mailbox and washed our hands. And I thought to myself, What a great neighborhood / country / life I have! My kids can play safely in the yard, forget their video games, get dirty, have fun, and learn about fluid mechanics all at the same time!

1. When a developer thinks he/she is done with a single code module (one source code file), that developer calls for a code review. The broadcast e-mail and meeting invitation must go out no less than 48 hours before the scheduled review, so the other developers have at least 48 hours to look over the code before the meeting. You can schedule a code review for 3:00 pm on Thursday as long as you click on the Send button by 2:59 pm on Tuesday (and there were a few of those).
2. The software developer can invite anyone they want to the review, but at least one participant must be at the Senior level. Go ahead and invite your friends! There was some worry about people only inviting people who would be favorable to them, but we quickly learned this principle: Friends don’t let friends write bad software. You are more likely to accept constructive criticism from your friends than from people you don’t get along with.
3. A quorum is three people: the developer and two other software engineers, one of whom must be at the Senior level. The code review works better with about 4-5 people.
4. The code file to review must be less than 1,000 lines long. Generally the other developers retrieve the code from the repository.
5. The meeting will not last longer than 1 hour. If the code review runs overtime, the participants adjourn and re-schedule.
6. The goal of the code review is to improve the code. All our jobs depend on producing and marketing high-quality software, and it is in everyone’s best interest for the code in the repository to work well and be easily maintained.
7. Everyone is nervous at first about their work being reviewed, and for this reason there is a Moderator. The moderator makes sure everyone stays on track, watches out for criticism that is not helpful, and ensures that the experience is professionally positive for the developer. The moderator has the power to kick someone out of the meeting if they are being arrogant or derogatory. I never saw that happen, though – usually it is enough to remind someone that the goal of the code review is to improve the code.
8. Everyone at the review sits around a table with a listing in front of them. The listing is printed with line numbers for easy reference. The developer begins with a brief explanation of the purpose of the code.
9. The developer leads everyone else through the code, page by page, or subroutine by subroutine. Everything is fair game for improvement. The reviewers speak up in they have comments on a certain section. If not, the review moves on.
10. It is great for less experienced programmers to attend! They can learn a lot from someone else’s code. Often they make very worthwhile contributions by requesting more extensive comments for some algorithm that is not clear. Sometimes you get people who just watch out for uniform spacing or lines longer than 80 characters. Those people contribute something positive to the process.
11. Everyone looks for adherence to the coding standards.
12. Sometimes design flaws are caught in a code review. The script has to sanitize input for web security. The code has to handle Unicode characters. Sometime a subroutine is just too long!
13. Reviewers can suggest tests that might produce a failure, if they suspect a bug. The developer makes a note of those and will verify later that the software operates correctly, or fixes the bug if it does not.
14. If extensive changes are requested, then another code review will be scheduled when the first round of changes are complete. This is rare. Even if there are lots of comments, usually the revisions take only a few days to complete.
15. After the review: When the developer completes the requested changes to the software, he/she adds a note to the header comments of the file saying that the code was reviewed on that particular date by the following people (full names). Then the developer may check in the code, and move on to another file.

The developer under review gets completed feedback in 49 hours. I’m sure our loyal Funmurphys readers can add to this process and improve it. Tweak it for your organization. Remember that the primary purpose of code review is to improve the code. A secondary purpose is to provide on-the-job training for the more junior programmers. From time to time people will see a clever way of doing something, or suggest one, and notice code overlap that can be eliminated.

Those should be reasons enough for any professional software developer to conduct code reviews. But suppose you are out there thinking, “I’m a good engineer! I’ve written code for years, it’s well tested, and there are only a few minor bugs in my work. I’m good! I don’t need code review. It’s just a waste of my time.” Yeah, you’re kind of arrogant, but you have a right to be.

Here’s why you should request and schedule code reviews on your own code. Because someday, when you least expect it, someone else will come along and have to maintain or extend your code. And yeah, they won’t be as smart as you. They won’t understand your brilliance. They won’t take the time to read through your code and figure out how it’s carefully designed to work. What they will do is go to your boss and say the following: “This code that YourName wrote is dog poop! (but they won’t say ‘poop’)! I can’t follow it at all. This code has to be completely re-written!”

Then your boss will be faced with a dilemma. She knows you are a good software engineer and you write good code. She has not heard any problems with your code until now. But the new person is so insistent that your code is dog poop, that it has to be thrown out and re-written from scratch, and the new person uses lots of CAPITAL LETTERS and exclamation marks and derogatory language in his e-mail complaint. I have seen this happen. What should your boss do?

Your boss has to evaluate the complaint. Your boss has to examine the code you wrote with a fine-toothed comb, checking if you are correct or if the new guy has some validity to what he says. Your boss has to call a technical review at which your detractor will be the star witness. You can’t defend yourself very well since you have moved on to another part of the project. You’re under suspicion. Unless . . .

Unless there is a short section in the header saying the following: This code was reviewed on March 28, 2010 by the following people: Ashley Adams, Bob Biltmore, Charlie Chang, and Debbie Dumas. When your boss finds that comment in the code, her course of action is simple: “Sorry, Mr. New Guy, but this code was reviewed by the software development team and found to be acceptable. You can suggest some improvements, but we are not throwing it out and re-writing the whole thing from scratch. If you cannot understand some else’s code, we will send you back into circulation and hire someone who can.”

Yes, code reviews can be held to Cover Your Anatomy. It’s not a great reason to do them. If the good reasons above are not sufficient to urge you to do code reviews, perhaps this bad one will. Enough said.

Now let’s turn back the clock 400 years to post-Elizabethan England, during the reign of King James I. He decided to produce a new translation of the Bible, the Authorized Version that would bear his name. Alister McGrath has written a great book about this period, which you should stop reading this blog to go out and buy, then come back here. The book is “In the Beginning: The Story of the King James Bible and How it Changed a Nation, a Language, and a Culture” (2001). The translators worked in teams. On page 187 we read this account of the actual translation process:

The translation in King James’ time took an excellent way. That part of the Bible was given to him who was most excellent in such a tongue (as the Apocrypha to Andrew Downes), and then they met together, and one read the translation, the rest holding in their hands some Bible, either of the learned tongues, or French, Spanish, Italian, etc. If they found any fault, they spoke up; if not, he read on.

When I read this excerpt I laughed out loud. These guys are doing a code review! They used the same process 400 years ago to produce a good translation of the Bible that we use in modern times to produce good software! They all sat around a table and checked up on each other’s work. When the King James translators found a discrepancy, they worked together to resolve the problem That’s just what we do, too! I am sure that nobody at Smarttalk or any other software company set out to emulate the King James Bible scholars. But we have hit on the same process to produce a high-quality product.

This does not mean that the King James Bible is a perfect translation; the McGrath book documents a few errors that were corrected later. Another example is Hebrews 11:3 in the King James Version, which reads as follows: “Through faith we understand that the worlds were framed by the word of God, so that things which are seen were not made of things which do appear.” But the Greek word used for ‘worlds’ there is Aion (Strong’s Concordance G165), and should be translated into English as ‘eons’ or ‘ages’. God’s word of command caused huge spans of time to come to pass, as well as physical worlds. The KJV is not perfect. Nevertheless, if people are still using my code 400 years from now, my descendants should be very proud!

Maybe someday I will compare and contrast the process of code review with the peer review conducted by scientific journals.

Remember:  occasionally, it may be an interesting question to ask why a man says what he says; but whatever the answer, it does not tell us anything about whether what he says is true or false.  We take no stock in the cheap political device of political warfare — unfortunately too common also  among economists — of arguing about a proposition by attacking or extolling the motives of the man who sponsors it or the interest for or against which the proposition seems to tell.

———————  Joseph Schumpeter in a History of Economic Analysis (Its cheapness must be why it’s used so much)

So now I watch the action and fast forward thru the commercials.  Tomorrow, all will be different – I will watch the Superbowl live and I’ll be tempted to ignore the action and watch the commercials.

My daughter in Middle School is taking a field trip to Washington, DC over Spring Break. They will tour our nation’s capital with American Christian Tours, a tour company that emphasizes our Christian heritage throughout history. She earned part of the money for the tour, and I am making her study up on the places she will visit. When she gets to Gettysburg Battlefield she will know who Pickett was, why and who he was charging, and what happened on that fateful day. When she tours the World War II memorial she will know who were the major powers and leaders on each side of the conflict. When she enters the American History Museum she will tell her friends to look for the half-naked statue of George Washington.

All this is normal.

The strange part for me is that she and the rest of the kids are boarding an airplane to fly to Washington, DC. An airplane! We live in Colorado, so Washington DC is too far to drive over the one-week break. It makes sense to fly. But an airplane??!!! For a Middle School field trip? Sheesh, next thing you know these kids will be taking a field trip to the International Space Station!

I grew up in New Jersey, and my class took field trips by bus to Philadelphia and New York City to see the sights. The historical sites were within easy reach. On the Circle Line ferry around Manhattan Island some elementary school kids from the city challenged us to fight: “Get your gang together. We’ll meet you in the boys’ room!” Remarkably, we were mature enough to laugh, politely decline, and ask them where they were from? They were fun kids once we got past the macho thing.

An airplane!

Perhaps Sean call tell us if airline travel has dropped in cost relative to the Consumer Price Index since the 1970s? In any case, this Dad has to let go and realize that times have changed and let my precious daughter fly to Washington DC for a wonderful and educational adventure with friends I know and teachers I trust to take good care of her. It should be a good trip! She’ll bring her cell phone with her. Oh yeah, you bet she will!

Ten years ago today I was working from home, since I was an independent software developer back then. This was The Day that the dreaded Y2K bug was supposed to hit. The End Of Civilization As We Know It, or just TEOCAWKI for short. Remember?

A number of social commentators were predicting that the Y2K computer bug would cause large-scale failures in our computer-based infrastructure, including some Christian conservatives like Michael Hyatt and Chuck Missler. Ed Yourdon predicted that computer systems administrators would head to the hills en masse because they realized that the problem was huge and couldn’t be fixed. My local hardware store carried large electrical generators with signs saying: “Don’t even think of returning this on January 5 if Y2K turns out to be a bust! We’re onto you.” There were tales of survivalists cashing out their retirement accounts, buying a ranch in the mountains, stockpiling guns and ammo, taking their wives and children up to the compound after Christmas, and keeping a loaded gunsight out for looters when the millennium sun peeked over the horizon. Even modern cars weren’t supposed to work. Remember all that?

As a software engineer, I issued my own prediction in March 1999: Y2K will be no worse than a hurricane. Power and basic utilities will be restored within 48 hours. You’ll be able to go back to work in a week. My prediction seemed pretty mild at the time.

I had a plan, too. I stockpiled about one week’s worth of food, water, and firewood for the “hurricane”, taking care to be sure that anything I bought could be used later for camping trips if Y2K fizzled out. Partly it made good sense to be prepared, partly I was fascinated by the social aspects of worried people getting ready for TEOCAWKI, and partly I wanted to reassure those around me. I still have some extra jugs of drinking water and a few packs of candles and lighters left over. All the Ramen noodles and beef jerky are long gone.

During the summer and early fall I received lots of letters from my bank, my insurance company, my utilities, my retirement company, my post office, all declaring that they had been certified as “Y2K Compliant”. Then in November I got a letter from the supplier of my diskette mailers, saying that they were certified as Y2K Compliant and that the supply of diskette mailers would be uninterrupted by the dawn of the new millennium. I just stared at the letter. Diskette mailers. It’s come to this, probably the most trivial and non-essential item that I purchase. That’s when it hit me that Y2K was gonna be a big bust. The alarmists were wrong. Everything’s going to be all right.

New Year’s Eve fell on a Friday that year, leaving an entire weekend for the computer people to fix whatever problems they found. Ed Yourdon was wrong – the computer system administrators (my friends and colleagues) behaved like the responsible professionals they are, working all that weekend to run tests, re-boot machines, and examine diagnostics for signs of any technical Y2K problems. The weather in Colorado was unusually warm.

I filled up all the bathtubs in my house with drinking water. I remember thinking, “Why should I do this? It’s just a waste of water. Nothing bad is going to happen.” But filling up the bathtubs was Part Of The Plan, so I did it anyway. That evening I discovered that the drains in my tubs didn’t seal very well, and I had lost about half my supply already. The best-laid plans . . .

Since I was working from home, I could keep an eye on the TV. Midnight and the Millennium Dawn were sweeping around the globe. The celebrations were wonderful to watch! In Australia they had trapeze dancers swinging from ropes affixed to the top of the Sydney Opera House. Japan had marvelous dancers and costumed performers. China had spectacular fireworks! Then came Thailand, India, and celebrations in Africa. A few minor problems were reported, like weather maps that displayed the year 19100 and some video rental fees not calculated correctly. But everything was coming out fine, even in Italy who had not done much to prepare. I just relaxed, let all the technical concerns slip away, and watched in wonder as the happy festivals spread around the globe with the coming sunshine. Wow!

Praise God! Happy New Year!