Coredump

Pull files off Android phone

2014-12-09T12:01:00.000+08:00

This assumes you have Android Debug Bridge (ADB) installed. This will pull all files from a directory in an Android phone.

cd /path/to/destination/directory
adb pull /path/to/source .

As Julian says, "Easy-peasy, lemon squeezy."

(I use this, by the way, since the Nexus 5 and OS X Mavericks refuse to work together in USB mode.)

Open URL in Chrome incognito mode from Terminal

2014-12-06T00:20:00.002+08:00

/usr/bin/open -a "Google Chrome Canary" <url> --args --incognito

(Works in 10.10.1, at least.)

Answered prayers

2014-06-07T00:00:00.000+08:00

[tl;dr: God delivers. :-)]

We started the year full of plans filled with hope and expectations. Some plans fell through, others were fulfilled in ways beyond what we imagined.

In January, I went to Amsterdam for a job interview. It was exhilarating: my first time in Europe, interviewing for a dream job. I got to travel for free! Sadly, the offer didn't materialize.

But, a few days after that, we received better news: kuya Gab got accepted to Pisay. That started the ball rolling as we brainstormed on whether to have him reside in a dorm or relocate with the entire family. We decided on the latter.

After that, it was a mad scramble to look for a suitable place. There were doubts, for sure: can we financially support this, how will the kids cope? But one by one, the pieces fell into place.

Through a church friend, we met people in Clark who helped point us in the right direction. We leased a unit inside Clark, very near Pisay. In a matter of days, we closed the deal.

It took a while to kink out the details, and after the turnover during the first week of May, we found out that we had a lot of work ahead to improve the house: the air-conditioning unit was missing, the kitchen sink and counter were damaged, plumbing in the bathroom didn't work. The house wasn't lived in for more than a year so one can imagine all the gunk we had to strip off the place.

Again, it was a mad dash with lots of hand-waving and hair-pulling, until we got our acts together, and systematically, in a matter of days -- just last week! -- began in the home improvement marathon that would rival reality TV shows.

In between these events, we had to contend with anxiety on the results of Peng's medical examination -- we had nothing to worry about, she didn't need new treatment; and Julian's new school (we narrowed down our choices to two, until another one, with tuition closer to our budget and nearer to where we'll live, popped out).

And then there was my plan to work in Clark. My client has a facility in Clark, and I was planning to ask my manager if I can work from there instead of travelling to the main office. I was still formulating my pitch, when, during a casual conversation with him, I mentioned our move to Clark. He asked if it would make more sense for me to work from Clark instead. (!!!) I could barely contain my joy, but I held back and controlled myself, and nonchalantly said that that would be a great idea, and will be a win-win situation for all parties involved.

Throughout all these -- my aborted job prospect, kuya Gab's acceptance to Pisay, Peng's continuing improvement, Julian's new adventure, and our move to Clark -- there was a common thread: that of hope and anticipation. Because all the plans we made, we prayed for first. We set out our plans, keeping in mind -- and believing in our hearts -- that God will guide us, and will not forsake us. At times, when it appeared our plans will not fall through, by some twist, right at the last moment, an opportunity will appear -- better and more than what we expected.

Those who know me well, know that I'm not prone to superstition, nor am I deeply religious. But the events that transpired -- opportunities suddenly opening up; people going out of their way, for no apparent logical reason; to help us -- point to a power far greater than what I can imagine. Hipsters will say that the universe conspired to help us out. My activist friends will say that objective conditions are ripe that led to these situations. Me, I believe that God was -- and is -- at work.

We laid out our plans to Him, asked Him for guidance and providence, and He delivered, amply and beyond what we had imagined.

