The End

                    On Friday we took the last software engineering test. I had mixed feelings about the test...I thought it was better than the second test, but now I'm having a few doubts. I'm not going to think about it till we get the grades though.
                  Overall, I think I learned a lot from this class. I think it has helped me a lot with programming languages concepts, and with some software engineering principles. I think I learned more about Java in this class than at any other class at UT (and most classes at UT are taught in Java!). I also liked learning a new language, Python. I may not be super comfortable with all the python concepts yet, but I am confident that I can write code in python without getting stressed out.
                On the Software Engineering side, the book Extreme Programming was very interesting. I kept applying all the principles mentioned in it to my internship over the summer, and thought of a few ways about how Extreme Programming might have helped me in the internship. Some of the articles were really informative, as well as interesting reads. However I thought a couple of  "What to do in College" type articles were more suited to a freshman class. Unless those articles were meant for us to retrospect? Having quizzes in every class forced me to read the quizzes, study a bit before class, and make sure I am not late for class. As annoying as this was, I am glad about it, since it instilled a discipline in me.
              This was the first time I wrote a blog, and I enjoyed it. I love writing, although, I think some of my blogs for this class have turned out a bit dry. This was also the first time I used Google Project Hosting, for the issue tracker. This turned out to be pretty useful during the last project. I also learned to use git better, and I started using git for my other pair programming projects too. This was the first time I was involved in making a website, which was really exciting. I also thought I learned a lot about group dynamics, which will definitely help me when I start working in six months.
           One suggestion I would like to make is that the tests, reading and classwork is very disjoint, which leads to poorer performance on tests. Maybe if all three were integrated in some way, the class would be even better than it is now.
            I am glad I took this course, I learned a lot, and I would like to thank Professor Downing for being a such a good teacher!

Second To Last Week!

           The time has flown! As always! The coming week is the last week of classes, and we only have one real Software Engineering class. Friday is the midterm, and no class on Wednesday! Tomorrow, we have another round of presentations - our team is the last one to present. I am sure that by the time we get to our presentation, everyone will be sick of hearing about the issue tracker, but I think we will say a few words nonetheless.
         I thought it was astonishing how all our points for the presentation are based on what the other students give us. I hope no one is spiteful, and everyone grades fairly. The last two presentations were interesting, I liked to hear other teams' take on the same project. It is interesting how the same goal can be achieved in so many different ways!
       For tomorrow, we had to read another Joel Paper. This one was on interviewing, and although it was addressed to interviewers, I think it had a lot of value to interviewees too. The biggest thing that I got out of it was that as an interviewee, you should show a lot of passion for the work that you are doing. Which is pretty easy, providing you do not stay too uptight during the interview. Another thing that is obvious is that on easy questions interviewers are looking for speed and accuracy, while on hard questions they are looking for the thought process.
     Anyway, I already have a job lined up after I graduate, and won't have to interview for a long time! But these tips are good to keep in mind anyhow. Looking forward to finishing up the presentation tomorrow.

Extra Credit Special Blog

This blog is about an article Is Design Dead? written by Martin Fowler.

While reading about Extreme Programming, I was confused about the role of design in Extreme Programming. This article sheds some light on the design principles in Extreme Programming. This article also explains the differences between planned and evolutionary design.

