06/08/2016

Why did I do my PhD?

Home


Source: own resources, Authors: Agnieszka and Michał Komorowscy

This is my second post about the longest project I've ever participated in i.e. about doing PhD. I decided that at the beginning I'll write why I actually started my Ph.D. studies and what I think now about my motivations.

I remember quite well this time in 2009 when I made my decision to get a Ph.D. It was supported mainly by a few things. Firstly, at that point I was a newly minted graduate of Warsaw University of Technology and I had a very good memories of my studies, being a student... and I wanted to continue that. Secondly, I wanted to do something different from what I was doing professionally for money i.e. typical applications for business.

Thirdly, I associated Ph.D. title with the some kind of prestige that will allow me to distinguish myself in the future. Fourthly, a half year earlier my wife and a few of my friends also started Ph.D. studies. Don't understand me wrong. I wasn't jealous, I didn't feel worse or something. But taking into account what I've written earlier it was an additional motivation for me.

What I think about these motivations now? I'd say that they are neither good nor bad but they simply are. However, I think that I missed a few important thing in 2009. Do you agree with me that my way of thinking was somehow romantic? Now, I know that it was. I assumed that I would be working professionally for money and I would be doing Ph.D. to "do something different". I didn't think much about my future scientific carrier, doing habilitation... I also didn't think much what I actually want to achieve during my studies. Though thanks to that I had an occasion to play with technologies like Azul Systems or Agilent N2X before focusing on historical debuggers :)

Briefly summarising my Ph.D. studies were a little bit like a hobby. And as any hobby, on the one hand it gives you fun and satisfaction, but on the another hand it doesn't necessarily lead you to something, and can be easily set aside or abandon. Many times I had a moment of doubt or wanted to say stop.

Would I made the same decision if I could go back in time? Definitely yes, but I'd consider it much more carefully. I'd think through area of my research so that it would be more perspective and more valuable on the market. Probably because of financial reasons I'd share my time between Ph.D. and the professional job. However, I'd try to find a job somehow related to my studies, where Ph.D. could be potentially beneficial. Currently in the vast majority of job offers (that I receive) it isn't. I'd also consider doing Ph.D. abroad (outside of Poland) where funding is better so that I'd be able to focus on science. Thanks to that my result would be also better.

You must be both romantic and pragmatic when doing Ph.D.

24/07/2016

Report from the battlefield #5 - Logging can kill performance

Home

Public Domain, https://commons.wikimedia.org/w/index.php?curid=48390
Source: own resources, Authors: Agnieszka and Michał Komorowscy

So far in Report from the battlefield series I wrote about my experiences as an expert in the recruitment company. This time I'll write a bug that I found in the production. It was all about the performance. The problem was that in the new version of an application one operation slowed down about 6 times. Initially, I suspected that amount of data simply increased considerably or some network problems. Fortunately, I easily reproduced the issue on my dev machine. Reproducing a problem is half the battle. Though performance problem are usually difficult to analyse so I was ready for a long investigation.

I started stepping through the code with a debugger just to see what is going on. Everything seemed to be ok until... One of the final operations was to log into a file what was retrieved from a database. What's important the log level was set to Trace so even large amount of data shouldn't matter in the production. Why? Because in the production, precisely because of the performance reasons, the logger should be configured not to log everything to a file. In other words it should ignore messages usually with the log level = Trace or Debug. However, after I had pressed F10 (Step Over), I had to wait a few seconds till the logging ends. BINGO!

My first though was that someone configured the logger in the wrong way in the production. Typical PEBKAC problem. To verify my hypothesis I changed the configuration of the logger and executed the problematic operation. Unfortunately, the problem occurred again. Another look at the code and I know what was wrong. And do you already know?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

The problem was that for large amount of data the application required a few seconds just to create/prepare a message for the logger. To make thing worse this message was created, regardless if it was later used by the logger or not. During development it may acceptable but not in the production! There are 2 potential solutions of this problem. Details depends on the logging framework:
  • The first approach is to simply check the logging level before creating/preparing a message e.g.:
    if(Logger.LogLevel == LogLevel.Trace) 
    {
        /* Prepare and log a message */
    }
    
  • The second approach is to use deferred execution for example lambdas e.g.:
    Logger.Trace(() => /* Prepare a message */).
    If a logger supports this syntax, a lambda will be executed if and only if it is required.

17/07/2016

The longest project

Home

Source: own resources, Authors: Agnieszka and Michał Komorowscy

