A Computer Engineering degree in 5 minutes

As you know, I have recently graduated as a Master of Engineering at Politecnico di Milano. I think each course in the program of Politecnico has some underlying principles which remain with you after the exam has been passed and the most technical things have been forgotten and left for documentation to remember.
Thus, I'll try to synthesize the most important concept I took away from each course. This list may be useful to engineers, students of PoliMi in Como and somewhere else, and just to curious programmers wanting to know what I did for 5 years.

First year

Mostly, the courses of the first year are mandatory and involve basic maths and physics which will serve in the next years.
Linear algebra: algebra is a mature way of dealing with multidimensionality, as you generalize numbers and their multiplication or linear combination with vectors and matrices.
Analysis 1: an engineer really needs practical math skills, and not mere memorization of proofs.
Analysis 2: this course should be named Analysis N as you generalize from the 1 input/output variable of Analysis 1 to N independent/dependent variables.
Electrical engineering: engineers build simplified models to work with reality; in practice you use resistance and capacitors and Kirchhoff's laws, not the Maxwell equations. This course could have been focused on hydraulics and be useful as well.
Physics 1: Entropy is a nasty thing, and how to find and conserve energy in nature is an issue.
Physics 2: Maxwell equations tell you anything you need to know about classical electrodynamics. Preparing for the exam means writing them on a sheet of paper and be able to explain and use them.
Computer science 1: C is the minimum common denominator between all languages, and may its pointers and arrays be with you, always.
Computer science 2: a process is really a virtual machine provided for you by the operating system, appreciate that.
Telecommunication networks: abstraction over abstraction, you can go from varying voltage levels on a wire to transmitting web pages reliably.

Second year

In the second year, you got to choose some courses, and to do some practical project.
Probability calculus: a mathematical model is built starting from sets and relations/functions.
Economy: an engineer must know where the money to fund his efforts comes from.
Differential equations: meteorologists cannot predict weather for more than a limited amount of time due to divergence from initial conditions.
Automation: feedback systems beat feed-forwards ones because they don't need an accurate model in order to work. Agilists, what do you say?
Electronics 1: according to classical physics, USB keys and other SSD drives cannot work. Fortunately, USB keys know some quantum mechanics.
Operations research: you can buy RAM if you have algorithms that consume too much space, but you can't buy time.
Computer science 3: algorithms are really intertwined with the data structures they work on.
Software engineering: maintainability is maybe the most important trait of design, and involves also writing diagrams not to avoid coding but to explain your code to other people.
Software engineering project: communication between teams is typically the hardest problem in software development.
Statistics and measurement: when you read 3:36:20 PM on your watch, it's actually a range like 3:36:19.5-3:36:20.5; and that interval has a mean and a variance.

Third year

Now you get to choose more than half the courses, and of course you have to work on a Bachelor's thesis which workload is of a course and a half.
Databases: SQL and the relational model are not going to go away soon, and they're really about sets more than tables.
Chemistry: the structure of [almost] everything we touch on a daily basis can be explained by protons, neutrons and electrons arranged in different ways. Not philotes, but near enough.
EM waves and nuclear physics: waves are cool because you can carry information on their properties, such as frequency, amplitude and phase.
Signals: a transfer function goes a long way, and for the engineer everything is linear, time-invariant and Gaussian unless the contrary is proven.
Computer installations: you shouldn't really buy servers randomly without doing some math first.
Theoretical computer science: computers cannot solve every problem, and do not parse HTML with regular expressions.
Knowledge engineering: stochastic algorithms and neural networks work, give them a chance over pure statistical learning.
Web technologies: HTTP is the lingua franca you need to speak.
Web technologies project: (web) frameworks have a steep learning curve.
Logical networks: sequential and combinatorial are two concepts which appear everywhere.
Information systems: that was just wasted time having to rework RUP diagrams before changing a single line of code makes you aware of why the Agile manifesto is so popular.
Thesis work: when on unfamiliar ground like new frameworks, languages and APIs, Test-Driven Development with a very short Red-Green-Refactor cycle will definitely speed you up.

Fourth year

