Git tricks

A couple of nice git tricks by Mislav Marohnić.

Why you should speak perfect English in IT

I bet you've heard that at least a couple of times: "Learn English, man, it's crucial in industry". Indeed, it is. No doubt about that. But how far should we go? We're never going to be able to challenge native speakers anyway, right?

You're not going to like the answer.

Level 1 - local backyard

English is crucial for a couple of reasons. First of all, it's a lingua franca of computer science and software engineering (actually, not only there, as you may have noticed). You talk English with team mates, you read reports written in English, you read blogs (guess the language!), you write code in English (don't dare to tell me you don't!)... English, English, English.

Secondly, almost all knowledge in this industry is presented in English, and the only reasonable way to take advantage of it is to learn the language (don't bother yourself with waiting for everything to be translated - that is simply impossible). If you want to be a better engineer, you have to read in English.

Thirdly, you'll have to speak from time to time with foreign employees, and the easiest way would be to use English, since everybody speaks it.

The basics of English should suffice, right? You can read, you can write, you can talk with other people. You'll survive.

Unfortunately that's true for a company far less international that you would expect.

Level 2 - facing the real world

When you get to a real international company, basic English is not enough. After joining a company that hires lots of people of different nationalites, you get exposed to real English. English spoken every day, every minute. You just have to be fluent - otherwise, you'll be totally worn out by the end of the day, being tired of translating everything both ways. You may get exhausted even sooner, if you're not lucky or qualified enough. That hinders you from expressing properly your thoughts and ideas, you loose your self-confidence, you make mistakes - both while talking to other people and coding. That boils down into one serious problem: you seem to be underqualified for other people. They get a bad impression about you. You loose points.

If your English is not good enough, you may run into problems with dealing with other people. You will simply be unable to communicate with them, solve problems or simply conduct design discussions. You won't be able to defend your ideas. You won't be able to even present and - worse - sell them.

And, most of all, you'll find it hard to become mates, and that may result in isolation and/or slower progress at work.


Fluency in English is also crucial for sucessful leadership. It's not an advice useful for PMs only. Without being able to communicate fluently, you won't be able to lead your co-workers. You may be pushed aside a bit. You won't have influence. Having no influence will be frustrating and you'll get the bonuses related to frustration, like getting bald soon.

Someone experienced, during one of his talks to students at my university, gave a hint how good your English should be:

You should be able to give this presentation in English as fluently, as you would do in Polish.

That's a good hint, but I believe this is the lower bound. Personally, I think you should not only be able to give a presentation in English as fluently as in Polish, but also be able to make it as enjoyable as you would do if you present something that you're really into.

That's all about selling.

Imagine you are speaking English with all of your co-workers (native speakers and people who actually do that: you can skip the excercise, and the whole rant as well). Imagine yourself not being able to get the jokes, come up with a funny reply, defend your position in the tribe. Will you achieve the same thing - position, status, respect? I seriously doubt. And what happened to the people that did not get the jokes?

Level 2.5 - emmigration

If it happened to you that you had to emigrate, you may have found that speaking fluently with people living at the place you just moved in (I assume that's a place where local yokels speak different language than you do) is somehow crucial to make them become your new friends. And making new friends outside of your home country is hard. It's all a matter of psychology - in the long run, you'll need these people so that you have someone to chat with or enjoy local events. It's not a problem of having a wife or not - people are social and enjoy packs, usually of size bigger than 2. It's also a bit different thing than at work, where it is a matter of being succesful. Here it is a matter of (enjoying) your life.

Conclusion

Speak English and never stop improving - that would be the general thought. We may not be able to challenge native English speakers in literacy or poems - but we may be able to joke with them, sell our ideas and buy theirs. We may be able to hold a position in the crowd - and not fade out in the both work.

How SQLite is tested

Interesting article showing that even open-source software can be tested professionally. What is stunning - there is 679 times more test code (counted in SLOC) that in the application itself!

Thanks to Arek for showing me that article.

A word about software metrics...

This article gives a nice and exhaustive overview of metrics used in software (code) evaluation. I'm a fan of the cyclomatic complexity and test coverage metrics, but I was unaware of the other ones. After reading this article, let me ask: which metric do you use to evaluate your software, Developer?

Update: even more metrics (coverage-related) here.

Java object serialization - 5 things you should know about

This is an article that a Java developer should be awared of. It's not really innovative; it just points out the basics that one should know when it comes to serializing an object in Java. For more exhaustive lecture (covering many more important issues related to Java programming), I suggest reading Effective Java by Joshua Bloch.

By the way, if you didn't read Java Generics and Collections by Maurice Naftalin and Philip Wadler (homepage), you really should.

Recent readings

Holidays gave me some time to catch up with some articles I've decided to read, but was unable to due to "things-that-have-to-be-done-right-now" ;-) Having some spare minutes, I read the following:

• Martin Fowler - Continuous Integration
• James Shore - Continuous Integrations is an attitude, not a tool
• in the mean time: Martin Fowler - Diff debugging
• C++ Template FAQ
• Introducing BDD
• Successful Git branching model.

One more to go: JavaScript closures, but not for today. I'll get to it when I'll start playing with Javascript (which I'm going to do soon).

All are worth reading (maybe except from C++ Template FAQ and Javascript closuers, if you're not interested), I think.

NieRóbcieTegoSami startuje!

Kilka dni temu wystartowała inicjatywa NieRóbcieTegoSami. Graficznie jeszcze jesteśmy w powijakach, ale pierwsze teksty już się piszą :-) Już niedługo także i mój debiut na tamtym blogu. Stay tuned!

It's going to be about motivation today

Have you ever had a feeling that these corporate mottos and missions statements are just a way to make the management feel that they're doing good job? Here is a short and simple explanation, why you had such a feeling.

Thanks to Marcin for showing me that.

.NET SplitContainer panels do not deserve a name?

For some time now I've been coding for a world-wide company called Zehnder. I'm implementing some logistic solutions for their Polish office workers. Technology limits: .NET 2.0.

Some part of the work includes UI - that is, Windows Forms. In order to split the form into two spaces, it seems obvious to use SplitContainer control especially designed for that purpose. Everything seems fine if one does not write unit tests for the UI. When it comes to doing so, a small shortcoming becomes visible - neither of the panels of the split container have a name! Unfortunately, the assumption of NUnitForms is that each control or form has it's own name; that is, one has to make sure that each control has a name. That is not a problem to name a control; it's a matter of simple assignments:

this.SplitContainer1.Panel1.Name = "Panel1";
this.SplitContainer1.Panel2.Name = "Panel2";
 
Not a big deal. But hey, where should one put that code? Is it the InitializeComponents() method body, which is strictly forbidden to be modified manually, a good place for that? Maybe. Until the Designer decides to overwrite this code. All in all, it seems that adding a separate method, let's say - InitializeSplitContainerNames() - and calling it after the InitializeComponents() method (in the form/control constructor) is the best solution (with all of the drawbacks this solution has).

I think.

NUnitForms a testowanie plików exe

Traf chciał, że ostatnimi czasy realizuję zlecenia pewnej firmy mającej siedzibę we Wrocławiu. Ze względu na technologie stosowane w tejże firmie, rozwiązania które tworzę ze swoimi partnerami są oparte o .NET. Nadszedł taki moment, że trzeba było napisać testy do Windows Forms, które tworzą UI naszej aplikacji. Dość rozsądnym wyborem wydawał się być NUnitForms i na jego użycie się zdecydowaliśmy.

NUnitForms ma tą własność, że nie lubi testować plików EXE - z założenia wszystkie formatki miały być zapakowane w plik DLL aby NUnitForms mógł je testować. Zanim jednak ślepo wydzieliliśmy formatki do osobnej biblioteki dynamicznej, zastanowiliśmy się, jak testować sam plik EXE.

Da się to zrobić.

PS. I tak zmuszeni byliśmy wydzielić bibliotekę dynamiczną z formatkami. Powód był prozaiczny: nasza aplikacja była zależna od początkowych ustawień (pamiętanych w pliku konfiguracyjnym z pomocą narzędzi z przestrzeni System.Configuration). Ustawienia te były wstrzykiwane do formatki głównej programu. A teraz pytanie: jak wstrzyknąć taki obiekt z innego programu? :-) Nie przyszło nam żadne rozsądne rozwiązanie do głowy i postanowiliśmy podzielić projekt. Swoją drogą, jeśli ktoś zna jakieś ładne rozwiązanie tego problemu - z chęcią posłucham :-)

Code-review, początek rozważań

Ostatnio, jako że mój blog zaczął bardziej przypominać wirówkę, postanowiłem napisać coś od siebie na temat przeglądania kodu (code review). Zanim to jednak nastąpi, pozwolę sobie przedstawić bardzo sensowny artykuł o tym, jak przeprowadzić taki przegląd w sposób socjalnie odpowiedzialny:

Effective Code Reviews Without Pain

Myślę, że każdy powinien to przeczytać zanim zabierze się za dyskusję na temat kodu - czy to własnego, czy też cudzego.

Kilka oczywistych rzeczy o kreacji obiektów w Javie.

Mało zaskakujące.

Mutability, Arrays and the Cost of Temporary Objects in Java

No, może poza tym, że wołanie "values()" na typie wyliczeniowym w Javie nie jest najrozsądniejszym wyjściem. Wygląda na to, że ze względu na nietrwałość/ulotność (lepiej brzmi niż niemutowalność, czyż nie?) zastosowano tzw. defensive copying - choć to już mało istotne.

Reading code top to bottom, not inside-out...

... czyli podsumowując to. Artykuł jest dość stary i przydługi, ale warto z niego zapamiętać jedną rzecz podczas pisania/czytania kodu: kod powinien się czytać od góry do dołu, a nie skacząc po nim wzrokiem niczym młody baranek hasający po zielonej łączce znaków ASCII. Swoja drogą: czy to właśnie nie jest takie goto,  ukryte w myślach? 

Ten post prawdopodobnie niewiele wniesie do Twojego życia - choć to zależy od Twojego programistycznego doświadczenia.

Modyfikacja kodu w locie

That sounds interesting.

JMangler is a framework for generic interception and transformation of Java programs at load-time.

 Nie żeby to była jakaś nowość, ale możliwości tego narzędzia wydają się być naprawdę spore.

Why API Design Matters

Znalazłem fantastyczny artykuł o tym, dlaczego warto projektować dobre API, jak bardzo boli korzystanie ze źle zaprojektowanego API oraz o czym należy pamiętać, gdy się takowe API projektuje. Nie jest to artykuł wyczerpujący temat (w końcu to tylko artykuł, a potrzeba książki...) ale z pewnością wart przeczytania. I zastosowania.

API Design Matters | May 2009 | Communications of the ACM

A must-read.

Java EE 6 opublikowana

Jako programista Java muszę wspomnieć o takim wydarzeniu. Cała praca związana z przedstawieniem nowej platformy została już wykonana - pozwolę więc sobie tylko do niej przekierować:

Java EE 6 feature overview

Miłego czytania :-)

