December 29, 2010

September 9, 2010

  • How to disable the Meebo chat bar on Xanga

    So I take a little vacation and when I come back, I notice this white bar along the bottom of every page on my Xanga site, and while it can be minimized a little bit (by clicking the down arrow on the right), it still leaves a small white tab sticking out of the corner "in case you want it back". Well, click on another page and the whole toolbar annoyingly comes back up again. I noticed that when I click on the "you are not signed in" part, it tries to sign me in, then fails and stupidly tells me to sign in. So finally I figured out somehow that this is a Meebo chat system, and it can be disabled.

    To disable the chat bar:
    * Go to Account settings and click on Chat on the left side (between Badges and Blogrings).
    * On that settings page are three checkboxes for Auto Start, Public Pages, and Private Pages. Uncheck those and click on Save.

    There you go - the irritating toolbar goes away! At least for your site - it seems Xanga rolled this out to everyone, so you might still get it popping up on other people's sites.

November 17, 2009

  • A poor man's Ant build number incrementer

    Our situation: our build server uses Ant to automatically get the latest versions of the source files, build the application and deploy it.  A build number is updated in a properties file, but we lost the ability to check that file back into source control. (no write access for build user to source control server). This means the build number, say 500, is always incremented to 501, packaged into the war file, and sent out on the server.  The next night, another automated build kicks off and the properties file is retrieved with the current build number set at 500.  So the build process dutifully adds one to it, builds and packages the application and sends it off to the server with the build number at 501.  Again.

    We needed a way to increment the build number to accurately reflect that a new build is generated and put out on the server - this helps not only to keep tabs on how many times we build the application, but the build number is also used as a random salt in the request parameters to prevent caching issues with browsers.

    The workaround below will pseudo-increment the build number based on a "build epoch" - the same way time is kept on unix-like systems.  Note the enclosing target and project tags have been omitted.

        <property name="build.epoch"              value="20090101"/>
        <property name=""              value="${DSTAMP}"/>
        <propertyfile file="${}">
            <entry key=""      value="${}"/>
            <entry key=""      value="${build.epoch}" type="int" operation="-" pattern="0"/>

    In a nutshell: define the build epoch property as a certain date in the past.  The property file then sets the build number to today's date, and then immediately does a subtraction operation using the build epoch.  The dates (in yyyyMMDD format) are treated as integers and you get a different build number for each day.  It's not a true increment (on month boundaries the next number jumps up by about 70) and there is only per-day granularity, but... it works.

    There must be tons of ways to avoid the whole problem in the first place, with so many opportunities to "do it the right way first".  While working on this setup, I noticed two thoughts flitting about in a certain echo chamber: "it's amazing"... and moments later: "it's asinine".  This is just how it turned out.

April 22, 2009

February 6, 2008

  • setting up the Flex facet in IntelliJ 7

    One of the new features of IntelliJ 7 is the support for Adobe's Flex language. You can enable this support by going to the project properties and adding a Flex facet, where you can specify the path to the Flex SDK. I set it up, but there was none of the expected IDE help for the ActionScript classes: no code-completion, class/type suggestions, not even syntax highlighting. Some Googling reveals a few more requirements: the JavaScript support plugin must be enabled (which it was) and the File Type needs to be registered for *.as files. In my setup, it was set to "Text files", adding the file pattern to JavaScript files (with a prompt asking if you'd like to reassign it from the existing text files setting -- very nice) and hitting OK then set off a somewhat lengthy parse of the ActionScript classes in the project. The Flex support is now working.

    Kudos to Serge Baranov for the extremely quick support response and helpful guidance.

    The things I do for bolded keywords...