Next semester is my last semester at UT. After I graduate, I am going to work, and so I am interested in reading articles that have relevance to design and programming practices in the industry. This article falls in that category.

            According to Martin Fowler, the more common design technique is evolutionary design.  As the name suggests, design is continuously evolving and changing as the system grows. However, this means that virtually there is no design, since design is not constant.  This leads to the “code and fix” nightmare which means that as the project progresses in time, expense of fixing bugs grows exponentially. As a contrast to evolutionary design, planned design is thought of in advance, before the start of the project. Often the team designing the project is different from the team implementing the design. However, planned design has its disadvantages too. The most important disadvantage is that requirements do change. The customer never knows what he wants and will always want more features. I experienced this first hand during my internship this summer. The customer demanded that certain features should be implemented, that had no hardware support. It fell upon us, the software team to design a solution to the customer demands. Thus, I agree with the statement that requirements are always changing, and that it is not viable to fix upon a constant design at the start of the project.

            After I finished reading the first section of the paper, I was a bit worried.  He mentioned two design patterns, and both of them seem to have grave problems. However, there was still half the paper to go, and extreme programming to look forward to. I was interested to read on.

            According to Fowler, XP advocates evolutionary design. From what I read about XP, this seems to be true.  Now, to me it seemed weird that such a flaky design pattern would be adopted by Extreme Programming, since XP seems to have quite a few followers. However, Fowler tried to explain this. He said that the principles of Extreme Programming mitigate the risk of evolutionary design. The risk of evolutionary design is that as the project gets older, it becomes more expensive to make changes. However, XP practices of Testing, Continuous Integration and Refactoring flatten this change curve.          
            This again builds on what I thought about XP in the first place. For Extreme Programming to work, all the practices of XP need to be followed. If not, then extreme programming won’t work. Simple design is a requirement of Extreme Programming.

            Design Patterns are reusable solutions to common problems in software design. Fowler advocates the use of Design Patterns in Extreme Programming too. He advises extreme programmers to invest time in learning about patterns, concentrating on how to implement patterns in their simplest form, and to be able to remove patterns if they aren’t performing their job.  I think that this is in general good advice, to follow, whatever type of programming you are doing.  Professor Downing touched upon some design patterns during lecture last week, and also showed us a couple of books to read on design patterns. I’m interested to read one of those at least over the winter break.

            In conclusion, I want to reiterate what Martin Fowler suggested was Extreme Programming’s take on design. XP design looks for skills like refactoring, a strong knowledge of patterns, knowing how to communicate the design to the programmers. XP design depends on knowing that decisions are going to change in the future, and that code should be as clear and simple as possible.

            I think this paper helped me understand design principles in general, and how to reconcile design with extreme programming. It gave me a deeper understanding of extreme programming, and helped make me ready to face the workplace.

Singeltons

       The past week was probably the hardest week conceptually for me in class. We covered topics like singelton classes, and reflection. Since these topics were really new, and hard to imagine for me, I was a bit overwhelmed. But I read more about the singelton design pattern here. Reading about the real world applications that need singeltons helped make the concept clear to me. The page also talks about how to make singeltons thread safe, which is interesting.
      The second big topic that we covered was Reflection. I am still quite hazy about this, and am not confident enough to write about it yet. I will go to office hours and will hopefully understand reflection enough to blog about it next week!
      Our project was due on Wed, and this time was smooth sailing. We were mostly done on Sunday, and all we had to do on Wednesday was refine the technical report and the powerpoint presentation. We are presenting next Monday, so we have the next couple of days to practice our presentation (since most of next week is Thanksgiving!! :) ) I am so glad that this class makes us present, I feel like it is so important to have presentation skills. Working hard is not enough, if no one knows what you have done. I believe that marketing your product is just as important as having an awesome product. I am glad that I am getting a well rounded education at UT!

Miscellaneous

         This week, I was sick on Monday, and left class after the quiz. Unfortunately, I missed the lecture about dynamic binding in Java and the Java virtual machine, so I felt rather lost on Wednesday. I realize how important it is to go to lecture, because concepts are just easier to understand when they are discussed.
       I think the concepts we went over this week are really useful. Every week I marvel at the fact that I thought I knew Java so well, but I only seem to have scratched the surface of this language. I know that this is a class in Python, but I am getting more out of this class in Java.
         The third part of the World Crisis Project is due on Wednesday. "Search" seems to be the only real functionality that we need to add. I think we are almost finished with that, and so we are going to add some "special features" to our website in the next two days. We have been working on the presentation, but are kind of confused what to put in the Powerpoint, since most of the presentation seems to be demos of the website and also the issue tracker apparently. We are also working on fixing the technical report. I am a bit confused about this, since I thought the TA was going to critique our first draft, but he only gave us a one line review of the paper. I am hoping that the rest of our paper was just fine.
       I am looking forward to finishing the World Crises project and ending the semester on a good note. Three more weeks to go!!!!

