Recently I was building a simple web application form where one of select boxes was driven by the value of a different box. The original code for this seemed pretty straightforward, but while the code worked perfectly in Firefox and Chrome, it was producing amazingly strange behaviour in Internet Explorer. Namely, when I’d rebuild the select box, IE would not position the text correctly inside of it, the dropdown wouldn’t appear reliably, and when it would, it wouldn’t necessarily show the correct text for the selections. In one case it was actually displaying four selections, when there were in fact only two. You could use the keyboard to select the values correctly, but this was still absolutely unacceptable behaviour.

I’ll do a write up on the behaviour later this week, but I decided to jump the gun and present the solution I developed first, since I don’t have good simple examples just yet. I ended up trying several ways of creating the options before appending them to the select element, but eventually, I had to completely recycle the selectbox in order to make it behave correctly. I’ve had other pages that didn’t misbehave in quite this way, so I’m trying to figure out the minimum case to recreate the problem before I send it to Microsoft.

Luckily, JavaScript makes it pretty easy to branch code based on browser in a way that doesn’t require doing the browser check all the time. Below is a generic version of the function to do the replacement, which includes calling a ‘change’ event handler, which unfortunately can’t be anonymous (at least in YUI3) since ‘change’ events can’t be simulated. Actually, having to rebind the changeeventhandler every time you change the contents of the select box is the only possible ‘challenge’ in the problem.

The non-IE version is a couple of hundred bytes lighter, and should be faster (though for most use cases, the difference is likely negligible). I’m not sure yet what the increased garbage collection load of this will do to IE, but in my case, that’s not likely to be a problem.

Compact Fluorescent Lights and the Environment

| 1 Comment | No TrackBacks

I’m highly interested in the ‘Green’ movement and the things that we are supposed to be doing that will help mitigate humanities continued impact on the ecosystem. However, I question a lot of the things that the green movement pushes, which sometimes seem like they might cause more damage over the long term than less. For instance ‘compostable’ plastics, which tend to be made from soy. I suspect these plastics require a lot of water in the processing, which very likely negates any benefit to them being able to avoid the landfill (though most almost certainly end up in landfills).

I’ve felt similarly about Compact Fluorescent (CFL) Light Bulbs for a while, knowing that the cost of production was going to be dramatically higher than for traditional incandescents, but being unsure that the energy savings in use would be enough to make up for it. Then, I saw one of the best written contributory articles to our local co-op newsletter, which for those who download the newsletter at the previous link, can find on page 36 of the PDF.

The article in question looks at this issue in a pretty complete way, presenting several interesting statistics:

  1. Making a CFL takes 5 times the energy of an incandescent, but you’ll need 6-10 incandescents for each CFL.
  2. The energy output of incandescents over a single CFL would require generating 200 pounds of carbon over the life of the CFL.
  3. A CFL contains ~5mg of mercury, and powering that bulb with coal (over it’s life) generates another 2.4mg of mercury into the environment, however, Incandescents would require 10mg of mercury output from a coal-fired plant. This is further mitigated by the relative ease of recycling CFLs.

Now, here in the Pacific Northwest, mots of our energy needs are met by hydroelectric, not coal, but still the proven energy savings of the bulbs have kept them an attractive option, but it’s nice that the statistics show that this is actually a real improvement we can make, that’s not only ‘green’, but saves money as well.

In many ways, I’m more interested in LED lighting, though it’s hard to find in the stores. LED bulbs have the potential to be even better over the long term than CFLs, Currently, LED bulbs last 5 times longer than CFLs, use less than half the energy, but cost about 10 times more. However, what I don’t know is how that translates into their production impact. Still, it’s an interesting technology I plan to watch.

Introducing gallery-slideshow for YUI3

| No Comments | No TrackBacks

