Co nowego w VS 2013 dla programistów ASP.NET?Bartlomiej Zass
Sesja z konferencji Microsoft Technology Summit 2013 na temat nowości, które pojawiły się w ASP.NET 4.5.1 oraz Visual Studio 2013 dla web deweloperów. Poruszane zagadnienia to m.in.: zmiany w IDE / Web Essentials, Web Forms, ASP.NET MVC 5, OWIN, SignalR, Web API 2
Prezentacja opisuje różne techniki optymalizacji aplikacji ASP.NET. Omawiane są role poszczególnych warstw wpływających na wydajność - od optymalizacji kodu po stronie klienta (techniki stosowane na poziomie kodu HTML i JavaScript) przez różne poziomy stosowania cache, wybrane ustawienia konfiguracyjne IIS aż po same techniki optymalizacji na poziomie kodu ASP.NET.
DynamoDB jest z nami od dłuższego czasu i pomimo rosnącej popularności dla części z nas logika kryjąca się za DynamoDB nie wydaje się być jasna. Wymaga od nas zmiany myślenia o strukturze danych, zmiany naszych przyzwyczajeń oraz dostosowania się do mocno wyznaczonych reguł. W swojej prezentacji Marcin postara się wytłumaczyć skąd biorą się różnice pomiędzy dobrze nam znanym światem SQL a światem NoSQL. Opowie również o tym, jak zacząć modelowanie tabel oraz czym są i do czego służą GSI.
Omówienie podstawowych wzorców projektowych oraz zasad architektonicznych na przykładzie aplikacji ASP.NET, ale w większości niezależnych od stosowanej technologii. Najważniejsze założenia domain-driven design, SOLID principles, itp.
Budowa RESTowego api w oparciu o HATEOAS
@braincodemobi2014
EN: https://blog.allegrogroup.com/it/braincode-mobi1-mobile-people-move-your-brains
PL: https://blog.allegrogroup.com/it/braincode-mobi1-mobilni-ruszcie-mozgi
http://info.put.poznan.pl/2013/12/16/2004
v1.1
Allegro.pl
Tomasz Górski - Gherkin - jak zostać poetą w IT
www.tsh.io
Celem prezentacji będzie pokazanie, jak poprawnie pisać testy w stylu BDD. Pokażę, jak konstruować zrozumiałe kroki, które będzie można wykorzystać podczas dalszej pracy.Poruszony temat zostanie rozwinięty od strony technicznej przez Szymona podczas kolejnej prezentacji.
Damian Zawadzki: O tym jak pisać aplikacje i z czystym sumieniem chodzić spać, czyli wstęp do Clean Architecture Wujka Boba – oczami Android Developera. Spróbujemy uporządkować i ustandaryzować kod tak, aby wszystkim żyło się lepiej.
Co nowego w VS 2013 dla programistów ASP.NET?Bartlomiej Zass
Sesja z konferencji Microsoft Technology Summit 2013 na temat nowości, które pojawiły się w ASP.NET 4.5.1 oraz Visual Studio 2013 dla web deweloperów. Poruszane zagadnienia to m.in.: zmiany w IDE / Web Essentials, Web Forms, ASP.NET MVC 5, OWIN, SignalR, Web API 2
Prezentacja opisuje różne techniki optymalizacji aplikacji ASP.NET. Omawiane są role poszczególnych warstw wpływających na wydajność - od optymalizacji kodu po stronie klienta (techniki stosowane na poziomie kodu HTML i JavaScript) przez różne poziomy stosowania cache, wybrane ustawienia konfiguracyjne IIS aż po same techniki optymalizacji na poziomie kodu ASP.NET.
DynamoDB jest z nami od dłuższego czasu i pomimo rosnącej popularności dla części z nas logika kryjąca się za DynamoDB nie wydaje się być jasna. Wymaga od nas zmiany myślenia o strukturze danych, zmiany naszych przyzwyczajeń oraz dostosowania się do mocno wyznaczonych reguł. W swojej prezentacji Marcin postara się wytłumaczyć skąd biorą się różnice pomiędzy dobrze nam znanym światem SQL a światem NoSQL. Opowie również o tym, jak zacząć modelowanie tabel oraz czym są i do czego służą GSI.
Omówienie podstawowych wzorców projektowych oraz zasad architektonicznych na przykładzie aplikacji ASP.NET, ale w większości niezależnych od stosowanej technologii. Najważniejsze założenia domain-driven design, SOLID principles, itp.
Budowa RESTowego api w oparciu o HATEOAS
@braincodemobi2014
EN: https://blog.allegrogroup.com/it/braincode-mobi1-mobile-people-move-your-brains
PL: https://blog.allegrogroup.com/it/braincode-mobi1-mobilni-ruszcie-mozgi
http://info.put.poznan.pl/2013/12/16/2004
v1.1
Allegro.pl
Tomasz Górski - Gherkin - jak zostać poetą w IT
www.tsh.io
Celem prezentacji będzie pokazanie, jak poprawnie pisać testy w stylu BDD. Pokażę, jak konstruować zrozumiałe kroki, które będzie można wykorzystać podczas dalszej pracy.Poruszony temat zostanie rozwinięty od strony technicznej przez Szymona podczas kolejnej prezentacji.
Damian Zawadzki: O tym jak pisać aplikacje i z czystym sumieniem chodzić spać, czyli wstęp do Clean Architecture Wujka Boba – oczami Android Developera. Spróbujemy uporządkować i ustandaryzować kod tak, aby wszystkim żyło się lepiej.
This is my presentation about Red Gate SQL Doc that I have presented on one of the meatings of Lodzka Grupa Profesjonalistow IT & .NET. Presentation in Polish.
Jak wykorzystać "kontenerowanie" aplikacji, tj. spakowanie zarówno kodu, jak i konfiguracji oraz wysłać to na serwer? Docker umożliwia zrobienie tego szybko i bez potrzeby wirtualizacji nowego środowiska w postaci systemu operacyjnego.
Prezentacja dotyczy architektury aplikacji internetowych od strony back-endu oraz front-endu działającego w środowisku wykonania przeglądarek internetowych.
“Dziesięć serwerów poproszę!“, czyli co może Ci zaoferować definiowanie infra...The Software House
Niezależnie od tego, czy jesteście developerami, sysadminami, czy też DevOps Engineers – prawie na pewno mieliście doświadczenie z webowymi panelami dostawców usług infrastrukturalnych takich jak AWS, GCP czy też OVH. Z poziomu tych paneli da się “wyklikać” wszystko, czego potrzeba, ale… czy aby na pewno tędy droga? Środowiskiem bardziej naturalnym dla każdego inżyniera jest wszakże edytor tekstu (czy też IDE) oraz różnorakie polecenia wydawane komputerowi w formie skryptów. Czemu by więc z tego nie skorzystać? Jeśli od klikania bez możliwości pomyłki boli Was ręka, zainwestuj w podkładkę pod mysz… ale przede wszystkim wpadnij na prelekcję Piotra, na której to opowie o założeniach podejścia IaC, jego zaletach oraz przedstawi najpopularniejsze narzędzia.
Prezentacja z konferencji Mobilization 2014.
Abstrakt:
Na rzeczywistych przykładach pokażę jak wygląda proces oceny bezpieczeństwa aplikacji mobilnych. Zobaczymy m.in. jak wykrywać słabości związane z przechowywaniem danych na urządzeniu, nieprawidłowości w transmisji, oraz najgroźniejsze - błędy w API po stronie serwera (np. błędy logiczne, kontroli dostępu, REST). Jednocześnie okaże się jakie techniki utrudniają ataki, jaki jest faktyczny wpływ na ryzyko poszczególnych podatności, oraz jakie zabezpieczenia warto zastosować w różnych aplikacjach.
Przenieś się do kontenera, czyli korzyści z Docker i Docker ComposeMariusz Bąk
Docker i Docker Compose to popularne wśród deweloperów narzędzia do konteneryzacji i orkiestracji kontenerów, które wypierają wcześniej stosowaną wirtualizację. Dzięki nim możemy opisywać infrastrukturę za pomocą kodu, utrzymywać jej spójność w ramach zespołu deweloperskiego oraz wersjonować ją. Znacznie ułatwia to rozwijanie złożonych z wielu usług aplikacji.
Prezentacja zawiera krótkie wprowadzenie do tych narzędzi oraz pokazuje kilka użytecznych i ułatwiających pracę trików. Prezentuje również stworzone przeze mnie open-source'owe narzędzie Feater, służące do dynamicznego tworzenia izolowanych środowisk testowych i demonstracyjnych. Dzięki wykorzystaniu przez nie konteneryzacji, można je szybko wdrożyć w typowym wykorzystującym Docker Compose projekcie
2. Behaviour driven development
Behaviour driven development (BDD)
• opiera się na Test Driven Development (TDD)
• metodyka “outside-in”
• Każda funkcjonalność jest ujęta, jako historia
(story), która definiuje zakres funkcjonalności
razem z kryterium akceptacyjnym.
3. BDD stwarza wspólne słownictwo dla analityka,
testera, developera oraz biznesu, aby
wyeliminować niejednoznaczności i
niezrozumienie pojawiające się w rozmowach
między nimi.
4. Podział BDD
SpecBDD
• narzędzie do rozwoju specyfikacji dla niskiego
poziomu implementacji części i komunikacji pomiędzy
nimi.
• ewolucja zwykłych testów jednostkowych.
StoryBDD
• tworzenie czytelnych dla człowieka, skierowanych dla
biznesu opisów zachowań.
• ewolucja DDD i testów funkcjonalnych.
• z StoryBDD pisze się scenariusze dla interesariuszy
5. Feature
Funkcjonalność jest opisana przez plik <my-
feature.feature> - zawiera dokładnie jedną
funkcjonalność.
Feature jest zbiorem przypadków zwanych
“scenariuszami” (scenario). Każdy scenariusz
zdefiniowany jest przez:
Context (Given)
Zdarzenia (When)
Oczekiwany rezultat (Then)
6. Bankomat
As a X
I want Y
so that Z
Feature: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I dont have to wait in line at the bank.
7. Jest kilka scenariuszy do rozważenia:
• konto może mieć środki
• konto może być na debecie, ale w limicie debetu
• konto może mieć przekroczony limit debetu
• jak konto ma środki, ale wypłata sprawia, że
będzie przekroczony limit debetu
• bankomat nie ma wystarczająco gotówki
8. Scenario: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
9. • Jeżeli coś nie jest opisane w pliku .feature to nie
znaczy, że ta część aplikacji jest nadmiarowa
albo powinna być usunięta – to po prostu znaczy,
że ta część nie jest ważna dla biznesu, chociaż
część kodu nie jest ważna dla niego to ciągle
może być ona ważną częścią aplikacji.
• Pliki *.feature to nie są testy. Są to opisy
funkcjonalności projektu. Behat daje możliwość
(dzięki definicjom kroków) automatycznego
sprawdzania, kiedy te funkcjonalności są
zaimplementowane.
10. Behat w praktyce
Należy dodać do composer.json następujące linijki:
{
...
"require": {
...
"behat/symfony2-extension": "*",
"behat/mink-extension": "*",
"behat/mink-browserkit-driver"
},
"config": {
"bin-dir": "bin/"
},
...
}
11. W katalogu głównym trzeba stworzyć plik
behat.yml
default:
extensions:
BehatSymfony2ExtensionExtension:
mink_driver: true
BehatMinkExtensionExtension:
default_session: 'symfony2'
12. Rozpoczęcie pracy
php bin/behat init @AcmeDemoBundle
(php vendorbehatbehatbinbehat
init @AcmeDemoBundle)
Po wykonaniu komendy Behat tworzy folder
Features a w nim folder Context z plikiem
FeatureContext.php w srcAcmeDemoBundle.
13. Pierwszy plik .feature
• Załóżmy, że w naszej aplikacji trzeba
zaimplementować funkcję logowania, aby
umożliwić dostęp zalogowanym użytkownikom do
szerszej części serwisu.
• Należy utworzyć pierwszy plik .feature. Dobrą
praktyką jest grupowanie plików .feature
dotyczących tej samej funkcjonalności w
specjalnym folderze tej funkcjonalności. W
folderze srcAcmeDemoBundleFeatures
utworzony został folder security a w nim plik
login.feature:
14. Feature: Login
In order to have access to the wide functionality
of application
As a guest
I need to login
Scenario: Going to login page will show login form
Given there is user "user" with password
"userpass" and role "ROLE_USER"
And I am on „demo/secured/login"
Then I should see "Username" in the
"label[for=username]" element
And I should see "Password" in the
"label[for=password]" element
And I should see an "input[type=submit]"
element
15. Scenario: Passing right values will
login
Given there is user "user" with
password "userpass" and role
"ROLE_USER"
And I am on „demo/secured/login"
When I fill in "Username" with
"user"
And I fill in "Password" with
"userpass"
And I press "Login"
Then I should be on "/"
16. Testujemy czy napisany kod spełnia napisane
przez nas feature:
php vendorbehatbehatbinbehat
@AcmeDemoBundlesecurity
Behat zwraca wynik:
2 scenarios (2 undefined)
11 steps (11 undefined)
0m0.165s
18. /**
* @Given /^there is user "([^"]*)" with password
"([^"]*)" and role "([^"]* )"$/
*/
public function thereIsUserWithPasswordAndRole($arg1,
$arg2, $arg3)
{
throw new PendingException();
}
/**
* @Given /^I am on "([^"]*)"$/
*/
public function iAmOn($arg1)
{
throw new PendingException();
}
19. Mink
Mink symuluje interakcje przeglądarki z aplikacją.
Aby pracować z narzędziem Mink należy zmienić
kod w pliku FeatureContext.php na:
class FeatureContext extends
MinkContext implements
KernelAwareInterface
21. <?php
namespace AcmeDemoBundleFeaturesContext;
use BehatMinkExtensionContextMinkContext,
BehatBehatExceptionPendingException;
class GuestContext extends MinkContext
{
/**
* @Given /^there is user "([^"]*)" with password
"([^"]*)" and role "([^"]*)"$/
*/
public function thereIsUserWithPasswordAndRole($arg1,
$arg2, $arg3)
{
throw new PendingException();
}
}
22. Schemat pracy w metodyce BDD jest
następujący: należy napisać się test, a następnie
przetestować system oraz w razie potrzeby
poprawiać go tak długo aż przejdzie testy.
Należy zaimplementować test oraz napisać kodu
programu. Po przetestowaniu programu Behat
zwraca wynik:
2 scenarios (2 passed)
11 steps (11 passed)
0m1.682s
Sukces!
23. Feature: Login
In order to have access to the wide functionality of
application
As a guest
I need to login
Background:
Given there is user "user" with password "userpass" and role
"ROLE_USER"
And I am on "demo/secured/login"
Scenario: Going to login page will show login form
Then I should see "Username" in the "label[for=username]"
element
And I should see "Password" in the "label[for=password]"
element
And I should see an "input[type=submit]" element
…
24. Scenario outline: Going to welcome page
will show personalized welcome message
Given I am logged in as <user> with
password <password>
And I am on "/"
Then I should see <message>
Examples:
| user | password | message |
| user | userpass | Hello user! |
| user1 | userpass1 | Hello user1! |
25. Feature: Welcome text
In order to have personalized front page of application
As a user
I need to go to welcome page
Background:
Given there is user "user" with password "userpass" and role
"ROLE_USER"
And there is user "user1" with password "userpass" and role
"ROLE_USER"
And I am on "/"
Scenario: Going to welcome page will show personalized welcome
message
Given I am logged in as "user" with password "userpass"
And I am on "/"
Then I should see "Hello user!"
Scenario: Going to welcome page will show personalized welcome
message
Given I am logged in as "user1" with password "userpass"
And I am on "/"
Then I should see "Hello user1!"
26. Co dalej?
We wrześniu 2012 na konferencji SymfonyLive w
Londynie Konstantin Kudryashov (twórca Behat)
oraz Marcello Duarte (phpspec2) pokazali, w jaki
sposób pracować z kodem, aby korzystać z
„Fullstack BDD”. Slajdy z tego wystąpienia
znajdują się na stronie: http://slidesha.re/RRKQFb,
a uzupełnia je wpis na blogu:
http://everzet.com/post/31581124270/fullstack-
bdd-2012-wrapup.
Editor's Notes
BehaviourDriven DevelopmentFeaturesPraca z Behat
Behaviour driven development (BDD) opierasięna Test Driven Development (TDD) jest metodyką “outside-in”. Rozpoczyna na zewnątrz przez identyfikowanie wymagań biznesu i następuje przekształcenie w funkcjonalności, które te wymagania spełniają. Każda funkcjonalność jest ujęta, jako historia (story), która definiuje zakres funkcjonalności razem z kryterium akceptacyjnym. BDD stwarza wspólne słownictwo dla analityka, testera, developera oraz biznesu, aby wyeliminować niejednoznaczności i niezrozumienie pojawiające się w rozmowach między nimi.
Są dwa dopełniające się, ale różne sposoby wykorzystywania BDD – SpecBDD oraz StoryBDD:SpecBDD jest narzędziem do rozwoju specyfikacji dla niskiego poziomu implementacji części i komunikacji pomiędzy nimi. To ewolucja zwykłych testów jednostkowych. StoryBDD skupia się na tworzeniu czytelnych dla człowieka, skierowanych dla biznesu opisów zachowań. Jest ewolucją DomainDriven Development i testów funkcjonalnych. Z StoryBDD pisze się scenariusze dla interesariuszy, ale te scenariusze nie są testami i nie mają za cel opisanie całej funkcjonalności aplikacji, poza tymi interesującymi dla interesariuszy. Chociaż scenariusze nie są testami ich faza akceptacji może zostać zautomatyzowana.Behat automatyzuje testy akceptacyjne zwinnej metodologii Scrum. Każdy test napisany jest w naturalnym języku składnią Gherkin. Behat jest narzędziem StoryBDD.
Funkcjonalność w narzędziu Behat jest opisana przez plik <my-feature.feature>, który może zawierać dokładnie jedną funkcjonalność.Feature jest zbiorem przypadków zwanych “scenariuszami” (scenario). Każdy scenariusz zdefiniowany jest przez:Context (Given)Zdarzenia (When)Oczekiwany rezultat (Then)
Szablon początku pliku .feature spełnia następujący schemat:As a XI want Yso that Z Gdzie Y jest funkcjonalnością, Z korzyścią lub wartością funkcjonalności, a X jest osobą (albo rolą), która czerpie korzyść. Siłą tego rozwiązania jest kładziony nacisk na zidentyfikowanie wartości scenariusza, kiedy pierwszy raz jest definiowana. Aby to zilustrować użycie plików .feature można użyć przykładu z bankomatem (używam przykładu z artykułu Introducing BDD). Jeden z plików .feature mógłbywyglądaćtak:Feature: Customer withdraws cash As a customer, I want to withdraw cash from an ATM, so that I dont have to wait in line at the bank.
Skąd wiadomo, że funkcjonalność wypłaty gotówki z bankomatu jest zaimplementowana? Jest kilka scenariuszy do rozważenia: konto może mieć środki, konto może być na debecie, ale w limitu debetu, konto może mieć przekroczony limit debetu. Oczywiście będą też inne scenariusze takie jak konto ma środki, ale wypłata sprawia, że będzie przekroczony limit debetu, albo bankomat nie ma wystarczająco gotówki.
Używając szablonu given-when-then pierwszy scenariusz może wyglądać tak:Należy zauważyć, że słowo “and” zostało użyte, aby połączyć wielokrotne wystąpienia given lub thenOba scenariusze są oparte na tym samym zdarzeniu i mają nawet te same „given” i „then”. Można czerpać z tego korzyść poprzez wielokrotne ich wykorzystanie. W dalszej części zostanie przedstawione jak dzieje się to za pomocą Behata.
Przedstawione zostanie testowanie aplikacji webowej korzystającej z frameworka Symfony2.Następnie: phpcomposer.pharupdate
Pracę rozpoczyna się wywołując komendę(Pracując w Windows 7 zamiast powyższej komendy należy wykonać następującą:
Słowa: „Given”, „When”, „Then” oraz „And” nie mają specjalnego znaczenia w kodzie, służą do oznaczania kroków oraz podwyższają ich czytelność.
Wszystkie kroki kończą się wynikiem „undefined”, ponieważ nie dopasowały się do żadnej definicji w pliku FeatureContext.
Success – definicja została znaleziona oraz wykonywanie nie wyrzuciło wyjątkuUndefinied – definicja nie została znaleziona, wszystkie następujące kroki zostaną pominiętePending – definicja rzuciła PendingException, co znaczy, że trzeba wykonać dodatkową pracęFailure – definicja wyrzuca wyjątek; Behat pominie pozostałe krokiSkipped – krok nie został wykonanyAmbigous – wiele definicji pasuje do krokuRedundant – wiele definicji ma ten sam wzorzec
Behat ułatwia zadanie pisania definicji kroków i generuje kod, który można wkleić do FeatureContext.php. Nie jest to konieczne, ponieważ testowanie aplikacji webowych jest łatwiejsze dzięki narzędziu Mink.
Po wywołaniu jeszcze raz Behata zauważamy, że nasz pierwszy krok kończy się wyjątkiem, a następne zostają pominięte. Dzieje się tak, ponieważ zakończenie błędem kroku może sprawić, że następne mogą źle się wywoływać
Należy zauważyć, że metoda thereIsUserWithPasswordAndRole() ciągle wymaga zaimplementowania. Dobrą praktyką jest dzielenie kontekstu, dlatego trzeba utworzyć nowy kontekst dla gościa. W tym celu należy dodać do konstruktora FeatureContext jedną linijkę
Tworzę plik GuestContext.php i wklejam do niego schemat metody zaproponowanej przez Behata.
Jednak jest jeszcze coś do poprawienia. Po przyjrzeniu się definicjom scenariuszy można zauważyć, że część kroków się powtarza. Aby nie powtarzać niepotrzebnie definicji kroków używa się Backgrounds.
Kolejną funkcjonalnością do zaimplementowania w serwisie jest spersonalizowana strona główna aplikacji. Jedną z jej funkcji jest odpowiednie przywitanie zalogowanych użytkowników. Należy utworzyć folder frontPage a w nim welcome.feature:
Można zauważyć, że oba scenariusze sprawdzają dokładnie to samo jedyne, czym się różnią to dane. Możliwa jest zamianadwóchpowyższychscenariuszyna: