18 kwietnia 2008

Duże firmy znają Pythona

Wpatrując się w poczynania na rynku w tematyce języków programowania nie może ujść mojej ciekawości niejaki Python. Opisywany na łamach wielu ciekawych artykułów oraz blogów. Znany również w NASA oraz firmie Google, jak również na naszych rodowitych uczelniach oraz na naszym rynku IT.



Co skłania człowieka do zainteresowania się językiem Python ... ogólna ciekawość na równi z prostotą kodowania w tym języku pokropiona różnymi testami z działania w większych systemach :) Skoro taki wielki brat IBM pisze o drzemiących sporych możliwościach, skoro google opiera swoje rozwiązania między innymi na pythonie to czemu tego nie przećwiczyć ...

Zdarzyło mi się brać udział w konferencji RuPy 2008, na której w gronie ludzi klepiących kod i tworzących niesamowite systemy w językach nie tylko Ruby i Python mogłem wymienić poglądy na tematy technologii pochodnych. Delikatna hermetyczność środowiska Ruby kontra Python nie była żadną przeszkodą, aby dowiedzieć się tego, że ludzie wiedzą co to jest PHP i jak wspominali "kiedyś się tym bawili". Jednakże w statystykach popularności Python plasuje się tuż PHP, ale oczywiście wszechmocna Java potrafi przegonić, jak po mocnej kawie ;)

Nawiązując do Pythona bardo podoba mi się rozwiązanie źródeł, które mogę bez problemu być osadzane w innych aplikacjach. Co czyni Pythona językiem, który można wbudowywać w inne języki bądź aplikacjie, czy też całe systemy. Przykładem takiego zastosowania mogą być gry, które jako język skryptowy obok Lua często mają Pythona. Doskonale wiemy, że są to specyficzne przypadki użycia i można wyszukiwać takich argumentów wiele na korzyść Pythona.

W kwestiach migracji, czy rozszerzania horyzontów przez programistów Python jest niezłym odkryciem, gdyż każdy średni programista skryptowy po tygodniu zabaw w Pythonie może zrozumieć i zacząć używać frameworka np: Django. A to już jest nieco niesamowite zjawisko, nieprawdaż. :-)

Materiały dodatkowe:
top 10 google tech talks

21 lutego 2008

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

15 lutego 2008

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/