Writing a thesis or scholar paper demistified

Jako że zaczynam pisać swoją pracę magisterską (jak i sporo osób z mojego rocznika - jeśli wciąż o takim można mówić) i jest to moja pierwsza praca, to kompletnie nie wiedziałem jak się do tego zabrać. Na szczęście, udało mi się wygooglać to:

How to Write a Term Paper or Thesis (PDF).

Jest to całkiem przyjemne i przystępne wprowadzenie do tego, jak napisać pracę magisterską. Jeśli użyć jeszcze takiej ściągi, a później zadać sobie te pytania, to powinno być w porządku.

PS. Oczywiście, nic nie zastąpi ścisłej współpracy z promotorem i - najlepiej - jakimś znajomym polonistą.

Wycieki pamięci i jak sobie z nimi radzić

Jakkolwiek problem wycieków pamięci jest całkiem poważny nawet w językach wyposażonych w garbage collector (o ile można tak mówić o językach), to rzadko pojawiają się informacje, jak z tymi problemami sobie radzić. Korzystając z okazji pojawienia się artykułu, który próbuje wypełnić tę lukę, pozwalam go sobie "wykopać":

How to fix memory leaks (in Java)

Artykuł oparty jest na Javie, ale przekazane treści są uniwersalne, a sama Java służy do osadzenia problemu w pewnych "namacalnych" realiach.

