Week 14

The final week is here. I remember when I started writing these blog entries thinking that they were due so close together that there was not going to be much that I could write of that did not sound redundant but the truth is with the pace at which this class moves it has not been that way. I am so glad I took this course, prof. Downing's class has been by far one of the most enjoyable and interesting classes I have taken at the University of Texas at Austin. The class material does not feel heavy or dense given that we basically analyze code as a group and move on whatever direction he intends us to. And the techniques we learn in class are definitely very valuable for the projects we have gotten assigned during the semester. Now that I look back, the first two projects, in my opinion, are basically a way for us to develop and polish our Python and general-programming skills. The last three projects (which really is just one big project divided into three different iterations) is where the depth comes in. I have said it before and I will say it again, what an experience it has been to work with 5 other software engineers and building such a cool application. I am very grateful for the experience.

Another aspect that I have really enjoyed about professor Downing's class is how oriented it is toward helping us during interviews and real-life projects with companies. He has brought several different guest speakers who have given us a fresh perspective on how what we have been learning in Software Engineering translates to their specific work environment. So we definitely have a good grasp on how the skills learned here will be of help in the future to whatever companies we end up working for (fingers crossed). I remember one of the guest speakers even went as far as telling us what he and the rest of the recruiting team at his company ask for in an interview. It has been a great class, definitely take it if you haven't!

Week 13

Well, this week was one of great achievements! We finally finished our IDB project and with it, the very last project of our Software Engineering class. I have said it before and I will say it again, this has been definitely one of the funnest project I have had in school and one that involved lots of learning and getting familiarized with several different technologies that interact together (which can get quite intense!)

For this last iteration of the project, the number-one task that Blake Ellingham and I had was incorporating the search bar into the site and providing a "Google search" feature within the data we store in our database. We used HTML and CSS for the search bar itself and customizing it. However, we relied on Javascript to be on the lookout for the user typing in data and clicking the "Search" button. At that time the first thing we do is parse the query. For example, as stated before, we added pluses where the spaces used to be for the purpose of redirecting to a different page.

We also created a different template to display the search results. The results are divided in terms of AND and OR results, meaning if the user searched for more than one word, then different results will get filtered into these two categories. I definitely strengthened my HTML, CSS, and Javascript skills with this last iteration of the project. I really enjoyed it because these technologies, in my opinion, are not taught in depth in school (I still have no idea why). So it was a great opportunity to get more familiarized with them and work on a project that simulated very well what working on a "real world" project is like. Working in such big teams can get quite complicated especially when it comes to communication.

I would say my biggest take away in terms of team coordination is that keeping everyone in the loop of what's happening in your team is key! If everyone knows what's going on, on all ends of the project there will be less room for confusion.

Paper blog

For a relatively long time I have been interested in the Mobile Application Development world. I think that the world we currently live in is rapidly becoming a friendlier place for both people who develop these products and end-users. It's a vicious cycle, a "build-it-and-they-will-come" type of situation. Today, good business practice translates to a smooth transition between whatever it is the business does and the technology it uses to carry it out. One of the many pieces of this technology puzzle is Mobile Development.

I chose a paper written by the Department of Computer Sciences at the University of Wisconsin Madison dealing with the analysis of mobile users' experience through two popular but very different applications. In order to measure and analyze the differences in user-experience they built a measurement framework and library, which when installed on applications could measure anything from "battery drain rate" while using the app to session length.

I think this way of "behind-the-scenes" data-analyzing is very effective for the developer given that they can capture instantly the way in which users respond to any particular feature. Additionaly, it is very helpful because any bugs or feature issues can be addressed right away when it is first detected. I do think it is somewhat intrusive on the end-user given they get access to a lot of their information but I imagine they agree to the terms when they decide to download the application. One of the most interesting facts I learned is that devices with relatively same CPU, memory, and battery capacity showed considerable differences in battery performance. They mention the Kindle Fire example where controlling the screen brightness reduced the average battery drain by 40%. I imagine this allows developers to engineer different enhancements to the application, corresponding to the device it is being downloaded in, so that battery can last the most in each one. Different devices may demand different things and, although painful for the developer to create different versions of the same product, this can help end-users some trouble.

Another cool aspect they mention on the paper is the fact that usage behavior is impacted largely by its platform and audience. For educational applications, for example, the daily active users was highly correlated with the day of the week. This may come into play in significant ways for the developers. If the application is being used mostly on week days (for schools or universities) then there is a clear need for their servers and everything supporting the application to be at its best performance during those days, allowing them to perform any routine tests, updates, or experiments on weekends. These analysis definitely shape the way an application interacts with end-users.

Altogether I think this is a very neat way of capturing data, in the paper they break down all the sections that were analyzed and the corresponding information. I think that this type of analysis saves developers a whole lot of surveys and marketing strategies to determine whether they are succeeding in the way they are portraying their product. It is very efficient and time-saving. I do consider that Mobile Development will continue to be an outstanding piece of our technology environment and that they will continue to come up with ways in which developers measure our response to their applications.

Week 12

One week less to go, between this class and O S I have been very busy but this week was interesting for Software Engineering. We touched up a little more on refactoring, we kept working on the example of the Blockbuster video store and worked with Java's reflection tool that, in the example of professor Downing, allows for creating an object of a particular type, deciding which type at runtime without using switch nor if statements.