Recently, at work, we had a desire to update an instance of a flash-based slideshow widget on our commencement website. This widget did absolutely nothing special, but the real problem we had was that, we didn’t actually have a license for Flash, and the way the slideshow had been built, we needed to be able to build the SWF file from scratch in order to update the order. Since our users rarely come to us with anything that isn’t some sort of emergency, we had to take the flash files to another department to make our quick change and compile a new SWF.

Of course, I knew there was no reason to continue to use unconfigurable Flash for this, but YUI didn’t have a slideshow widget. So, I decided to start writing one. Due to the excellent widget framework, I had a quick-and-dirty example written in a mere couple of hours. Of course, that was not something I was really going to release, though I did push it up to my github.

It was about a week before I was able to return to the project, but I have now submitted a very basic, but functional widget to the Y! CDN.

The javascript to run the above slideshow is simple, for the user:

The CSS that it requires is straightforward, and is part of the widget’s assets:

The widget will automatically take care of placing the images in the upper-left hand corner of the widget’s content box, as well as cycling through all the images using the transition sent in via the animation configuration option.

The core of slideshow is mostly done at this point. I plan to add support for the an image to transition in, instead of only having the top image transition out. Most functionality will likely be added via the plugin framework. And I have several plugins planned.

  • Titles - Adds the widget header which will be populated with the ‘title’ value from the images array.
  • Descriptions - Like Titles, but in the footers. I’m thinking this will take either a string or a function to generate the content of the footer div.
  • Image Centering - This will center all the images in the content box, allowing the slideshow to consist of images of different sizes.
  • Image Navigation - Buttons (probably images with click events, but you get the idea) which will allow the user to force transition between images.

The plugin framework is great because it allows you to customize a widget with exactly the kind of features you need. There are a lot of other kinds of plugins that would be appropriate, and I’m certainly open to feature requests, or pull requests would be better!

Integrated Circuit Design as a Game

| No Comments | No TrackBacks

Saw this on the Make Magazine Blog today, but it’s a little game called KOHCTPYKTOP, which is Russian, and loosely pronounced ‘Constructor’. It’s centered around the idea of creating simple integrated circuits by laying metal and silicon down on a design surface and running them against expected voltage readouts.

This is a great little puzzle game, and I know that if you’ve any interest in electronics, you’ll probably enjoy it. When you’re not pulling your hair out in frustration that is…

The USDA is currently accepting public comments on the issue of allowing a Genetically Modified Alfalfa plant developed by Monsanto, which could, by the USDA’s own research, infect organic alfalfa farms, potentially causing them to lose their ‘organic’ labeling. Needless to say, many people are upset about it, not the least of which are the people at Food Democracy NOW!, who want your comments. Now, this product has made it past USDA environmental review, that, in theory, shows that the environmental impact of this GMO crop will fall within acceptable levels, however those are defined.

FDN is calling this something that ‘threatens the very fabric of the organic industry.’ Now, I think that battle was lost years ago, when Organic was defined in such a way that the biggest players in Organic are companies like Kraft and Heinz, but the real issue here, in my opinion, is the danger of these GMO crops. Not that they’ll cause health issues with those who consume them, but rather the danger to the ecosystem, particularly when you look at the docket and realize that this GMO is only meant to be herbicide-resistant. A so-called ‘Roundup Ready’ crop.

It is the nature of agriculture to support the cultivation of certain plants at the cost of others, however, with these ‘roundup ready’ crops, it encourages wholesale dumping of these chemical plant-killers in manners that don’t necessarily control the application of the chemical very well, which can kill plenty of plant life that is found in areas external of the GMO crop, further reducing plant diversity (and most likely insect/animal diversity by extension) in those areas. Plus, since the plant has been modified to be difficult to kill, when it does spread to non-GMO versions, it becomes impossible to seperate the GMO version from the non-GMO version, further reducing biodiversity. It is this cross-breeding between GMO and non-GMO life, and the fact that the non-GMO life is almost guaranteed to be the dominant form over time, that worries many ecologists.

