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.

Week 8

This week, in my opinion, has been somewhat of a slow transition between midterm week and new material (plus the beginning of the 3rd project). We did learn a little more about Python's inheritance functionality and how it compares to Java's. We also spoke about some of the String functionalities, and Python's so called regular expressions. However, at least in my case, I think that the IDB1 project is what took the most attention during this week. My team and I started preparing and dividing the project among all members so we all know what we are supposed to be doing. Something that seems very interesting to me is that, for the very first time, I will be working in a project that will be divided into several sub-pieces, which will be brought together eventually to form the whole project. So this "divide and conquer" technique is a new one for me in terms of working with several partners in a coding project. It is worth mentioning though that, at all times, all sub-groups will be aware of what the others are doing. It's just that given the time constraint it does not make much sense to try to do the whole project as a whole group, especially when each group has between 5 and 6 software developers.

Now, in terms of the actual components that will end up forming the project, there are several that either I have never heard of before, or that I have never used. Heroku, for example, the cloud platform that allows you to build apps, is a tool I hadn't heard of before. I have read up on what it is and how it is used, this part will go to the team that works on the back end of the project. I will be working on the front end, which consists of using twitter bootstrap to come up with a nice UI for the website. About a year ago I created a website using the same exact tool so I have some decent experience with it but it definitely will be challenging to connect all of the pieces together later on.

Week 7

This week was midterm week, definitely a lot of pressure. I had already heard that prof. Downing’s tests were very meticulous and detailed-oriented. I felt relatively comfortable with the multiple choice questions given that I had done all of the readings, and then for the Python short answer questions I think I did run into some trouble at first but I think that I was able to solve them relatively decent as well. Definitely challenging questions. However, in the longer coding questions I did take some time to try and come up with a good design algorithmically. I am not sure what the balance will end up being in terms of my grade. I definitely think that what makes this test most stressful is the fact that we only have ninety minutes. It’s a very short amount of time when you think of the type of questions that are asked there. However, to be fair, prof. Downing does give us a so called cheat sheet so we can bring any information we want to the test. In theory this also contributes to the idea that it’s a very challenging exam but it’s definitely nice to have an information resource during a test.

In terms of lectures, this past week we also went over Python’s concept or way of “overloading” class methods. Prof. Downing used the example of writing an equals method so that it compares content and not memory address because, as in Java, the generic equals method goes directly to memory comparison. We also discussed iterators, which had some strange parts to it such as if you call the iterator function on an iterator, it just returns the iterator itself. However, I do feel much more comfortable with Python and with my programming practices and standard in general since this class started.

The next part of the class consists on a project that has been assigned in groups of approximately five programmers. We need to be able to come up with a theme that expands to several other sub-themes. I am not sure what the other requirements of the project are since I was not able to attend class on the day prof. Downing first explained the project, but I assume this week will start off with more information regarding the project.

Week 6

This week we have been learning a lot about the insides of Python in terms of coding advantages. I had never used lambda functions nor packing and unpacking variables in a function's parameters, but it definitely seems to me that, after getting used to such programming standards, a coder's cleverness would benefit significantly. At least, I think that the use of lambda functions are a very elegant and efficient way of quickly solving a problem by coming up with a function on-the-go. I still remember professor Downing's class example where he showed us an entire function, if I'm not mistaken it was to calculate the root mean square error, that was written in several statements, and then, with Python's beauty, was brought down to just the one statement, ha! 

This week we have our first midterm, I really have no idea of what to expect. In my opinion, so far in this class we have learned mostly about coding (and more specifically Python coding) techniques to improve the way one writes programs, but I'm not sure how professor Downing will test this on the midterm. I will probably go over the material we have learned in class and practice by using them in testing programs. But there is definitely a conceptual part to it. We were given a study guide with several key topics from which we can start studying.

On a separate note, professor Downing also gave us a heads up that we need to start creating groups for the project we will be working on. My group and I have started brainstorming about interesting topics we could work on, even though this week's priority is the midterm. I was not able to attend class the day that the project's parameters were explained but from what I have gathered, the first thing we need to to do is choosing a topic that can ramify into different complementary topics. So for example if we were to choose the music industry then we could branch out into music producers, songwriters, musicians, and singers. We will see what we end up choosing.

Week 5

This week we really dove into differenciating generators, lists, dictionaries, and sets; similarities and differences. This definitely helped in the process of developing our Netflix project, which I will get to in a second. I think the most interesting features I found were that generators, for example, are exhaustible, meaning that once you ask for its contents, they get automatically erased. It seems to me that they (generators) are a data structure with which you want to be very careful in case you wanted to use it. Lists are your typical array but as my partner and I found during our project, they are relatively slow to traverse (especially compared to dictionaries). And finally, I remember from my Java classes that the map data structure is one of the fastest ones out there, given that it uses either a hash table or a binary search tree as internal container (yielding an average of O(1) and O(logN) respectively for most basic operations). So as soon as I realized that dictionaries in Python are the equivalent to maps in Java, I knew that they had to be among the fastest data structures, and after testing we definitely saw it.

Our Netflix project had two basic requirements: Getting it to run under a minute, and yielding an root mean square error of less than one. My partner and I kept running into the problem of getting a runtime of over a minute. So, after much debugging, we came to two conclusions. One, we needed to use dictionaries for everything. Lists are definitely very slow. The second conclusion was that we were reading in too many cache files; about five or six. We kept taking them out as long as we were still getting a root mean square error of less than one, and, as it turns out, we ended up only using two caches. Now we have a running time of less that one minute and a root mean square error of less than 1. It has definitely been one of the most interesting and relevant projects I have worked on.