WC 2 and Refactoring

        This week we started talking about Refactoring in class. We did the examples that Martin Fowler had in his book about the video rental store. I found this much more interesting than the book, and a much better learning experience.
        Reading code written in a book can be tedious, and I sometimes find myself skipping over the code examples that Fowler shows. I catch myself in time, and re-read them, because they actually show what is going on. However, doing the examples in class, in an interactive manner, is much more useful. Coding is supposed to be a hands on process, I don't think anyone can learn to code by just reading about it. I also think it is hard to remember all his rules about refactoring, I think refactoring is something that is very intuitive and doesn't need an actual Rule-Book.
      The second phase of the World Crises project was due last Wednesday. This was harder than the first part, since the website needed to be dynamic. I worked on the UML diagrams, which was a lot of fun, and also on the merge import. No one was really sure about what merge import was supposed to be doing, and we needed to get it clarified from various sources. This kind of showed me what it is like to work with a customer, and not know what the customer really wants. There should be open communication between the customer and the programmer, in order to give the customer what he needs and wants.

Of World Crises and Underbars

           The second part of the World Crises project is due on Wednesday, and we spent a major part of today working on it. Since we want to maximize our learning, and get the most out of this project, we decided to switch roles in the team. Everyone who worked on the back-end last time is working on the front-end this time, and vice versa. Last time I worked on more of the front-end, and I was a bit disappointed not to be working on front end for this part, because in this phase we get to make our webpages dynamic and PRETTY!! Oh well, maybe next time....
           I am interested in the back-end stuff too though, since it is all new to me, it is really exciting. I had a lot of fun with the UML class diagram, and no, I am not being sarcastic. I just wish I had more time to learn more. As it is, I am going to end up doing just enough to complete all the requirements of the project, since this is a really busy week for me.
           The last week in class we compared Java classes and Python classes. I think I even had a dream about naming stuff with _className__variableName, which wasn't pleasant since I dislike __s. But on the whole I found the discussions useful. I think this class is a really good introduction to Python, and it makes me want to take OOP next semester just so I can feel comfortable with C++ too.
         We had to read five chapters of the Refactoring book for Friday. What I got from the book is that the author seems to be good friends with the Extreme Programming guys, and they all seem to love to repeat themselves over and over and over again. But I did like how he had a lot of examples in the book, I find that a really good way to learn something.

Exam Week

          The second exam for Software Engineering was on Friday, and my whole week was spent getting stressed about the exam, and trying to prepare for it. I re-read all the papers and the Tom Jewett Database book, and compiled a detailed cheat sheet. However, to my surprise and slight disappointment, the test only had three questions from the readings! There were a bunch of programming questions, some easy, some which required a bit of thinking. Overall, I wish I had had more time for the test. I think an hour is too short a time for a programming test. The Haskell part was surprisingly easy for me, I think my CS 337 class helped me a lot on that part. Oh well, I will know how I did on the test in a week.
       The beginning of the week was about the WC project. As project leader, I wanted to make sure that everyone was on top of their piece of the project, and that no one felt overwhelmed with work. This involved writing a lot of emails! But on the whole it was fun, I enjoyed it! The project itself was interesting too, I like learning to use new tools, and the Google App Engine seems like a really useful tool. I noticed that you can pay them a nominal fee to get your own domain name, which would be useful if I want to make my own website in the future. I hope that by the time we finish all the parts of the project, I will be really familiar with the Google App Engine.
      The aspect that I enjoy most about this project is that I am getting to work on so many things that have interested me, but I have never worked on before. I have never built a website before, and I am really excited to help make our website user-friendly, and impressive. I definitely like the projects in this class much better than the tests!

Miscellaneous

            This class teaches me so much about programming languages! I now know stuff about Java (and Python) that I hadn't even thought of before. This week made me realize how easy it is to use a programming language, without even knowing some of the basic characteristics of that language. From now on, I am definitely going to investigate the actual ways in which a language functions. I think that will definitely help in improving the quality of my programs. One of the cool things we talked about in class this week was regular expressions and pattern matching in Python. I think that is really fun, while also being useful of course!
           On Friday, we went over the big Os for inserting and removing elements from the beginning, middle and end of different containers. This was mostly a review for me, but it was useful since most interviews tend to ask a few questions about Big O. To recap, array lists are the best for removing and adding elements to the end, indexed look up in an array list is also constant time. Linked lists are good for removing and adding elements to the beginning or the end, with an O(1), however lookup is expensive in a linked list, O(n).
             This weekend I worked on the project, which is due on Wednesday. I like having a big group of 6, since one person doesn't have to do too much work! We divided the work equally amongst all of us, which seems to be working fine as of now.
             The second test is already upon us! It is on Friday, and I want to start studying early for this test since I know that we have covered a lot of material.
          

