Codility

Home

Jestem wielkim zwolennikiem sprawdzania kandydatów na programistów przy pomocy zadań wymagających napisania kodu. Sam również byłem egzaminowany w ten sposób nie raz i nie dwa. W pamięci zapadły mi jednak rekrutacje z udziałem portalu Codility, który weryfikuje nie tylko poprawność kodu ale również jego wydajność, za każdym razem było to dla mnie ciekawe wyzwanie.

Postanowiłem więc skontaktować się z Codility i zapytać czy w ofercie mają produkt pozwalający programistom ćwiczyć ich umiejętności. Odpowiedź na zapytanie dostałem bardzo szybko i niestety okazała się negatywna, ale zostałem zaproszony do ich biura w Warszawie aby porozmawiać o tym pomyśle.

Trochę to trwało zanim udało się nam ustalić termin spotkania, ale w końcu pewnego popołudnia wsiadłem w tramwaj i pojechałem na Plac Bankowy. Na miejscu przywitała mnie przemiła Czeszka Zuzana, miałem okazję poznać zespół pracujący nad rozwojem Codility oraz porozmawiać o ich pracy. Ponieważ nie miałem wcześniej okazji korzystać z portalu od strony rekrutera pokazano mi jak to wygląda.

Na koniec wręczono mi upominek w postaci książki Looking For a Challenge? z opisem kilkudziesięciu ciekawych zadań programistycznych, przygotowanych przez zwycięzców międzynarodowych konkursów programistycznych.

À propos problemów algorytmicznych, dowiedziałem się również, że część zadań Codility dostępna jest w Internecie dla każdego programisty, ale nie wszystkie łatwo znaleźć. Poniżej, dzięki uprzejmości Codility, macie ich pełną listę. Lista ta z czasem będzie z czasem rozszerzana o tzw. zadania well known czyli takie, które są dobrze znane i nie ma sensu przy ich pomocy testować kandydatów ale idealnie nadają się do ćwiczeń.

• psi2012
• phi2012
• chi2012
• upsilon2012
• tau2012
• sigma2012
• rho2012
• pi2012
• omicron2012
• xi2012
• nu2011
• mu2011
• lambda2011
• kappa2011
• iota2011
• theta2011
• eta2011
• zeta2011
• epsilon2011
• delta2011
• gamma2011
• beta2010
• alpha2010

Wizytę wspominam bardzo miło. Tym bardziej, że Codility odwiedziłem nie jako klient, ale jako "człowiek z ulicy". Cieszy również, że to polski start-up odnoszący sukcesy na świecie.

Migracja bazy danych w EF

Home

Już dawno temu pisałem o zastosowaniu RavenDB w swoim projekcie. Początkowo byłem zadowolony z tego wyboru ale jakiś czas temu zdecydowałem się przejść na Entity Framework + SQLCe. Czemu? To temat ta cały post, tak w skrócie to zirytowało mnie to, że RavenDB stara się być mądrzejszy od programisty oraz to jak trudno osiągnąć w nim niektóre rzeczy. Nie twierdzę, że RavenDB jest zły, ale tak jak inne dokumentowe bazy danych nie do wszystkiego się nadaje.

Wracając do tematu, przechodząc do EF zdecydowałem się wykorzystać podejście code first. Wcześniej tego nie próbowałem i muszę powiedzieć, że byłem bardzo zadowolony, migracja odbyła się w miarę bezboleśnie. Swoją drogą zaprocentowała początkowa decyzja aby ukryć technologię dostępu do danych za dobrze określonym interfejsem. Dzięki temu zmiany musiałem wprowadzić w niewielu miejscach. Nie ma jednak róży bez końców. Kiedy po jakimś czasie chciałem dodać nową właściwość do swoich encji otrzymywałem błąd:

The model backing the context has changed since the database was created...

Za pierwszym razem poradziłem sobie z tym tworząc bazę danych od początku i importując dane ale na dłuższą metę byłoby to uciążliwe. Zacząłem kombinować nad rozwiązaniem, które zmieniłoby schemat bazy danych przed użyciem EF. Wtedy natknąłem się na artykuł opisujący to zagadnienie i był to strzał w dziesiątkę. Oto krótki opis co zrobiłem:.

