Menu / szukaj

.NET DeveloperDays 2016

W poprzednim tygodniu odbyła się konferencja .NET DeveloperDays 2016. Niestety udało mi się dotrzeć dopiero na część główną konferencji – opuściłem warsztaty. Zastanawiałem się jak można podsumować tą konferencję. Tym razem postanowiłem odejść od typowego formatu oceny każdej prezentacji. Wydaje mi się, że dojrzałem już do takiego etapu, że prezentacje traktuję jako część dodatkową konferencji. Natomiast jako główny element traktuję możliwość spotkania i porozmawiania z ludźmi.

Stosując to kryterium ciężko jest przyczepić się do czegokolwiek. Było sporo miejsca, gdzie można było porozmawiać. Nawet stojąc pośrodku nie bałem się, że ktoś mnie stratuje, potrąci, wpadnie na mnie. Wynikało to chyba, z tego, że miejscem konferencji była hala, z której zostały wydzielone trzy pomieszczenia na prelekcje, a resztę stanowiła przestrzeń, w której można było swobodnie porozmawiać. Na obrzeżach były punkty z kawą, ciastkami, XBoxy. Trochę tłoczno robiło się w trakcie obiadów – wtedy tworzyły się długie kolejki głodnych programistów. Czytaj dalej

.NET DeveloperDays – Ostatnie dni normalnej ceny

Jeśli ktoś jeszcze nie zdecydował się na udział w konferencji .NET DeveloperDays powinien się pospieszyć. Od 1 października cena wzrośnie o 200 zł. Z wejściem na konferencję nie powinno być problemu, ale coraz mniej miejsc zostało na warsztaty.

Poniżej znajdziecie tematy warsztatów:

Jeśli chodzi o mnie to pewnie wybrałbym się na warsztaty prowadzone przez Dino Esposito lub Teda Newarda. Pierwszego – Dino chciałbym zobaczyć w akcji, ale w tym przypadku obawiam się, że nie będą to warsztaty, a raczej kilkugodzinne wystąpienie mistrza. Natomiast warsztaty Teda zapowiadają się ciekawie.

Lightning talk – Autofixture

Zachęcam do pobrania i przejrzenia prezentacji z mojego lightning talka dotyczącego biblioteki AutoFixture. Zadaniem tej biblioteki jest ograniczenie części Arrange, a tym samym kosztów utrzymania kodu w testach jednostkowych poprzez ułatwienie nam tworzenia obiektów. Prezentację można ściągnąć z GitHuba – AutoFixture – Lightning talk. Prezentacja przedstawia przykłady użycia wspominanej biblioteki oraz zawiera porównanie AutoFixture do innych bibliotek dostarczających podobną funkcjonalność. Oczywiście na GitHubie znajduje się również kod z przykładami.

Testy jednostkowe SQL – raport pokrycia kodu

Pisanie testów jednostkowych do kodu jest dziś powszechną praktyką, aczkolwiek nie dla wszystkich języków. Pisząc strony WWW, aplikacje desktopowe czy też mobilne przywykliśmy do tego, że tworzymy testy jednostkowe sprawdzające kod aplikacji. Natomiast nie robimy tego dla kodu napisanego w bazie danych. Po części dlatego, że używamy narzędzi ORM, które generują ten kod za nas. I wtedy nie ma rzeczywiście takiej potrzeby.

Inaczej wygląda sytuacja w momencie, gdy sami piszemy kod SQLa. Wtedy kod ten powinien zostać przetestowany na takich samych zasadach jak normalny kod produkcyjny. Jeśli nasza baza stoi na Microsoft SQL możemy do tego wykorzystać bibliotekę tSQLt. Bibliotekę tę używa się bardzo prosto. Pozwala ona fakeować widoki, tabele, funkcje, jak również procedury składowane. Osoby bardziej zainteresowane tematem odsyłam na stronę biblioteki. Czytaj dalej

.NET DeveloperDays nadchodzi wielkimi krokami

Wielkimi krokami zbliża się konferencja .NET DeveloperDays, która odbędzie się w dniach 19.10 – 21.10 w hali EXPO XXI w Warszawie. Będą to trzy dni poświęcone technologiom powiązanym ze środowiskiem .net. W pierwszym dniu odbędą się całodniowe warsztaty. Natomiast w kolejnych dniach odbędą się wykłady prowadzone między innymi przez Jona Skeeta, Daniela Fishera, Adama Granicza czy Dino Esposito.

Konferencja wygląda dosyć ciekawie ponieważ nie jest ona przeładowana tematami związanymi z .NET Core, Dockerem, czy też F#. Wspomniane tematy są obecnie istotne i aktualne, ale wydaje mi się, że w ostatnim czasie były one zbyt często poruszane w dość podobnym zakresie i przynajmniej dla mnie stały się zbyt wyeksploatowane. Czytaj dalej

Win-Win w Scrumie – forma współpracy

Pojęcie win-win wywodzi się z teorii gier i opisuje takie rozstrzygnięcie gry, w którym obie strony odnoszą korzyść. Podejście to można wykorzystać w trakcie zawierania umowy, dotyczącej wytwarzania oprogramowania, kiedy to jedną stroną jest zespół Scrumowy. Z reguły podmioty zamawiające oprogramowanie oczekują podania estymacji kosztu wytworzenia aplikacji i na jej podstawie decydują o zawarciu umowy z danym dostawcą.