Packing and Unpacking

            This week, we learned some more about the weirdness of Python. Python has named arguments, which means that you can name the arguments in a function call. This is nice because it gives more clarity to the function call if the arguments are meaningfully named. However, this functionality could be a pain if some function header needed to be changed. Changing the function header requires all the function calls to also be changed, which could mean a lot of time-consuming work. Python also gives us the feature of declaring default values for parameters, like C++. And then the weird part comes in. Python can take in an iterable item as an argument, if it is preceded by a *. This iterable item is then unpacked into its corresponding elements. Conversely, python can also pack elements into a tuple, if the function header lists *something as an argument.I am assuming that these are useful features to have in a programming language, since python clearly has them! I haven't thought of a good way to use them yet though.
            On Friday, Professor Downing described the group project that we will be working on for the rest of the semester. I liked the idea of a website that focuses on collecting and imparting information on the current natural disasters. This seems like a project that will have some application in the real world. I have never worked on websites before, and I am excited to begin this project! I hope that working in a group won't be too hard; the git repository at least should make it somewhat easier. We should all remember to push changes frequently though, since merge conflicts are really tedious. I had to face a couple of merge conflicts with git at my internship this summer, and I did not appreciate the time I had to spend to go and fix those. I think working in a team of 5 should be easier than working in a team of 20 though!



    

Netflix

           I learned something cool about Python in class this week. While talking about how to calculate the RMSE, Professor Downing showed us how to write the program in one line. Python lets you condense most expressions, so code looks very compact. I don't know how readable it is though, I myself would not feel very comfortable trying to decipher complex Math in one statement.
         This week started out with talking about the Netflix project and then moved to operators and how Java, Python and Haskell handle different operators, and have different expectations about l-values and r-values. The concept of l-values and r-values was new to me, and I found the exercise in class about whether an operator expects/returns an l value/r value, really interesting. For example, increment operators in Java require an l-value and return an r-value.           
         The Netflix project was one of the more interesting projects I have worked on this semester. I had heard of the Netflix prize of course, and I was excited to try it out myself! It looked really challenging in the beginning, but I was surprised to find that it did not take my partner and I very long to get an RMSE less than 1. It was fun trying to manipulate weights and figure out other ways to get a lower RMSE. We already finished the project and turned it in, and its due on Wednesday! In the past, whenever I have had to pair program, I have always worked with my friend. We are really used to each other by now, and are comfortable with each others style of coding. For this project however, we were not allowed to work with the same partner as last time, and I had to work with a stranger. I was a little apprehensive at first, but I was pleasantly surprised that it was pretty comfortable working with someone new. I applied the concepts of pair programming that we had learned, with satisfying results.

Of Wikis and Exams

         This week for me was all about finishing off PFD and studying for the first exam. On Tuesday, we got our Test Generator working, which was a relief, because that meant we were almost done. All we had to do on Wednesday was tie up the loose ends, and write the Wiki. I find writing a wiki on my algorithm to be an interesting process. Although I am sick of working on a project by the time I get to the wiki, I think it is a good idea to write it. It helps me actually think about my algorithm, and sometimes I find that I could have optimized certain things. I also like that it forces me to translate my algorithm into English, a skill that will definitely help me in the future, when I want to explain my program to my boss, or to a customer.
         The first exam was on Friday. I had heard that the tests in this class are very hard, so I knew I should spend a lot of time studying for the test. Although Professor Downing said that he would design the test so that our double sided cheat sheet would be useless, I spent hours preparing a cheat sheet. And I made sure that not even a square inch on that paper was left blank! This was lucky for me, because most of the answers to the memorization questions that everyone seems to be complaining about, were on my cheat sheet! I was so glad that I took the time and effort to prepare a summary document of all the readings we had for class, it sure came in handy! However, I wish I had put some python syntax on the sheet, since under pressure of the exam, I forgot that to use the python iterator the syntax is i.next() not i.next. I really hope the grader doesn't penalize me much for missing the parentheses!
         Overall, I think I am learning a lot from this class, and I am excited to start working on the Netflix project!

