Technical Details

The headline: Pythons Will Colonize U.S. 

Its global warming Al Gore’s fault!

See the link below for source and what is more or less a toy applet to demonstrate sniffing the MAC Address(es) of a machine from the browser. The HTML illustrates the simplest (albeit hackish) approach for cross browser support. I’ve tested this with FF 2.x, IE 5-7 and Safari 3.x on Windows, unfortunately Leopard doesn’t support Java 6 yet. This solution will only work with Java 6, I do no checking in the code for this fact, it’s a demonstration after all.

One thing is for sure, IE treats Java as a third class citizen, I’ve done some timings: FireFox averages  10.5 seconds to start the Java plugin (which is barely acceptable), but IE is terrible with an average startup time of 31.8 seconds this is after clicking through the two levels of dialog about how this applet is insecure and may destroy your system, “oh the humanity” of course this can be turned off, but the default for most folks is to try and scare the pants of you.

You can find the package and source here:

http://www.softwaresamurai.com/Agwego/mac/macaddressapplet-1.0.tar.gz

NOTE (2013-02-09):

For recent versions of Mac OS X, the applet won’t run as is due to changes in Apple’s Java security sandbox model. This may also be true for other systems and browsers. To have this work properly you will need to sign the jar with a code signing certificate.

 This is a good article on Merging and Branching in SVN 1.5

I generally agree with this article, except for the fact that developers should be applying schema patches in the course of regular development.

Managing change with your database yields a great many benefits. Since the schema change scripts are in source control, you can recreate your database as it looked at any point in time. Is a customer reporting a bug on build 3.1.5.6723? Pull the source code tagged or labeled with that version number and run the baseline, then all schema change scripts included in the tag. You now have the same database and have a much better chance to recreate the bug. Also, changes move from development to test, and ultimately into production in a consistent, orderly, and reproducible manner.

This is a bad precedent and if you get lazy and don’t apply the schema changes to the original schema you’re soon going to run into problems where the only source for table definition will be the database itself, a very bad situation for developers (that’s why you have version control in the first place, tag your schema changes) Yes you need these schema migration files for production systems and they of course need to be tested, but developers should always be building their development database from source and never applying schema updates unless they are testing them.

I recently finished working at a place where the DBA had set up such a scheme when I left there were 22 schema updates (that spanned 7 years) that had to be applied, in some cases the original table definition barely resembled the updated version and the updates were scattered through 22 different files truly brain damaging.

So in conclusion keep all your DB artifacts in separate files, for me that includes tables, triggers(rarely use them), indexes, stored procs, … I would go as far as keeping the schema changes in separate files based on the artifact they are responsible for updating, all relatively easy to script. ALWAYS UPDATE YOUR BASELINE with the schema changes.

They are still supported but Sun’s documentation has gone to pot. There’s almost nothing out there describing implementing applets with Java SE 6. Sure there are a lot of examples with 1.4, but the world has changed modern browsers and W3C have deprecated the applet tag, and if you’re trying to do something like interact with your applet via javascript there’s almost nothing discussing this and of course the old Applet tag is broken in “Modern” browsers, and although there are 20 examples they all seem to be toys with respect to Web 2.0, namely they are still using the applet tag, thanks for coming out.

Here’s what I’ve come up with for embedding applets and interacting with them via javascript, it’s a bit hackish but it has the cleanest/simplest code I could come up with.

    <!–[if !IE]> Firefox and others will use outer object –>
    <embed type=”application/x-java-applet”
           name=”mac_address_applet”
           width=”0″
           height=”0″
           code=”com.yourco.MacAddressApplet”
           archive=”macaddress.jar”
           pluginspage=”http://java.sun.com/javase/downloads/index.jsp”
           style=”position:absolute; top:-1000px; left:-1000px;”>
        <noembed>
        <!–<![endif]–>
            <!—->
            <object classid=”clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA”
type=”application/x-java-applet”
name=”mac_address_applet”
style=”position:absolute; top:-1000px; left:-1000px;”
                    >
                <param name=”code” value=”com.yourco.MacAddressApplet”>
                <param name=”archive” value=”macaddress.jar” >
                <param name=”mayscript” value=”true”>
                <param name=”scriptable” value=”true”>
                <param name=”width” value=”0″>
                <param name=”height” value=”0″>
              </object>
        <!–[if !IE]> Firefox and others will use outer object –>
        </noembed>
    </embed>
    <!–<![endif]–>

Once I’ve repackaged the applet which “sniffs” the first MAC Address of any interface on your machine, which I guess could come in handy from time to time.