This is an ongoing hobby project of mine. I have more data, just haven't dedicated as much time since the season ended. It's pretty fun to play around with, and I hope some fans can appreciate the
encyclopedic nature of the project.
GO Phils!
This project required lots of data retrieval, which was one portion I did the most work on. Using Python to collect information from the web after a semester of practicing was fun for me. Part of what made it fun was the anticipation of running a script
to collect the data and waiting stretches of time to see what dataset was returned.
Another thing that stands out was configuring the sort method used in the height analysis. It took a good deal of time and specificity,
but the end result felt worth the effort.
For this project I managed the majority of what is seen. I built the webpage, wrote the Javascript visualization coding, acquired the data, and came up with the topic. My team mates helped with Tableau visuals and giving style input, as well as helping with the documentation.
The most complex challenges of this project were collecting data, organizing it, and displaying it. Not having access to an API challenged us to build our own. What was turned in included a server that utilized JSON to populate data. This was not formidable with the charting method of CanvasJS however, what was ultimately turned in had a 'Populate Data' button that was required to make the visuals visible.
If I were to redo the project, I would change the data handling to use a SQL server that would negate the need for a 'Populate Data' button, or avoid the server need all together by writing the data points as they are currently seen(entirely in the JavaScript).
This was a collective effort, but I was responsible for the web components and created a few of the data visualizations, along with the visual playback of traffic densities over time. My partners performed technical analysis with work that is included on the site in R Markdown files.
The challenges were mainly time constraints, which made data cleaning and analysis have to be more condensed. I am glad we used Tableau for the most part because it can alleviate a lot of pressure caused by not having a long duration to complete the work.
There isn't much I would have done differently, but given the opportunity, I would go back and perform some analysis in Jupyter Notebook, and convert it to HTML similar to the R Markdown files. Also, I think if I had known the world around me was about to change dramatically, I would have put forth more effort. However, I am happy with what we accomplished, and there's not much I would change.
This was the first time I ever worked on an information problem using web components to address and present them. It opened a door to web applications that I have continued to work on and use in my research and studies. I really enjoyed being
able to present a project in class where I could guide attention from us presenters to peoples phones. We opened with "If you'd like to follow along from our site, pull out your phone and go to 'pgcelection.herokuapp.com'."
It felt
like a real accomplishment coming from a group of individuals that had never worked on a website prior to that semester.
Prior to the final presentation and demonstration, we gave a preliminary presentation concerning our goals and
ideas related to the project. One thing I focused on was the table of locations. There were roughly 270 polling places to consider, and I hoped to help users get directions with the click of a button. Happily, we delivered on the goal
of having a searchable, sortable, and dynamic list of locations; each providing a link to Google maps for directions, and each being delivered from a server built using JSON script.
The leadership of this project is well documented in the final report, but I was the project manager and helped guide a lot of our efforts. My group members played pivotal roles in styling and aesthetics, along with some technical parts that help to make the final project what it is. We all learned a lot from eachother while also learning what we did in the process of building a web application.
I never imagined how difficult it could be to make a table that works well on a website or mobile application, but it is surprisingly tedious, and requires real decisiveness. In order to keep a data table aesthetically pleasing on a phone, the data needs
to be super tidy, minimal, or very selective. If you build a server to facilitate the data going to that table, it can be even more time consuming.
Getting on the same page with a group of undergraduate students
can be more tedious than building a reasonably web-adaptive data table, and for our group we struggled early on to communicate effectively. Until we finally sat down for about an hour and worked together to right the ship, things did not
look very promising. It was imperative to define our roles and make concerted efforts to complement one another.
If I were to go back and change anything, I would probably have put more time into the mock ballot and improved the appearance. Another goal I would have focused more on, would be serving up ballots based on specific precincts. That was an aspect we left unfinished, but would have served to create a more meaningful prototype for a voter information site.
My favorite part of this project was the end result, but the process was filled with enjoyable moments. Creating a Graphical User Interface was completely new to myself and my group members. Learning Object Oriented Programming with Python
over the semester and being able to apply those skills in a tangible way was very satisfying.
The game logic is essentially my understanding of how Spades should be played, and took a lot of effort to script. I'll discuss what
I would have done differently below, but I'd say it's comparable to creating an algorithm. Seeing it function as intended felt very empowering.
I served as the project manager for this, and led much of the technical efforts. My group members helped a lot in piecing different parts together, and went to great lengths in testing. The implementation of music and time delay between cards appearing/disappearing were mostly accomplished by others in the group.
There were many challenges with this project. When we started, we still had not learned some concepts that would have been very helpful to have comprehension of. Most of the group not knowing the rules or having experience with the game
also created some obstacles, but that was part of the fun for me at least; it meant we got to play cards together to improve understanding!
There were a lot of mistakes made in building the game that can be attributed to overcomplicating
things. I discuss this further below.
Were I to redo this project, I would simplify the rules and logic. There would be more 'Classes' than the ones we used, and shorter snippets of coding for each part. This would create cleaner code that would be easier to understand, and
hopefully reduce the amount of if-else statements required.
Another thing that I would do is define group member roles more exclusively so things came together more smoothly, and I would ensure each of us were competent with GitHub
to avoid unnecessary rework and complicated sharing of work.
Although my team did not win a prize for this project, I enjoyed the outcome of our efforts. In one week, the four of us used our skills to look at a problem as thoroughly as possible and present something in an effective way. It was a great experience in data analysis and one I used to build on the following year.
This project was a strong group effort, and I cannot quite say I was a project manager. What I can say is that I had a strong influence on how the project was presented and was responsible for the filming, editing, and interviewing seen in the video clips. I was also responsible for the sampling distribution charts that involved running simulations in R-studio. In my opinion that was made a strong case for the idea that weight/size made a difference in disease susceptibility.
We had trouble focusing on the parts of this project that would have helped us get to the point quicker in presentation and gave too much of an overhead look at the problem, rather than looking at the most meaningful results. While I believe interviewing a subject matter expert was helpful in conveying the subject of the information problem, I don't feel it was necessary for the purposes of the project. However, I did think it was necessary in setting us apart from the several competitors that chose the same dataset to work on for the Data Challenge. All in all, I think we could have wrapped things up more efficiently and had a more effective project, but I am happy with what we put together.
Our group put together a 'one-pager' for our judges to peruse regarding our presentation. At the time we put the project together I was lacking in the areas of web design and GitHub repositories. This had a negative effect on presentation and group cohesiveness. What I would do differently, and did so in 2020, was sharing work in GitHub and creating a website for our work. The second go round, instead of printing pamphlets, we printed QR codes to our website and had included interactive visuals generated using Tableau. It worked, and in 2020 my group won 'Outstanding Undergraduate Project'.
This was my first ever project that involved writing code. I really enjoyed this because it felt empowering to be able to write things into my computer console and get some results based on my input. It made me want to be ambitious with the project and push myself to do something that was actually interesting. Granted, I was very new to coding, and still have much to learn, but in the end I created a program that took user input and generated a technical report specific to them. It exceeded my expectations and I learned a lot.
To put it bluntly, there was no leadership in this project. None of us knew or were taught how to work together using a git, and sharing work was complicated. I did all of the work on this, and did what I could to simplify things to allow my group mates to contribute, but there were to many shortfalls in communication and lapses in technical understanding. I discuss further in 'what I would do differently'.
The greatest mistakes in this project were not actually returning results and not writing more functions. It's a print-centric program.
The first thing I would do differently is get everyone on the same page using GitHub. Secondly, I would work with my mates to better define our roles, and hopefully create more cohesiveness. Third, I would have done things in a more object oriented way
with cleaner scripting.
EDIT(12/16/2024): I still include this work as an example, for the sake of what it was addressing. Without bias, observing pay rates across an organization, you begin to understand the values as well.
That is not to say that I saw anything wrong with what I found, but for an expert, having the ability to quickly crunch numbers is a tremendous asset. I would not have done a thing differently with this project, except for wear a helmet that one day I crashed my bike
One other thing I feel now, is that my groupmates did a decent job for Python being new to all of us and I appreciate what I learned working together.
