design

10 Futuristic Materials

Accelerating Future » 10 Futuristic Materials:

1. Aerogel

Aerogel

Aerogel holds 15 entries in the Guinness Book of Records, more than any other material. Sometimes called “frozen smoke”, aerogel is made by the supercritical drying of liquid gels of alumina, chromia, tin oxide, or carbon. It’s 99.8% empty space, which makes it look semi-transparent. Aerogel is a fantastic insulator — if you had a shield of aerogel, you could easily defend yourself from a flamethrower. It stops cold, it stops heat. You could build a warm dome on the Moon. Aerogels have unbelievable surface area in their internal fractal structures — cubes of aerogel just an inch on a side may have an internal surface area equivalent to a football field. Despite its low density, aerogel has been looked into as a component of military armor because of its insulating properties.

[There’s nine more. Awesome stuff.]
Source: The Hole

Far Foods by James Reynolds

Far Foods by James Reynolds: James Reynolds’ Far Foods project is an alternative packaging for supermarket. It shows the distance that some foods travel from and the
resultant carbon dioxide released during the journey. The receipt features a boarding card style tear-off strip.

James Reynolds has recently graduated from Kingston University studying Graphic Design. He lives and works in London. (Copyright 2009 James Reynolds)

Via Designboom

[Nice idea!]
Source: The DesignAddict Blog

Where are the true believers?

Where are the true believers? – Good Experience: Or should we invest $50 billion in a new electronic medical record? That’s the proposal from the government, and I can’t imagine it changing anything. [I know they won’t for two reasons… and in this case I will stick to the computer tech of the situation. When I worked at a compnay that worked with hospitals, i saw first hand the mess that is many hospitals data infrastructure. I mean it’s really truly horrible. Monolithic, badly engineered hacks rule the day. I can imagine how it got there… but I blame the administrators who obviously invested the bare minimum in their infrastructure and now have a huge morass out of which to climb. Second is at a more personal level. I have a fine primary care physician. I trust him, he pays attention, knows the family history, etc. Because of the business side of the doctoring business he joined the equivalent of a conglomerate, which naturally centers their IT cost. All good, except they have a EMR system and when it fails to connect to the database (I wasn’t there as a tech, but as a patient) the system is worthless. No EKG or other tests. No access to records, no updates. Just a few simple paper pages to record new information that no doubt will have to be transcribed (with errors) by the staff. It’s 2009 for criminies sake… what the hell is that? No local storage? No syncing of records? What a freakin mess. And this from a major player in health care in my area. “Sucks” doesn’t begin to describe it…

BTW, as for the true believers… I think they’re there. I’m just not sure there’s enough of them where it matters.]

Workling, BackgroundJob, and some config file and UTC caution.

One of the features of the software I’m building is the ability to upload images and other binary files. Like so many other Rails apps we’re using attachment_fu. So far so good. We expected the “client” could pull these assets when they needed them and store them wherever they desired. And the developers rejoiced.

A follow up story required that we move those assets over to the website via SFTP. Since we use Capistrano I wrapped Net::SFTP (a Capistrano dependency). We wired it into the Model via after_save, and after_destroy, and again the developers rejoiced.

I decided to move the “hard coded” user, pass, etc. stuff to a config file, so created a YAML file and added the aforementioned sftp stuff, and some other application specific that was crufting up the place. I created an initializer to load the file, and again the… yeah, ok, you got it. Soon after there was some stuff that was environment specific so I created the 3 basic environment sections (development, production, and test) and moved along. I figured I could test for them in just one spot (for now) and all would be good. I’ve since had a change of heart, but no matter for now.

A short while later I accidently demo’ed the new transfer code with a very large image file, and was less than impressed by the way it went. Since Rails is single threaded (still, for the moment, although about to change as I write this) the file transfer absorbed copious resources on this somewhat long lived transfer. Genius that I am, I said we should run the transfer as a background process, and since I know we have other similar requirements coming up Real Soon Now(tm), decided to implement a queue as well. After looking around the landscape I decided on Workling and BackgroundJob. It looked like they would play nicely, and keep thing clean and straightforward.

In go the plugins, get things setup and migrated, create a worker class, and fire off the MyWorker.asynch_test_method. Cool! I see stuff in the database… hmmm nothing happened. I’m going to skip through the process at this point, and just discuss what we (I was pairing with Evan during most of this) found.

