Week FatalCreated on 20140128
Architectural design patterns brought back memories from last year’s software design patterns in OOSE2. Even though most of them were known to me, it was good refresher and an easy topic to read about.
I remember that last year I finally got to know the model-view-controller (MVC) after practicing it in one of the other courses assessed exercises. Seems that these patterns are almost everywhere (duh) as we are discussing some of them (client-server, peer-to-peer) also this year in DIM3 and even OS3 (pipe and filter, message oriented).
While I was studying for the finals last year, I remember I found this guy on youtube who turns out is making very, very useful videos about many topics in computing science. Here is the playlist with his design patterns (code is also provided and thoughtfully commented):
Week MgCreated on 20140121
It took me the better part of the week to make my mind understand the difference between an object and component (of course, next to reading and writing about all my other courses) but I think I finally got it. A component is a group of objects that can live by itself and can connect via middleware to other components, providing ins and outs of the component.
It does resembe a lot an object, but an object while it's describing an entity, it usually cannot work by itself. The closest to a component in fact is actually a merge by a package and an object.
The workshop was interesting, having a glimpse of Apache Felix although I think it will take me some more time to really grasp the concept (maybe work proffesionally on it?).
I also rebooted the team project this week, after a very lazy winter vacation. We are having some minor troubles with python but otherwise the front end is almost done but the backend does need some more work especially on the algorithms and scoring part.
That's the week wrap. Now party!
Week ?v=5FFRoYhTJQQCreated on 20140121
I have been using Apache Ant and Ivy during my last summer internship and I must say it has a very nice easy learning curve. After about 10 minutes of simple tutorials and a bit of tweaking, you understand the basics of it and it solves hours of problems. You are ready to go in no time - automate lots of tasks when you want to recompile or deploy things quickly when the boss asks you that he wants a demo in 10 minutes. This is a website that helped me getting it.
I haven't used Jenkins though but I did have some experience with open source development. Launchpad does something similiar once you update your code and push it with
bzr push. Now I understand what it does in the background and in my eyes, this is a step further from ant and ivy - even more efforts saved on mundane tasks, leaving the programmer worry about the more human problem aspects like algorithms, data structure, abstraction and code writing. I think there are many advantages in the continuous integration - like immediate feedback on non-functioning software, automated tests and metrics produced by them albeit some drawbacks like setting up time and necessary development of a test suite.
As I am looking into the schedule, this semester starts from the last thing - the dellivery and evolution of software and then digs deeper into testing, architectures and modeling. The warm up material was useful to get into the tone of the continuous integration and also understand a little real world examples as the lecture concentrated more on abstract implications.
Semester 1 SummaryCreated on 20140102
Contribution and Achievements
This is not the first time that I worked in a team but it was the first time that the team wasn’t chosen by me but selected on random. So here is to what we’ve done during semester 1:
Create a team organization document. This was our first task as a team but we didn’t have much of an idea what organization should we describe - organization for the Team Project or the PSD assignments? I don’t think this was clearly understood. However we liked the agile methods so we tried to brainstorm about that.
Assign risks. Again, not clear in the beginning. We had no idea about the group assignments and what will this involve. And on the Team Project we were just getting started to understand the scope of the problem - too early to assign risks. So we tried to generalize them and later edit them and narrow them down as things became more clear (and after we got feedback) which was good.
Setup trac server and git repository. I think that was clearly described and we were able to set it up with no trouble.
Group work. We created the two prototypes of programs, trying to keep up with the principles of good software engineering (modularity, abstraction, incremental development) and of the Agile manifesto.
Team project. Our team won the award for the best team project progress. We worked hard, went through several design and architecture iterations, always working close to our manager, receiving constant feedback. Moreover, I believe that we truly want our project to succeed as we see it as something more than just a University task - we actually see the potential in the real world and I think that motivates us.
Despite the difference in experience of the team, we were able to balance the workload and give non-technical tasks to less technically experienced members of the team. I think my greatest personal achievement is patiently understanding the needs of the individuals and yet push them when the deadlines are soon and otherwise the tasks would be doomed. I believe this is a personal achievement since my character is usually much more temperament and I always try to take as many tasks as possible, hardly trusting other people. I think this semester taught me that given chance to people, they will do their best and providing constant feedback would stimulate them to work harder and thus gaining better results.
I wanted to give equal chance of tasting the leadership position to each of the individuals, however in the current form of the team there needs to be an experienced leader like myself in order for work to be done in time. I will try to take this lesson to the second semester.
In other words, the team experience outside of the classroom is various - some had summer internships, worked for companies part time, others didn’t have that option. In such a team if there is no hierarchy, as my experience during the first semester shows, work is done primarily by the more experienced members, widening the gap between the individuals and thus creating a typical Catch-22 scenario. What my plan for the second semester is that rather than concentrating on perfect tasks, we can concentrate on improving team stability and narrowing the gap between the knowledge and experience between the individuals. We can practice agile techniques like pair programming and code review. By producing slightly inferior code in the beginning and investing some time in initial bootup, I believe we can produce an overall better product at the end rather than huge deltas between the individuals of the team.
During the semester our regular PSD courses and homework assignments have thought me a great deal of how small and medium companies go through the process of defining the needs, capturing the requirements, making a plan and creating throw-away prototypes.
We learned about different design models, some historical like the waterfall, V and spiral and the more recent ones like agile development. I particularly like the agile techniques - they feel less “business and management” and more “computer science”. I have participated in three hackathons only this semester and created one myself to see that there is a specific culture among the IT guys. We like to do things quickly, play with it, throw it away and start from scratch if it doesn’t work. We are much more like children exploring the ways toys work than grownups who need exact plans and requirements. We can make things quickly and show it to our customer in a week rather than closing ourselves in months or years doing something and in the end failing to deliver whatever the initial requirements were. That is what agile is all about.
Of course, the rest of the world doesn’t always work like that. Therefore we find a balance between what we love and what our customers need. Hackathons and hackathon-like-coding is surely fun but rarely produces code ready for production, since there is no time to write comments, documentation and many times even the code itself is “hacky”. Relatively longer hakcathon-like coding in a week or two is a good compromise between fast coding and good coding. Thus comes the scrum method, identified by its daily standups and status reports and a fictitious leader who is also a developer like the rest of the team but just puts the hat of a leader in the meeting in order to facilitate the meeting.
Of course, we can’t start coding without knowing what we need to do. Here comes capturing of requirements. We had mock interviews with our professors in the University, a short, interview like tuning of the initial requirements. Additionally for our team project, we were having constant monitoring from PhD students and weekly meetings with our manager. The PhD students helped us define what is possible, viable and feasible to do given very high level specifications, iterating through different architectures while the manager started “lowering” the helicopter view he first gave us thus exposing us to more and more details. We are keeping documents in Google docs in order to always be up to date with the requirements as well as specific issues on github as to what precisely needs to be done.
Personally, I am satisfied with the course so far. We had a good amount of practical work, great 25/25/50 division between individual, group work and theoretical knowledge which I would love to see in other courses as well. Learning about theory and applying it in the same week is invaluable learning technique which lasts to years and not just for the exam. Looking forward to the second semester!
Week XCreated on 20131209
Tomorrow is the team presentation. I feel we made very good progres in the last 5-6 days and now feel much more secure in what is going on with the architecture, final design and technologies that we will be using. Of course, we still haven't had any user evaluations but we are busy building the system which we will fine tune with A/B testing and direct user observation. We have tons of features waiting on the MoSCoW queue and also reflected in the github issue tracker. We have cleared some already but there are many more to come.