December 3, 2007

  • sparse notes on upgrading wiki: PHP 5.2.5, MySQL 5.0.45

    Upgrading PHP, MySQL and (possibly) Mediawiki itself. PHP is currently at 5.1.5, and MySQL is also a bit dated at version 5.0.24 . Thanks to our security audit coming up at the end of the year, it's time to get the updates in! yay, woohooo... yawn.

    The PHP 5.2.5 MSI installer on a Windows 2003 Server/IIS6 system (using the ISAPI filter) will configure IIS with a link to the php library as e.g. "C:PHPphp5is~1.dll". This needs to be changed into the full path such as "C:PHPphp5isapi.dll". After this it will correctly find PHP. (This is changed in the IIS Manager, go to each of your website's properties, Home Directory tab, in the Application settings section there is a configuration button). Don't forget to do a custom install and enable the MySQL extension.

    MySQL doesn't seem to upgrade cleanly over the older version. The troubling part lies in the "start service" of the re-install, which fails with no explanation why. The event log gives a cryptic answer about catching a signal 11 and quitting (Google has only 1 hit on this, of a user reporting this as a bug from about two years ago). The issue actually appears to be the residual files left in the Program FilesMySQLMySQL Server 5.0 directory. Once you delete those and run the installer again, it starts up the service cleanly. For kicks, tell it to create a brand new database, and run the restore operation (bonus points for forgetting to do a backup... tsk tsk).

    Mediawiki (old version 1.9.3) then has issues keeping you logged in. A test upgrade doesn't work, even with about 3 different permutations on the install dance (extra kudos for forgetting to backup... "there are two types of computer users: the paranoid and the inexperienced"). As an idea, I tried installing a new instance of the mediawiki software (Mediawiki 1.11), and the config script helpfully tells me that PHP does not have write access to the session directory (the PHP variable session.save_path). To fix this, go to the directory properties, sharing tab, and give the Network Service the ability to read and write (disable the others as a precaution). The wiki works again!

    edit 2008-05-07: typo in the title about the PHP version being upgraded to, it's 5.2.5 not 5.2.25. New release 5.2.6 came out this week.

November 7, 2007

  • worked it out: unable to import photos from digital camera via USB to fedora 7 system

    I ran into this problem and spent an annoying two hours trying to figure it out. I couldn't get the photos off my camera to my Fedora 7 x64 system. The gthumb import dialog gives the error:

    "An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device."

    Google turned up a few hits but none seemed to give the immediate answer. A few of the hits suggested it was a permissions problem. This is verified via the terminal with 'gphoto2 --list-files' (if you run it as root, you can access the camera fine, but not via the regular user account). However, I didn't want to switch to root just to get photos off my camera, and I wasn't thrilled either to be going back to 2004 with my shell script to do the file transfer.

    A few of the Google hits mention futzing with udev. I don't know jack about udev, but sometimes I just can't ignore that devilish mischievousness that cackles at the thought of poking various internal bits of the system, gleefully ignoring the blaring red alarms and risking the health and safety of women and small furry animals. There's a directory of rules for how udev should create device nodes when the system encounters new hardware. A search through /etc/udev/rules.d/50-udev.rules shows the string "usb" in several places, such as this group of lines:

    # usb devices
    KERNEL=="usb/dabusb*", MODE="0660"
    KERNEL=="usb/mdc800*", MODE="0660"
    KERNEL=="usb/rio500", MODE="0660"

    However, changing these to mode 0666 does not work. Farther down the file, there is this line:

    SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", 
    NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"

    This has a mode also, so I set it to 0666. Instead of exploding on me, the photo import now works. Yay! Now that I have new photos, you may berate me for not updating my photo blog.

    P.S. You might be wondering why mode should be "666". There's nothing satanic about it, it's just a throwback to the Unix-style file permissions (read/write/execute for owner,group, and others).

October 5, 2007

  • under construction

    This is where I put up a cheesy pic of a road construction sign with some stick-figure guy shoveling manure. Site is being redesigned and re-purposed. Photos will still be here, but so will other stuff too.

    In other boring news, I read "The Good Earth" earlier this week. This is the sort of book I wished I could have read before I got old.

  • asdoc and -templates-path

    The flex documentation tool, asdoc, would not do anything I asked it to. It would spit out an error message saying "Error: 'templates-path' is not a directory". I couldn't figure out where the heck it was being told to use a templates-path: there's no reference to it in the flex config file, and it's not an environment variable. By luck, I was poking around the help messages ("asdoc -help list") and noticed templates-path is an option to the asdoc tool. A quick look at the adobe asdoc tool reference shows it's the path to the documentation templates it needs to build the documentation, and has a default setting.


    Of course it needs templates to build the documentation! It was something stupid, like not finding the templates and thus quitting. The solution was to specify it explicitly on the shell: "asdoc -templates-path path to templates other options".