Coding Exercises Day 2 (Problem #4)

Problem:
Given two strings, determine if one is a permutation of the other (i.e., the two strings are anagrams of each other)

static boolean areAnagrams(String s1, String s2) {
  if (null == s1 && null == s2) {
    return true;
  }
  else if (null == s1 ^ null == s2) {
    return false;
  }
  // Both strings are non-null and identical length
  else if (s1.length() == s2.length()) {
    // char are two-byte primitives in Java
    int numChars = Math.pow(2, 16);

    int[] s1CharCount = new int[numChars];
    int[] s2CharCount = new int[numChars];

    countChars(s1, s1CharCount);
    countChars(s2, s2CharCount);

    for (int i = 0; i < numChars; i++) {
      if (s1CharCount[i] != s2CharCount[i]) {
        return false;
      }
    }
    return true;
  }
  return false;
}

static void countChars(String s, int[] charCount) {
  for (int i = 0; i < s.length(); i++) {
    charCount[Character.numericValue(s.charAt(i))]++;    
  }
}

Coding Exercises Day 1c (Problem #3)

Problem:
Find the height of a binary tree given the root node

  int getHeight(Node node) {
    int rval = 0;

    if (node != null) {
      rval = 1;

      Node left = node.getLeft();
      Node right = node.getRight();
    
      if (left != null || right != null) {
        
        rval += Math.max(getHeight(left), getHeight(right));
      }
    }
    return rval;
  }

Coding Exercises Day 1b (Problem #2)

Problem:
Implement a function in C which reverses a null-terminated string.

void reverse(char* str) {
  
  int length = strlen(str);

  if (length > 1) {

    int startIdx = 0;
    int endIdx = length - 1;
    
    while (startIdx < endIdx) { 
      char temp = str[startIdx];
      str[startIdx] = str[endIdx];
      str[endIdx] = temp;

      endIdx--;
      startIdx++;
    }
  }
}

Coding Exercises Day 1 (Problem #1)

I've decided to start honing my skills by working on a coding problem every day. The code might not be correct and it might not even compile, but the important thing is to code something each day.

Day 1 (Problems completed: 1)

Problem:
Implement an algorithm to determine if a string has all unique characters.  What if you cannot use additional data structures?

boolean allUnique(String s) {
  boolean rval = true;

  // Java uses two-byte chars, so lets initialize an array of size 2^16
  boolean[] trackChars = new boolean[Math.pow(2, 16)];

  for (int i = 0; i < s.length; i++) {
    int charAsNum = Character.getNumericValue(s.charAt(i));
    
    if (!trackChars[charAsNum]) {
      trackChars[charAsNum] = true;
    }
    else {
      rval = false;
      break;    
    }
  }
  return rval;
}

SystemH - iPhone Application

For my final project in Software Engineering class, I've opted to develop an iPhone app for the Team Hawaii Solar Decathlon project.

The app will provide an interface to the Home Management System, which we developed as a semester-long project in our software engineering class. This blog post will document the weeklong project process.

I've had a little iOS experience during my internship with Ikayzo, Inc., but for the most part, I'll be learning as I go.

Day 1 (Monday, May 9):

The iPhone must communicate via XML with the backend to the Home Management System (HMS). So I looked up a few XML parsers for iOS and found the following useful articles:

• how-to-chose-the-best-xml-parser-for-your-iphone-project
• how-to-read-and-write-xml-documents-with-gdataxml

Seems like for now, we'll try gdataxml for the simple reason that the iPhone needs to be able to both read and write xml data to the backend system.

The app will request data from the HMS via a GET request, and send commands to the HMS via a HTTP PUT command.

Downloaded the entire HMS project from the Google Project Hosting site, and examined the backend system and house simulator to get a better understanding of how the systems work in their current final state.

Time spent: 2 hrs

Day 2 (Tuesday May 10):

Started reading the following book and started doing some iOS tutorials. I plan to take about 3-6 hours doing tutorials to familiarize myself with how to setup different screens and support navigation through an app.

• Beginning iPhone 4 Development

There are a few things that I need to be able to do in order to complete the project:

• connect to a URI
• parse and write XML
• get XML data and put XML data to a given URI
• have multiple screens/views
• navigate easily and naturally between the views
• be able to include images and other items in the app
• allow the user to enter in an ip address or base URI
• store user settings

Tutorial 1: Button interactivity. Did a short tutorial on how to make buttons interact with text on the screen. This should be useful since there will be buttons on the app that should display a response message when pressed.

Tutorial 2: More interactivity. This tutorial goes over the following controls: segmented controls, switches, and sliders. It also dealt with modal windows (alerts and action sheets).

Total Time: 4 hrs

I think at this point the main thing I need to worry about is navigation within the app. That and XML parsing.

TOTAL TIME SPENT ON PROJECT SO FAR: ~22 hrs

Day 5 (Friday May 10):

Blogger went under for maintenance yesterday and somehow purged about two days worth of writing. Oh well, no harm done :)

So this is where I stand now:

• Can parse XML from the backend system
• Have implemented a navigational bar as well as a tab bar
• Finished Energy calculation
• Have tested an HTTP PUT request to change the Aquaponics temperature successfully
• Have implemented AJAX-type updating to live update every N seconds

The image below is a good indicator for how far I've gotten:

Still to do:

• I'm still having a great deal of trouble putting sliders inside of cells within UITableView. This, however, can probably wait until version 2.0. Tables are nice and great to look at but I need to really read up on custom cell subclassing first.
• Might be good to implement some sort of timestamp to read what time the last update was.
• User settings (host URL or IP), time interval to update
• Slider controls to send a command to the HMS.
• Error catching for when a connection is lost or when there's a parsing error.

I've about 4 hours left. I think it'd be reasonable to expect the timestamp implementation as well as the slider controls for at least the HVAC system. I have a feeling lighting will be neglected.

Time spent: 4 hours

Just made a wiki page for the app on Google Projects.

I'm also gonna take a quick stab at showing a timestamp at the bottom of each screen to show the last updated time.

Done for today. This week. 7:39pm. 2 more hours in the bag.

-------------------------------

Total Time Spent: 28 hrs

A06. Persistency

I finally had a chance to finish the integration of Wicket, Berkeley DB, and Restlet. For this assignment, we were tasked with the following two items:

• Create a secondary index on the timestamp field
• Provide a web page that will allow the user to get and store data
  
  

Some background:

This is a database of contacts, which includes the following fields:

1. Unique identifier (user-entered)
2. Name (first, last)
3. Information (text field)
   
   

My understanding of REST, two months later:

When REST was first introduced to us, along with the MVC (model view controller) architecture, I didn't really understand how prevalent both of these ideas were out in the wild. But now that I'm interning at a web development company, and learning Ruby on Rails, it's become apparent that there's no avoiding either of these ideas.

At my internship, we have interface designers and web developers. And I can fully appreciate the MVC model for web development, because it allows the developers to worry ONLY about scripting and writing code to get the inputs and outputs to work, while the designers can focus on making the website pretty. It's a really nice way to separate effort, where doing something on one end has minimal if any impact on the other end.

REST, on the other hand, keeps popping up. Rails supposedly is a RESTful architecture. There are usually no absolute URI's defined, and URI's are created on the fly for the most part, depending on what resource or object from the database that you want to view. I'm still a little fuzzy on how machines talk to other machines via REST, but the entire concept of representations and XML really helped me understand things better when I started my internship. Everything it seems has an XML style hierarchy structure when sending information back and forth between systems.

Kata 1: Create a Secondary Key called Timestamp

This was relatively easy, since I already had experience doing this for the Solar Decathlon project I had been working on, which incorporates a BerkeleyDB backend with a Wicket frontend and Restlet simulator. I happened to work on the BerkeleyDB portion of the project for the first project milestone, so this wasn't a stretch at all.

Duration: 1 hr

Kata 2: Creating a Form Page using Restlet, Wicket, and BerkeleyDB

This was a little more difficult, because it had been so long since I worked on Restlet. So I had to re-watch some of the screencasts by my Software Engineering professor. I also had to go and review some of the Restlet code I had written before to re-acquaint myself with things.

Once I had completed the exercise (screenshots are shown below), I wanted to make sure that I could build two .jar files (one for the contact server and one for the webpage interface client) via Ant. This actually almost took as long as the exercise itself, due to some directory renaming issues.

Duration: 3 hrs + 2hrs to get both the client and server .jar files to work and build via Ant

Screen Shots of the finished Kata:

Screenshot 1: Storing a Contact into the Database

Screenshot 2: The confirmation that the contact has been added

Screenshot 3: Retrieving a record via its unique ID

Download the Eclipse Project: HERE

A07. API Design for iHale

I always had a general idea of what APIs were, but the latest module on API design really helped to define what exactly they are for me. First and foremost, I didn't even know what the acronym stood for: Application Programming Interface. I really just saw APIs (most specifically the Java API in particular) as a toolset that I could easily call upon to do magic for me. I never gave it too much thought as to where the magic came from.

After watching Joshua Bloch (of Google fame) give this presentation on good API design, I have a much better understanding of the steps and thought process that goes into designing an API.

Things I've learned about API development:

• if in doubt, leave it out; it's always easier to add to an API than to remove something from one. This is what's known as the pain of deprecation.
  
  
• naming conventions in API implementation should be really straightforward; you ought to be able to read an API without too much documentation (should read almost like prose)
  
  
• the planning of API's are of extreme importance. A good API can be a godsend of efficiency to a company and a poor one can be a total disaster, and impossible to overcome.
  
  

We have started upon our own API development with regard to the Solar Decathlon Team Hawaii project.

The Solar House being built by the University of Hawaii Team is made up of several subsystems (Aquaponics, HVAC, Lighting, etc.), all of which will feed information from sensors to an intermediary system named iHale. iHale is based on the REST architecture and is the backend system that allows for the exchange of information between the house subsystems and client applications (mobile browsers, desktop apps, etc.).

Here's a diagram of the iHale system and how it interacts with other systems within the house:

Team Name: Nai'a (Dolphin)

REST API: Here

Java API: Here

Looking back:

The hardest thing I think was grappling with the magnitude of the entire project and completely understanding the requirements. The option of sending commands to the house subsystems also complicated things to a small extent. Prior projects had basically involved tweaking existing mockup eclipse projects, but this project involved applying the previous three modules to create our own structure.

This did, however, give me much more insight into how API development progresses, and how you try to not only code to get things done, but for the most flexibility and understandability in the future. I think I have a much clearer understanding of REST now that we have concrete resources (the sensors and database objects) and verbs (getting the data from the sensors and pushing commands to the house subsystems).

Also, in an attempt to streamline the API, we did not include a database to hold a record of actions committed by the home user. We were unsure how this data would be used; we can definitely see a use for historical state data, but the added functionality and overhead of adding another database table didn't seem to be worthwhile. If the need comes up, the system has the flexibility to add this if necessary.