Categories
Environment Government

EPA’s report on Keystone XL Pipeline

Today the EPA released a comment on the State Department’s draft report on the Keystone XL Pipeline. The conclusion states:

Based on our review, we have rated the DSEIS as E0-2 (“Environmental Objections-Insufficient Information”) (see enclosed “Summary of Rating Defmitions and Follow-up Actions”).

Environmental Objections is defined as:

The EPA reyiew has identified significant environmental impacts that must be avoided in order to provide adequate protection for the environment. Corrective measures may require substantial changes to the preferred alternative or consideration of some other project alternative (including the no action alternative or a new alternative). EPA intends to work with the lead agency to reduce these impacts.

The Category 2 insufficiency is further identified as:

The draft EIS does not contain sufficient information for EPA to fully assess environmental impacts that should be avoided in order to fully protect the environment, or the EPA reviewer has identified new reasonably available alternative that are within tbe spectrum of alternatives analyzed in the draft EIS, which could reduce the environmental impacts ofthe action. The identified additional information, data, analyses, or discussion should be included in the final EIS,

This all translates to, “Busted!”

Access the report directly.

Categories
Critters Documents Legal, Laws, and Regs

The Dollarhite Rabbitry FOIA Results

A few years back I came across an article about the Dollarhites in Missouri and their little bunny business. According to the article, the Dollarhites only started raising bunnies to teach their son responsibility. It was, at most, a small, casual business.

In 2011, the Dollarhites were outraged to receive a notice of violation from the USDA, with a fine of $90,643. There was a lot of huffing and puffing about government overreach in the article, but I had enough experience with the USDA APHIS to know there had to be more to the story than was being told. I decided to file a FOIA request for all documents related to the case.

The USDA informed me that the investigation was still ongoing and they couldn’t provide me most of the documentation. They did, however, provide me a few documents, one of which I had already discovered for myself: that the Wayback machine had archives of the Dollarhite bunny selling operation as far back as 2006, not 2008, as the Dollarhites claimed.

Eventually the Dollarhites got Missouri politicians, including Claire McCaskill, to intervene on their behalf—something I wish politicians would not do, because this just leads to inconsistent applications of the law (a law created by Congress, I want to note). Especially when a little research on McCaskill’s part would have demonstrated other interesting documents associated with the case:

  • Rather than a casual operation, the Dollarhites were selling bunnies to a petting zoo in Branson, as well as a pet store. In one year, they sold over 4000.
  • An early investigative report notes Dollarhite was aware of AWA licensing, and gave the investigator the impression he was going to continue breeding and selling pet rabbits without a license (doc)
  • An investigator noted Dollarhite’s seeming hostility to regulation, as well as her safety concerns (doc)
  • An internal USDA memo expressing concern about enforcement in the case, considering the circumstances, in this case, most likely the publicity and Congressional interference (doc)
  • Another frank, interesting look at the USDA’s view of discussions with Dollarhite’s attorney, who seemed to be less than aware of how the government operates (doc)
  • A disturbing note sent by Dollarhite to the USDA (doc)
  • A very disturbing note sent to the USDA with an implicit threat (doc)

Among all of the more colorful documents are investigative reports, documented proof, as well as several settlement offers extended to Dollarhite that would have let him off without a fine as long as he agreed to stop selling bunnies as pets without a license—something Dollarhite didn’t note as frequently as he noted that $90,000 fine.

When the Dollarhites settled with the USDA, the USDA was free to fulfill my FOIA request, and I’m listing the documents here for others to access.

As I said earlier: there’s always more to these stories than what you see on the surface. Thankfully, the FOIA allows us to discover the missing pieces.

I wrote three articles on the Dollarhites:

John Dollarhite and his $90,000 fine

The Dollarhite Saga

Dollarhites: A saga that should end

Access a listing of the Dollarhite FOIA documents, individually, or as one document.

Categories
Just Shelley

When UPS says “train derailment”

I received a notice from UPS on a package shipped from California. “Train derailment” was all it said.