The monoculture present in modern agrictulture is already worrying, but has, until recently, still been based on traditional selection, with change in an organism happening slowly over many generations, based solely on selecting traits based on what was most desirable in the current generation. With GMOs, we can greatly change very fundemental things about an organism in a single generation, and the question that hasn’t been answered in a manner that is acceptable to macroecologists is if it’s even possible to do that in a way that doesn’t have potentially expensive ripples. I suspect that the answer to that question is that no, we can’t have GMOs that don’t have a severe impact on the ecosystem around them, and I don’t think we’re ready to be excercising those changes.

Blocking "Domain Smacks" in Apache

| No Comments | No TrackBacks

Recently, some intrepid person decided to buy uwrejects.com and have it show Washington State University’s website. Frankly, I thought it was pretty amusing, but there were a fair number of concern by certain excecutives at the institution. However, it did seem to remind me of the concept, of the “Domain Smack”

Alright, sorry for the ad (I’m not even getting paid for that), but it explains what the hell a domain smack is.

So, what do you do when some jokester decides to domain smack you, and you (or your boss) is really concerned with it? Just a few rules with modrewrite, and you’ll be fine, on Apache at least. IIS and other servers can do this as well, and IIS can even import Apache modrewrite rules easily.

The syntax is fairly straightforward. Turn the RewriteEngine on (if you haven’t used it yet in the .htaccess file), check the Referer header (which is misspelled in the specification) for the smackingdomain, then rewrite ANY URL (the .+) to either return forbidden or redirect back at whomever has decided to make fun of you.

At the end of the day, WSU is seriously considering doing nothing. Which is good, because it’s better to have a sense of humour about such things. However, good mastery of conditional URL Rewriting rules are good to have, and I’ll probably do some more advanced stuff with it later, since the documentation lacks a lot of examples which could be really nice to play with.

As reported by the New York Times and Change.Org’s Sustainable Food Blog, researchers at the University of Toronto and Washington University have devised a means to make mammals insensitive to pain. So far, they’ve only worked on mice, but the protien that they’ve genetically engineered away from the mice is common to pretty much all mammals.

The writers reporting on this are discussing the development due to how it could impact commercial animal production in the US, which is rife with animal cruely abuses, like veal production in boxes, or docking of pigs tails to keep them from biting each other’s tails. The argument is that by making the animals insensitive to pain, they are no longer as effected by the unpleasant conditions in which they live. Of course, it could cause issues with the animals not moving away from potentially dangerous situations because they are simply not bothered by pain. For instance, part of the reason pigs tails are docked as so that they’ll fight back if their tail gets bit. Without sensitivity to pain, they’re not likeyly to fight back, which raises the threat of infection to the animal.

However, the biggest problem is that this research, while interesting, wouldn’t actually solve the problem. From an animal rights perspective, it probably encourages even more egregious abuses, since poor handlers will likely be rougher with the animals than before, simply because the stimulus they were providing is no longer effective. Plus, how does the lack of perception of pain make the actions any less offensive? But ignoring the issue of animal rights and cruelty, this solution does nothing to solve the problems that modern commercial animal production causes elsewhere.

The environmental impact of CAFOs? Could get worse, since the animals insensitivity to pain encourages even higher densities. Which encourages greater centralization. Which increases the food safety risk. While the removal of this protien is unlikely to have any negative health effects on it’s own, and animal breeding is easier to control than plant breeding, there isn’t much risk of some of dangers of genetically modified food that are often raised, but the most likely end results of this technology are highly negative.

The research is interesting, and the knowledge of the mammalian pain experience could be used to generate some new pain treatments. However, as a technology with reasonable application in modern commercial animal production….I don’t see it. And I see it making things worse.

Hacking MSTest out of Visual Studio

| No Comments | No TrackBacks

For a while, we’ve been using Hudson as our Continuous Integration server for a while now, but we had a problem where the unit tests we had written were all in MSTest. However, MSTest doesn’t like to be installed without all of Visual Studio. Luckily, Mark Kharitonov at Shunra has figured it out and written up a post about it. I’ll only note two things I had to do to make his solution work:

  1. I had to add the VS2008Stub\Common7\IDE folder to the global PATH so that mstest.exe could be found (and restart Hudson so Hudson would update it’s PATH)
  2. Hack MSTest to allow me to use the /testmetadata and /testlist options.

