Amazon SimpleDB - taka prostota baza danych od giganta

Każdego kto zajmującego się technologiami internetowymi, jak również "potencjalnego zjadacza bajtów" :) może zainteresować podejście do tematu prostych rozproszonych baz danych jakie oferują duże firmy. Firma Amazon w minionym roku wyszła naprzeciw z alternatywą Amazon SimpleDB i o tym właśnie rozwiązaniu jest niniejszy wątek.

Istnieją technologie tzw. rozproszone - bo o nich mowa - cechują się z punktu widzenia klienta:
- nieskończoną mocą obliczeniową
- nieograniczonym rozmiarem macierzy dyskowych
- szerokim pasmem transferu
- dowolną liczbą wirtualnych serwerów (zarówno różnych systemów operacyjnych, oczywiście nie mylić z M$)


Oto kilka linków zgromadzonych na ten temat

http://www.informationweek.com/news/software/soa/showArticle.jhtml?articleID=204803008

http://www.sriramkrishnan.com/blog/2007/12/amazon-simpledb-technical-overview.html

http://www.amazon.com/Success-Stories-AWS-home-page/b?ie=UTF8&node=182241011

http://www.informationweek.com/news/internet/showArticle.jhtml?articleID=201300517

http://www.informationweek.com/news/management/showArticle.jhtml?articleID=190302909

http://www.informationweek.com/news/internet/ebusiness/showArticle.jhtml?articleID=193700262

http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=148

Ciągła integracja + testy automatyczne przy pomocy Selenium i Hudson (Jenkins)

Od zawsze programiści marzyli o produkcji oprogramowania bez jego pisania :-)
Niestety o ile programiści dalej sobie marzą o tym,
ich koledzy teserzy, psujący dzieła programistów mają do wyboru automaty do testowania.

Automatyczne testowanie jest jednym z głównych postulatów eXtreme Programming (XP). Automatyzacja polega na użyciu oprogramowania do sterowania wykonaniem testów, porównywania ich wyników z oczekiwanymi, czy raportowania.

W dobie zaawansowania dedykowanych aplikacji internetowych i pozornie prostych w budowie systemów aukcyjnych oraz sklepów interenetowych, wymagania stawiane testerom stale rosną. Od testerów wymaga się podstawowych zdolności programistycznych, zwłaszcza, gdy używa się narzędzi testujących w sposób automatyczny.

Gdyby nie Selenium oraz Hudson / Jenkins testerzy stali by się w sposób naturalny świetnymi programistami. Na szczęście mogą nadal skupiać się na testowaniu jakości i zwracaniu uwagi na dziwne i "na niby bezpieczne" rozwiązania. Poniżej wyjaśnię na czym polega trick ;-)

Wszystko zaczyna się od zmiany podejścia i zastosowania:

• pomysłodawcy funkcjonalności powinni myśleć o optymalnych krokach możliwych do wykonania w produkcji, które można w zrozumiały sposób przetestować - bez budowania wzmocnionych mostów dla testerów, gdy potrzebujemy wykonać funkcjonalnie kładkę :-)
• TDD - programowanie ukierunkowane testami (Test-Driven Development) opierające się na technice automatycznego testowania, zaczynając od testu wynikającego ze specyfiki funkcjonalności, po czym realizowanie małymi krokami funkcjonalności, aby zapewnić poprawne wykonywania testu
• ciągłej integracji - po każdej zmianie, raz na wydanie, ciągle w repozytorium SVN/trunk lub GIT/master wykonywanie testów automatycznych, analizy statycznej kodu oraz wszelkich weryfikacji wykrywających
• reagownie na zmiany i błędy w trakcie procesu tworzenia a nie tylko incydentalnie po wydaniach
• świadome myślenie o lawinowym charakterze strat, gdy błąd który można usunąć w trakcie produkcji znajdzie klient po wydaniu wersji
• automaty służą do testów systemowych i integracji całości systemu a nie tylko, aby sobie budowały w nocy kod tak dla draki; aby ktoś z jakiegośtam działu nie zepsuł pracy kogoś z któregoś tam działu :-)

Tak mi się wydaje, że dopiero po uświadomieniu w drużynie projektowej od biznesu po produkujących kod, dlaczego warto automatyzować testy można przejść do zabawy z Selenium IDE, Selenium RC oraz Hudson ew. Hudson. Cytuje mądrą wypowiedź znawców kontroli jakości:

Ciągła integracja to przede wszystkim sztuka szybkiego przepływu informacji w procesie produkcji. Im szybciej wiemy o problemie, tym więcej czasu i za mniejsze pieniądze zareagujemy. Im później, tym większe ryzyko.

Materiały: http://www.thinkvitamin.com/features/webapps/easy-automated-web-application-testing-with-hudson-and-selenium

http://agilesurfing.pl/2011/programowanie/automatyczne-testowanie-kodu-jak-to-robic/

http://test-driven-development.com/