OPW Application Project – Overview
This is the first of my documentation for the application project I submitted to the GNOME Outreach Program for Women. First, a little background…
In order to apply for the internship, one must make a small contribution to a FOSS project first. If you are selected, you get a paid 3-month internship where you can continue to hone your skills. In case you missed the last post, I was one of the fortunate ones! I’m thrilled beyond measure to have this opportunity. This internship goes from January 2 to April 2. I am asked to blog at least once every 2 weeks about my projects and experiences… but knowing me, it’ll probably be more often than that. This post outlines the contribution I submitted with my application, which was part of the basis for my selection for internship.
I am working on a cool and philanthropic project called TidePools, through the Open Technology Institute (OTI). In order to understand the following explanation, it’s worth checking out the TidePools website to get an idea what is going on. Should you wish to see the full code listings for my application project, here is the GitHub repository where my code will be stored. GitHub has a fancy interface that displays the code with syntax highlighting, which greatly enhances readability, so I won’t clog the blog by reposting my code here. (You can view the code by clicking on the name of the file you wish to view.) I will post key sections in future posts along with explanations.
At the moment, one can move the map around to locate landmarks and events in the local Red Hook community, but there is no way to search and get a listing. My task was to create a search engine so that users can search for name, description, event type, or location. (Date and time search will eventually be added as the details of implementation are ironed out.) The first three are simply keyword searches. Location will eventually involve clicking a point on the map, and then entering a distance in miles or kilometers from that point to get a listing of items within the given radius. Creating a new map, necessary to kick off the rest of the functionality, wouldn’t work on my own machines at the time; so for now, the “chosen” point on the map is hard-coded with the longitude and latitude of the Red Hook post office. That’s what the ‘input type=”hidden”‘ stuff with longitude and latitude is about, when you look at the search.html code and see:
<input type="hidden" name="lon" value="-74.001862406731" />
<input type="hidden" name="lat" value="40.674576233841" />
Later, when the search engine is integrated with the existing user interface, clicking a point on the map will determine the longitude and latitude to be submitted. Let me back up a bit and describe the involved files.
The first file, search.html, is just the HTML “code” to display an ugly and very basic webpage that asks the user what s/he wants to search for, and then sends that information to the program. It’s okay that it’s ugly, because the users will never see it. It just provides an easy way for us developers to test that everything’s working behind the scenes. Eventually, we will take just the little form box and buttons and paste that stuff into the spiffy-looking map interface. is just specifying a point in the map to start from, for an example. When this code is plugged into TidePools, those will be removed because the user can just click any point on the map and it’ll give that location to my program for processing their search.
The second file, search.php, is the code from the real program, written in the PHP web programming language. This program takes the search criteria, feeds it to the database to search for landmarks and events that meet those criteria, and then writes the proper HTML code to make a web page display with the search results. PHP is cool in that sense, because basically you’re writing the code that writes the code. The ugly results page will go away, too, because we’ll just paste this into the main program and the results will display all purty-like in a text box inside the nice little map interface. For location searches, the user can enter a distance radius in either miles or kilometers, which is then converted to longitude and latitude before searching (querying) the database. Location search was the most difficult to do, hands down. I’ll cover this in a separate post, as part of the difficulty was due to a scarcity of documentation and examples online.
Hopefully, this provides a useful overview of the project I came on board with, what I set out to do, and a few of the things that need to be done. More to follow as I delve into the code that made it work, and what I’m working on now.