I had to do #2, because the MSTest plugin for hudson seems to only want a single TRX file, which would have required me writing a bunch of MSBuild stuff I didn’t feel up to writing so that MSTest would run once for the entire build, instead of once per Test DLL file. By using the /testmetadata option, I can set up a vsmdi file and tell it which tests to run, which also provides me the added benefit of disabling certain tests that I might not want to run for some reason or another. In my case, I had a few tests that went against the database that really need to be rebuilt using a Mocking framework. They can’t run on the CI server (the CI server doesn’t have access to the Database), but they have some mild use currently on my local machine, so I don’t want to simply exclude them.

Anyway, MSTest, it turns out, actually checks your Visual Studio license to determine how it should function. Basically, it offers a few more options if you have a Visual Studio license, and a few more options if you have a Team System license. We don’t have Team System (or we’d probably be using Team Build anyway), but we do have Visual Studio licenses. Of course, they don’t tell you that the binary does different things based on a registry key, that’s what my good friend .NET Reflector is for.

Due to the fact that Reflector actually displays disassembled code, code I didn’t write, and I sure don’t have permission to redistribute, I’m going to gloss over what exactly I did to figure out what to do in the next paragraph. I’ll likely put together a new post in the future about hacking .NET using Reflector, but it will be on non-encumbered code.

It turns out there are five special codes that MSTest looks for to enable or disable features, namely the Test List Editor (what I was interested in), Team Developer Tools, Tfs Integration, Remote Execution, and Authoring Non Core Tests. I’m not entirely sure what those last four are (though I plan to investigate), since as I said, I only really need the first one. Interestingly enough, the way they’ve implemented this security, it’s a pretty simple hack to enable the ones that you aren’t licensed to use. Which wouldn’t be the right thing to do, which is why I’m not providing those codes, or even the actual location of the codes you shouldn’t have, to you, my reader. I’m covering my own ass.

Open up Regedit on your development box, and point it to HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\Licenses, and you’ll see a list of keys (probably only one, but it could be more than one). Export the keys you see under this hive, and then import them into your CI server, and it should automagically unlock the features you were missing on CI, check the /help output to be sure. Note: On a 64-bit system, the Hive is HKLM\Software\Wow6432Node\Microsoft\VisualStudio\9.0\Licenses. Just make sure you export and import to and from the correct location, if there is a difference in bit-width between your two boxes.

Now, you should have all the MSTest features you had on your development box on your CI box, and you didn’t have to do a full install of Visual Studio in CI.

Copying Files out of the Windows GAC

| No Comments | No TrackBacks

Sometimes you need to get a file out of the GAC on Windows, either to look at in someting like .NET Reflector, or maybe to copy a DLL (licensed, of course) to a server when you don’t need (or want) all the other cruft that the installer might drop on the box. I’m not going to judge.

GAC View in Windows Explorer

The GAC can be viewed on a Windows box by heading pointing Explorer to %windir%\assembly, but Explorer abstracts that folder away so that you can only do limited things with items in the GAC. They’ve even gone so far as to make it impossible using any of the GUI filesystem tools in Windows to navigate into the subfolder heirarchy. So, when faced with a GUI that just won’t cooperate, I turn to my trusty friend, the command line.

GAC Directory Structure from Command Prompt

Now, I can see the structure of the files that I’m looking for, and if I look back at the Explorer view, it even provides me clues on where to look. For instance, the fifth column, Processor Architecture, tells me which GAC_ folder I need to look in. For me, I’m almost always interested in GACMSIL. Once in that folder, there is a new folder for each unqiue entry in the Assembly Name column for the given Architecture, followed by a group of folders following the naming scheme {Version}_{PublicKeyToken} (that’s two underscores between Version and Public Key Token). Inside of this last folder, is my DLL, which I can copy out to another location.

