Monday, December 31, 2012

The year's sunset

As we trail off toward the sunset of the year, it's hard to imagine that but one year has passed on by. The year has been one of my most exhausting ones yet also one of the most fulfilling, and I'm deeply thankful for God's sustenance throughout it. Just this time last year I thought I would soon be leaving the San Francisco and the Sunset District, yet here He has placed me, and now more than ever the Sunset has felt like home. And what better way to celebrate than with a sunset such as this on a routine walk back home?

Wednesday, October 03, 2012

Let's go Oakland...

Apparently ESPN's "Baseball Think Factory" thought that the A's had a 0.4% chance of winning the division. Maybe from here on out our baseball thinking caps should bear the large letter "A" on it.

Or maybe a samurai hairstyle.

Wednesday, July 18, 2012

Browsing Apache Derby databases

It can be fun to run complex queries on databases by command-line tools, but sometimes the beckon of a graphical aid is just too strong. Since migrating the tXtFL leagues/teams/players/etc from a convoluted structure of individual files to a simple database, I've enjoyed using the Base application for browsing data. I use LibreOffice anyway for much of my office needs, and setup for database grazing was a mere 11 steps.

There were a few shortcomings, however, that propelled me to explore a few database browsing alternatives. LibreOffice isn't the lightest of programs, both in terms of disk and RAM consumption as well as startup time, so taking a quick peek at the data can take longer than expected. Moreover, LibreOffice locks the database until the entire office suite is closed, preventing me from accessing the db from the tXtFL app until I've closed LibreOffice--including any other LibreOffice apps still open.

So what are the alternatives? Browsing the Wikipedia database tool comparison table, I found a number of open-source alternatives that support JDBC connections, which are required for connecting to the Apache Derby database that my app uses. My goal was to test out the ease of setup and connection to the database both via embedded and network modes. In embedded mode, only one program can access the database at a time, whereas in network (client/server) mode, my app hosts the db for a concurrent connection from the db browser.

As setup wasn't always completely straightforward for each of the apps, I've outlined the steps below using the scenario of connecting to the tXtFL database.

Getting the database driver (Apache Derby)