Week 4

The first week of February was a short one as well. The university decided to close down (once again) due to weather issues. However, we did learn (or kept going over) some useful and very interesting stuff. Prof. Downing has put a lot of focus on the importance and usefulness of assertions, which are a very fast and effective way of testing at runtime whether your code is doing what it is supposed to be doing. In order to show us in code how they are usually implemented, he gave us a couple of examples where some assertions work, meaning they make sure the code is doing the correct thing, and others where they don't hold and even some where they don't get called due to other factors. He also quizzed us on this so I definitely think this is something he wants us to start implementing as part of our coding standards.

We already started our Netflix project. I think it is one of the most interesting projects I have gotten lately. It consists of trying to predict what a handful of Netflix users think of different movies (aka their ratings). There are different cache files, which contain important data regarding their usual behavior (past ratings, ratings per decade, etc.) and, with the help of those files, we need to predict what they think of any movie x. Prof. Downing told us that Netflix at one point was offering a million dollars to whomever came close to what their actual algorithm predicts (I cannot remember how precise it had to be). So for now my partner and I have implemented a reading function in order to process the cache files and store them for future use, and a running function, which basically starts the program. I think it is going to be a really interesting lab and one that will give us great satisfaction in the end, given that we'll be able to say that we implemented a Netflix rating-predictor (hopefully!)

Week 3

This week in class we have been learning more about assertions, exceptions and even the "try and catch" block (as Java calls it), which in Python goes by the name of the "try and except" block. I learned that the "try and except" block may also have a "finally" or an "else" clause, which seemed very interesting to me. After the first couple of weeks in the class I can say I am enjoying very much prof. Downing's teaching style. It had been quite some time since I took a class where they called on students, but now I remember how effective it is at making us be very attentive during the class. I feel everything we talk about in class soaks in much more smoothly than in other classes.

The first project, Collatz, was due this past Thursday. Looking back, it was a little more challenging than I had thought. Especially since my computer kept complaining about the makefile and wouldn't run it, which prevented me from creating the Collatz.html and Collatz.log files. Another problem I had was that the oracle that was supposed to test our solutions showed that I was not passing its tests, when a couple of days before it showed I -was- passing them (I definitely panicked for a while). I am assuming it had something to do with the fact that I have been working both on my computer and on the GDC building's computers so with different environments a lot must change. I can definitely say I feel much more comfortable with git, Github, and the command line after this assignment. To the point that I'm now using Github repositories for some of my other programming classes to keep an updated copy of my projects in the cloud. However, in terms of the coding assignment itself, I am sure that the projects will get more and more challenging as the weeks come. I think it's very safe to say this project's main purpose was to get us familiarized with a style of work and turn-in requirements rather than to test out coding skills.

2nd Week

This week we only had one class day due to Martin Luther King Jr. Day and a snowfall on Friday. However, on Wednesday we did spend some considerable amount of time learning how to use git, which, in my opinion, is key for us to feel comfortable using such a powerful tool (Github). I had previously used git in my last internship; we, interns, had a common repository where we kept all our individual and team projects. I remembered a lot of commands from there but git is definitely very meticulous about its commands and instructions so I had to review some of them. I think that for us to have to keep an updated repository with our projects and having to turn in a link to the repository as well as other requirements, is a very elegant way of presenting our work. Additionally, learning how to use git without the graphic user interface gives you plenty of experience with the command line, which, I think, is something that every programmer must know how to use.

in terms of Python programming I would say i feel more comfortable after finishing project one (Collatz). Problem-wise it was not as challenging as one could imagine, I only had to write about twenty lines of code but it already gave me some exposure to the way things are done in Python, and I think it was mostly about getting us to feel more familiarized with Github anyway. From what I have gathered, I think Python is very different to the rest of the languages I have learned in UT so far. One of the things I find most particular about it is the fact that indentation is the indicator of what the scope of a function or a control flow statement is. In a nutshell, I think the class is going great, it definitely is my favorite out of the ones I'm taking this semester. I think prof. Downing is a very knowledgable person and I am very excited about learning more from him and from the projects that will be assigned throughout the semester.

My name is Luis Delgado, this is my 4th semester as a CS major and I'm very excited for this class. In this blog I will be writing weekly about what we learn in class and my thoughts on it. I don't have any Python experience but I have heard it's relatively easy to pick up. So far I have liked prof. Downing's teaching method. He is very patient with students, and the fact that he calls out people during his lecture is a very effective way of making us pay attention during the entire class period.

This week we have mostly been going over the 3N+1 problem. It consists of the following: Given any positive number
    -If it's even, divide by 2
    -Else, multiply by 3 and add 1
Doing this repeatedly will make you arrive at 1. An interesting fact we learned is that the problem hasn't been completely proved even though it has been tested with thousands of numbers and all of them end up at 1.

Prof. Downing has been showing us how the problem would be solved in Java, which is the language most UT CS students are most familiar with, and has been slowly migrating the concepts to a Python version of them. He first showed us how it would be directly translated from Java to Python and on Friday he started to show us some of the advantages of Python over Java, which make the direct translation be almost inconvenient compared to a natural Python solution. One of the cool things we also learned this week about Python is that data types (int, double, etc.) instead of being simply a declaration, act as a function which returns an object of that type.