Overenthusiastic bison.

Groaaan...I thought I was on such a roll at work...things seemed to be going so smoothly...TOO smoothly! I think it is a general rule of research that when things are going smoothly, it means there's something terribly wrong that you just haven't caught yet - I recently built models and ran simulations for almost a dozen datasets for a project, only to discover today that the mesh generator hadn't been working the way I thought it was and ALL of the meshes weren't of high enough resolution at the surface! Horrors!!! My work has been set back by weeks!!! I think only a n00b doing finite element simulations would forget to check something like this. Gaaah. *Slams head against monitor* I spent most of today entering numbers into the computer, waiting a few minutes for it to generate a mesh (while annoying people on google chat who were probably working), checking how big the mesh was, and repeating the process if it wasn't satisfactory. Boy, this is going to be a long week...but at least I discovered the mistake before running any pulsatile flow simulations, which are an even bigger time investment... O_O; Imagine if I worked in a lab that did animal testing or something - you can't mess up those experiments or you'd have to order new animals, or even worse, wait for them to grow!!!

THINK POSITIVE THOUGHTS, BISON3!!!


Maybe it's time for some therapeutic shopping. I went to the mall twice recently and didn't return with a single hooded object.

Fifty?

I think I'm growing increasingly lazy...the 8 minute walk between the parking lot and the Clark Center where I work is starting to feel like a trip around the earth. This is very sad - I used to walk for about 25 minutes from my dorm to the Clark Center when I lived in Lantana and I didn't think it was so bad at the time. Bison3 is turning into a sloth. :(

I'm also too lazy to figure out where these bisoncomics are going. Even though there are like fifty of them now, there hasn't been much character development besides the increasing emo-ness of the rabbit. How do real comic artists churn out so many of these things?!



Despair.

Edit: Hrmm I just realized that the age of that small rabbit is inconsistent. In a previous comic she didn't even know what a bison was, and now she's taking chemistry. Oh well....

Another interesting week.

Hrm...this summer is turning out to be a lot more exciting than usual. Exciting stuff isn't always good, but this week a lot of interesting things happened. For some reason, my dad suddenly developed a interest in hybrid vehicles and I went to test drive a couple of cars with my mom. Suddenly there is a random new Prius in our driveway and no one's really sure whose idea it was to buy that particular model in the first place!!!

Mom: The salesperson asked your dad why he finally chose the Prius over the other cars we looked at, and he answered that it was because we (Mom and Bison3) wanted it. I told him I wasn't the one who wanted it, but you liked it a lot.
Me: Huh? I didn't say I wanted a Prius specifically...I just thought it was way better than that other car we tried.
Mom: Oh. I guess no one actually wanted the Prius.

Actually I think everyone likes it a lot but no one's admitting that they were the one who wanted it, because it cost way more than my parents were originally planning to spend on a new car. -____-; Anyway, I think it is pretty awesome! It looks very futuristic and it is shaped like a large hamster. Bison3 takes full responsibility for wanting a Prius. I guess I don't get to drive that one, though, I inherit the old car. :P

Umm what else...oh yeah, I submitted THE APPLICATION a few days ago, after obsessing over it for weeks! Now, while it is being processed, there is nothing I can do for a while but WAIT. IN FEAR!!!!

Also, I found some datasets at work that may potentially disprove our hypothesis for the project I'm working on. I guess this makes things more interesting...?

And I finally unpacked my last few boxes from moving out of the dorm, including the box containing my tablet and some old food (eeeew), which means more terrible bisoncomics:


There are some things you can't fight. O_O

Android: simple guide to unit tests

I couldn't find anything like this when trying to figure out how to write unit tests for my android app, astrid, so I decided to put together something for you! This guide will show you how to

• write unit tests for your android app
  
• execute them in eclipse
  
• see code coverage results in EMMA (can't figure it out yet...)
  

So, before we start, I expect that you've installed the Android SDK, have an application that runs, and understand unit testing with JUnit.

First, you need to create a new Android project, because for some reason, your unit tests need to be a separate android application from your main app. For organization purposes, you can put your test project within your main project (or not).

In Eclipse, File => New, Other, Android Project.

• Project Name: your-app-tests
  
• Create New Project In Workspace
  
• Location: browse to your main project, and make a tests subfolder. Select it
  
• Package Name: your.package.tests
  
• Uncheck "Create Activity"
  
• Other stuff: up to you
  

Now that you've created your new project, time to overwrite the AndroidManifest.xml with the following (replace com.example.app with your package):

<?xml version="1.0" encoding="utf-8"?>

<!-- package name must be unique so suffix with "tests" so package loader doesn't ignore us -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app.tests">
        <uses-sdk minsdkversion="3">

    <!-- We add an application tag here just so that we can indicate that
         this package needs to link against the android.test library,
         which is needed when building test cases. -->   
    <application>
        <uses-library name="android.test.runner">
    </application>

    <!--
    This declares that this app uses the instrumentation test runner targeting
    the package of com.example.android.apis.  To run the tests use the command:
    "adb shell am instrument -w com.example.app.tests/android.test.InstrumentationTestRunner"
    -->
    <instrumentation android:name="android.test.InstrumentationTestRunner"
                     android:targetPackage="com.example.app"
                     android:label="Simple Tests for My App"/>

</manifest>

Next step is to delete everything beneath in the res/ folder, since you won't be needing it. You will also need to set up your build path to depend on your parent project, so you can reference code from it. Right click on your test project, go to "Java Build Path", Projects, and add your main project as a dependency.

Alright! You've created your test environment. Now that you've gotten everything set up, you will find this handy:

Android Javadoc: android.test package summary

I encourage you to read about AndroidTestCase and InstrumentationTestRunner.

Let's write our first unit test. Assuming your package is com.example.app, you need to create two files. First is our test suite that runs all of the tests:

com.example.app.AllTests

package com.example.app;

import junit.framework.Test;
import junit.framework.TestSuite;

import android.test.suitebuilder.TestSuiteBuilder;

/**
 * A test suite containing all tests for my app.
 */
public class AllTests extends TestSuite {

    public static Test suite() {
        return new TestSuiteBuilder(AllTests.class)
                .includeAllPackagesUnderHere()
                .build();
    }
}

Simple enough, right? It's a test suite that includes all tests in the current package (com.example.app) and subpackages. Next is to write an actual test to test the test harness.

com.example.app.test.SanityTest

package com.example.app.test;

import junit.framework.Assert;
import android.test.AndroidTestCase;

public class SanityTest extends AndroidTestCase {
    public void testSimpleAssert() throws Throwable {
        Assert.assertTrue(true);
    }
}

This is a really trivial test that asserts that true == true. A few things to notice here:

• Your tests should extend AndroidTestCase or its descendants. Tests extending InstrumentationTestCase won't get run automatically
  
• Notice that the method starts with "test". All your tests must start with this, no JUnit4-style @Test annotations are provided
  

Shall we give it a run? There are two ways to run Android unit tests: through eclipse, and on the command line. We'll start with eclipse, which gives you a nice JUnit view for looking at stack traces and such. Right-click on your project, Run-As, "Android JUnit Test". If you're looking at your LogCat and Console output, you should see that your test application gets installed, loads your main application, then starts. Something like this:

[2009-06-25 02:43:49 - astrid-tests] ------------------------------
[2009-06-25 02:43:49 - astrid-tests] Android Launch!
[2009-06-25 02:43:49 - astrid-tests] adb is running normally.
[2009-06-25 02:43:49 - astrid-tests] Performing android.test.InstrumentationTestRunner JUnit launch
[2009-06-25 02:43:49 - astrid-tests] Automatic Target Mode: using existing emulator 'emulator-5554' running compatible AVD 'android-15'
[2009-06-25 02:43:49 - astrid-tests] Uploading astrid-tests.apk onto device 'emulator-5554'
[2009-06-25 02:43:49 - astrid-tests] Installing astrid-tests.apk...
[2009-06-25 02:43:52 - astrid-tests] Application already exists. Attempting to re-install instead...
[2009-06-25 02:43:55 - astrid-tests] Success!
[2009-06-25 02:43:55 - astrid-tests] Project dependency found, installing: data-3.0
[2009-06-25 02:43:55 - data-3.0] Uploading data-3.0.apk onto device 'emulator-5554'
[2009-06-25 02:43:56 - data-3.0] Installing data-3.0.apk...
[2009-06-25 02:44:00 - data-3.0] Application already exists. Attempting to re-install instead...
[2009-06-25 02:44:06 - data-3.0] Success!
[2009-06-25 02:44:07 - astrid-tests] Launching instrumentation android.test.InstrumentationTestRunner on device emulator-5554
[2009-06-25 02:44:25 - astrid-tests] Test run complete

While your test runs, the JUnit view should pop up somewhere, and you should be able to see your single test run to completion.

important! if you want to re-run your test, you need to close the JUnit view, then use the "Run" button in the toolbar or right-click on your project again. If the old JUnit view is still open, the tests didn't run for me.

Alternatively, you can run your tests from the command line. I've yet to understand the intricacies of the various command line flags, but you can run something like:

adb shell am instrument -e coverage true -w com.example.app.tests/android.test.InstrumentationTestRunner


Alright! Hopefully that was comprehensive enough to get you started. To see an example of testing code in action (I'm currently using it to test my service layers), you can poke around in Astrid's codebase, for example the data-3.0 branch.

If/Once I figure out EMMA coverage, I'll add it to this page. I love seeing my code turn green =) Currently, I can generate coverage.ec files, but they're empty, which tells me that eclipse isn't instrumenting the .dex file appropriately. Of course there doesn't seem to be a configuration option for it!

Let me know if this was helpful, or if you're stuck, feel free to ask a question and I may respond on the blog.

Bison3's "adventure."

Apparently nothing worth writing about has happened in my life for over a month. But this week, loads of exciting things happened. Many things were the bad sort of exciting, but I guess they still count....

Monday 6/15 - Day after graduation. Bison3 goes to lab at 8:45 in the morning and spends 9 hours working non-stop making figures for a poster.

Tuesday 6/16 - Leaving for bioengineering conference in Lake Tahoe at 12:55 p.m. Bison3 arrives at the lab at 9:30 in the morning, and scrambles to finish her poster after getting comments from professors. Around12:10 Bison3 scurries into the Clark Center poster printing room, and finds 3 people in line ahead of her, all going to the same conference!!! Poster was printed in time, but wet ink smeared all over table. Takes 10 minutes to clean up. That's what you get for picking the expensive glossy paper. Bison3 leaps into PI's car with the poster's ink still drying. House near Lake Tahoe has a lot of creepy deer antlers. Bison3 looks over her freshly printed poster with lab members, and discovers several mistakes!!! Lab members planning to arrive later are asked to re-print the poster and bring it the next day. That's a waste of, like, $60 or something. >.< In the evening, Bison3 notices a bug bite on her leg beginning to swell.

Wednesday 6/17 - Lots of conference talks. During the evening reception, Bison3 is excited about her drink ticket and greedily guzzles down a concoction of vodka and fruit juice in under 10 minutes. Lab members tell her her face is looking very red and appear concerned. A while later Bison3 is curled up on a couch in the antler house with an enormous headache. Lab meets for poster presentation practice. Later, Bison3 who is still curled up on the same couch gets killed early in a game of Mafia "to put her out of her misery."

Thursday 6/18 - Poster presentation day - wake up at 6:30 to get poster set up. Bison3 notices that the bug bite on her leg has grown much bigger, and hopes the swelling will go down soon. While Bison3 is practicing in front of her poster, an extremeley sketchy grad student inquires sketchily about her school and her project. Sketchy grad student seems to have limited English-speaking abilities, as he refers to stent grafts as "blood tubes." -__-; Bison3 is disturbed, decides to look for lab members. Poster presentation goes okay, after much practice.
Back at the antler house, Bison3 notices her bug bite has swollen to 6 inches in diameter. Lab members are concerned and take her to local hospital. PI jokes that the only hospitals available in the Tahoe area are vetinerary and that they will have to do. In her state of panic, Bison3 *almost* believes this. Bison3 is prescribed some antibiotics at a local hospital. Amputation jokes abound!

Friday 6/19 - Probably the only normal day.

Saturday 6/20 - Bison3 goes with some lab members to a random art fair in the morning, and buys a large, hideous bison-shaped magnet! Cardiovascular growth and remodeling lectures in the afternoon are complicated and full of PDEs. :( Bison3 does not have proper shoes for the evening banquet. Poster presentation winners get a free student edition of Abaqus? Bison3 doesn't know how to use Abaqus. O_O Late at night Bison3 finds herself extremely dehydrated for some reason.

Sunday (today...) - Bison3 gets up at the crack of dawn after sleeping for only 3 hours, feeling extremely sick and still dehydrated. Tries not to look too ill so lab members won't take her to hospital again. On the way home, Bison3 looks at the long list of possible side effects /reactions for her antibiotic prescription...ahhh...this explains everything....

Now Bison3 is at home drinking a lot of Gatorade and trying not to pass out from low blood volume. Hooray!!!

I believe this is enough excitement to last a couple of months. Strangely, going to the conference was one of the most fun things I've done in, like, a year. The rest of summer had better be painfully boring. God, my head feels awful. @_@

Till We Have Faces

So I just finished "Till We Have Faces", a book by CS Lewis about the myth of Cupid and Psyche, and it was good enough to warrant a blog post. Faces, which was written in 1956 and a few years after the Narnia chronicles, was a book that Lewis reportedly had been thinking about since his doctoral studies. Although I last read Narnia over 10 years ago, I could feel the echoes of Aslan and the world of Narnia as I turned the pages of "Till We Have Faces".

To summarize the story briefly, Till We Have Faces tells the story of three princesses in the lands surrounding Greece, the youngest of whom, Psyche, is the most beautiful woman in the kingdom and forced to be a sacrifice to appease the gods. Psyche is rescued by a mysterious being who Orual, the protagonist of the story and Psyche's older sister, is convinced is a demon. Her subsequent "rescue" causes untold heartbreak for Psyche and takes Orual on a long journey in search of truth.

One of the themes of the book is the strange form that love takes whereby it can cause asphyxiation and death - we see through the eyes of others in the story that the ones Orual loved the most suffered cruelly under her manipulations even as she meant the best. Another theme, and the title for the book, is the idea of obtaining one's own "face", or "voice", instead of living in the voices, ideas, and moralities of others - that the gods will not talk a mortal until she has found her own face. Finally, an undertone of the whole book is the dark, mysterious, awful, bloody, yet comforting idea of holiness, held in contrast to the "Greek" ideals of Nature and Reason. Other ideas explored include womanhood and suffering.

Many consider the book to be one of Lewis's masterpieces, with the New York Herald Tribune proclaiming it "the most significant and triumphant work that Lewis has yet produced". Personally, I really enjoyed the book, which provides an interesting exploration of the spirit world, what it must feel like to hear someone talk of an afterlife you don't believe in, and some great insights on the nature of the hidden God. I found the last two chapters abrupt and jarring, especially compared to the rest of the novel. I ended up reading it in about six hours total.

In general I find Lewis a bit too unsubtle in his symbols, and you may experience the same discomfort, but this book is much different in purpose, scope, and content than the Narnia series. Lewis's descriptions and portrayals are vivid and well wrought and Orual is a deep and interesting main character. I wouldn't characterize this book as life changing, but it was a great read and has given me much to chew on.

---

As an interesting side note, many of my coworkers write blog posts about software engineering. I don't feel that way about my work; it's interesting to think about theory and languages and practices, but for me, at the end of the day, it's a tool for solving problems. I'm much more interested in things like this book that deal with people and their relationships. Go figure.

Abstract submission for Journal of Intelligent Structures and Systems

Recent developments in wireless sensor networks have led to increased interest in structural health monitoring. There is a need for algorithms that can detect changes in a structure’s response to vibrations and other excitation due to structural damage. This paper presents a unique algorithm based on estimating the structural response parameters such as stiffness and damping using a Kalman filter approach on observed vibration signals: acceleration and displacement. The Expectation Maximization (EM) algorithm is used to estimate the state transition matrix, and an adaptive Kalman filter is used to model the signal.

The Kalman filter derivations presented in this paper demonstrate that this approach optimizes the prediction accuracy. Kalman filters are nice. The mathematics behind them are just plain beautiful. They never tell you that you’re twenty pounds overweight or that your teeth are crooked. Kalman filters will never ask you why you can’t be more like your brother. They don’t keep their eyes open when you kiss them and then when you ask them whether it’s alright between us they say everything’s fine and then quickly look away. Kalman filters simply give you the best linear estimator of the true state of a time history given your observations, the best non-linear estimator if the signal is jointly Gaussian. What more could you ask for? So yeah, Kalman filters are pretty cool, and the results look good.