Python/DevOps

From today I am going to write blog in English and also I will write more posts.

Wstęp Przy codziennej pracy z pythonem często korzystasz z takich typów danych jak słownik, lista, krotka czy zbiór. Ale warto pamiętać, że istnieją również inne typy danych, które często mogą Ci się przydać, a o których niekoniecznie słyszałeś. Przedstawię kilka z nich, które moim zdaniem są warte uwagi. Counter Typ ten przydaje się wtedy gdy chcesz np. sprawdzić ile razy występuje dany obiekt w zbiorze i dodatkowo chcesz to trzymać jako słownik. Przykład: deque Obiekt deque idealnie nadaje się do stosu lub kolejki . Dodawanie oraz pobieranie elementu jest zbliżone do O(1); nie ważne czy pobierasz z końca czy z początku. Jeżeli jednak chcesz dostać się do elementów po indeksach lepiej jest skorzystać z listy, która jest do tego przystosowana, więc siłą rzeczy jest szybsza. Poniżej, krótkie porównanie: defaultdict defaultdict przydaje się tam, gdzie chcesz stworzyć słownik w którym przy dostępie ma już mieć zdefiniowaną domyślną wartość. Zamiast martwić się sprawdz

Wstęp W ubiegłym roku pisałem o ultrajsonie , który wypadł bardzo dobrze. Przedwczoraj natrafiłem na bibliotekę ultramemcache , którą również postanowiłem przetestować i sprawdzić czy jest ultra. Do porównania wykorzystam biblioteki python-memcached oraz pylibmc . Pierwszy test odbył się standardowo poprzez odpalenie jednego procesu. Drugi natomiast z wykorzystaniem czterech procesów co znacznie przyspieszyło działanie. Jeden proces: python-memcached ultramemcache pylibmc Cztery procesy: python-memcached ultramemcache pylibmc Wyniki Testy wykonałem kilka razy dla każdego ze skryptów i wybrałem najlepsze wyniki dla danej biblioteki. Był to bardzo prosty test, ale da się zauważyć spore różnice w szybkości działania tych bibliotek. W przypadku jednego procesu ultramemcache poradził sobie najlepiej, chociaż pylibmc jest tuż tuż... Jeżeli chodzi o cztery procesy to pylibmc jest zdecydowanym zwycięzcą . Zachęcam do robienia swoich testów. Do sporządzen

Ostatnio często muszę robić diffy w gicie i zapisywać je do plików. Przykładowa nazwa pliku z diffem wygląda tak: {branch}-{branch/commit}.diff Diffy pomiędzy poszczególnymi commitami nie są mi potrzebne. Aby otrzymać takiego diffa można wykonać komendę git diff {branch/commit} > ~/diffs/{branch}-{branch/commit}.diff . Przykłady: git diff develop > ~/diffs/develop-master.diff git diff 66666 > ~/diffs/66666-develop.diff git diff 18361 > ~/diffs/18361-develop.diff git diff 47529 > ~/diffs/47529-0dbf4fa.diff Jak widać jest trochę pisania.  po co za każdym razem wpisywać katalog w którym ma zostać stworzony plik po co podawać nazwę brancha na której właśnie jesteś (i to dwa razy!) ;) pracuj na gałęziach, których nazwy składają się wyłącznie z cyfr to oczopląsu dostaniesz po kilkunastu takich komendach Dlatego też postanowiłem napisać do tego prostą funkcję w bashu. Założenie było proste, mam podać nazwę funkcji i jako pierwszy parametr przekazać nazwę brancha/comm

bumpversion to ciekawa paczka do automatycznego podbijania wersji twojej paczki ;). ( screencast )  Jedną komendą jesteś w stanie podbić wersję w swojej paczce w kilku miejscach (oczywiście, najlepiej informację o wersji trzymać w jednym miejscu, ale czasami jesteś zmuszony, aby zrobić to w kilku plikach). Przykładowo, twoja aktualna wersja to 0.1.10, zrobiłeś małego fixa i chcesz podbić wersję do 0.1.11. Dodatkowo informacje na temat wersji trzymasz w pliku setup.py oraz w random_words/__init__.py . Zapomniałem dodać; jak chcesz to zajrzyj do paczki RandomWords , bo to na niej jest przykład. Teraz wystarczy odpalić: bumpversion --current-version 0.1.10 patch setup.py random_words/__init__.py i gotowe. Skrypt podbił wersję w pliku setup.py oraz w random_words/__init__.py Dokumentację i więcej przykładów użycia znajdziesz na githubie . P.S. Screena musiałem zrobić lokówką bo ubuntu odmówiło przed chwilą posłuszeństwa, a nie chce mi się resetować systemu.