This year is full of projects: you're a "graduate" student by now, so you're expected to show originality and autonomy.
Advanced computer architectures: we may be stuck with the x86 instruction set, but if you try a RISC architecture optimization can do wonders.
Advanced database and web technologies: it's not only SQL, and even universities recognize CouchDB and MongoDB now.
Advanced software engineering: there's so much going on in a project other than code. You don't see this on a small scale, and it doesn't mean that you have to write it all down, but diagrams and documentation have their communication purpose.
Computer vision: test-driven, object-oriented Matlab is a reality. But math is hard, especially for 3D models, so leverage libraries for complex domains you don't have time to explore by yourself. Oh yeah, and computers can see, but barely.
Image processing: testing image-related code is not easy, but regression testing it is.
Model identification: estimating the value of a stochastic process isn't just sampling and taking an average.
Multimedia information retrieval: Google (and Google Images) work because of math that you must have the courage to study.
Pattern analysis and machine intelligence: studying machine learning gives you an edge over all the programmers that don't know what regression is because of their theoretical background.
Performance evaluation of computer systems: utilization and queuing networks are concept that apply to servers but to teams as well.
Workgroup and workflow systems: you may dream of creating the new Tomb Raider, but 90% of the money is in business software.

Fifth year

In the last year, you can choose courses from other campuses, and you work on a master's thesis for a third of your time.
Philosophy of computer science: ethos is an important part of execution. When in Rome, do as Romans do.
Network architecture: one day we will all have fiber in our homes and send phone messages over 4G instead of SMS.
Distributed systems: remote procedure call is not a modern way to build a distributed application, it's fundamentally different from running processes in a single addressing space.
Game theory: people are rational. Somewhat, if you consider their utility functions.
Interactive TV: recommendation systems literally print money.
Pervasive systems: the way to go is smaller computers, who use less power and are not even based on a general purpose CPU.
Thesis work: scientific work has other priorities with respect to programming; background and validation and are key with respect to coding and design.

PHP.TO.START - July 11th

I will be in Torino on Monday for PHP.TO.START, a day-long event oriented to PHP businesses and university students. The event would be in Italian and has been created by Indigeni Digitali and Skuola.net.
Who wants to work with EJBs if you can work with PHP? :)

Subscription is mandatory and closes on Sunday. I will make the trip with the 8:00 AM Freccia Rossa if you're coming from Milan.

Weekly roundup: back from Bardonecchia

I have returned from an Alta Scuola Politecnica one-week event organized by (UX|service|strategic|product) designers, and although I had some reserves at first I enjoyed the startup game where we had to craft an experiment to test the viability of a service idea, using only existing technologies (no fancy web application allowed). This approach is reminescent of Google's Pretotyping Manifesto, so it struck the right chord in me.

Anyway, while I was away my four weekly articles have been published by my editor.
Practical PHP Testing Patterns: Humble Object shows you how to deal with untestable controllers and other framework-based objects.
How to bomb a technical talk is about what I have learned from my first foreign, professional conference.
Practical PHP Testing Patterns: Test Hook is a measure of last resort.
The eXtreme Programming Values are not just a marketing tool.

The Shower Methodology and Kanban

I'm still reading (really slowly, in order to absorb informations better) Test-Driven Development by example by Kent Beck.The author cites Paul Ungar's Shower Methodology for writing code:

• If you know what to, type it.
• If you don't know what to type, go take a shower.

 Many teams would be happier, more productive, and smell a whole lot better if they took his advice. -- TDD by Example

The shower is indeed the place where many difficult problems are solved. When you have a difficult problem, and it becomes and stay your top priority, your brain daemons (background processes) will work on it for you, and present a fresh solution in an unexpected moment, when you stumble on the problem in an unfamiliar environment such as the shower. When you are parking your car, or walking, or showering, these processes will leverage your free CPU.
Sometimes raising money becomes your shower top priority:

I realized recently that what one thinks about in the shower in the morning is more important than I'd thought. I knew it was a good time to have ideas. Now I'd go further: now I'd say it's hard to do a really good job on anything you don't think about in the shower. [...] Money matters are particularly likely to become the top idea in your mind. The reason is that they have to be. It's hard to get money. It's not the sort of thing that happens by default. It's not going to happen unless you let it become the thing you think about in the shower. And then you'll make little progress on anything else you'd rather be working on. -- The Top Idea in Your Mind

Test-Driven Development is an extension of Ungar's Shower Methodology. Given a red (failing) test, you'll have to make it pass:

• If you know what to type, type it: always start from the Obvious Implementation if you know what it is.
• If you don't know how to achieve the result, Fake It: return 0, return 4 and other hard-coded test-specific production code are ubiquitous as TDD starting points.
• If you still can't generalize after faking the response, try Triangulation: write another test which feeds the system other values and expects a different response. This test, when passing, will ensure there is no hard-coding anymore.
• If with triangulation you still don't know how to go on, take a Shower.

For example, given the test for extracting the square root of 2:

$this->assertEquals(1.4142..., sqrt(2));

I would code an Obvious Implementation for sqrt(), if I already know the algorithm.
If I'm unsure, I would insert return 1.4142 to get a green bar initially, and then go on writing the algorithm.
If I do not know the algorithm at all, I will insert another test for sqrt(3) to triangulate it (even more than one test if it's the case).
If now I wonder what the algorithm is and I have no idea on how to go on, I will take a shower and think about it.

Disclaimers: TDD in this version is a methodology for implementing a single feature (it doesn't cover prioritization, or estimation, or everything else). It acts as a low level of abstraction, which can become higher if you can write end-to-end and functional tests.
Note also that taking a shower may be metaphorical: you can go work on another project, or another component, or to a meeting, or google for some resource on algorithms and data structures.

Our Kanban board

After all this talking about breaks, the comparison that does not always fit is with Kanban and Work-In-Progress limits. If you have to build a car, indeed you will achieve a very short lead time if you limit the buckets of semi-finished parts: there will be less inventory to transport and store, they will be exchanged more frequently and so on...
If you have to develop software, well, it depends: if you always perfectly know what to type, you can place a WIP limit of one or two user stories and work only on one feature at the time. Scrum and every Agile methodology does exactly this with iterations; Kanban does it at a finer level by limiting the tasks that can be moved forward in each phase (analysis/development/testing/deployment/...).
If I am on a PHP web application, Usually I perfectly know what to type: no problem with WIP limits.
Yet if learning is involved, you may juggle different stories and tasks in the same time period, working for example for one day on each, rotating them. I am tackling a difficult computer vision project where I have to solve problems that range from tracking vehicles in a video to estimate their positions and understand if they will collide under certain conditions. I'm putting in it 4 hours a week: there's no way I will be able to do more due to the research and experiments involved (half of the time I do not know how to go on; and it's normal.) Multitasking is the only way to go if I do not want to lose the other 36 work week hours.
So if I had an hard WIP limit on the projects I can tackle, I would be screwed. You know what works with very large WIP limits? Universities. Normally in Italy you can have 6 courses at the same time. If you try to do one course at the time (20 hours a week for three weeks), you will shoot yourself. Formally, there are almost no limits in the engineering faculties: you can complete your studies following the order you prefer.

Thus I think WIP limits are important as they avoid attacking too many things at the same time, and never complete any. Yet if creativity is involved, shuffling projects and go taking a shower when you need it will help you more.

I went for a shower after writing a draft of this article, and I thought also about the analogy of reading books, which is an example of where Kanban is really useful (summing it up: don't buy books if you do not already read all the ones from the last order.) In the cases of user stories, car parts or books we have a set of items which is useless until it goes through all the stages: a user story is deployed, a car part is on the road, a book is ordered, unpackaged and read. You don't get value from a still wrapped book sitting on your shelf, a story you can't deploy yet or an engine not mounted on a car.
With university, it's beneficial to have related courses taken at the same time instead of serially: you can often apply in practice a concept coming from another course, or compare different approaches (mathematical one vs. physics one vs. the engineer's attitude to linearize and model everything as a Gaussian; or the operations researcher attitude towards a problem vs. the computer scientist goal to find the best data structure to solve it).
With research projects like the computer vision one, the end result is unclear and there are no subparts that can be defined earlier. That's how it works in scientific research. I often don't have user story to transport from one side to the other of the board: I have challenges to overcome with creative thinking, and creativity is not a very repeatable, optimizable process.

Note that there is always a bit of creativity in every software project: that's what makes it fun.

Weekly roundup: computer vision

I still have an exam to pass after my first semester in the master's program. It is the exam of computer vision, which consists of a project - in my case, automated detection of traffic infraction.
My goal is, given a video of an urban intersection and some configuration of the scene parameters, to detect vehicles that do not respect priority. I'm more or less correctly tracking the vehicles, but the challenge now is to rectify the scene in real world coordinates (meters instead of pixels):

The project is all TDDed, and it is hosted on Github, just for backup's sake. So this is an example of what you can do at PoliMi, computer engineering's program.

Here are my original articles published this week.
Practical PHP Testing Patterns: Test-Specific Subclass goings on in the Practical PHP Testing Patterns series.
Struts vs. Zend Framework compares an old-style Java framework such as Struts 1 to Zend Framework 1.x.
What Firefox 4 means to web developers? is a light analysis of what features new browsers are providing us.
The PHP frameworks poll results presents the results of the recent popularity survey on Web Builder Zone.

Weekly roundup: the "innovation" buzzword

I just returned from the first seminar of Alta Scuola Politecnica on Lake Maggiore. It's too early to make a judgment on this experience, but the speakers (e.g. Francesco Lissoni, Trevor Pinch) had indeed made a good job in transforming the course title (Something something something innovation if I remember correctly) into tangible concepts: why pursuing innovation and what it means, how to involve users into your projects, the impact of patents and intellectual property, and other interesting topics.
And working with colleagues of very different backgrounds (management, graphic design, even aeronautics) and nationality (Russia, Serbia, Colombia) is surely an unstable and funny terrain.

While I was away, my four articles for this week have been published on DZone.
Practical PHP Testing Patterns: Mock Object
Table-free CSS layouts in 10 minutes
Practical PHP Testing Patterns: Fake Object
Which PHP framework would you use today for a brand new application?

Weekly roundup: Lake Maggiore

I'm leaving for the whole week to Lake Maggiore due to university events (ASP, and no it's not ASP.NET but another acronym.) So far we haven't yet done anything at ASP apart from expressing preferences for projects, and this will be our kickstart event.
It seems that my project, which will shape many hours of my work in the year to come, will be related to e-learning services, and has been proposed by Accenture, whose clients include 94 companies from the Fortune Global top 100 index. Hope to have an interesting experience.

Here are my original articles published this week.
Practical PHP Testing Patterns: Test Stub
GitHub is a web application, Twitter is not (yet)
Practical PHP Testing Patterns: Test Spy
Eliminating duplication
Expect articles to pop out on css.dzone.com during the week - I left four other originals to my editor for publishing. For the upcoming week I will be slow in responding to comments, though.

Weekly roundup: ASP

No, not Active Server Pages, but Alta Scuola Politecnica, the joint program of Politecnico di Milano and Politecnico di Torino. I returned yesterday from the first event in Turin, where courses and projects were presented. We'll see what will come out from it.

Here are my original articles published this week.
Practical PHP Testing Patterns: Delta Assertion
Behavior-Driven Development in PHP with Behat
Practical PHP Testing Patterns: Guard Assertion
My love story with SSH

References are actually good

I realized in the last weeks that I'm guilty of not citing enough references while writing here and at Web Builder Zone. References are something that cannot be avoided in academic work, where they are called citations.

For example, in my slides on image manipulation detection, references look like this:
Main Hany Farid, A Survey of Image Forgery Detection (2009), in: IEEE Signal Processing Magazine, 2:26(16-25)
Valentina Conotter, Giulia Boato and Hany Farid, Detecting Photo Manipulation on Signs and Billboards, in: International Conference on Image Processing, Hong Kong, 2010
R. Hartley and A. Zisserman, Multiple View Geometry in Computer Vision, Cambridge University Press, 2004
...


What references are
References are simply a list of academic papers (good), books (also good) or web pages (not good in academia, but often the only viable reference on the web). The reader interested in learning more, or in verifying that you're not scamming him, will follow the references. It's like saying: this isn't something I dreamed last night after after several beers; there are other sources which propose the same concept, and they are generally trusted by the community.

Yet, I don't see many references in blog posts and articles (if you leave out the original source, for republished articles.) And I'm the first to plead guilty for this. I know many posts present an opinion, and not a scientific research, but while explaining a pattern or a methodology citing independent sources would actually help our case.

The worst thing a technical writer can think of is that there is no added value in posts that link similar articles. Actually, your argument is stronger when backed by someone else, even if it loses a bit of originality. This is how you add value to something already written on another web page.

• You make an additional explanation of the topic from your point of view, and moreover with your background, which is different from everyone else. I know what my colleague, a front-end developer, thinks of Ajax. Now what do you think, as a graphic designer, a PHP coder or a or salesman?
• You port the example to other tecnologies and fields. Some of the things I say to PHP developers have been well-known from Java programmers for years.
• All ideas are made from other ideas*, so even the most original articles build on previous work.

* Myths of Innovation

Blind detection of image manipulation slides

As part of the Image Processing course, I have given a presentation on Blind detection of image manipulation. Which means: how to crunch an image with an algorithm and tell is it has been photoshopped or not.
Here are the slides.

Blind detection of image manipulation @ PoliMi

View more presentations from piccoloprincipe.

Weekly roundup: returning to university

On Monday I'm returning to the university regularly, after the vacation. This week I will give another presentation, this time as part of the Image Processing course. The topic will be techniques for image forgery detection, which simply means how to discover if an image is photoshopped. I will publish the slides after the short talk.

Meanwhile, here are my original articles for this week. They were published on DZone between Monday and Thursday, as always.
Practical PHP Testing Patterns: Creation Method
These are not the buzzwords you're looking for
Practical PHP Testing Patterns: Implicit Setup
A programmer on the cloud

I am Bachelor of Science and here's my thesis

Some updates on what's been going on here.
July 22th was the graduation day for the Bachelor's programs of Politecnico di Milano. I gave my presentation on my thesis project -  a multimedia search engine for musical videos which annotates songs with parameters like language, artist, lyrics and predominant emotion.

Chansonnier: web application for multimedia search on song videos

View more presentations from piccoloprincipe.

Video walkthrough (1:43)

My thesis is now also available under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. It is in Italian, because the policy of Politecnico di Milano is to keep discussions in Italian for the Bachelor's programs (while many Master's programs are entirely taught and managed in English). The thesis contains many examples on Test-Driven Development and build automation, describing my experience with tools like JUnit, HttpUnit, Selenium, Ant, Equinox & OSGi.

How I learned to stop worrying and love new words

Because of the subject of my Bachelor's degree thesis, I am currently busy learning more and more about Java technologies, in particular the OSGi specification and the frameworks that implement it.
In the past, I saw articles about OSGi passing in DZone's feeds, and never cared much about it. It's possible and desiderable to avoid contact with many technologies we are not considering for right now: somehow we have to limit the amount of new information in our self-improvement process to the actually useful fields.
However, the thesis subject (audio and video search) is interesting but it involves a large amount of Java technology, in particular a framework built on top of the OSGi model. Here comes the pain: I did not know what OSGi was at all. Instead of continue worrying about it, I decided to dive into OSGi and I'd like to recall my steps here so that you can decide to take a similar journey on an argument that you are required to know.

Step 1: Wikipedia
Wikipedia is the starting point of most of my researches, even if it is not 100% reliable as every community-crafted content is. Wikipedia took me from an empty word (OSGi) to a definition:

The OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments.

Moreover, well-written Wikipedia articles have many internal links to related material, both in the page body and in the See also section. Every new term you encounter usually points to its own definition, a scenery that can lead to a tab explosion but also to deep knowledge.

Step 2: define concepts in your own terms
I quickly discovered that OSGi applications are composed of bundles. The bundle term is part of the Ubiquitous Language of OSGi, but I did not know an exact definition. When you are doing a panoramic of a technology, it's useful to start with a good approximation which uses already grasped concepts:

OSGi bundles are particula JARs which includes some metadata files along with the hyerarchically organized .class files that contain the bytecode. Bundles export or import Java packages they respectively provide or require.

This is an approximation, since JARs and bundles do not strictly overlap. But it is a good one and let me abstract away most of the bundle internal organization for a while.

Step 3: resources to learn more

• Google is often the best friend of a developer (as the GIYF acronym correctly says.) You can look for tutorials, but also for particular frequently asked questions.
• Books on the subject, particularly if they contain good code samples, are the best road to a deep understanding of the technology. However they may not be the right material if you're only looking for a crash course.
• YouTube videos are instead highly distilled knowledge, and the equivalent of a crash course. A 1-hour long talk can teach you very much about the assumptions and the usage of a framework like OSGi without effort: you just need to listen to the speaker.
• also a search on Wikimedia Commons will bring you a lot of diagrams about your preferred technology (example), used throughout all the Wikimedia Foundation wikis.

Step 4: practice
My first practising step was producing an OSGi bundle and deploying it in an OSGi framework. I've done it even before step 3 because I like to get a walking skeleton as soon as possible, but I've gone reviewing my code once I had learned a larger part of the theory. Getting a running example is always a confidence booster however, even if you are copying much of the code without knowing its meaning.

The same learning process is going on for me for other material I'm using in the thesis, such as BPEL and the SMILA framework. While there may be aliens with genetic memories, you shouldn't be afraid of new concepts: everything you know was learnt at some point in your life.

Teachers and the value of formal education

Question: is it clever to drive for half an hour and drive back another half hour to listen to a 90 minutes lecture?

If the teacher is worth it, yes. At Politecnico di Milano I found out that very often the professors are not in their position because of some random event. And what is true for school and university professors is usually true for other kinds of teachers, like consultants and coaches.
When I give advice on php applications, I do my best to distill knowledge from my previous experience, like a good teacher would do. The focus in every technical subject is not on giving fish, but in teaching how to fish.

You probably want to improve yourself and your career if you're reading here. So, what a teacher or a mentor gives you in order to become better?

• interest for the discipline: maybe the most important  job of a professor is stimulating interest and passion about his subject. I am glad that many teachers I encountered during my education left me with a desire to deepen my understanding of computer science. Many did not - maybe I would be a little more knowledgeable on history if I did not become fascinated by it only half the way in high school, because of the way my teacher conducted lessons. The only thing I remember before the year 1000 is that the Roman Empire was formerly a republic.
  
• Insights which we could take years to arrive to: the fact that, as engineers, we focus on the technology-independent algorithms is still one of the best lesson I have learnt during this semester. Or let's talk about the importance of conservation laws...
  
• Solution to a question in a few seconds as an authoritative source. However, we should not abuse a teacher's time: even the best professor may be wrong or outdated sometimes, and other students have the same right for teacher's time as us.
• Goals which are adequate to the industry standard. If you are very interested in the discipline, maybe you'll want to expand those goals.
• And yes, a degree which should be useful when you apply for a job.
  

And what you invest in a teacher?

• money: subscription to the high school or university, or fee if he's a private teacher, Agile coach, etc. In Italy nearly all the universities are public and I am in range to go everyday to the best  technical university of the country (this may only be luck); this means that I will graduate debt-free and I am scared by seeing people in US taking a 50,000 or 100,000 dollars loan to cover education expenses. Wouldn't you think that Harvard isn't lucrating on subscriptions? At least MIT created Open Course Ware.
  
• Time to schedule and show up at encounters such as lessons and exercises sessions. If you are very familiar with a subject you may skip lessons altogether to save time, but beware of spending more time in catching up with the lessons than the one you saved by skipping them.
• Will to work hard instead of sleeping all morning.
  

Courses in database systems, computer science, software engineering... are probably the smartest way to become a qualified, all-round software developer. Today I am going to the last semester lesson at 14:15 CET.