On Wednesday we had a guest speaker who is a former student of professor Downing and took Software Engineering with him. He definitely had good advise for us as well as lots of information about his start up, "The Zebra". As far as advise, he spoke about technical interviews. He recommended a book, whose name I can't remember, but I was surprised it wasn't "Cracking the Coding Interview" because that is the one everyone talks about. However, he also recommended a website called www.careercup.com whose CEO is Gayle Laakmann McDowell, the author of "Cracking the Coding Interview." He also mentioned it is very valuable for students to have interned before looking for a job. Other than that, he spoke quite a bit about his start up and the way their software works. One of the cool things was the issue tracker they use for software repositories. Contrary to Github's, the one they use (Pivotal Tracker) allows them to keep track of points and owners which, in their system, is highly relevant. The layout was pretty different than Github's.

On the other hand, my team and I started working on the very last project of this class. It is a continuation of the previous two projects, so basically we will be enhancing our website with new features. As front end designer, one of the features I recently was able to contribute with, was the incorporation of a search bar so that users can search for any content on our site. I used javascript to call a function upon the clicking of the "Submit" button. The function then parses the user input and searches the database, fun stuff!

Week 11

One week less to go, the second phase of the project consisted of making all the data be pulled dynamically from the database, which meant basically getting rid of anything that used to be working statically. Thankfully, my group and I implemented the templates this way since phase one, so in this sense we had relatively less work than other groups. However, there were still many other things we needed to fix or get right in order to get past this phase. One of the less exciting tasks, I think, was the actual researching of the data that would go into the database. Some of my team members wrote a script that pulled all the data we had saved in an excel file, parsed it, and saved it in the database so in that sense, the actual population of the database was very efficient. For the frontend we rearranged some of the objects in order to account for larger chunks of information (now that the database was going to be fully functional). However, most of the work was done in the database and API sections.

I'm linking quite a bit what we are currently discussing in class: Refactoring. Prof. Downing is using the example of a video rent store and has shown us how to improve potential code that checks things like whether a specific client has returned a movie that was rented x amount of days ago. I think the idea of refactoring is very sexy given that it cleans up existing code and makes every thing run more efficiently. This is always a plus in software engineering. In parallel, my project group and I did some refactoring during phase 2 to some of our phase 1 code. For example, one of the changes we made was the associativity between Classes. Before, in phase 1, if we wanted to delete a Game from the database, we would have to disassociate it from all the consoles and studios that it had and delete those if necessary. The new way we did it was so that if we wanted to delete it we could just go ahead and get rid of that piece of data without having to worry about relying objects.

Week 10

One week less to go! In terms of projects, this week was the ready-set-go week for the 2nd phase of project 3. The main goal of this phase is to change everything from working statically (if any) to a more dynamic approach. So, in our particular case, no more hard coded names of games, consoles, and studios in our splash page. However, thankfully during phase one we decided to take the less appealing approach at the time, which was making everything dynamic from the get go (except for the references in the splash page). So since last week our project has been using templates for all the categories and feeding them with data retrieved with the help of Django and our API. So in terms of that we really have less work than groups who implemented everything statically during phase 1, however, there are still other aspects to phase 2. For example, during this phase we will be implementing the data base that will be feeding the data from now on. That is what we have been doing during the weekend. This actually has a lot to do with what we have been discussing in the class room (SQL and getting information from data bases). I think that in the end, when the project is complete (after phase 3) I will feel very proud of it and will probably be able to talk about it during interviews and any type of professional environment. It has been by far one of the most "real-world/professiona-ly" projects I have worked in since I have been a student in UT CS.

In class, prof. Downing has spent some time teaching us how to code in SQL and different techniques to manipulate data stored in large databases. This obviously comes in very handy for our project. I am also currently taking a class called Data Management, which emphasizes quite a bit on SQL so between that class and prof. Downing's Software Engineering I have began to feel very familiar with SQL's syntax and way of manipulating data. We will see how all this fits into phase 3 eventually.

Week 9

This past week was the first week after Spring Break. My team and I knew that the project would be due right after the break so we spent the break getting familiarized with the technologies that each would be using in its respective task. I chose to work on the front-end along with Blake Ellingham, so I started researching Twitter Bootstrap templates and going through the source code to see how my group and I could adapt it to fit our project. Before leaving for the break we had discussed what the splash page and what the templates would look like, so I had an idea of what I was looking for.

I had a lot of fun with this phase of the project. We used technologies such as Twitter Bootstrap, Django, Heroku, and Apiary. Our splash page looks very sexy and I learned a lot about passing information through JSON blocks, which I hadn't used before. I am looking forward to the next phase and hopefully I will learn a little more about the back-end that supports the site, given that the front end is pretty much done. We have working templates that can display any data that is fed to them. As I mentioned in my previous post, one of the features that I had never experienced before was working with five other software engineers in a project. It really gave me a sneak preview of what, in my opinion, some projects in the real world will be like. The whole team is divided into sub-groups, they all complete their assigned tasks, and then we all combine our results to make up for the whole project. It's a really interesting, chaotic at times, and efficient way to work.

I would say one of the take aways my group and I got from the project is that communication is key in order to succeed. It really cannot be emphasized enough, planning ahead and staying in synchronization with the rest of the team definitely pays off in the long run. We, as a team, will work on that to improve our efficiency and working style altogether.