There's this oft-repeated passage in the Bible, in Jeremiah. To paraphrase: "For I know the plans I have for you: plans to prosper you and not to harm you; plans to give you hope and a future." It's so often cited in church, it tended to be a cliche. (The context, of course, was God's promise of deliverance of His people from exile, but I digress.) There's a reason why the Bible is called the "Living Word": this cliche, this "mantra", still resonates deep within those who sincerely believe that God has a plan, and that His will is "good, acceptable, and perfect."

We laid out our plans to God, and He initiated, He facilitated, He consummated, and He continues to deliver.

FIX: Postfix without MySQL dependency

2014-03-19T12:04:00.001+08:00

MySQL client libraries has been bundled with Postfix in RHEL 5. Unfortunately, this conflicts with the Oracle MySQL libraries when we try to update Postfix:

---> Package postfix.x86_64 2:2.3.3-6.el5 set to be updated
--> Processing Dependency: mysql for package: postfix
--> Running transaction check
---> Package mysql.x86_64 0:5.0.95-5.el5_9 set to be updated
--> Processing Conflict: MySQL-client conflicts mysql
--> Processing Conflict: MySQL-server conflicts mysql
--> Processing Conflict: mysql conflicts MySQL
--> Finished Dependency Resolution
mysql-5.0.95-5.el5_9.x86_64 from Updates has depsolving problems
  --> mysql conflicts with MySQL-server
MySQL-client-5.6.10-1.rhel5.i386 from installed has depsolving problems
  --> MySQL-client conflicts with mysql
MySQL-server-5.6.10-1.rhel5.i386 from installed has depsolving problems
  --> MySQL-server conflicts with mysql
Error: MySQL-server conflicts with mysql
Error: mysql conflicts with MySQL-server
Error: MySQL-client conflicts with mysql
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

<rant>Adding MySQL support to Postfix introduced an unneccessary dependency. Clearly, the people who pushed for this did not think about the use case for those who install upstream MySQL packages.</rant>

Fortunately, someone in Red Hat noticed this abomination, and removed it in RHEL 6. But those still using RHEL 5 are out-of-luck: they either have to stick with the MySQL packages provided by Red Hat if they want to use it with Postfix, or use a different MTA if they want to use upstream MySQL.

This won't hold in our case. Our only recourse was to remove the MySQL dependency in Postfix. So, after downloading the source RPM, it was a simple matter of adding this to .rpmmacro:

%MYSQL 0

and running

rpmbuild --rebuild SRPMS/postfix-2.3.3-6.el5.src.rpm

The binary RPM was then added to our local repository. We had to remove Postfix first, update the rest of the packages, then re-install Postfix, but this time without the pesky MySQL dependency.

Tough nut to crack

2013-11-15T12:28:00.001+08:00

To exercise my (almost-non-existent) Python skillz, I wrote a script to generate passwords and passphrases from common words. The script (in Github) also computes the bit entropy of the generated passwords, and compares them against the plain words (without obfuscation).

As a bonus, I also wrote a generator for XKCD's passphrase scheme: choose four random words from a word list, resulting in a higher entropy and better recall.

The script uses four schemes -- well, three, actually, if you don't count the plain text version (for control): simple character substitutions (e.g. "@" for "a", "3" for "e", similar to "l337 $p3a|<") and padding in-between words; padding short passwords with random characters; and the XKCD algorithm.

Here's a test run using the word list from Linux, /usr/share/dict/words:


Cryptogamia738314396617973004177668             35   208.40
0nl3pYUG%/50$?9&(.)+.70:01<[=_:                 31   203.19
resoaked16166235184403414647125208              34   202.44
flophouses37070490830801046024                  30   178.63
nontaxonomic1968304520123681                    28   166.72
ferrocerium42507400944791500                    28   166.72
^#fILLIPIng/@-2/1;.                             19   124.54
?&p5y(HROM37rI(2l                               17   111.43
]NigHt-cELlAr\]4?                               17   111.43
squads-leftpertestself-regulatedecarburized     43    75.68
arienzomiscounselingtritheocracyreverberantly   45    75.68
pseudepigraphic                                 15    70.51
bubble-and-squeakMariandDorkus                  30    56.76
Lyonaisquadriannulatebumblepuppy                32    56.76
re-excitelactoidununderstandable                32    56.76
subthreshold                                    12    56.41
bioscientist                                    12    56.41
francisca                                        9    42.30
apyrene                                          7    32.90

The padding scheme produces passwords with higher bit entropy, understandably, because of the length. Complexity-wise, though, they won't cut it since they don't have enough character classes (mix of upper- and lower-case, punctuation marks, and digits). The character-substitution-plus-padding scheme does a better job, while XKCD-style is good enough.

(Caveat: I'm not a mathematician. This is a purely "pedestrian", hence loose, interpretation of entropy based on my limited understanding of the concept, but I'd like to think that the math is sound. :-)

Take note that I used a different algorithm for calculating the entropy for XKCD and the other schemes. For XCKD, for example, I assumed a fixed-sized data set from which to derive the passphrases, so the calculation is:

$$E = l * {log_2{R}}$$
where $E$ = entropy
$l$ = number of words in the passphrase
$R$ = total number of words in the data set

For the other schemes, I use the classic definition for calculating entropy, which is the same as above, but $l$ is the length of the password, and $R$ is the range of possible characters.

I also tested the generated passwords against several online strength testers. Interestingly, Wolfram Alpha provides a great password strength tester. It also suggests passwords, based on your input.

Next step is to write a generator for the Schneier scheme: take a memorable sentence, add some memorable tricks (character substitutions, padding), then turn it into a password. That should be fun.

FIX: Cannot boot after vmware-tools installation

2013-11-11T12:23:00.000+08:00

Ugh, more SLES 10 SP4 woes!

A bunch of SLES 10 SP4 servers failed to boot after VMware tools were installed. Apparently, initrd did not load the necessary drivers and modules. This was a known issue that was fixed in a later version of vmware-tools.

The VMware tools installer takes apart /etc/sysconfig/kernel, specifically the INITRD_MODULES directive, and reconstructs it by adding its modules (vmxnet and vmxnet3). However, the new configuration removes the rest of the original modules:

- INITRD_MODULES="piix mptspi processor thermal fan reiserfs dm_mod edd"
+ INITRD_MODULES="vmxnet vmxnet3"

and rebuilds the initial ramdisk image with only these drivers. Hence, the server will fail to boot without the other devices.

The workaround in the Novell site was to boot from a rescue disk, reconstruct the configuration file, and run mkinitrd.

To prevent the boot failure, what we did was edit the config file right after the installer finishes. We then run

/usr/bin/vmware-tools-config.pl

to let vmware-tools rebuild initrd -- this time with the correct drivers.

After reboot, it should be good to go.

We also filed a bug report with the vendor regarding this. Note that this does not happen in RHEL, as it doesn't use /etc/sysconfig/kernel for building initrd.

FIX: Hung suse_register when connecting to local repo

2013-11-10T20:19:00.000+08:00

We have legacy SLES 10 SP4 servers that needed to be rebuilt. After the usual AutoYaST unattended builds, we had to register it to a local repo managed using SMT (Subscription Management Tool, Novell's version of Red Hat Satellite). However, the registration to the Novell Customer Center hung.

As it turned out, it was waiting for data from ZMD, the Zen Management daemon. However, the ZMD service thinks it's still busy and fails to respond accordingly. suse_register needs data from ZMD to determine the installed products to be sent to the Customer Center, and with a broken ZMD, it cannot continue and just hangs there.

So, the ZMD service had to be restarted, but since it thinks it's still busy, the normal

/etc/init.d/novell-zmd stop

rczmd stop

invocations won't work. It had to be forcibly killed:

killall -9 zmd

After that, its cache, DB and log file needed to be removed:

rm -rf /var/cache/zmd/web/*
rm /var/lib/zmd/zmd.db /var/log/zmd-messages.log

(The log file had to be deleted to avoid sharing contention error.)

When everything is cleaned up, the daemon can be started again:

rczmd start

the repository can be fetched:

rug ping -a

and then registration process can continue:

clientSetup4SMT.sh
yast2 inst_suse_register

I'm not sure how it's done now in SLES 11 (we've since moved on to RHEL), but hopefully, they got rid of this abomination called the "Zen Management" suite.

ownCloud on OpenShift

2013-08-19T20:55:00.001+08:00

Last July, Google shut down Reader, one of my most favorite apps, and to ease off my Reader withdrawal, I decided to host my own RSS reader. There were several alternatives out there, but I opted for ownCloud's News app, hosted on OpenShift. I've outlined the steps I took below.

ownCloud is a cloud storage app that runs on a LAMP stack. OpenShift is Red Hat's Platform as a Service (Paas) offering that allows rapid application deployment using various software stacks.

The steps below have been liberally taken from Isaac Christoffersen's OpenShift ownCloud quickstart. I've also forked Isaac's quickstart that incorporates the steps. Feel free to fork and submit pull requests.

This guide assumes that you have an OpenShift account, and the requisite client tools. This also assumes that the app is located in the project directory.

mkdir -p ~/projects
cd ~/projects

Create app.

rhc app create owncloud php-5.3 mysql-5.1
rhc alias add owncloud your.alias.goes.here
rhc app show owncloud
rm owncloud/php/*.php

Get ownCloud.

mkdir ~/projects/owncloud-dist 
cd ~/projects/owncloud-dist
wget http://download.owncloud.org/community/owncloud-5.0.10.tar.bz2
tar xjvf owncloud-5.0.10.tar.bz2
cd owncloud
rsync -av . ~/projects/owncloud/php/

Add script to auto-configure ownCloud.
In ~/projects/owncloud/php/config/autoconfig.php:
Add OpenShift-specific action hooks.
Add the following action hooks to be executed at specific points in the deployment process of the OpenShift app. The scripts are located in ~/projects/owncloud/.openshift/action_hooks.
- pre_build - Restores an existing configuration file and removes the autoconfig script above for succeeding pushes.
- deploy - Ensures that the MySQL cartridge is available.
- post_deploy - During the first push, it will autoconfigure the ownCloud instance. For succeeding deployments, it will ensure that an existing configuration is used.
Use cron.
The News app requires background jobs that need to run regularly, so add OpenShift's Cron cartridge.
```
rhc cartridge-add cron-1.4 -a owncloud
```
Cron jobs go in ~/projects/owncloud/.openshift/cron/ under the respective periods. Add the following job that runs every 15 minutes (in ~/projects/owncloud/.openshift/cron/minutely/owncloud.sh):
Make sure to enable the system cron in ownCloud's Admin settings page.

Deploy ownCloud.

cd ~/projects/owncloud
git add .
git commit -a -m "Deploy to OpenShift"
git push

Log in and start using ownCloud on OpenShift.
Go to https://your.alias.goes.here, and use admin/OpenShiftAdmin as the default first-time credentials. (Make sure to change this ASAP.)

Be my Valentine

2013-02-16T10:38:00.000+08:00

I know, it's late, but still...

Baking on a microwave

2013-02-10T14:12:00.000+08:00

...was a fail, sort of. :-P

So we bought a cheap stand mixer (Philips kitchen appliances were 50% off in Manila shops), and were trying to come up with recipes we can do with it. First in our list was mocha frosting, which turned out quite well.

Next up was bread made from rice flour. But we didn't have an oven. I scrounged the internet for instructions, found a few gems, and made up my own recipe.

The bread was a bit too hard, probably because the microwave took out all the moisture, but it tasted like puto (native rice cake). It wasn't that bad.

Get disk size in Linux

2013-01-08T09:34:00.000+08:00

Usually, you'll need root, like so:

sudo /sbin/fdisk -l | grep -E "^Disk"

But you can also use this:

printf "%.1f GB\n" $(echo "`cat /sys/block/sd*/size` * 512 / 1000000000" | bc -l)

Create a local EPEL mirror

2012-12-13T17:02:00.000+08:00

We use some add-on packages from EPEL. Since we want to peg packages to specific versions only, and to reduce the number of servers that connect directly to the internet, we decided to build a local mirror for the EPEL repository.

Install dependencies.
Patch reposync to add option for "flattened" directories. (By default, reposync creates a directory named after the repo ID for placing the downloaded packages.)
Create the repository directories.
Start downloading the repo.
Copy the packages to staging first.
Create repo metadata.
Add the following configuration file to /etc/httpd/conf.d/.

Restart Apache.
Use the following yum repo config in /etc/yum.repos.d/.

To test:

sudo yum repolist

Clinical

2012-12-03T13:47:00.000+08:00

Now that the senti post is done, on to the heart of the matter.

We discovered a lump last October 21, and had the tumor excised immediately afterwards, on October 25. Peng was diagnosed with invasive ductal carcinoma last November 5.

We sought another opinion from a specialist in Metro Manila, and the initial diagnosis was confirmed on November 7. The oncologist scheduled another consultation on November 15, where we decided on the treatment: modified radical mastectomy.

The procedure was performed on November 19, and we stayed in the hospital until November 21. We left for the province on November 23.

The pathology report on the breast mass as well as the review of the first excision were released and discussed on November 29. There were no residues from the tumor, no lymphovascular invasion, and no lymph node involvement. The hormone receptor assay for estrogen, progesterone and HER2/neu turned negative, too. The diagnosis was stage II, triple-negative breast cancer.

Peng will undergo chemotherapy sessions every three weeks, starting on December 21, for six cycles.

The prognosis is quite good. We're very confident that we can effectively knock off this condition. The test results were great confidence boosters, and succeeding treatments will ensure that this will all be over and behind us soon.

'the hope which has no opposite in fear'

2012-11-17T13:09:00.000+08:00

The words were stark:

"Histology of the first slide showed fibrocystic change while the other slide revealed neoplastic proliferation of epithelium [... that] appears to be of ductular origin."

The report screamed: "HISTOPATHOLOGIC DIAGNOSIS: INVASIVE DUCTAL CARCINOMA".

As I read each line, I was silently muttering, "no, no, no...". My wife, Peng, just stared at the page -- the words might not have sunk in yet.

After discussing the findings with the doctor, we sat on the bench outside the clinic, the early morning light seeping into the dimly lit corridor.

"Why?" Peng asked. I usually have quick replies to all her questions, but this time, I had nothing.

We consulted another specialist, who confirmed the diagnosis and provided options for treatment, which were the same as what the previous doctor recommended: "modified radical mastectomy". The words seemed all muddled up, the meaning hidden in jargon: "hormone receptor tests", "lymphatic-vascular invasion", "cellular differentiation".

They all boiled down to this: Peng has breast cancer, she would have to lose her left breast, and undergo chemotherapy.

The words finally sunk in.

At night, while huddled in the darkness, she would ask, "Why? Why me?" I would tell her, it may be something in the way her body reacted; it could be in her genes; we may never know, but really, the important thing is that it's treatable, there's a big chance of recovery, she will get well.

Yes, I try to convince myself, too: Peng -- my wife, the mother of my kids, love of my life -- will get well. We will get rid of the cancer, we will go through all the treatments, we will beat this.

We're scared. But we're not alone. Our families and friends, as soon as they heard the news, formed a protective cocoon around us, giving solace, telling us, "Everything will be alright." We're grateful.

* * *

At times, when I feel scared, I recite the "Litany Against Fear" from Dune: "I shall not fear / Fear is the mind-killer [...] / Where fear has gone there will be nothing / Only I will remain."

Yes, there is still fear, but it will soon be gone. This time, it won't be just me replacing it in the silent void. As e. e. cummings wrote:

love is the voice under all silences,
the hope which has no opposite in fear;
the strength so strong mere force is feebleness:
the truth more first than sun more last than star

---do lovers love?why then to heaven with hell.
Whatever sages say and fools, all’s well

Everything will be alright. All is well.

Add EXIF timestamps to photos

2012-07-29T10:43:00.000+08:00

My car got sideswiped yesterday. Worst, the driver neither had insurance nor a license. We had to go through the hassle of filing a report with the police, complete with photo evidence of the accident.

I only had my phone with me, which unfortunately isn't very feature rich (it's an old Android phone flashed with CM7, but I digress...), so there wasn't any timestamp on the photos.

ImageMagick to the rescue! ImageMagick can extract basic EXIF data from images, as well as annotate them on the fly. I used the following script:

for img in IMG*.jpg; do
   fn=$(basename ${img} .jpg)
   convert ${fn}.jpg ${fn}.exif
   tstamp=$(strings ${fn}.exif | grep -E "^[0-9].*\:.*")
   convert ${fn}.jpg -fill red -gravity South -pointsize 72 -annotate +0+5 "${tstamp}" annotated_${fn}.jpg
   rm -f ${fn}.exif
done

So it went from this:

to this:

Ugh! That scratch would have to wait.

Sync iPad with Fedora

2012-07-07T18:26:00.001+08:00

I don't have a Mac anymore, and we don't have any Windows desktop at home (yes, we're a Linux-desktop household, yay!), so one itty bitty issue is syncing the iPad, which has become the mobile entertainment device du jour.

Good thing there's libimobiledevice, a worthy project that "talks the protocols to support [Apple] devices." The software library doesn't depend on any proprietary library, and doesn't require jailbreaking -- it Just Works (TM). Hooray for open source!

Unfortunately, we're still on Fedora 15 (Lovelock) -- yeah, I know, it's end-of-support already, but I'm a bit queasy about upgrading to "Beefy Miracle" -- and its libimobiledevice version doesn't support iOS 5 out-of-the-box.

So I did what any self-respecting Linux user would do: build my own package from upstream. (Well, maybe not all Linux users would do that...) It was the usual download-configure-make-make install combo.

Then I found out that there's an existing build for F16 that works just as nicely. D'oh!

I'm a bit O.C. so I opted for that (much cleaner) build instead:

# cd /var/tmp
# wget http://kojipkgs.fedoraproject.org//packages/libimobiledevice/1.1.1/3.fc16/i686/libimobiledevice-1.1.1-3.fc16.i686.rpm
# yum localinstall libimobiledevice-1.1.1-3.fc16.i686.rpm

I plugged in the iPad, fired up Banshee, and I haz iPad syncing:

One downside, though, is that video syncing is not yet available in this version of Banshee. Perhaps 2.2 or 2.4 has that functionality, but I don't want to go through dependency hell. I'll just upgrade to F16 (or F17 -- it's inevitable, I guess...) instead.

HOWTO: Build driver update disk for SLES

2012-06-25T17:50:00.001+08:00

Okay, so we have this humongous ERP server we call the "Monster", with a, well, not-so-esoteric network card. We were in the process of upgrading it to SLES 10 SP4, but we hit a snag since SP4 doesn't have the most recent driver.

So it was off to HP we go, to search for the latest driver, which was in the form of a kernel module package (KMP). Using Novell's reference as a guide, we built a driver update disk (DUD).

Build the KMP to a usable RPM.
Create a build directory and extract the module.
Create the staging tree.
Populate the tree.
Create post-update script to workaround a SuSE bug in processing multiple RPMs.
Create MD5 sums.
Create package description.
Create information file.
Build ISO.
To use, add
```
dud=1
```
in the linuxrc boot option.

Goodbye, MBP

2012-06-12T12:41:00.000+08:00

The recently concluded Apple WWDC 2012 keynote left a bitter taste in the mouth. I can hear fanboys ooh-ing and ahh-ing, going cazy over the newfangled gadgets pandered before them; I can almost hear their eyeballs pop and their jaws drop. The raves about the new MacBook Pro (slimmer, more powerful, with better displays) was especially gritty, and set my teeth on edge.

Okay, it *is* bitter -- *I* am bitter. The wounds from my recent woes with the MBP are still fresh. And I'm afraid I might have lost the MBP for good.

Water was accidentally spilled on the MBP, while I was carrying it home on my bag, inside its sleeve. It was only when I got home that I discovered that the sleeve and the MBP was soaked. It took every ounce of control not to scream, and the first thing I did was set the MBP on its side to let the water drip.

I took it to the service center. A week later, they told me that the logic board needs to be replaced. The replacement board was worth Php 55,000. Uhm, let's see: I bought the 2010 MBP for Php 65,000, renewed AppleCare for Php 13,000, had the keyboard assembly replaced for Php 10,000, and bought an assortment of accessories for it. Do the math.

There was no way in the coldest place in hell I would shell out that much to get this... thing... back to life. So I took the MBP home. I can use an external display with it, but the battery won't charge. It won't use the power adapter either. When I got it, only five minutes of battery life were left, so I did a quick rsync to back up whatever files I can salvage.

As I shut the MBP down, I wondered when -- if ever -- I will get a new one. The specs of the new MBPs are enticing. Wait, this is me not being a fanboy: I need a laptop, and the Mac fits my requirements at the moment. I was actually saving up for an iMac to replace the only desktop PC left in the house, but now, I don't know.

I've always known that the cost of ownership of an Apple product can burn a hole in my pocket. I accepted that risk. I was a willing victim. I drank the Kool-Aid, too -- well, not the whole pitcher, but enough to make me chant, "Once you go Mac, there's no turning back". Now, I just feel so... empty and uncertain.

(Not that I have an emotional attachment to the MBP, nor to any gadgets for that matter, but it did help me through some of the most crucial moments in my career. I developed and wrote my whole thesis on the thing, for one. Plus, I can run Linux pretty well on it.)

So yeah, I'm a bit bitter, but I can move on. Goodbye, MBP. It's been a good (almost) two years.

Picasa uploads via command line

2012-05-05T11:16:00.001+08:00

(The tool described here has been around for a while. This is a "memo-to-self" post, as I tend to forget a lot of things these days. {Sign of old age, maybe. Heh.})

I've been using Picasa for quite some time now, even opting for additional Google storage just so I can back up my photos "in the cloud". (Which reminds me to keep my current storage plan -- US$ 5 for 20 GB -- lest it be overtaken by the egregious Google Drive plans. But I digress...)

Unfortunately, Picasa does not offer a native uploader for Linux. (Yes, there's a Wine -- yuck! -- alternative, but it's severely outdated.) So I was stuck to using the iPhoto plugin on the Mac. Most of our photos, however, are in the Linux boxes, so it gets pretty messy sharing the albums in Mac, opening them in iPhoto, and creating new albums from there.

Enter googlecl, which exposes Google Data APIs in a command-line interface. It's written in Python, and requires Python >= 2.5, and the gdata-python-client, Google Data APIs' Python client library. Setting it up is a breeze: it's as simple as downloading and unpacking the latest tar ball, running setup.py, and adding the appropriate PYTHONPATH.

cd ~/bin
curl -0 http://gdata-python-client.googlecode.com/files/gdata-2.0.17.tar.gz | tar -xz
cd gdata-2.0.17
python setup.py install --home=~
cd ..
curl -0 http://googlecl.googlecode.com/files/googlecl-0.9.13.tar.gz | tar -xz
cd googlecl-0.9.13
python setup.py install --home=~

(Nifty trick alert! Download and decompress .tar.gz files using the curl | tar -xv combo.)

After that, uploading to Picasa is as easy as invoking

PYTHONPATH=~/bin/gdata-2.0.17/src:~/bin/googlecl-0.9.13/src google picasa create "Album Name" /local/path/to/album/*.jpg

During the first run, an OAuth link is displayed, which would have to be opened from a browser so googlecl will be authorized to access the Picasa account.

Since this is now in the command line, automation is possible for, say, uploading new photos once they're stored in a certain path, or running a cron job to post new photos to an album.

Borked MBP keyboard

2012-03-03T15:55:00.000+08:00

So the Macbook Pro's keyboard broke: the kids spilled juice on it, and several keys got stuck. The laptop booted properly but I couldn't log in (I did not configure SSH).

I took it to Digital Hub in Greenhills for repair. After a week, Digital Hub reported that the Macbook's top case was due for replacement. Since liquid damage was not covered under Apple Care, the replacement part would set me back Php10,450. Ouch. They also said that the keyboard backlight doesn't work anymore, and that the logic board also needs to be replaced because of that. The logic board replacement was quoted as Php55,000. WOW!

No way I'm gonna replace the logic board just so I can have the fancy keyboard lights, so I opted to have the top case replaced instead.

Two weeks later, I went back to Greenhills, claimed the Macbook, and while testing it, confirmed that the keyboard light no longer worked. I also got the old top case, and hesitantly parted with Php10,450. (That was worth some people's monthly salary already!)

This was worth Php10,450.00

The sad Macbook's top case (back)

The next day, I was surprised to find out the the keyboard backlight still worked. So I called up Greenhills to verify, and asked them why they also recommended to have the logic board replaced to have that functionality back. I wondered out loud if the top case replacement was really necessary.

Digital Hub sent me an email detailing the work done on the laptop, including photos of the liquid damage. Apparently, the keyboard connectors to the logic board were already corroded, and the tech's (kneejerk) "worst-case" recommendation was to have the logic board replaced. The report also mentioned that the old keyboard has become unusable because of stuck keys.

Okay, fine: the top case replacement may have been necessary, but for the logic board?

"Evidence" of the kids' shenanigans

Here's another

...and another

The "corrosion" in the logic board connectors

Corrosion due to liquid damage?

More evidence!

My takeaway from this sad episode:

The cost of owning an Apple product is ridiculous. Ah, the perils of being a fanboy!
Apple Care is worth diddly-squat. (Well, I did RTF-fine-print, but should've paid more attention about that section on "accidental" and liquid damages.) Which brings me to...
Getting a silicone keyboard protector (Php350 on CashCash Pinoy) could've saved me from this aggravation. That protector is now worth Php10,450.

View hidden files in Mac OS X

2011-09-04T10:19:00.001+08:00

Just plunk the following in a file:

Change the file's mode to executable, then invoke using

view-hidden.sh yes

Hidden files (including "dot" Unix files) will be viewable in Finder.

Create Kerberos keytab file for single sign-on

2011-06-03T13:59:00.000+08:00

On a Windows 200[38] server:

Cars 2 trailer, in LEGO

2011-05-20T13:07:00.000+08:00

ZOMGWTFBBQ! I'm *almost* through in my LEGO City Space collection (just one more set!). Will this be the next one?

PS. Yesterday's post was my 666th. Just saying.

Paean to the letterpress

2011-05-19T10:39:00.000+08:00

(I missed the smell of ink and the sound of rolling presses. Heidelbergs, Bodoni and Blueback are personal favorites. I loved the way I can lay out pages on a grid, and then mess it up by extending beyond the column guides {the old technician laying out the leads always threw a fit!}. Photogravures were "cutting-edge" and novelties. {Yes, Pagemaker was still in its infancy when I started, and I didn't want anything to do with Ventura Publisher.} {I'm showing my age...:P})

Letterpress from Naomie Ross on Vimeo.

Customize fatal error messages in Perl CGI apps

2011-05-18T10:35:00.001+08:00

We all know Carp and CGI::Carp, and they're quite useful when catching errors in your apps. But, the messages are butt-ugly, sorry to say. CGI::Carp to the rescue. It has some nifty functions that can be used to make the error messages friendlier.

To set a custom message when fatal errors are encountered:

use CGI::Carp qw(fatalsToBrowser warningsToBrowser set_message); ### Custom fatals browser message BEGIN { sub handle_errors { my $msg = shift; my $err_mail = "Error%20message:%0A%0A\ -------------------------------------------------------------------------------%0A\ $msg%0A\ -------------------------------------------------------------------------------%0A"; my $err_msg = "

Encountered an error:

\ $msg\

Click here to send a report.

"; print($err_msg); } set_message(\&handle_errors); }

(Side note: The mailto URI scheme has some great extensions as well.)