Acceptance Tests

      On Friday my partner and I spent a couple of hours working on PFD, and we were thrilled when we thought we had got it working. It was passing all the unit tests, and we thought it was ready to be entered into Sphere. However, when we submitted the solution to Sphere, it failed! We were uncertain why that happened, and so we decided to write more unit tests. The unit tests were passing, but Sphere wouldn't accept our solution.
 We realized that it must be a lack of understanding of the problem on our part. We needed more tests, from other people.
      Luckily some people had uploaded their acceptance tests to the public repo, and we used some of those. After looking at the tests, we realized that it was indeed a lack of understanding of what the problem wanted that caused our solution to fail. I think Acceptance Tests are very important for the programmer to gauge correctly what the specifications of a problem are. I don't like Sphere for this reason, since Sphere only gave us one sample test (The fact that the webpage would not load correctly on any browser except IE is a whole other gripe). One sample test is not enough to explain what the problem is actually asking for.
     Anyway, we fixed our logic, and got our program accepted by Sphere. I am so thankful that we all have to upload a thousand acceptance tests to the public repo, it really helped us out! We need to write a test generator now, which will enable us to help some of our classmates out in return!
     The reading for the past week was pretty good, finished reading Extreme Programming, and read some articles that highlight the importance of checking for overflows. We learned about exceptions in class, which I found really interesting and useful. I had a very vague idea of exceptions before this, and I liked learning about them.

Collatz

    The last week in software engineering was mostly about the project. The project was due on Wed at 8 pm, and I was working on it till 7:45 pm! That is pretty last minute for me, but there were so many details in this project to worry about that I wanted to make sure I had everything right. The program that we wrote needed to be accepted by Sphere, and this gave me an opportunity to learn about a cool online code judge. It was cool, but also a bit frustrating, because Sphere just says wrong solution, without showing specific test cases where the solution failed. This made it very hard to debug the program, but I guessed that they do not want to reveal test cases, in case people try to hard code solutions in their program!
    But anyway, apart from Sphere, it took a while to set up the git repository. I think it is really useful for version control though. In previous classes, I have tried to do some version control myself, which involved keeping copies of entire folders locally. Finally everything got really messy, and I always got confused as to which the latest folder is!
    The reading for the week was the rest of the Extreme Programming book, which talked about test first programming, and the importance of writing Unit Tests. I thought that was really insightful, since I sometimes get bored of writing tests. However, I am inspired to write more tests in the future. We also read a couple of articles about pair programming. I have always liked pair programming, and I am glad that we get to work with a partner for the next assignment. I think two heads are better than one, and working with someone else also makes homework fun! That rhymed!

Weekly Blog #1

     Quizzes!! Week two of software engineering introduced me to the concept of a quiz at the beginning of every class. I was scared about the first quiz, and read the two articles over and over, trying to remember minute details in order to do well on the quiz. But after Quiz # 3 I feel more comfortable, and have gotten used to the idea of taking quizzes all the time!
     We had to read the first twelve chapters of a really good book called Extreme Programming. I found the concepts in the book really interesting, and as I was reading I was constantly comparing the work style described in the book to my own work at my internship (at Qualcomm) this summer. When I start working full-time, I would like to apply some of the techniques described in the book to my work - of course the techniques mentioned should really be applied to an entire team, and not just an individual.
    The quizzes also had a couple of questions that would help us optimize our program for the Collatz assignment. I am going to try to use these optimizations to improve my code performance.  I liked how the quiz questions were relevant to our assignment, although when I first saw the question it did seem a bit random!
    The first project, which is due on Wednesday includes not just programming, but being able to use the Google issue tracker and a git repository. We also need to write a wiki, and create documentation for our code using Doxygen. I think these are all good skills to have, and am glad that we are being forced to develop these skills as part of the project.
   Anyway, talking about the project reminds me that I have a lot of work to finish, and so I'll sign off now!

Week 1

      The second class of my last year at UT was Software Engineering. I had heard a lot about this class from my friend, and I was looking forward to it. Since I knew we were going to have to work in a team for some of the projects, a couple of my friends and I made sure to take the same section of the class.
      The class seems exciting, and I look forward to doing a LOT of programming in the next few months. Apparently most of the programming is in Python, which is a new language for python. I better start getting familiar with Python! We already have some homework, which I'm going to finish this afternoon. This class seems perfect to prepare me for the working world, since our Professor wants us to learn a lot of skills that will be useful on the job. We are going to be using Git Hub - luckily I have some experience with Git from my internship this summer! Hopefully I will remember to use commit --amend when needed! The first project is due on Sept 7th, and I guess I should start working on that too, as soon as we learn about the cache that is going to have to be implemented in the project.