Python/DevOps

Watchdog is a python API and shell utilities to monitor file system events . I am using it for tasks like build sphinx docs or run tests after changes in file/directory. It's very easy to use. For instance, you are writing documentation and after each saving file you have to run command like "make html". So, why you don't this automatically?   Simple command: watchmedo shell-command --command="make html" --wait source What does it? Watchdog began to watch source directory. If something in this directory will be changed, then watchdog will run your command (make html). Simply, right? If you use Firefox you can install Auto Reload add-on. Auto Reload automatically reloads matching tabs when selected local files change. So, after saving file, your documentation will build automatically and Firefox automatically will refresh tab with documentation in browser, brilliant! You can also use patterns. For example, you want to run tests after saving file...

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/...

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.

Jeżeli korzystasz z Travis-CI do testowania swojego repozytorium na githubie oraz trzymasz paczkę na pypi , możesz w łatwy i prosty sposób dodać informacje na temat statusu do pliku README. Dzięki temu userzy będą widzieć czy wszystkie testy przeszły pomyślnie, jaka jest aktualna wersja paczki oraz jaka jest ilość ściągnięć. U mnie dla repo RandomWords wygląda to tak: Travis-CI W dokumentacji travis-ci znajdziesz informacje o tym co musisz umiejscowić w odpowiednim pliku. PyPI Osobiście korzystam z dwóch formatów. Markdown dla github oraz reStructuredText dla PyPI. Markdown : [](https://crate.io/packages/$REPO-NAME/) [](https://crate.io/packages/$REPO-NAME/) reStructuredText : .. image:: https://pypip.in/v/$REPO-NAME/badge.png :target: https://crate.io/packages/$REPO-NAME/ :alt: Latest PyPI version .. image:: https://pypip.in/d/$REPO-NAME/badge.pn...