The inspiration for my most recent iOS app, Color 360, is quite interesting if a littly lengthy due to some necessary background information. As a researcher in a bioanalytical laboratory, a large portion of my work was developing methods to measure concentrations of drugs or small molecules in various matrices such as blood plasma and urine. These methods must meet certain FDA guidelines in order to validate the resulting data, and a significant aspect of these guidelines is focused on the methods' reproducibility regardless of the sample's source. Every sample, regardless of matrix, will have different molecular compositions from source to source. If these molecular variations affect your method then the resulting data is unreliable and the method should be adjusted.

For one study we were analyzing human plasma samples and noticed that the plasma samples' degree of hemolysis had a significant effect on the method's result. Blood is drawn from the subject and centrifuged to separate the red blood cells (RBCs) from the blood plasma. Hemolysis is the rupturing of the RBCs during this process, and results in the RBCs' molecule rich contents to irreversibly release into the surrounding blood plasma. From a subject's genetics to the amount of time between the blood drawing and centrifuging, many factors determine the amount of hemolysis each sample experiences and this variability makes it important for an assays performance to be independent of this phenomena.

Unfortunately, our lab was unaware of this issue until after all the study's samples had been analyzed. To determine which samples were most affected our sponsor asked us to examine each sample and determine its degree of hemolysis. Hemoglobin, the molecule that gives blood it's distinct red color, is one of the molecules contained within the RBCs which means a plasma sample's degree of hemolysis is directly proportional to the amount of red color in the sample. A pure plasma sample with no hemolysis is a very pale yellow color and as the amount of hemolysis increases the sample color becomes more pink and eventually red when the hemolysis is severe. Our sponsor asked us to categorize each sample as either having none, slight, or extreme hemolysis.

For the purposes of the study, this very imprecise categorization method was adequate. However, the science nerd within me had a lot of issues with it because ultimately whether I thought a sample was "slightly" or "extremely" hemolized based on whether I thought the sample had crossed some arbitrary pink to red line was too subjective. While going through some of the samples I was thinking to myself there must be a better more reproducable way to measure how red a particular sample was and that's when I thought about using the camera on my iPhone, which is just a bunch of little sensors that literally measure colors. Excited, I went home and began pouring over documentation and various resources to learn how to access the iPhone camera and the resulting color data of a particular pixel, and within a few days I had a working prototype. Surprisingly, the app worked really well. As long as I calibrated the color scale in the same light as I measured the actual samples, and used the same calibrators from day to day, I could reproducably measure how "red" a particular sample was.

Once I had this prototype, I began having a lot of fun just pointing the camera at different objects around me and extracting the color from it. That's when I thought it would be cool to have an app that could capture and catalog different colors that you might come across in the environment around you. Obviously, there are serious unavoidable limitations (such as the color space of the camera being only a small subset of the real world) that prevent the idea/app from being complete, but ultimately I thought it was cool and therefore I built it anyway.

Wine Tasting Friend started out as a course project for my Advanced PHP Programming course, but as I often do with many of my projects I took it well beyond the required parameters. Since growing up in the Napa Valley I've always had a strong interest in the wine industry and absolutely adore the beautiful vineyards that were ever present throughout my childhood. During one wine tasting trip I came to the realization that there was no easy way to plan on the fly which winery was best to go to next. This stemmed from the seemingly basic but difficult to answer question, "What and where is the nearest wine tasting room that closes at X". The closing time is critical, as any seasoned wine taster knows if given two wine tasting rooms of about the same distance away, but one closes in 30 min and the other closes in an hour, then choosing the one that closes first alows enough time to go to both.

My original idea consisted of both a web and mobile application. The mobile app would serve as a wine tasting companion that you used while wine tasting to seemlessly find your next wine tasting room. The web application would serve as the primary way to create and update the underlining data. Wineries would sign up for accounts and update their wine tasting room information. Users could also create and manage their accounts from the web as well. When I was building this web application, I was already pretty experienced with PHP so this was a prime opportunity to really push myself and create a fully fledged PHP web application. That being said every aspect of the website was designed and built from the ground up by me (except of course for the winery information which was taken from various online resources).

I kept working on the project for a while, but eventually I was running low on time and had to put it on the shelf. Some key compenents of the website are as follows:

• MVC style object-orientated PHP backend
• Dynamically generated HTML content
• User account creation
• MySQL database
• Email verification
• Secure multi-level access
• Modular design for easy customizing

The first thing you might notice when working in a Good Laboratory Practice (GLP) compliant FDA regulated research laboratory is that there are logbooks for literally everything. Receiving samples... logbook, weighing chemicals... logbook, changing equipment... logbook, etc. Most biotech companies use expensive computer systems to manage this information logging, but many academia labs (especially ones with limited funding) must resort to old fashioned pen and paper logbooks. From legibility issues to making corrections, there are a lot of issues inherent to GLP compliant pen and paper logbooks, where all entries and modifications must be intialed, dated, and often co-signed by supervisors.

There are a few open source projects available for this sort of thing, but all of them were unnessesarily complicated and designed to manage entire labs by including things like supply ordering, sample tracking, data reporting, etc. This gave me the idea to create a very streamlined logbooking PHP application that could run on your lab's local intranet and fulfill all the GLP/FDA requirements. So I created DSU Logbooks, an object-orientated MVC style PHP application for creating, managing and updating labbooks in a GLP compliant laboratory.

This turned out to be slightly easier said than done thanks to a couple unique issues. Early on I made the design decision to avoid designing the application in such a way that directly represented these logbooks as individual tables in a MySQL database. My reasons were two fold, one I didn't like the idea of just creating a glorified MySQL query engine á la phpMyAdmin, and two I just wasn't comfortable with giving database create (and potentially drop) permissions to my PHP application. I understand that any security concerns for doing this could be mitigated with a little extra work, but I figured why not avoid it if possible. So I had to design a MySQL schema and data model that allowed for user-defined columns and tables, which as it turns out was a little tricky and took a couple iterations before the database performance was acceptable.

The other decidely complicated aspect to this project was figuring out how to do modifications. To be GLP compliant every modification to any aspect of a logbook entry must be documented with the initials of the person making the modification, the original item before the modification, and the reason for the modification. Incorpating this information into the database and presenting it to the user in a seemless easy to follow manner was not trivial, but then again that's what made it so fun to build.

There's not much to say about HTML other than I know it and I'm good at it. I first taught it to myself as a high school freshman, and while I haven't kept up with it 100% through the years it's fundamentally the same. I am significantly more interested in the software that outputs the HTML, but ultimately HTML is what the user gets so knowing it well goes a long way toward creating good user-experiences. CSS in many ways is more important than the HTML it accompanies, and while I haven't known it as long as I've known HTML I can say I'm proficient in it as well. Of course, I have a strong understanding of how to use CSS (from box-models to psuedo classes), but ultimately CSS is about aesthetic design and I'm much too biased to make any claims toward my ability in something so subjective.