Software Engineering has been a great course overall. The course has covered many topics, from using various tools like git, Travis CI, and unit testing libraries to Python to SQL to design patterns. In addition, much of the work is done outside of class in the form of projects, both individual and in groups. The first few projects formed an introduction to some of the tools and processes that one might encounter in industry. The last three projects centered around building a website from scratch within a team of five people. The website project was a good experience for coordinating work with other people and learning how to put distinct parts of the project together. It also gave us the opportunity to work with databases, APIs, and frontend frameworks as well as see how quickly technology changes in even a few months time.

This week in Software Engineering, we finished discussing method overriding in Java and emphasized the fact that the type of arguments must match in order for the method to be overriden in a child class. One of the potential issues with this is that a change in the method signature in the parent class would result in incorrect behavior for classes who override that method. This issue can be avoided by declaring methods as abstract so that child classes are forced to override them.However, doing so is impractical in many scenarios because Java does not allow abstract methods to implement any behavior, so this may result in a duplcation of code in the child classes.

This week in Software Engineering, we started discussing various techniques for refactoring code. We went over the example about movie rentals in Fowler’s Refactoring book and discussed techniques such as extracting methods, moving methods between classes, and using state objects instead of type code. We also discussed the quirks of method overriding in Java and the danger of defining methods in children classes with the same name but different arguments. We also went over the difference between static and dynamic binding. The most interesting part of this discussion was how to figure out which method an object should execute if that is not known until runtime.

This week in Software Engineering, we continued our discussion on SQL, starting with the various types of joins (cross, inner, natural, left, right) and continuing with subqueries, support for set operations, and data aggregation. One of the interesting things I learned was that SQL could be used to calculate statistics on data sets in addition to just returning subsets of data.

This week in Software Engineering, we discussed commonly used regular expressions in Python before jumping into sql. We learned how to use mysql to create tables, insert data, and select data using where clauses and joins. This applied what we learned about selections and projections in relational algebra.

This week in Software Engineering, we implemented several relational algebra operations in Python, including project, cross join, theta join, and natural join. Although we will not be using these implementations directly in Python, it was useful to use a language we were already familiar with to explain a new concept. We also were introduced to xml and json along with the schemas used to define types and pointers within them. It was useful to learn about the advantages and disadvantages of each type of schema and see how they could be applied to the same dataset.

This week in Software Engineering, we started working on the first phase of the project for the remainder of the semester. For our project, we’re displaying information about Congress, including the current House of Representatives and Senate members, the Committees these members are in, and recent Bills that have been passed. Hopefully this would be useful in giving everyone a clearer sense of some of the activity happening in our government.

This week in Software Engineering, we discussed the various ways to pass in arguments to functions in Python. The most interesting thing I learned was the various uses of * and ** to unpack iterables and dictionaries when calling functions and pack them when using them in a function. In addition, we learned about function decorators, which is a super cool functionality that allows you to “decorate” your function with additional checks, such as for pre- and post-conditions.

Most of this week in Software Engineering was a continuation of what we did last week. With the test coming up next Thursday, Professor Downing gave us more problems to do during class to prepare us for what will hopefully be similar ones on the exam. Although the solutions to these problems ended up being really short and simple, a few lines of code at most, arriving at the “correct” solution took some thought. Without some of the hints we were given, I’m not entirely sure if we would have gotten the answers, but hopefully with some studying, the exam will turn out okay.

This week in Software Engineering was pretty hectic in trying to finish up Netflix and making sure all the requirements were met and acceptance tests passed. It was a relief to finally turn the project in on Thursday with a good enough RMSE of 0.96. Although this was not under 0.95, it was a definite improvement over the 0.99 we had last week.

This week in Software Engineering, we were introduced to our second project, Netflix. When the Netflix assignment was first posted, I was really confused on what we were supposed to do, and it didn’t help that I missed the class where we went over it due to an interview. Even after my partner explained it, we were still unsure how to approach the problem. I think one of the reasons why was that the project is very open-ended and much of it is based on analyzing empirical data and making educated guesses off of the trends. In addition, much of the project involves creating caches of the given datasets or using other team’s caches, so there was a lot of work that needed to be done initially to get the appropriate information. It took a few days of work, but when we finally got the root mean square error under 1.00, it was really exciting.

This week in Software Engineering, we had our first guest speaker from Bloomberg. He gave us an overview of the tools and technologies he used on the job as well as advice on finding a job. I think one of the best pieces of advice he gave was to evaluate during interviews whether you would like to work with your interviewer and to realize that interviewers are probably doing the same to you. As I interview in the next few weeks, I definitely need to keep this in mind.

The second week of Software Engineering started to pick up a bit as we were introduced to our first project. I thought how Professor Downing went over the major components of the project each class day was really useful in digesting all the requirements introduced in the project specification. I like how the simple problem we were given still has many components to it that make the entire project interesting. Although I have not gotten the chance to really start working on the meat of project, I think having a roadmap in my head will really help. I do wish I had started thinking about Collatz before class on Monday just to get a chance to figure out some of the things for myself, but I’m sure there will still be plenty of challenges to work on.

This will be my first time writing a blog (at least with consistent entries), but I think it will be an good experience. At the very least, writing lets me take a step back from a normally hectic schedule and organize my thoughts a bit better. For this first post, I want to focus on my perception of Professor Downing’s Software Engineering class at the time I signed up and how it has changed after attending the first few classes.