Podpisanie umowy tzw. time and material, w której to rozliczenie następuje na podstawie faktycznie przepracowanego czasu nie zawsze jest dobrze odbierane przez zamawiających. Zawsze można spróbować przekonać zamawiającego do zastosowania rozwiązania hybrydowego. W przypadku takiego rozwiązania zamawiający zobowiązuje pokryć koszty działania zespołu przez określony czas (np. rok), ale może również w każdym momencie zrezygnować z dalszej jego pracy. W takim przypadku zamawiający powinien zobowiązać się zapłacić część środków, które wynikałyby z dalszej realizacji kontraktu (np. 20% pozostałej należności). Czytaj dalej

BB-8

Czasami o sukcesie firmy decyduje drobny przypadek. Taki przypadek pomógł firmie Sphero osiągnąć globalny sukces. Do niedawna firma ta była znana zaledwie garstce osób, które lubią różnego rodzaju gadżety. Będąc bardziej precyzyjnym, firma ta produkowała niewielkie samo jeżdżące roboty zabawki, którymi można było sterować za pomocą komórki. I ciężko było mówić, że firma to odniosła sukces – udało jej się sprzedać około 500 000 robotów w ciągu 4 lat.

Rozwinięciu biznesu pomógł przypadek. Dokładniej wejście do kin nowej części Gwiezdnych Wojen. Okazało się, że ich robot jest bardzo podobny do robota BB-8 z tego filmu. Drobne modyfikacje pozwoliły wypuścić na rynek 8 września 2015 roku nową zabawkę, która momentalnie podbiła rynek. W ciągu pierwszych 12 godzin udało się sprzedać około 22 000 egzemplarzy.

PDF Combiner 1.7

W najnowszej wersji aplikacji wprowadziłem następujące zmiany:

– zmieniłem sposób łączenia plików
– poprawiłem działania przycisków Move up i Move down,
– naprawiłem wygląd aplikacji przy niestandardowych ustawieniach DPI w Windowsie,
– dodałem zabezpieczenia przed przypadkowym nadpisaniem pliku łączonego.

Najnowsza wersja może być pobrana ze strony aplikacji.

As a [type of user], I want [some goal] so that [some reason] – jak napisać dobre user story. Kryterium INVEST

Jest to typowy szablon historyjek (ang. user stories) stosowanych w scrumie. Historyjki tak zapisane pozwalają na szybką identyfikację trzech kluczowych elementów:

  • roli, której potrzebę biznesową będziemy zaspokajać,
  • funkcjonalność, która zostanie zaimplementowana,
  • wartość biznesową, którą dostarczy implementacja.

Pisanie story nie jest jednak takie proste. I dosyć łatwo można popełnić błąd. Zastanówcie się jak często widzieliście story (pol. historyjki – chyba nie przekonam się do używania polskich nazw, brzmią one strasznie nienaturalnie…), które zaczynało się następująco:

As a user…

As a product owner…

Nie wyglądają one źle, ale na samym początku tracimy podstawową informację – o tym kto będzie używał naszej aplikacji. Przecież inaczej projektuje się interfejs dla kogoś obytego z technologią, a inaczej dla np. pani z księgowości.

Z reguły z definicją funkcjonalności, którą należy zaimplementować nie ma kłopotu. Brakuje natomiast zdefiniowania wartości biznesowej oraz kryteriów akceptacji. Można się zastanawiać, czy nie wystarczy nam sam środek – definicja funkcjonalności. W sumie na jej podstawie powinniśmy móc zaimplementować wymagany fragment oprogramowania.

Nic jednak mylnego. Dopiero połączenie tych trzech elementów umożliwia nam zrozumienie całego kontekstu problemu i zaproponowanie rozwiązania, które dostarczy wartość biznesową dla konkretnej roli. Kryteria akceptacyjne pozwolą nam natomiast w łatwy sposób sprawdzić czy zaproponowane rozwiązanie spełnia wymagania przed nimi stawiane. Czytaj dalej

Mockowanie typów DbContext oraz DbSet z wykorzystaniem Moq

Pisząc testy jednostkowe w aplikacjach, które przechowują dane w bazie danych prędzej, czy później będziemy zmuszeni do odizolowania warstwy dostępu do bazy danych. W opisywanym przypadku jako ORM wykorzystywany jest Entity Framework.

Kod definiujący podstawowe elementy wygląda w następujący sposób:

public class User
{
  public int Id { get; set; }
  public string Login { get; set; }
  public string Name { get; set; }
  public string Surname { get; set; }
  public bool AccountLocked { get; set; }
  public virtual List<Role> Roles { get; set; }
}

public class UsersContext : DbContext
{
  public virtual DbSet<User> Users { get; set; }
  public virtual DbSet<Role> Roles { get; set; }
}

public class UsersService
{
  private readonly UsersContext usersContext;
  
  public UsersService(UsersContext usersContext)
  {
    this.usersContext = usersContext;
  }
 
  public User AddUser(string login, string name, string surname)
  {
    var newUser = this.usersContext.Users.Add(
      new User
      {
        Login = login,
        Name = name,
        Surname = surname,
        AccountLocked = false
      });
  
    this.usersContext.SaveChanges();
    return newUser;
  }
 
  public IList<User> GetLockedUsers ()
  {
    return this.usersContext.Users.Where(x => x.AccountLocked).ToList();
  }
}

Chcąc odizolować warstwę danych od aplikacji można wykorzystać jedną z dwóch opcji:

  • napisać dodatkową implementację klasy UsersContext, która na potrzeby testów jednostkowych będzie symulowała działanie bazy danych. Obiekt nowej klasy zostanie wstrzyknięty do obiektów, które do działania potrzebują klasę UsersContext.
  • wykorzystać jeden z dostępnych frameworków mockujących – w tym przypadku Moq.

Czytaj dalej