So I have to backtrack to discover that a coal train derailed in Nevada on Sunday, damaging the tracks. The tracks weren’t fixed until Tuesday, which delayed all other trains using these same tracks. My package arrived in Kansas today, where it was most likely unloaded from one of the delayed trains. My package will probably be arriving Monday rather than Friday.

At least I now know my package isn’t one of many, strewed across some desolate wilderness somewhere amidst twisted and torn metal—most likely being pawed by bears or wooly men.

Categories
Specs

Response to a recent posting in Google+

Recovered from the Wayback Machine.

My response to a recent post in Google+ by Ian Hickson:

You’re comparing apples to oranges, +Ian Hickson. There’s a world of difference between developing a specific piece of software and creating a specification.

In addition, you’re also incorrect with your understanding of the ‘tech lead model’. You may have worked on a lot of specs, but I’ve worked on a lot of projects for a great number of companies. What you’re saying is, well, hogwash.

Typically, software applications are defined for one specific use: a business use with well defined and finite customers who provide detailed instructions (user requirements) about what they want.

The tech team meets regularly with the users, and the users—or the group of people representing the users—are the ones that have the final say on the product.

There is usually an overall architect if the project is large—but they don’t just think up what’s needed on their own, and attempt to tell the users what they want. And the architect doesn’t work in a vacuum. The data people are the ones responsible for data design, and others are responsible for other decisions, such as types of equipment to purchase and software to use. Then there’s the testing team, the user acceptance folks, the documentation people, and so on.

I’ve worked on a couple of systems, including support for Saudi Arabia’s air force defense system, where the numbers of people in the team number into the hundreds. Someone playing King of the Mountain wouldn’t last a day.

It is very much a team effort.

And many of these teams work really well. I’ve been privileged to work with great teams at Boeing, Nike, Sierra Geophysics (a Halliburton subsidiary), John Hancock, and various other companies and government organizations. One key thing about all of the teams is the understanding of the importance of each team member, that no one is King of the Mountain, and cooperation and mutual respect is the name of the game.

The problem with your comment Ian, and others of like nature, is you really don’t have much exposure in the real world. You really haven’t worked that many jobs for many companies. You’ve insulated yourself in a tech bubble and you seem to believe if you say something with enough surety and confidence, others will believe you. True, some do, but primarily only among others like yourself, who typically haven’t a significant exposure to real world development.

You’re all spec wonks.

Being a spec wonk isn’t a bad thing, and brings its own expertise to the table—but it definitely doesn’t somehow magically make you all capable of understanding what everyone needs.

Because you’re all spec wonks, it’s especially important to get feedback and input from others who do have the real world experience you lack. But you just don’t see that. If anything, you seem to hold real world experience against people.

“Oh, I’ve done more spec work than any of these people. What do they know about specs?”

They may not know the mechanics of how a spec is worded, they may not have a lot of experience building browsers, but they definitely know what works outside the offices of Mozilla, Google, Opera, Microsoft, and Apple.

You know what’s funny, but in the teams I worked with, the most important player was the end user. We used to complain—loudly—if we couldn’t get access to reps from the business end. We needed these people because they knew what the application needed to do in order to be successful. We wanted to create successful applications.

The browser companies, they’ve forgotten all of this. They cater to a small portion of end users—most decidedly geek—and have ignored anyone else in their push to Be First with the latest gewgaw.

They incorporate stuff into browsers now that make them insecure and decrease their performance, but it’s all Cool and Stuff, and that’s OK for the tiny audience they only seem to care about. The only problem is, in the real world, we actually care more about security, reliability, performance, and accessibility than if the browser is all Cool and Stuff.

You have users wanting to be involved. You have experts from other fields asking, sometimes even begging, to be involved. You have other techs with vast experience—real world experience—wanting to be involved. Yet you throw it all away. And then you brag about it.

Sad

Categories
Technology

Look out: Android in the kitchen

Recovered from the Wayback Machine.

I was a late comer to the legions of mobile device owners. However, when I finally crossed over with my purchase of the first generation Kindle Fire, there was no looking back. To the Kindle Fire has now been added an Android smart phone and other tablets —the number of which I’ll keep to myself, or I’ll mark myself an Android junkie.

