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.

.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.

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.