For all of these programs, I ended up needing to manually add the database drivers. You can pick them up from the Apache Derby download page. I used the latest current release (, and the lib or bin packages should be fine. All you'll need is the derby.jar file, plus the derbyclient.jar file if you're connecting to a Derby db in network mode.


If you already use LibreOffice for its excellent word processor and spreadsheet capabilities, why not give it a shot for database management? I've previously described the process but wanted to update it hear in a more streamlined fashion.
  1. In Tools > Options > Java, click on Class Path > Add Archive. Browse to and select the derby.jar file you downloaded from the Derby website, then click OK.
  2. In File > New > Database, choose "Connect to existing database," select JDBC, and press Next.
  3. For the Datasource URL, choose your path, such as derby:C:\Users\[username]\.txtfl3\FootballDB for the tXtFL db.
  4. For the JDBC driver class, enter org.apache.derby.jdbc.EmbeddedDriver.
  5. Enter your username/password (or skip it for tXtFL) and save the file.
  6. Click on Tables to start browsing your data!
For connecting to Derby in networking mode, you can repeat the same steps, with the following adjustments:

  • Add the derbyclient.jar file to the Class Path list.
  • Point the Datasource URL to derby://localhost:1527/C:/Users/[username]/.txtfl3/FootballDB (or whatever your server address is).
  • If you're running tXtFL, make sure that in the tXtFL Options pane, "Open database as server to allow multiple connections" is checked and that the program is running!
Unfortunately I cannot post a current screenshot of the database browser in action as it failed to load. I have Java 64-bit installed, and apparently 32-bit Java is required for LibreOffice on Windows. Another quirk is that when scrolling data, the table only advances line-by-line, which can be slow. Pressing the arrow to advance to the end of the table and then backing up to the line of interest can speed the process. Nonetheless, LibreOffice has served my db browsing very well for several years, and I will certainly be watching for continued updates to the suite.


I learned about SquirrelSQL from Apache Derby's own website. At about 35 MB, the app weighs in at a much more economical size than LibreOffice does while still providing all of the functionality as a db browser. And although startup time wasn't any snappier, a patch from way back in 2007 ensured that disconnecting from the database released the lock, without having to shut down the entire program. That means that you can flip back and forth with ease between viewing your db and running your program that depends upon it. Of all the db browsers I tried, only this program appeared to employ the Derby command to fully shutdown the database without shutting down the program.
  1. When installing the program, I used the squirrel-sql-x.y.z-install.jar installer. Make sure to choose the Derby plugin during installation, as apparently this plugin brings the crucial patch to disconnect the db completely.
  2. In the Aliases pane, press "+" to add a new alias.
  3. Press New to add the Derby driver. In the Extra Class Path tab, press Add to pull derby.jar into the list, and then press List Drivers to automatically load in the drivers. I tried using the supplied derby.jar from the program's plugins folder but could not get it to load successfully.
  4. For the URL, use the same paths as above or wherever you've stored your own db.
  5. Press OK to open the db.
  6. In the tree, open TXTFL > TABLE to find all the tXtFL tables.
  7. Wait, what happened to all the entries after 100? In File > New Session Properties, open the Object Tree tab and uncheck the "Contents - Limit rows" box to see your complete tables.
Again, you can repeat the steps but with derbyclient.jar and the network URL address to connect to the db in network mode. Note that for some reason, a username/password must be supplied even if your db does not have or use one. Fortunately, I simply supplied a single letter for both fields (eg "a" for username and password) and connected without a hitch.


I loved using DBEdit2 only because it's so pleasantly minimalistic. It's but a fraction of the size of LibreOffice, starts up happily snappily, and does away with all but the bare necessities in its interface.
  1. Before opening the program, drop derby.jar into the DBEdit2 program folder (eg C:\Program Files (x86)\DBEdit 2), replacing the older version (10.7) that's there.
  2. In Connections, choose Add, then Derby.
  3. As far as I can tell, the Input dialog box doesn't actually create a file in that location and may actually just be for naming your new connection.
  4. In the Connection dialog, add the URL as above. For network connections, the username/password can be filled as for SquirrelSQL (eg "a" for each field).
  5. Once you've made your connection, you're presented with a totally blank screen. Fear not! To browse your data, you can directly input sql commands. As an extra aid, the Help menu helpfully includes an "Insert 'select * from'" shortcut to do just that for you in the sql text area, and then you can click on the icon on the far upper right to browse your db schema and double click on tables to drop their name into the sql command. When you're ready to roll, press the blue "Play" icon to run the command. Voila!
Clearly this option may not be for all, but I do plan to experiment further with it. Reminds me a bit of the beloved SQLiteBrowser, or an even simpler version of it.


Perhaps the king of the pack in terms of full-on complexity is Orbada. It's on par with SquirrelSQL in size and startup time as well as walloping with features and a complex interface, but with an extra splash of color to liven things up a bit and a flurry of additional wizards to make you feel as if setup is easier.
  1. In the Program > New connections... dialog, press Drivers, then New.
  2. Name the driver as you like, and then browse to your derby.jar file using the button next to the Source of driver drop-down. Press the refresh button next to the Class drop-down to pick up the autoloaded driver. Press OK, then Close.
  3. Back in the connections dialog, press New to define your connection.
  4. Name it as you like (regardless of the prompting), then choose your derby driver.
  5. The series of text fields are supposedly supposed to walk you through the URL syntax, but I found it easier just to copy and paste in the URL from above into the Connection string field. Note that username/password is not required, even for networked connections, in this app.
  6. Once you've connected, you can write sql commands as in DBEdit2, or you can be lazy and go to View > Browse tables (JDBC) to view them in all their colorful glory.
As with LibreOffice and DBEdit2, the entire program must be shut down when connected to an embedded db to free it for access from another program. In network mode, the database can be disconnected without shutting down the program, but make sure to commit (Connection > Commit changes) prior to disconnecting.

So there you have it, four free alternatives to view your Apache Derby database (or many others). I had been hoping to find a one-download, one-click option, but instead I found 4 options that required at least 5-6 steps. Well I suppose that if the steps here reduce the number of steps to manually query and debug the database, the investment may be worthwhile. Certainly the price of the software was.

Friday, July 06, 2012

Panning around southern Africa

A few of the wider highlights from my recent excursion to the southern hemisphere as an attempt to encapsulate a broad glimpse of my experience, if you catch my drift.

Elephant herd enjoying a drink in Etosha, Namibia

Climbing Dune 45 in the Namib Desert

Trekking out to Deadvlei, once an oasis in better days

A closer look at Deadvlei, a clay pan punctuated by forlorn acacian remains

The rolling hills of Kuiseb Canyon on the road toward Swakopmund

Damaraland onward toward sunset in Namibia

Another watering hold in Etosha, showcasing a wider variety of spp.

A double rainbow stretching out toward the multi-falls of Victoria Falls from the Zimbabwe side

A340s taking a rest at Johannesburg airport in South Africa

Monday, May 14, 2012

Post-student status

For the first time in 25 years, I am no longer a student. There have definitely been some perks to being a student, but I'll gladly pay the extra $79 for Amazon Prime membership on its own (or was that $39 for ex-students?). So glad to celebrate my final graduation with my parents, my sister, and even big Elijah! What amazing blessings from on High!

Saturday, May 05, 2012


Hot on the heals of a super sunny San Franciscan day--enough to break through the fog and the Giants' 4-game losing streak--the supermoon rests for a moment in the trees before catapulting itself into the clear night air.

Monday, April 02, 2012

Android-x86 ICS on VirtualBox

Awhile back I stumbled across a pre-made .vdi file with Android 4.0 ready to go for VirtualBox. The stock releases of Android-x86, which I had been using for Android 2.x systems in VirtualBox to test my Android app, hadn't yet supported ethernet in the 4.0 iteration. I was particularly happy to find ethernet support in the pre-made image, but it did have its limitations in terms of customization and SD card support (or at least documentation of them), for which Android-x86 had been very adept at both.

Fortunately, there appears to have been active discussion on this very topic on the Android-x86 mail list, and new builds have appeared that support ethernet out-of-the-box along with many other various improvements. So now if you need to test your Android app without having to plug in your device, you can once again take full advantage of the full suite of Android-x86 support. Here are some of the improvements I found:

  • Sounds support: now even button presses have a satisfying click, despite the lack of haptic feedback on my laptop.
  • Ethernet: with ethernet support, I can now connect directly from the host to the virtual machine via ADB for launching and debugging Android apps.
  • Google Play Store: somehow they managed to include the old Android Market, which seamlessly gets upgraded to the latest and greatest Play Store after first launch.
I had previously been quite excited and hopeful about the announcements of Intel x86-based Android support in the default Android emulator, which spoke of greatly improved performance using hardware-based acceleration. In my cursory tests, however, I continued to see a considerable performance lag both compared to my own actual device as well as the VirtualBox-based Android-x86 image. Perhaps I don't have the correct settings, or the Intel-based images may improve, but for now I'm happy to stick with the VirtualBox-based setup.

So how does one actually get the Android-x86 4.0 distro working in VirtualBox? The steps are similar to the previous description, with a few changes:
  • Grab a special android-x86-4.0-eth0 build, which includes the latest ethernet patches. As of the 20120327 build (but not on prior builds), I found that ethernet support allowed not only web browsing, but also the all important ADB access for Android app testing. I installed the "generic" package for use in VirtualBox.
  • Follow the previous instructions for setup and installation.
  • Turn off mouse integration through Machine > Disable Mouse Integration. Otherwise the mouse is nowhere to be found.
  • Turn off display sleep through Settings > Display > Sleep > Never time out. Otherwise after a period the time display can become unresponsive, even though the mouse still moves about.
  • When you want to shut down Android, you can press Ctrl-H to bring up the shutdown dialog (which I could never find in the pre-made image).
Now the big question for me is this: with Android successfully running within Windows, is it possible to replicate the Windows 8 (Metro mobile + classic desktop) experience via Android + VirtualBox + Window 7? Perhaps we shall see.

Tuesday, March 27, 2012

Child Neurology match

After eight long years, I never thought that Match Day would arrive. But arrive it did, and it's exciting to know where I'll be going for the next five years of pediatrics and pedineuro. And thankfully, where I'll be going is to stay put.

One of my classmates said that she Skyped her family while opening up the match envelope. I thought guiltily about how my dual camera, video-chat-enabled Android phone sat forlorn and ignored in my pocket while I opened my envelope the traditional, analog way, with nothing but the match envelope in hand and my fellow MSTP veterans alongside. But I think my phone (and family) will forgive me, as I was soon off to the dialer to let them know the news.

My fellow MSTP classmates weren't exactly "featured" on the UCSF news site, but if you look closely in the background, here are four of us tucked away on Match Day!

Tuesday, March 13, 2012

Retrofitting a website for mobile viewing

For a couple years I had toyed with the idea of optimizing one of my websites for the mobile workforce. I mean, who wouldn't want to view the latest, up-to-the-minute tXtFL news while taking the inbound MUNI or BARTing across the Bay? All those news clips, coming at a blazing 0.00001 posts per minute, or thereabouts.

But all questions of necessity aside, how does one actually build a mobile website? There are a ton of already-built mobile sites available, and for my tXtFL Mobile app, I made use of Blogger's new mobile template to feed up tXtFL news while trying to figure out a more permanent solution for the Text Flex website as a whole.

The problem was that when I searched for "mobile website creation," I mostly came across commercial sites for building a mobile site from scratch, using their portals. What I ultimately wanted, however, was how to port an existing website to the mobile platform, without having to completely rewrite it or compromise the full-sized site.

As I continue my search, I realized that what I was actually looking for is what's called "Responsive Web Design." The name isn't totally intuitive as I think most websites of all types these days strive to be responsive, but the idea is that sites built this way attempt to provide different views from the same raw content based on the client's platform. In other words, if someone with a desktop-sized screen views a page from my site, they see it as is. If someone with a phone checks it out, the page will responsively adapt itself using a mobile style guide to fit the smaller screen. All without requiring a separate site or special server code.

Fortunately, I found that applying the "responsive" technique to my website wasn't as challenging as I had anticipated. As I learned the steps through perusing a number of various tutorials, I figured that I would aggregate only the most salient points here, in case you might be feeling in the mood for some midnight website retrofitting yourself.

Reorganizing the page structure

My old site was built with tables. Yes, the very thing that you learn first in any web design class or tutorial not to do, that I did. I suppose that it was fashionable when I learned basic web design (from Elizabeth Castro's illustrious book, version HTML 4, still on my bookshelf). Mobilizing my page for the mobile screen by responsive design, however, makes liberal usage of page layout based on div groupings rather than by table formatting, which can then be shifted to different parts of the page based on float styles.

For example, my original layout had three columns, which fit perfectly fine on wide desktop screen, but not so fine on the thin phone screen. With a three-column table, I would somehow have to change the column structure dynamically, which could get rather dicey. With divs, however, I could defer all of the layout issues to the CSS stylesheet, which would adjust the float values of each section to align them differently, or perhaps turn off whole sections altogether, such as the unnecessary ad bar occupying the right column of the page or even the top ad.

This reorganization took the most time for the conversion process as I had to un-learn all of my tabular design principles and think in the div way. As it was something that I had wanted to do anyway, I had now found a pleasant excuse for applying it.

Identifying the page layout for mobile browsers

Converting the page to a div-based structure afforded it extra flexibility, to be adjusted based on separate stylesheets for the desktop and small, mobile screens. But first I needed to identify the page layout to mobile browsers so that they would know to look for the proper stylesheet. The first step was to specify the viewport setting to avoid scaling. While it's wonderful that mobile browsers scale big pages to fit into the small screen so that we at least have an idea of the full contents of the page we're viewing, in our case we actually want to keep the text full size and adjust the size of the page instead.

In the head section, I specified:
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

The browser bypasses its scaling and reads the page as fitting in the screen width, which in the case of most mobile browsers is, well, small. Now that the browser sees the page as small, we tell it to load the stylesheet for small pages:
<link rel=stylesheet type="text/css" media="screen and (max-width: 650px), screen and (max-device-width: 650px)" href="mobile.css" />

In this case I set the screen width threshold at 650px, which I arbitrarily chose based on the fact that some old computers out there might run at 800x600px, and I didn't want them to feel too old by feeding them with a mobile version of my page.

Mobile-specific page layout

One could add the "media" tag above to each style specification in one's current CSS stylesheet, but I preferred to create a separate, mobile-specific stylesheet in which I could house all specifications for mobile screens. Not only did this make it easier for me to differentiate between stylings for the desktop and mobile platforms, but I also only needed to make the media assignment once per page, as above.

Within the separate stylesheet, I made a number of mobile optimizations to the page. I flipped the "off" switch (ie display: none;) on both left and right columns, since the additional details they provided didn't seem useful for those on the go. For the top menu of the Text Flex home page, I decided to swap in an entirely different div for the mobile version, lacking the search box and containing an abbreviated set of links.

Images can be a challenge for at least a couple reasons. The large images we so thoroughly enjoy on our fancy big desktop displays just don't fit in the crowded phone screen. These large images also most likely don't fit our limited data plans so well. And for those of us without 4G LTE connections, the download wait times won't fit our patience so well, either. Some slightly fancier solutions I've read are to specify image width by the "max-width: 100%" property, though this route unfortunately won't solve the problem of image download size. Another solution is to use some JavaScript magic to load different images based on screen size.

The cruder but perhaps more straightforward solution I found was simply to create separate divs with large vs. small versions of the same image. The main stylesheet turned on the large div, but the mobile sheet swapped it for the small div.

By targeting page contents based on platform, I also knew that visitors to the mobile layout wouldn't be looking for a download of the desktop tXtFL app, but rather the Android version. To prevent confusion, I simply turned off the desktop download section, leaving the Android download links prominent (and perhaps I should swipe in an Android screenshot for that desktop one).

Testing the page

One added benefit I found to responsive design is that I don't even need any special testing tools to take the site for a spin. I don't even need a mobile browser! All I need is a regular ol' desktop browser, which I then converted into a mock-mobile browser by none other than manually dragging it to a smaller size. That's it!

Well, not totally content with such a simple solution, I went out looking for a Google Chrome browser extension and found all that I was looking for in a simple extension called Window Resizer. It does exactly that (nothing more, nothing less), resizing the current window to various preset sizes. Refreshing the page brought the page all into alignment.

So I suppose that it's about time for me to migrate the rest of my site to the mobile-ready page layout structure. And maybe by the time I do so, I'll learn a few more optimizations, to begin the cycle all over again!

Wednesday, February 15, 2012

TI-89 goodness!

Back in high school, your TI-89 was your best friend. Well at least in math class. Or maybe most elsewhere too.

That's why my TI-89 still sits on my desk, and on occasion gets picked up and graphed upon, too. But today I came across a nifty Android app that purports to put that calculator right in my pocket, right in my Android phone. Yes, the TI-89 emulator, aka Graph 89, has graced the Android Market and made its home in my phone.