For instance, System.Core, the core DLL for .NET that everyone has anyway, can be found at: %windir%\assembly\GACMSIL\System.Core\3.5.0.0_b77a5c561934e089\System.Core.dll

GAC Directory Drilldown from Command Prompt

Now that you know how to find the files, it’s trivial to copy them to wherever you need to, for whatever you’re looking to do. Of course, if you use this to break a license or anything else shitty, it’s not my fault.

BackTrack4 SD Card with Asus Eee PC

| No Comments | No TrackBacks

I’ve been watching Hak5 since it hit Revision3 last year, and I’ve generally enjoyed the show. Recently, host Darren Kitchen talked about creating a persistent Backtrack boot-able flash device. Since I’d be using this with my EeePC (or another laptop), I decided that the idea of running an OS off a thumb drive for any period of time was scary, so I decided to go the SD Card route.

Unfortunately, Revision 3 doesn’t provide good show notes for how this was done, Hak5.org is down, and Backtrack’s own page on a persistent USB drive is completely empty. The provided content is taken almost verbatim from Darren’s presentation on the linked video above, and I’ll embed the video after the instructions. I just felt that a write-up would be convenient.

  1. Download the Backtrack4 ISO
  2. Set up bootable media with Backtrack, either burn a CD, or a thumb drive using unetbootin
  3. Boot BT4, put your SD Card in your computer and find out what device it mounted as. Enter dmesg | grep hd.\|sd. at the command prompt, the bottom entries will likely be the correct ones. On my system, it was /dev/sdc so that’s what I use.
  4. Run parted /dev/sdc (I vary from Darren on this)
  5. Type print at the command prompt, odds are you’ll have 1 partition. Delete all the numbered partitions with the rm command.
  6. Create the first filesystem with mkpartfs primary fat32 0 2.5GB This will create a two and a half gigabyte, fat32 partition as your main data store.
  7. Make Partition 1 bootable with set 1 boot on
  8. Create Partition 2 with mkpart primary ext3 2.5GB 100%. This will fill the rest of the device with a empty partition. I used an 8GB drive, but the 100% will fill the rest of the drive.
  9. Exit parted with quit
  10. Run mkfs.ext3 -b 4096 -L casper-rw /dev/sdc to create the persistent area on the storage.
  11. Run mkdir /mnt/sdc1
  12. Run mount /dev/sdc1 /mnt/sdc1 to mount the first partition you created.
  13. Run rsync -r /media/cdrom0/ /mnt/sdc1 to copy all the files from the boot media to the boot partition. This will take some time.
  14. Rum grub-install --no-floppy --root-directory=/dev/sdc1 /dev/sdc to install grub on your sd card.
  15. Edit /mnt/sdc1/boot/grub/menu.lst in your favorite editor
  16. Change the line ‘default 0’ to ‘default 4’ to load in persistent mode by default.
  17. To the end of the kernel line for the Persistent Live CD option, add ‘vga=0x317’
  18. Shutdown and reboot.

EeePC Notes:

  1. My EeePC is an original 8G, meaning that it’s running a Celeron M, not an Atom, and it has the smaller (6”) screen.
  2. To select your boot device from the Eee PC Menu, hit the ESC key when the system starts to boot (these things boot fast, so hit it quick) and choose the ‘USB2.0CardReader’ option to boot from SD. If you’re booting from a thumbdrive and your thumbdrive has a U3 partition, odds are you’ll want the first one on the list. If it refuses to boot it, reboot and try the other.
  3. The system is currently booting into a text console for me, not the GUI. If I want the GUI, I can just type ‘startx’ and it comes right up. I’m trying to solve this issue, and when I do, I’ll update this post.

Find recent content on the main index or look in the archives to find all content.

Once You Know, You Newegg

μ-updates

  • No Updates!
OpenID accepted here Learn more about OpenID
Powered by Movable Type 4.21-en