We wprowadzeniu do wyrażeń regularnych pisałem, że tekst przeanalizowany przez silnik nie może być analizowany ponownie. Jednak nie do końca była to prawda. Wyrażenia regularne dostarczają nam mechanizm lookaround, który pozwala nam rozejrzeć się z poziomu aktualnie analizowanego miejsca.

W poprzednim wpisie z serii o RabbitMQ dowiedzieliśmy się jak poprawnie obsłużyć sytuację w której konsument z jakiegoś powodu nie poradził sobie z obsłużeniem wiadomości. Powodów może być wiele, ale nie to jest najważniejsze. Najważniejsze jest to, że wiadomość bezpiecznie wróciła do kolejki i może być obsłużona ponownie. Tylko, że w praktyce oznacza to często zapętlenie się jednej operacji, bo wiadomość, która wróciła do kolejki prawdopodobnie za chwilę znów nie zostanie obsłużona poprawnie. W tym wpisie postaram się wyjaśnić co zrobić w takim przypadku i jak rozbudować nasze kolejki o mechanizm Dead Letter Exchange.

W relacyjnych bazach danych tworzenie relacji jest naturalnym sposobem odwzorowywania rzeczywistości. Jednak w przypadku, gdy mamy odczynienia z wyszukiwarką opartą o nierelacyjną bazę danych sprawy nieco się komplikują. Choć ElasticSeach dostarcza mechanizm parent / child, który można potraktować jako odpowiednik relacji w tradycyjnej bazie danych.

W ostatnim wpisie stworzyliśmy prostego producenta oraz konsumenta wiadomości. Wszystko działało prawidłowo, jednak nasze aplikacje były bardzo proste oraz ich działanie nie było uzależnione od żadnych aplikacji zewnętrznych, co nie zawsze będzie prawdą. Dlatego warto przygotować się na najgorsze scenariusze. A takim scenariuszem może być sytuacja, w której podczas przetwarzania wiadomości przez konsumenta nastąpi jego niespodziewane zakończenie i nie zdąży on poprawnie przetworzy otrzymanej wiadomości. Co zrobić w takim przypadku ??

Życie blogera jest ciężkie. Po zakończeniu prac nad wpisem zamiast się nim cieszyć, to już myśli jaki będzie kolejny. Po wpisie o SQL-u czas na coś dużo lżejszego. Czyli coś o co czasem jestem pytany, a mianowicie jaki ostatnio dobry film obejrzałem. I nie mam na to pytanie dobrej odpowiedzi, zwyczajnie nie pamiętam wszystkich dobrych filmów, które mógłbym z polecić. Więc w takich sytuacjach przypominam sobie ten ostatni, który był dobry. A przecież jest ich tak wiele.

Bazy danych są wszędzie, niezależnie czy zdajesz sobie z tego sprawę czy nie. Czytając artykuł na swojej ulubionej stronie internetowej możesz mieć niemal 100% pewność, że jest on zapisany w jakiejś bazie danych. Wśród stron internetowych niekwestionowanym liderem jest MySQL. To nie znaczy, że jest to jedyny wybór. Mamy jeszcze takie silniki bazodanowe jak PostgreSQL, SQLite, MSSQL, Oracle i wiele więcej.

Posiadając stronę internetową zapewne mamy na niej zainstalowane statystyki. W większości przypadków będą to statystyki Google Analytics, które zbierają sporo informacji o użytkownikach wchodzących na naszą stronę. Pytanie tylko, czy potrafimy odpowiednio wykorzystać tę wiedzę i czy nie dało by się wycisnąć z nich jeszcze więcej ??

ElasticSearch rozwija się bardzo dynamicznie w związku z czym możemy zaobserwować dość częste wydawanie nowej wersje silnika. I pojawia się pytanie, czy aktualizować ? Osobiście chętnie aktualizuję, czy to ElasticSearch-a, czy też frameworki na których pracuję. Wyznaję przy tym kilka zasad, jedna z nich to stabilność działania. Dlatego w tym wpisie pokażę, jak w prosty sposób przenieść nasze indeksy do nowszej wersji ElasticSearch-a wykorzystując _reindex.

Pracując z GIT-em jesteśmy przyzwyczajeni do pracy z gałęziami. A to za sprawą bardzo prostej idei jaka za nimi stoi. Mamy gałąź główną master i na jej bazie tworzymy nowe gałęzie, które później scalamy. Proste, eleganckie i bardzo wygodne rozwiązanie. Jednak możliwe jest nieco inne podejście do tematu gałęzi. Podejście to pozwala przechowywać kilka różnych "projektów" w jednym repozytorium bez wzajemnych relacji pomiędzy poszczególnymi gałęziami.

Close