I haven't been blogging for 4 months and it's the longest break I've ever had. Why? Was I sick? Did I have no ideas what to write about? Did I have no time? Did I have too much work? Fortunately, nothing of that. The reason is completely different and probably surprising. So, I finished the longest project in my life.
  • The project that I started in 2009.
  • The project that for all these years was somewhere in my mind.
  • The project that I wanted to abandon over a dozen of times.
  • The project that took hundreds or thousands of hours.
  • The project that allow me to learn a lot of.
  • The project that I would have done in a different way if I had had this chance.
  • The project of which I'm extremely proud.
  • The project after which I simply had to rest.
What could it be? The answer is PhD in Computer Science. On 12 April 2016 I defended my doctoral dissertation, written under the supervision of Professor Janusz Sosnowski, under the title:

Methods of analysis of information systems based on logs of historical debuggers

Even now I remember how relieved and happy I felt then :)

In my work I focused on the problem of storing and analysing of data collected by historical / reversible debuggers. I performed a detailed analysis what could be and what should be improved when it comes to working with them. In the result I proposed new models of representation of execution traces and I implemented tools that facilitate working with data recorded by historical debuggers. I also performed experiments showing advantages of my ideas. It was a really, really huge job.

Now you may want to ask some questions:
  • Was it worth it?
  • Why did you do so?
  • Did you work professionally at the same time?
  • How did you share time between PhD studies with your work? Is it possible at all?
  • What did you actually gain?
  • How to start PhD studies?
  • How much could I earn at the university?
  • Would you continue your science career?;
  • Why you didn't write about PhD earlier
  • And many, many more.
I plan a series of post about doing PhD in the computer science. Many topics will be specific for Poland but many will be general. I want to do that because of two things. Firstly, it'll be a form of therapy for me :) I simply want/need to write about something that was so important to me for such a long time. Secondly, I think that there are not so many blogs/articles about writing PhD so it should be simply useful for others.

If you have any specific questions just let me know.

18/03/2016

Two things I learned about HTML and CSS

Home

I've never worked a lot of with CSS. However, from time to time I do something with it, for example in order to check out new possibilities. Recently, I read about CSS transformations and I decided to give it a try. For the beginning I wanted to achieve a very simple effect i.e. a red square with a blue and a green diagonal lines. It sounds simple and it is simple but there are traps in this exercise. I decided to write this post because it took me a moment to figure out that was wrong. It was also difficult to find a solution in Internet. Maybe because it is so obvious ;)

My idea was to use 3 div elements. One for a square and 2 for diagonal lines. I also wanted to use transformations in order to rotate divs so that they look like diagonals. My first attempt looks as follows. Do you know what is wrong? There are 2 main problems here.

Scroll down if you want to see a correct solution:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.


I changed two things, one in html and one in CSS:
  • The first problem was that I used div as a self closing tag. It is not allowed. Browsers treat <div /> as <div >. It is quite difficult to spot.
  • The second problem was in the greenLine style. It was not enough to rotate the green div by 45 degrees. Firstly we need to translate it in this way: translate(100px,-141px) rotate(45deg). It might be surprising because in the case of the blue div the rotation was enough. However, we we have to remember that the green div is not located in the origin of the coordinate system but just below the blue div. The blue div looks like a thin line but it's height is set to 141 pixels.

14/03/2016

Report from the battlefield #4 - Do not waste my and your time

Home

The Report from the battlefield series is based on my experience as a reviewer. The idea is simple. In order to evaluate programming skills, a candidate is asked to write a simple project. To do so he/she needs to invest some amount of time (roughly speaking a few hours). Taking this into account I assume that he/she must be interested in finding a new job. Otherwise he/she wouldn't spend his/her private time writing a project which rather isn't extremely exciting. The more I'm surprised why some people doesn't care about the first impression.

Here are some examples showing what I'm talking about:
  • A connection string used by the application referred to some server that of course wasn't available to me.
  • The database used by the application didn't contain any sample data.
  • I had to manually create a database used by the application. There was a script but it didn't work without fixes.
  • The application crashed immediately when started.
  • ...
It's wasting of time from my perspective. It is true that all these problems can be fixed quickly but they require additional effort from me. You can believe me that it is extremely annoying. Instead of making an actual review someone forces me to fix bugs. What's the worst these bugs could be avoided easily with a little bit more effort.

Please remember, the first impression is important. It'll be appreciated if a reviewer can run your application just by pressing F5 in Visual Studio (or in another IDE). You can test it in a straightforward way. Before submitting a project to a review, copy it to another machine and try to run it there. It should work without any additional actions.

Currently, if a project cannot be run without problems I don't make a review. However, I have a soft heart and I give a candidate one chance to fix them. Do you think that it's a good approach? I have my doubts because an employer probably wouldn't do so.