One of the recent changes in Rails (we started with 2.1 and have since moved to 2.1.2 as I write this) includes control over Time Zones. We had talked and played around with this a bit and decided that for our purposes UTC was just fine, and so left the default setting. Stuff in the database gets stored as UTC and when everything works as expected is converted to a local time setting, if you set one. Here’s the first gotcha. Since this is fairly new, folks have liberally sprinkled libraries with calls to Time.now(). Which is fine for what it is, but at least with the version of Ruby we’re using (1.8.6 as I write this) returns local time… but the database is living over in UTC land. I wouldn’t notice if my time zone was Greenwich Mean, but over here on the East Coast of the US there’s a five hour difference. So we hunted down (not for the first time mind you) the use of Time.now in the BJ runnner.rb an changed it to Time.now.utc. One bug down.

The next one was bug in the bj_invoker.rb that is installed by Workling in the script folder. Stuff happens (and a patch is being submitted) but there’s a bit of meta-programming going on, and it was hard to find the places where STDOUT was being nullified, and because it’s trying to act as background or async process, exceptions are being swallowed. So no significant logging, and no exceptions. In the end we patched the runner code in BJ to display STDERR and STDOUT, and we wrapped a method call in a begin/rescue in Workling to enable some exception logging at least in this common case.

Having done that we found our error, fixed our bugs, and watched everything work. And the developers rejoiced.

The lessons so far: Developers do not pay enough attention to time zones so watch for gotchas like how time is being stored in your database vs. how you test for time stuff. Secondly, only the main path will be well worn. All others will have bumps. Workling is commonly used with Starling and so using with other, even supported libs may be a somewhat more bug laden experience than one would hope for. This wasn’t too bad, but the process was methodically annoying and to a degree, orthogonal to our goals.

So… next we have the config file caution. So there’s this nice thing known as the Rails environment. It’s a beautiful thing as it makes it easy to separate development from testing and production. You can point each environment to a unique database. Excellent! You can change key settings about caching, and reloading of classes that makes development smoother and production faster. Yay! So what’s the caution? While those three are standard folks make up others. In addition to those three we have two others which are not common. They serve they’re purpose, but they’re not conventional.

Today I had a deploy fail. Hmm, that’s odd, they’re usually so smooth. Migration failed… nothing strange in there. Hmm there’s a couple of lines about config files… so what it turned out to be were two plugins that each rely on a config file. In one case the developers did the right thing and when they could not find a config file section that matched the environment, shut themselves down and wrote about it in the log. Excellent! The second was seriously hard wired to the config file, and so tossed an unhandled exception when it couldn’t find the matching environment section. Worse, the config file isn’t necessary for the setup we used, and the docs say it can be removed. (It can’t, for the same reason). So an unnecessary config file, missing an unnecessary environment hung my deploy. Sad. But it made me realize that I was missing those sections in my own little config file, so I added them in there as well, and have a card to rewrite the loading code to ensure that we always do the right thing if the environment section is not there.

A coupe more… it’s worthwhile in your Capistrano deploy stuff to be able to run migrations with –trace turned on. You should have matching environments on your development machine as you do elsewhere… I know I do… now. Lastly, as much as possible have a match to your production environment where you can make a mess without consequence. We use VMWare to slice up a hefty machine, and it’s a great tool for the purpose. It doesn’t hurt that we use Engineyard as our host and so can use the Express vm for testing.

Billykirk

123B_FRONT_OPEN1.jpg There’s a certain amount of synchronicity in my life. New things pop up in several places at once. In this case a friend with whom I often pass design ideas, sites, and writing sent me a link to the design of a token he liked, and another blog pointed me to Freeman Transport who making a fixie bike with S&S couplers and a bag to match. The bag looks like the work of Billykirk, which a few days I never would have known. There’s a link on the sidebar… cool.

Anyway, the designs are interesting, and I heard from Chris Bray when I wrote about a future product, and we’ve been passing design ideas back and forth. Cool. I love the understated simplicity coupled with handworked quality that seems to be the hallmark of their designs. Personally, I like the No. 123 Shoulder Pouch and from the Preview page, the item I wrote to Chris about the No. 206 ‘Green’ Giant Shopper. (Bergundy? Oh yeah…)

And to my biking friends, Freeman Transport will be selling the bag by itself.

merb-slices

merb-slices are “Little slices of MVC cake”. These are self contained merb apps with models, controlers, views and assets that you can distribute as rubygems. You can mount a merb-slice at a specific point in your router definition and you can override any part of the slice up in your main app. So in a way these are similar to what Rails-Engines promise, except merb-slices are built into the framework and will not break when merb itself is updated.

Check out the tutorial/screencast for a peek at how merb-slices work.

[Nice. Merb continues to impress.]
Source: Brainspl.at