JavaScript widziany okiem programisty Java - tablice

W trakcie prototypowania małego serwisu internetowego próbowałem iterować po tablicy - o tak:

var links = [['link1', 'title1'], ['link2', 'title2']];
for (link in links) {
  alert(link); 
  // do stuff with link 
} 


Zagadka: co wypisze wywołanie alert(link);? Otóż 0 i 1. Żadna niespodzianka, jeśli wie się, że tablice w JavaScript są obiektem, a nie typem wbudowanym jak w wielu językach programowania, a iterowanie po obiekcie JavaScriptowym... to iterowanie po jego kluczach. Jako, że klucze w tablicach to indeksy, to zmienna link zwraca kolejne indeksy: 0, 1, ... . Oczywiście, do długości tablicy.

Więcej o tablicach można poczytać tutaj.

PS. Chciałbym podziękować Marcinowi za pomoc przy tym problemie.

Delete this! [C++]

W ramach odświeżania swojej (dość zakurzonej, niestety) wiedzy o C++ natrafiłem na bardzo ciekawe pytanie:

Czy można wywołać instrukcję delete this; wewnątrz metody obiektu? Co się stanie i dlaczego? Czy można wykonać jakiś inny kod po wywołaniu tej instrukcji?

Zmieszałem się. Z jednej strony - dlaczego ktoś chciałby robić coś takiego? Z drugiej okazuje się, że są sytuacje, w których takie wywołanie ma sens (nie tylko semantyczny). Całość tematu została ładnie wyjaśniona tutaj, a w tym miejscu znajduje się kilka informacji pobocznych.