Technical Details

This isn’t the first study I’ve seen on this topic of productivity is proportional to your screen real estate, but it dows put a price on this productivity.

Can you see your way to wasting less time? One new study says yes: Organizations that upgrade their employees’ standard-format monitors to widescreen displays can realize productivity gains equivalent to 76 extra work days a year per worker, as well as annual cost savings of more than $8,600 per staff member, according to a recent survey. (That math assumes a staffer who makes $32,500 annually.) 

CIO: http://www.cio.com/article/194501 

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.

If you ask me the Java installer is broken, at least from a usability perspective.

Here’s a breif list:

• You have to install demos and samples (I don’t want them installed)
• The installer spawns at least one other installer (this installer doesn’t pick up the path from the previous install, very dum)
• Even though you want to install things in some place other than  “Program Files” the  JavaDB is  installed there (idiots)
• If you grab the Java EE + SD, it doesn’t install the JRE, WTF, so I’m not going the other route install the JRE/JDK and then install Java EE
• I’m probably going to uninstall JavaDB and download the standalone installer to install it again (sheesh)
• The JavaDB (any platform) installer isn’t one, just a zip, somehow I find this more comforting (but the download page lists Windows 2000 as one of the options, what is this 1999?)
• Too many options on their download page Java EE/JDK Update 3/Net Beans blah blah blah http://developers.sun.com/downloads/

Sun, do yourself a favour (and everyone else at the same time) and get your act together.

I’ve become a big fan of vmware, but if you undersize a virtual disk and need to expand it on Linux, brace yourself for about an hours worth of work (at minimum.)

Here’s the process I eventually followed (this seems way too hard/complicated)

• BACKUP up your virtual machine!!!
• expand the virtual disk:

  vmware-vdiskmanager -x 16GB myDisk.vmdk
  

for instance this will size myDisk to 16GB (this size isn’t additive it’s an absolute size)

• Now you must boot your virtual machine into DOS or some OS that will recognize your disk, I went the BartPE route and added the vmware scsi driver so it would recognize the
  scsi disk. I couldn’t find the actual scsi driver on the web fotunately I had a copy of the VMWare Converter which
  contains a copy of the drivers. You can follow the instructions at this site but the driver that is offered is incomplete.
• Once you’ve booted BartPE start diskpart and issue the following commands:
  • diskpart> list disk
  • diskpart> list volume
  • diskpart> select volumen=n
  • diskpart> extend
  • diskpart> exit
• Reboot the virtual machine, restarting Fedora (or your brand of Linux)
• Start the Linux Volume Manager (lvm)
  • Find the physical volume with lvm> pvscan
  • Resize the physical volume lvm> pvresize /dev/sda?
  • Resize the logical volume lvm>  lvresize -L 14G /dev/VolGroup01/LogVol00
  • lvm> exit
• Finally resize your filesystem with (on Fedora, other brands of linux may have a different command):

root# resize2fs /dev/mapper/VolGroup00-LogVol00

• Sheesh, that was a lot of work, the procedure for windows seems slightly easier, but I couldn’t find all this information
  easily in one place for Fedora/Linux, good luck.

I’ve been doing a lot of date related things in Java recently, and having an independent tool to generate sane test data is very handy.

Try it here: http://www.esqsoft.com/javascript_examples/date-to-epoch.htm 

Also includes free Javascript, nice.

Also check out thisother java script date library.

http://www.ajaxian.com/archives/mad-cool-date-library 

The original reference is good for near dates but seems to drift quite a bit for dates way in the future. The following link seems to do a very good job of date caclulations, plus it includes a number of rather unusual calendars and things like MS-Excel date serial numbers, very handy.

http://www.fourmilab.ch/documents/calendar/