I watch TV shows and movies on the devices, do most of my research on them (paging through PDFs is much simpler with a touch screen), scan products at the store for background information not listed on the can, navigate to new locations, and yes, play games. Where the crafty devices shine, though, is in the kitchen.

I have an old red binder filled with recipes (not *women) I’ve collected, modified, or created over the years. Recently, I purchased the Living Cookbook software to manage my collection, as well as back it up to Dropbox for safekeeping. What I didn’t want to do with the new software, though, was continue to use paper recipes. With paper, I’ll inevitably spill something on the page, and the large letter size paper actually takes up a lot of counter space.

What I needed was to transfer my recipes from the software to my Android tablet (my Samsung Galaxy Tab 2 7.0 inch tablet in this case—sorry Apple). Luckily, there really is an Android app for that (don’t sue me Apple).

I downloaded My Cookbook, a free/pay app that allows us to create our own cookbooks. Though the interface is rather primitive, what it lacks in gewgaws it makes up for by being able to parse recipe files from many cookbook software applications, including Living Cookbook.

The work flow goes as follows:

  1. Enter the recipe into Living Cookbook. Cry a little when I see how many calories per serving. Vow to eat less.
  2. Export the recipe in any of the supported formats. I use the Living Cookbook .fdx format. Ummm, XML. Long time no see.
  3. Create a synch folder on Dropbox using a built-in My Cookbook feature. Copy the exported recipe to this folder from my computer.
  4. In my tablet, import the recipe into the application and I’m ready to go.

I bought a little tablet stand at Amazon, so the device sits upright and stable on my counter (away from the oven and sink, of course).

When I’m ready to cook something, I pull up the recipe, gather my ingredients, and then follow the directions. I would prefer having both ingredients and directions on same page, but it’s simple to swipe the page to move between views.

If I’m feeling text weary, I can use the My Cookbook feature that allows audio output of the directions. For the most part, though, it’s easy enough to read the instructions.

Once the ingredient manipulation is complete, I can return to the summary page and click the little timer icon. This triggers another Android application that runs a timer, My Cooking Timer programmed with each recipe’s cooking time.

While the end product is boiling/steaming/baking, I can pick up the tablet and check my email, read an article using Pocket, or even make notes for my book using a speech to text application or sound recorder. The speech-to-text app ListNote sometimes results in an some interesting wording, but at least I have enough to work with.

None of the applications impact on the timer—an important feature, because I have been known to get distracted and burn things. Just to note: a smoke detector is not designed to be a food timer.

From a food safety perspective, the use of the tablet is a plus, because using it ensures that I’m washing my hands frequently so as not to smear up the device. Washing hands frequently while cooking is essential to prevent cross-contamination. Going from handling chicken to chopping lettuce can make an interesting science experiment, but not necessarily an enjoyable eating experience.

Of course, you don’t need an Android tablet to do all of this. You can use your iPad or iPhone—if you have money left over from buying the device to actually purchase food to cook.

Ingredients for Cooking in the Kitchen with Android:

  • Cloud storage helps when it comes to interfacing a PC to an Android to share data. I’m partial to Dropbox, primarily because so many Android apps support it. And it’s free for most uses.
  • You can input recipes directly using most Android cookbook apps, but I find an application like Living Cookbook to be simpler and more comprehensive. The key is the ability to export the recipe (unless the software has a comparable mobile app that supports your device, which Living Cookbook does not).
  • A mobile cookbook app, such as My Cookbook that allows recipe import and/or direct addition. Be careful when selecting an app. A cookbook app is not the same type of app as a recipe app, which provides access to existing recipes, but rarely allows you to input your own.
  • Timer software that either works with your cookbook app, or that you can use outside the application. The My Cooking Timers Android app works with the My Cookbook app. There are freeware and pay versions of both apps.
  • A tablet stand that makes it easy to read the recipe and that securely holds the tablet out of the way on the counter. If you’re clever you can probably make something.
  • Soap, water, hand towel—because egg and Android don’t mix.