• Dodałem nową właściwość do encji.
• Zmodyfikowałem logikę biznesową.
• Uruchomiłem Package Manager Console.
• Jako Default project wybrałem projekt, z klasę dziedziczącą po DbContext. Jeśli takich klas jest więcej zostanie zgłoszony błąd.
• Wydałem polecenie Enable-Migrations.
• Do projektu został dodany katalog Migrations, a w nim klasa Configuration.
• Wydałem polecenie Add-Migration tj. Add-Migration AddColumn.
• W projekcie została utworzona klasa AddColumn dziedzicząca po DbMigration. Dla mnie interesujące była metoda Up, w której umieściłem kod odpowiedzialny za uaktualnienie bazy danych. Wyglądało to w następujący sposób:
  
  

  public override void Up()
  {
     AddColumn("TranslationEntities", "Translation2", c => c.String(true, maxLength: 4000, storeType: "nvarchar"));
  }
  

  
  Metoda AddColumn to metoda klasy DbMigration. Jest ich dużo więcej np.: AddForeignKey, CreateIndex czy RenameColumn.
• Na koniec użyłem klasy MigrateDatabaseToLatestVersion w celu zainicjowania bazy danych:
  
  

  Database.SetInitializer(new MigrateDatabaseToLatestVersion<ExpressionsDataContext, Configuration>());

  
  
• Przy kolejnym uruchomieniu aplikacji zadziały się dwie rzeczy. Do tabelki TranslationEntities została dodana nowa kolumna oraz utworzona została nowa tabela __MigrationHistory. Dzięki tej nowej tabelce EF będzie śledził historię wprowadzanych zmian i nie uruchomi tej samej migracji więcej niż raz.

To bardzo prosty przykład. Jestem ciekawy jak ta funkcjonalność spisuje się w bardziej skomplikowanych scenariuszach. Czy macie jakieś doświadczenia?

Konwencja wołania

Home

Konwencja wołania (ang. Calling convention) to zestaw zasad, który określa w jaki sposób metoda wołająca przekazuje parametry do metody wołanej i odbiera od niej wyniki. Programując w .NET, o ile nie współpracujemy z kodem natywnym, w ogóle nie musimy się tym interesować. Zgłębiając ten temat można jednak nauczyć się kilku ciekawych rzeczy.

Zacznijmy od tego jakiej konwencji wołania używa CLR. Na to pytanie można odpowiedzieć na dwa sposoby. Odpowiedź "wysoko poziomowa" brzmi: CLR został zaimplemntowany jako maszyna stosowa i nie używa rejestrów, a więc parametry oraz wyniki zostaną przekazane na stosie. Oto prosty przykład, zacznijmy od klasy:

public class Test
{
        public string ReturnString(int i, bool b)
        {
            return i.ToString() + b.ToString();
        }

        public string ReturnString(Fun f)
        {
            return f.ToString();
        }
}

Teraz spójrzmy na kod w C# i odpowiadający mu kod IL, w którym użyto tych metod:

var t = new Test();	newobj instance void ConsoleApplication1.Test::.ctor() stloc.0
var res1 = t.ReturnString(10, true);	ldloc.0 ldc.i4.s 10 ldc.i4.1 callvirt instance string ConsoleApplication1.Test::ReturnString(int32, bool) stloc.1
var res2 = t.ReturnString(new Fun());	ldloc.0 newobj instance void ConsoleApplication1.Fun::.ctor() callvirt instance string ConsoleApplication1.Test::ReturnString(class ConsoleApplication1.Fun) stloc.2

Istotne fragmenty zaznaczyłem na czerwono. ldloc.0 odpowiada za wrzucenie na stos obiektu, na rzecz którego zostanie wywołana metoda (this). Potem wrzucamy argumenty dla wołanej metody czyli ldc.i4.s 10 oraz ldc.i4.1. Po wywołaniu metody zdejmujemy natomiast wynik ze stosu i zapisujemy w zmiennej lokalnej o indeksie 1 przy pomocy komendy stloc.1. Dla drugiego wywołania wygląda to podobnie. Polecenie newobj tworzy nowy obiekt i umieszcza referencję do niego na stosie.

Czemu jednak CLR został zaimplementowany jako automat stosowy (maszyna wirtualna Java zresztą też), a rejestry pojawiają się dopiero kiedy program jest wykonywany i IL jest zamieniany na kod natywny? Otóż CLR to komercyjna implementacja VES (ang. Virtual Execution System). VES jest częścią standardu ECMA-335, który jest niezależny od docelowej architektury, a w szczególności nie wspomina nic o żadnych rejestrach. Dzięki temu konkretne implementacji standardu mogą używać rejestrów w dowolny sposób.

I tutaj dochodzimy do odpowiedzi "nisko poziomowej" na postawione pytanie, czyli jakiej konwencji używa kod natywny wygenerowany na podstawie IL dla Windows'a. Otóż jest to konwencja fastcall, w której na przykład dla architektury x86 dwa pierwsze parametry przekazywane są w rejestrach ECX oraz EDX. Więcej szczegółów na ten temat można znaleźć na blogu Joe Duffy'ego.

