This week, we continued with the project we’d been working on last week. As I mentioned in last week’s post, we’d been split up into two team – the data team and the front end team. Though we worked together last week, we spent this week mostly by ourselves, finishing the tasks we were given by Chip. The two of us on the data team, Quinn and I, worked together to create a stable database which the front end team could then use to create the quiz that the users would then take.

We started off by using the POJOs from last week and creating a library which we could call to parse them. We wrote a parser class for each POJO we had created, which we could then use to parse the data we were receiving from the POJOs so that the file would return the data in a specific file format.

To proceed, we needed to have our program be able to read the data from where it was stored, which is the database. Since a lot of the data we would be using was in the process of being ported to the AWS cloud, we decided to use DynamoDB as our database, which is Amazon’s default NoSQL database. One performance benefit we can get from DynamoDB is that while SQL databases are strongly consistent, DynamoDB is eventually consistent, which leads to high performance benefits when transferring large amounts of data, as the system does not have to keep track of all the data in the system all the time while needing to modify it immediately.

Once we had become familiar with DynamoDB, we spent a day or two writing more parsers for different output datatypes, and implemented a system by which the users – who, in this case, are the exam designers – could choose which files they wanted to be displayed and how.

We then finished off the week by writing programs that could convert the data we already had in text files into the data format that we needed, as well as an interface that could directly ask the user for the data and write it into the system. This, for me, was the most fun part of the week, as we had previously only known how to write the data directly to the database without using any programs, but through this we were able to change what was in the database and keep expanding it so that we could have our entire question bank in the database without having to go through the trouble of writing it all straight to the database.

This week was definitely the hardest in terms of work we had to do, but it was also one of the most fun weeks, as seeing the project slowly come up in front of my eyes is a wonderful feeling, and I’m excited to see where we can take this project!

This week, the interns were given a project of our own, which all of us were told to work on together. The project was creating a test for users of the website, which is something that will be deployed to the actual website once we finish working on it. Being really excited, we wanted to jump into the project snd start coding, but Chip had something else in store for us – We were not to write a single line of code until we had a concrete plan about what we were going to do, how we were going to do it, and what we would accomplish by it.

We spent three whole days on figuring out our entire plan. We had a rough idea of how we wanted the project to look, but a rough idea wouldn’t do. Chip helped us in the first few steps, by showing us how we were to figure out what we needed to do to formulate the plan, and from there, he left it to us. Ultimately, after running through each possible use case and all the pros and cons the application would have, we were able to come up with a ~700 line document that described exactly what we wanted to accomplish, and how we were going to accomplish it. Chip seemed to be pleased with that, so he gave us the thumbs-up to begin working on code designs for the project.

We were split up into two groups, with two of us working on the back end, with the databases and tables for the project, and the others focusing more on the front end, with what the user interface would look like. The front end programmers took off to do some more strategizing and working, and left Quinn and I, both backend workers, to do our job.

Finally, Chip asked us to start the project off by writing basic POJOs (Plain Old Java Object), which we then filled with getters and setters, so that they would be able to handle the passing on information back and forth easily. We worked on this until the end of the week, but now we have a good framework that we should be able to build upon next week, when we begin the real work of implementing everything we came up with. Look forward to reading about how we make progress on our project!

This week started off with me being assigned to the data team to help them with their problems. As I sat with them and started to learn the technologies they used to do their jobs, I began to understand that a major component of data retrieval and parsing is handled by threads, as they increase the efficiency of the code, and make the operations much faster. This led me to spend some time on my own, learning how threads function. Chip picked up on this, and offered to teach all of us how threading and concurrency work in java. He showed us this really interesting sorting algorithm called SleepSort (look it up, it’s hilarious), and used it to teach us how threads work.

After all the other interns had gone to work on their individual projects, Chip sat down with me, and we decided to go through some old code that StockCharts was using, and find ways to refactor it by possible using threading, but with the main goal of making the code more readable and efficient. We found a particularly interesting bit of code that already used threading, and decided to look into it and try and make it more efficient. Expecting to not have to work on it for too much time, we sat down, ready to refactor.

The code, we learned, wasn’t something that could be cleaned up in a few minutes. Chip and I sat there for hours, trying to clean up the code and make it more readable and efficient. There were many parts of the code that weren’t very important, and could be done better. There were also parts of the code that were completely unnecessary. One such part of the code was a synchronized method, which didn’t seem to have any practical purpose at all except for keeping better logs. Synchronized methods force threads to only be able to execute the method one at a time, and the next thread is only able to access it once the first thread is completely done with it. This is to prevent concurrency issues. Now this function. while helpful, also highly cuts down on the benefits that would be received by using threads, as this would nullify the performance benefits that came with the threads, especially if it was used for something non-essential.

We found a few such methods, that were synchronized even though they had no reason to be. We spent the whole afternoon cleaning up the code, and when we were done, it was supremely exciting to see the difference we had made in readability, extensibility, and efficiency.

This tale has a realistic (which is to say, sad) end – we couldn’t get the code to run for a while, as we had to fix all the other classes and packages that were dependent on this bit of code so that they were able to run it properly. The code eventually ended up working, and it was a happy day for all of us – well, those of us who worked on it, at least. The other people didn’t seem to share our level of enthusiasm about this.