Archive for the 'Projects' Category
This past academic quarter I elected to do an independent study. A lot of hype has been surrounding web development over the past few years, and the python scripting language for even longer than that. Figuring it was time to immerse myself in both subjects and the technologies related to them, the independent study turned into a full four credit project aimed toward creating a web application for administering quizzes. Because I only had ten weeks to learn everything involved with developing a web application on top of the language, I coerced my good friend David Brenner into doing it with me. Development is done, and I now feel like I can talk intelligently about my experiences.
The project was developed using straight python, utilizing the mod python Apache module to serve Python Server Page (psp) files. Python isn’t my favorite language to code with, it is lacking some things that I’ve come to expect from a scripting language, and some things are just silly. Examples of lacking features include the ability to get an iterator for a collection. Iterators that grant references both to the next and previous element of a collection grant superior control and the ability to keep state while iterating. Python only allowing you to move forward through a collection with its “for x in collection:” construct really hurts while parsing large sequences of text, and having to revert to array notation and keep an index is much less human readable than just manipulating an iterator.
Annoyances with the language include python being a scripting language that doesn’t default to printing the string value of non-string objects, and using procedural style method calls intermixed with object-oriented style. For example, to print an object (say an array), you can’t just do print(“Array contents: “ + arrayName). You have to manually return the string value by using print(“Array contents:” + str(arrayName)) in order to avoid an error that print() was expecting an object of type string. I know python’s mantra is “explicit over implicit,” but languages are tools that you learn how to use. As I learn more, I expect to gain proficiency with the tool in order to save me time in the future. Python is easy to learn and easy to use, but I have yet to find any tricks with the language that save me time or make my job easier than it would be with another language. One last thing that I simply do not understand is the necessity to include a reference to “self” in method and constructor definitions. I strongly prefer the method signature to match the required call, python’s decision to branch from that convention is one that I can’t imagine will have a justification strong enough to alter my opinion of the practice.
As it goes with web development, we also used javascript, a MySQL database backed with InnoDB table engines, LDAP for authentication, HTML, and CSS. Development was utterly boring. Being a computer science student, I enjoy working on new things that present challenges and reward creative solutions. The most thought intensive part of this project was the parser run on imported quizzes using a format we decided on – and that was developed in the fourth week. Everything else was the brainless transfer of requirements to code. Some of the people I go to school with are attracted this kind of development, and I think I know why: frontend web dev is easy. Writing the backend logic isn’t bad, but the interface code and associated handlers could be composed by a high school student with some spare time and only rudimentary knowledge. The things learned in computer science definitely aren’t applied in that domain.
Finally, to wrap up loose ends: object relational database design is neat and very handy, javascript is odd at first but easy to pick up, dealing with web requests and forms is tedious, debugging web applications is a *bitch,* and Debian Linux with Apache, Subversion, screen, and vim makes for a great development and hosting environment.
Web development has its place, but it isn’t for me. I’m capable with python, but I’ll stick with ruby. And if you introduce yourself to me, try to be more descriptive than “I’m a web developer” so my experiences don’t tarnish my opinion of you – because I bet you are more skilled at writing code than that title would suggest.
While working on our independent study, Dave suggested we use foreign keys to establish relationships between our databases. We were using the MyISAM engine by default, which doesn’t support foreign keys. The fix to the problem was simple. Since our database doesn’t have much useful data in it, popping open the createdb.sql script we are using in Vim and issuing one quick command took care of everything:
:%s/);/) ENGINE=InnoDB;/g
Now all of our tables are using the InnoDB storage engine. I love Vim!
I’m one of those people that tends to get distracted when I’m procrastinating. Most often, this comes out when I’m doing a programming assignment and I go to open documentation in my browser. For those of you that weren’t aware, Firefox and Stumbleupon are a developer’s worst nightmare - so many interesting things, only a click away! It had to stop.
So I hacked up DocBrowser, a minimalist’s web browser created solely for the purpose of quickly accessing documentation and APIs. It is free of clutter and distractions, leaving only you and the information you seek on the screen. It is not extendable, and its feature set is limited. It is therefore exactly what I had in mind when I started coding it.
I’ve created a page for it here. It is free, and is only 1.5mb, so why not download it and give it a shot?
Windows only, requires .NET 2.0.
Last time, I talked about the requirements and initial division of an attendance database project for Computer Science House. If you recall, we left off with the project having been split into parts that will eventually be coupled into a complete system - these parts being an iButton interface, iButton back end, user interface, and client back end.
Mark, having been on the last team’s attempt to create this database, was tasked with getting our preliminary idea of what the database should look like up and running. Additionally, since he’ll be working directly with the database, I’ve assigned him the task of creating a PHP interface for interacting with the database. This interface will be called from the user interface as a means of centralizing the database calls for easier updates and maintenance.
Dave offered his help with whatever module needed developing, so he is primarily responsible with developing the user interface. He’ll be using PHP, JavaScript, and CSS as his development tools, utilizing Ajax-ian techniques for creating an interactive interface. This is going to be the most time consuming part of the project, so while Dave is responsible for the primary design and page layout, both Mark and I will be jumping on board to implement specific features when our parts are complete.
As for myself, being the only one with the iButton hardware for now, I am implementing the iButton interface and back end. The technologies I am using are Java, JavaScript, and LiveConnect. Java allows for the development of both the iButton communication application (the iButton interface) and the applet (iButton back end), the first of which was necessary to use the iButton Java SDK, and the second of which allows us to use LiveConnect to make the iButton IDs available to our web user interface invisibly.
The division of the project into smaller parts allows each member of our team to develop in parallel. With an emphasis placed on clean, self-explanatory interfaces existing at the points in which the modules come together, core development should proceed smoothly. As a bonus, each member is granted the freedom to develop in their own style at their own speed, with the only required communication occurring when it is time for members to link up their pieces.
For now, we code. See you when it comes time to integrate!
In my short career as a software developer, I’ve gained experience in multiple programming languages, development styles, and team roles. One role I have yet to play however is project manager. Transforming an idea into an end product using several stages of development with multiple people using many necessarily distinct technologies has always intrigued me (and here is my first public announcement-) an ideal job. Since there is no room for me to gain experience in this arena at my current job, I’ve decided to take on a small project and recruit two others to help me mature the concept and realization of a meeting attendance database for Computer Science House (CSH).
The basic idea of the attendance database falls in CSH’s need to record when members attend committe and general house meetings so we may conduct evaluations of our members. It is a simple idea until the requirements are analyzed. They are as listed:
- The system must be able to store and retrieve which members were present at a specific meeting.
- The database will be on a central server, but the client must be multi-platform and portable.
- The system must be able to able to verify on some level that a member was physically present at a meeting.
- Corrections to the database shall only be made by the executive board member presiding over the meeting.
And once these basic requirements are met, features will include:
- The system must be accessible in the absence of an Internet connection.
- The system will make the job of the executive board members easier by not requiring their involvement in recording a member’s presence at the meeting.
- The system will include functionality for the evaluations director and chairman to generate reports of meeting attendance for all members to aid in quarterly evaluations.
Once equipped with the requirements and feature requests, I set out to find a couple of intelligent members that could aid in designing and development of the project. They are David Brenner (chairman, spring quarter ‘07) and Mark Schillaci (evaluations director, ‘07-’08). Dave learns as naturally and relentlessly as his heart beats and is capable of grasping abstract concepts easily. This makes him great for picking something up and applying it quickly. Mark is less experienced than Dave or I, but is also sharp. The reason I asked him to be a part of this project has two factors. First, he was on the last attempt to create the attendance database, and second, because he isn’t afraid to dream. This second factor paired with his lack of fear of being wrong yields great ideas that, when grounded and refined, become solid and actionable contributions.
With a team assembled, analysis of the requirements and how to move them into implementable items began. The first step was a separation of the system into components: the database and the client. Following this, an analysis of the components was made in order to fit the requirements. The database being hosted centrally is a given, so it really doesn’t need further discussion. The client requirements state that it must be portable and multi-platform, and obviously must be able to communicate with a database remotely. Additionally, it should be able to verify the physical presence of a member. This one is more interesting.
When developing for multiple platforms, the most efficient way to proceed is to create something that has a single interface for all platforms and a codebase that requires little or no modification to make available to other platforms. This results in creating a single user experience regardless of their operating system, and most importantly as a developer, an easy to maintain system. These objectives are most easily achieved with a web application, where any user with access to a graphical web browser that supports javascript will be able to use our application.
The issue of verification on the client required more thought, and came to me while I was working on another project. The first method proposed by the developers of a previous attempt at creating the attendance database was to have the executive board member or house secretary log in, then manually type in or check off the names of people who were present. This system is flawed - it relies on the individual entering the information to see each member, which in a crowded room with members sitting behind couches can be unreliable. It also leaves the members not knowing if the person taking attendance noticed them, resulting in their asking “did you get me?” Immediate feedback to the member is necessary to prevent this. My solution to this problem is to use iButtons.
iButtons are a technology that in their most simple form are capable of carrying a guaranteed unique 64 bit ID. We already use them on CSH in our Drink projects Big Drink and Little Drink, as well as in prototype implementations of our iButton doorlocks, so the technology is not foreign to our members as an identifying token. In our case, a USB iButton reader would be connected to the laptop from which the attendance database client was running, and members upon entering the meeting place would click their iButton into the reader which would then record their attendance at the meeting. This solves the requirement of ensuring a member is physically present at the meeting and easily addresses the feature requesting that little involvement from the executive board member be had in recording attendance.
The final subdivison of the client ends up looking like this with the above taken into consideration: the user interface (graphical interface), client backend (database communications,) iButton interface (physical reader and accompanying software), and iButton backend (local communications with client). In the next part of this series, we’ll discuss the technologies involved, the solutions decided upon, and the initial roadmap of development.
