Amusing Typo of the Day

Screen-shot of an error message on a phone I was working with today… C’mon, even spell-check would have caught that misspelling.

Team Lunch

We had a team lunch today since G. (a product manager who mostly works off-site with customers) was in town, to celebrate the re-release of the product I’ve been working on. We went to this Brazilian restaurant in downtown. It was kind of fun, nice to get out of the office too. I really need to get a recipe for those Brazilian cheese bread balls; they are so good. I remember thinking the same thing when I went to my Brazilian au-pair friend D.’s Brazilian theme party too. Yum Yum.

Work is moving along, getting into documenting things to pass off to the porting team, which means going back and writing a lot of additional documentation. It’s nice to get the chance to do that, and quite satisfying in moderation, but after a while can get kind of tedious to do for long hours straight…maybe its a good thing its Friday!

Busy Time

Things have been really crazy and busy at work this week…we’re trying to get a release out the door by the end of this week, so a lot of extra stuff that needs to get done in between…I’ve been at work late every day this week, but then again, maybe that’ll works out even since I’ll need to leave early next Friday to go camping.

Pizza

At work we’ve had pizza twice this week. Its actually been perfect timing both times too, because it was on the exact days I had no idea what I was going to do for lunch and hadn’t brought anything and figured I’d have to go pick something up. One of the pizza lunches was a thank you for a bunch of us assisting another project team, and the other was celebrating the end of an office weight loss challenge.

Porting to Touch Phones

So work’s going pretty good…I’m really enjoying what I’m working on, I haven’t been doing as much work with actual (cell-phone) handsets lately, but none-the-less having fun. I’m working with two very different phones right now, an LG touch handset and a very basic Samsung feature phone.

Right now I’m working on adding/testing the features for touch-enabled handsets to the J2ME edition of the app. This entails things such as making sure we have all the right images and requesting any missing ones from the art department, setting up a configuration file that specifies all the fonts, fixing lots of little bugs like re-positioning the buttons so that the larger buttons (that a fat-finger can press) fit on the screen, ripping out unnecessary code so I don’t have to fix other issues in twelve places, etc.

Basically I’m just doing all that little fun stuff that makes the app just…work…knocking out one bug or problem after another until it is ready to submit to QA. There are lots of little things that go into making the big thing work.

JList that can be selected by keyboard entry

The default behavior of a JList is that when you use the keyboard to press the first character of a list item, the selection will jump to the first item starting with that letter. Additional presses of the same letter will cycle through all the items starting with the same letter.

For a small list, this functionality works great. For a larger list with hundreds of items however, you may not want to press a single key thirty times to get to the item you are looking for.

So I did a little research about how to make the list work more like windows, where if you type quickly, it will navigate to the item in the list that starts with the prefix selected. So you could type the first few characters of the item to jump much closer to or exactly on the item you are trying to reach.

It turns out this is not difficult but it requires a bit of boilerplate code. My example code here is a modified version of some example code released under the GNU license.

One of the keys to making this work is you need to define how long between key-presses should the system interpret the new keypress as a starting a new search vs. adding additional characters to the original search. CHAR_DELTA in this example code defines how long the system will wait between keypresses before presuming you’re starting a new search, here we are saying you have to type at least one key per second (1000ms) to add additional letters to your search. m_key is needed to track what key sequence has been typed so far, and m_time tracks the time of the last key-press in order to identify whether the threshold of time has elapsed to make this a new search.

     //elsewhere: jList1 = new javax.swing.JList();

    private static int CHAR_DELTA = 1000; 
    private String m_key; 
    private long m_time;

    private void keyPressHandler(java.awt.event.KeyEvent evt) {
        char ch = evt.getKeyChar();

        //ignore searches for non alpha-numeric characters
        if (!Character.isLetterOrDigit(ch)) {
            return;
        }

        // reset string if too much time has elapsed
        if (m_time+CHAR_DELTA < System.currentTimeMillis()) {
            m_key = "";
        }

        m_time = System.currentTimeMillis();
        m_key += Character.toLowerCase(ch);

        // Iterate through items in the list until a matching prefix is found.
        // This technique is fine for small lists, however, doing a linear
        // search over a very large list with additional string manipulation
        // (eg: toLowerCase) within the tight loop would be quite slow.
        // In that case, pre-processing the case-conversions, and storing the
        // strings in a more search-efficient data structure such as a Trie
        // or a Ternary Search Tree would lead to much faster find.
        for (int i=0; i < jList1.getModel().getSize(); i++) {
            String str = ((String)jList1.getModel().getElementAt(i)).toLowerCase();
            if (str.startsWith(m_key)) {
                jList1.setSelectedIndex(i);     //change selected item in list
                jList1.ensureIndexIsVisible(i); //change listbox scroll-position
                break;
            }

        }
    }

Interview Puzzle Anecdote

Today at work E. was doing more interviews…and then sometime thereafter–I’m not sure exactly what prompted it–but shortly thereafter he bet F. he couldn’t solve this interview question correctly in 15 minutes. And by correct, I don’t mean, works for most cases, but doesn’t fall apart on certain rare edge cases. Unlike a lot of interview questions generally speaking, this one is actually quite relevant to the type of stuff I do at work all day, and conceptually, its pretty simple–kind of deceptively simple. So right after F. turns in his answer, someone else walks by and asks what we’re all talking about and pretty soon half of everyone sitting nearby is discussing the question “oh that’s easy” one person says hearing the problem, course, that person not having actually tried to write out the correct solution completely…It was kind of entertaining

Work’s going good

Monday they rearranged the office. My new desk is, now that all the dust has settled, probably in a nicer location than my old one. Plus, I got just enough more space for an extra bookshelf for all those heavy programming books to go on.

I finished the assignment I was working on earlier this week (a bug where songs were being cut off by 5-10 seconds one out of every 3-5 times roughly)…and now I’m on to writing new code to re-skin the app…kind of fun.

Things I’ve learned about Interviews…

Always always have a copy of your resume in front of you during a phone interview. When they suddenly surprise you with a rather expected first question like “tell me about what you did at your last job” and you momentarily you blank in panic, you can stop and take a breath while you glance at your resume and remember the “better” words you carefully chose about how to articulate it.

Always have questions prepared to ask the interviewer. They will ALWAYS ask you if you have questions. And from everything I’ve read and heard, “no I don’t have questions” is never a good answer. You need questions to show them you are evaluating the fit of the job/company to your needs. I’ve found useful questions for initial/screening interviews are usually along the lines of “what would I be actually be doing at this job”. eg: Continue reading Things I’ve learned about Interviews…

Sometimes its the Little Decisions…

Its funny sometimes to think back how some of the seemingly trivial decisions make a big difference in the path your life takes.

Like, one that stands out, for example, senior year of college, when I was at the spring career fair applying for summer jobs, and I have two versions of my resume, one tailored for defense contractors and one generic resume for other industries. There was that moment when I reached into my folder of resumes and decided to hand the recruiter my defense resume… That particular company actually had two divisions, one doing defense contracts and the other in the transportation industry. In fact, I was slightly intrigued by their transportation group from my prior experience doing an internship for another company in the transportation industry. But I was running low on generic resumes, and had a good number of booths left to visit. So I pulled out a copy of the defense resume. Spur of the moment decision. That innocuous choice ended up shaping the first four years of my career after I got the interview for that company’s defense division, and henceforth accepted the position I interviewed for. In the end, I was happy with where I’d ended up, but it’s funny to think how such a small decision could have caused me to end up somewhere completely different.