Od siebie dodam, że jeśli korzystamy z P/Invoke to domyślnie metody natywne wołane są przy pomocy konwencji Winapi, która w systemie Windows jest tożsama z Stdcall. Zachowanie to możemy zmienić przy pomocy właściwości CallingConvention atrybutu DllImportAttribute.

Coursera

Home

Ponad rok temu pisałem o możliwości wzięcia udziału w kursach online dotyczących uczenia maszynowego czy baz danych prowadzonych przez Uniwersytet Stanforda. Kursy te okazały się strzałem w dziesiątkę i na przykład na ten dotyczący uczenia maszynowego zapisało się około 100 tysięcy osób!

Wracam do tego tematu ponieważ ostatnio kolega wspomniał mi o projekcie/firmie Coursera, która oferuje każdemu, bezpłatnie, możliwość wzięcia udziału w ponad 300 kursach online, z różnych dziedzin, które zostały przygotowane przez uczelnie z całego świata. Interesują cię kompilatory? A może gra na gitarze lub system monetarny Chin? Każdy powinien znaleźć coś dla siebie. Projekt dopinguję tym bardziej, że założycieli jest profesor nadzwyczajny z Uniwersytetu Stanforda Andrew Ng, który przygotował i poprowadził wspomniany kurs uczenia maszynowego.

Na bieżącą chwilę Coursera ma już 2 mln 700 tysięcy użytkowników. Nieźle jak na projekt, który wystartował niecały rok temu. W każdym razie uważam, że to wspaniała inicjatywa, tym bardziej warta docenienia, że daje dostęp do rzetelnej wiedzy za darmo, co w obecnych czasach jest coraz mniej oczywiste. Żeby tylko znaleźć na to czas ;)

Co to jest dobre oprogramowanie?

Home

Pytanie jak powyżej pojawiło się w rozmowie w jakiej ostatnio uczestniczyłem. Każdy z nas ma na pewno swoje zdanie na temat cech, które powinien posiadać dobry program/system. Nie inaczej było w tym przypadku i padło wiele odpowiedzi. Po bliższym przyjrzeniu się, okazało się jednak, że odpowiedzi te można pogrupować w raptem cztery kategorie, co było dla mnie pewnym zaskoczeniem. Dodam, że w rozmowie uczestniczyło pięć osób, wszystkie techniczne, ale o różnym doświadczeniu, które pracowały przy różnych projektach i w różnych firmach. Te cztery kategorie to począwszy od najpopularniejszej:

• Program/system powinien być łatwy oraz tani w utrzymaniu i rozwoju. Do tej kategorii można wrzucić bardzo wiele rzeczy: odpowiednia architektura, obecność testów jednostkowych, dobra dokumentacja wymagań, stosowanie wzorców projektowych itd. Pojawienie się tej kategorii jednoznacznie wskazuje na programistyczny background osób biorących udział w rozmowie.
• Program/system powinien spełniać wymagania i oczekiwania klienta, rozwiązywać jego problemy.
• Program/system powinien spełniać wymagania i oczekiwania użytkownika, być ergonomiczny i łatwy w użyciu. Kategoria ta może wydawać się podobna do drugiej kategorii, ale kładzie nacisk na użytkownika końcowego, który w wielu przypadkach nie jest tożsamy z zamawiającym oprogramowanie (klientem).
• Program/system powinien przynosić firmie tworzącej oprogramowanie zyski, dobrze się sprzedawać. Bez tego też nie da się obejść. Nawet jeśli oprogramowanie zostało napisane z zachowaniem wszystkich zasad i jest cudeńkiem inżynierii, ale się nie sprzedaje, to nie można nazwać go dobrym.

Sądzę, że zestawienie to, pomimo, że krótkie, jest kompletne. Udało się w nim uchwycić interesy różnych grup ludzi, którzy uczestniczą w przedsięwzięciu informatycznym czyli: firmy informatycznej, zespołu tworzącego produkt, klienta/firmy zamawiającej oraz użytkowników końcowych. Interesy tych czterech grup są nierzadko ze sobą sprzeczne ale dopiero kompromis pomiędzy nimi pozwala stworzyć naprawdę dobry system informatyczny.

Po zakończeniu tego posta zacząłem się zastanawiać ile projektów, o których słyszałem, rozmawiałem lub przy których pracowałem spełnia powyższe wymagania. W większości przypadków, które przyszły mi do głowy, mogę gdzieś wsadzić szpilkę. A to system co prawda przynosi kupę kasy ale jest napisany w taki sposób, że woła o pomstę do nieba... Inny z kolei to kawał dobrej programistycznej roboty, ale z jego urynkowieniem jest już gorzej... O wiele łatwiej jest mi znaleźć oprogramowanie wystarczająco dobre, czyli spełniające tylko niektóre z tych wymagań.

A jakie są Wasze doświadczenia?