Nie sądziłem, że powstanie druga część.
Z drugiej strony pierwsza część była znośna, na pewno lepsza niż można było sądzić po zwiastunie.
Jak sobie pościelesz to mnie zawołaj
Nie sądziłem, że powstanie druga część.
Z drugiej strony pierwsza część była znośna, na pewno lepsza niż można było sądzić po zwiastunie.
Książka „Co nas nie zabije” Lagercrantza była niezła, choć słabsza niż trylogia Larssona. Jej ekranizacja – „Dziewczyna w sieci pająka” – jest niestety słaba.
Żeby w kontenerze Symfony uzależnić rodzaj wstrzykiwanego obiektu od akcji, która jest wykonana można posłużyć się następującym wyrażeniem:
app.some_service: class: App\Service\SomeService arguments: - "@=service(container.get('request_stack').getCurrentRequest() !== null and container.get('request_stack').getCurrentRequest().get('_route') == 'app_some_route' ? 'app.dependency.specific’ : 'app.dependency.generic’)"
Tak skonfigurowana usługa app.some_service
zostanie zbudowana z zależnością app.dependency.specific
jeśli aktualna trasa (route) to app_some_route
, a jeśli inna to zostanie wstrzyknięta app.dependency.generic
. W praktyce można to wykorzystać np. do wstrzyknięcia repozytorium bazodanowego w dla akcji z panelu administracyjnego (gdzie potrzebna jest aktualna wersja danych) lub repozytorium czerpiącego dane z cache dla prezentacji danych użytkownikom.
Z drugiej strony taka definicja usługi jest zagmatwana i może utrudniać debugowanie, więc pewnie postarałbym się inaczej rozwiązać taki problem.
Podczas przenoszenia systemu na nowy dysk zafundowałem sobie mały problem: nazwałem grupę woluminów LVM tak samo jak na starym dysku. Kiedy do świeżo postawionego systemu podłączyłem stary dysk, żeby skopiować dane ów problem objawił się tak:
# vgscan Reading volume groups from cache. Found volume group "cherokee" using metadata type lvm2 Found volume group "cherokee" using metadata type lvm2
Jak wiadomo, żeby aktywować LVM trzeba podać nazwę grupy woluminów, a skoro ta jest zduplikowana to jest to problem. Jego rozwiązaniem jest zmiana nazwy jednej z grup. Ja postanowiłem zmienić nazwę starej grupy.
Czytaj dalej „Zduplikowana nazwa grupy woluminów LVM”
Pracuję na laptopie Dell Latitude E5450 z replikatorem portów Dell Advanced E-Port II oraz z dwoma monitorami Dell U2515H podłączonymi przez DisplayPort. Na co dzień taki zestaw spisuje się dobrze, ale przez długi czas trapiła mnie uciążliwa usterka. Mianowicie po zablokowaniu/uśpieniu laptopa, co powoduje wygaszenie wszystkich ekranów, a następnie odblokowaniu/wybudzeniu dodatkowe monitory pozostawały wygaszone. W systemie były widoczne, w ustawieniach ekranu były na swoich miejscach, ale nie wyświetlały obrazu.
Próbowałem różnych rozwiązań: połączenia przez HDMI, użycia sterowników NVidii zamiast nouveau, ale okazały się nieskuteczne. Doraźnym rozwiązaniem była zmiana rozdzielczości obrazu albo wzajemnego położenia ekranów.
Skuteczne rozwiązanie podpowiedział mi kolega z pracy. Jest nim przestawienie w menu monitora na użycie DisplayPort 1.2. Po wykonaniu tej operacji od kilku dni problem nie występuje.
Przed wykonaniem tej operacji należy upewnić się, że sprzęt i system obsługują DisplayPort. Kolega, który pracuje na identycznym zestawie, za moją radą przestawił monitor na DisplayPort 1.2 i monitor przestał wyświetlać obraz, w OSD nawet nie można było wybrać menu, w którym jest opcja przestawienia wersji DisplayPort. Żeby to odkręcić musieliśmy podpiąć jego monitor pod mój komputer.
Młodsi stażem programiści pewnie tego nie pamiętają, ale kiedyś synonimem systemu kontroli wersji był Subversion. W dziewięciu na dziesięć przypadków podczas rozmowy kwalifikacyjnej należało się wykazać znajomością SVN-a.
Z tamtych czasów zostało mi kilka projektów w SVN-ie. Większość z nich już od dawna nie funkcjonuje, ale kilka wciąż żyje, np. acp czy ta strona. Raz na ruski rok coś w nich poprawiam, choć ze wstydem przyznaję, że robiłem to wprost na serwerze, bo przy wymianie domowego serwerka parę lat temu już nawet nie stawiałem serwera Subversion. Teraz jednak postanowiłem zrobić z tym porządek i przenieść kod do gita.
Pamięć podręczna przeglądarki może napsuć krwi programistom zajmującym się frontem. Wielokrotnie byłem świadkiem podobnych dialogów:
– Frontend developerze, mówiłeś, że to naprawiłeś, a nie działa.
– Naciśnij Control i F5.
– Aaa, OK.
Żeby wymusić na przeglądarce pobranie nowej wersji plików (JavaScriptów, arkuszy stylów) można do nazwy pliku dodać query string z wartością zmienianą razem plikami czyli tzw. cache buster, na przykład:
<link rel="stylesheet" type="text/css" href="compiled.css?v=1.23">
Mniej więcej tak robiliśmy w aplikacji, z którą obecnie dużo pracuję. Występujące w przykładzie 1.23 to była wersja aplikacji. Wartość ta była pobierana z pliku konfiguracyjnego. To rozwiązanie miało przynajmniej dwie wady:
Ponieważ do wydań używamy ansible’a postanowiliśmy zautomatyzować generowanie wartości dla cache bustera.
W pierwszym podejściu chciałem użyć daty i czasu wykonania skryptu np. w formacie RRMMDDGGMMSS
, ale to rozwiązanie nie za dobrze działa w wypadku, gdy wydanie jest robione dla podzbioru serwerów (tzw. rolling update). Czas uruchomienia skryptu jest inny dla każdej grupy serwerów.
Lepszym rozwiązaniem moim zdaniem jest użycie ID commitu z gita. Zalety tego podejścia to:
W roli ansible’a można to ograć następująco:
- name: "Get git short commit ID" command: git rev-parse --short HEAD args: chdir: "/tmp/build-directory" register: git_revparse
W powyższym przykładzie wartość chdir
to katalog, w którym mamy kod aplikacji z repozytorium git. Po wykonaniu tego kroku w
w zmiennej git_revparse.stdout
będzie znajdować ID commitu, które można przekazać np. do szablonu pliku konfiguracyjnego.
Obecnie linki do skryptów i styli wyglądają mniej więcej tak:
<link rel="stylesheet" type="text/css" href="compiled.css?v=c109ad9">
Swego czasu Skype na Linuksie (w tym na Debianie) był bardzo ułomny, dostępna była wyłącznie wersja 32-bitowa, a instalacja była upierdliwa. Między innymi dlatego starałem się unikać Skype’a.
Niedawno zostałem zmuszony do przeproszenia się ze Skype’em i ku memu zaskoczeniu okazało się, że Skype for Linux dojrzał. Ze strony można pobrać pakiet DEB, a instalacja sprowadza się do zwyczajowego:
dpkg -i /home/joe/Pobrane/skypeforlinux-64.deb
Instalator dodaje repozytorium do listy źródeł apta, ale nie pobiera klucza, więc po wykonaniu aptitude update pojawi się błąd:
W: Błąd GPG: https://repo.skype.com/deb stable InRelease: Następujące podpisy nie mogły zostać zweryfikowane z powodu braku klucza publicznego: NO_PUBKEY 1F3045A5DF7587C3 E: The repository 'https://repo.skype.com/deb stable InRelease' is not signed. E: Failed to download some files W: Nie udało się pobrać https://repo.skype.com/deb/dists/stable/InRelease: Następujące podpisy nie mogły zostać zweryfikowane z powodu braku klucza publicznego: NO_PUBKEY 1F3045A5DF7587C3 E: Nie udało się pobrać niektórych plików indeksu, zostały one zignorowane lub użyto ich starszej wersji.
Żeby go naprawić wystarczy pobrać klucz GPG:
curl https://repo.skype.com/data/SKYPE-GPG-KEY | apt-key add -
Sama aplikacja (w wersji 5.3.0.1) zdaje się działać poprawnie i stabilnie, niestety wciąż brakuje w niej niektórych funkcji, np. Udostępniania ekranu podczas rozmowy konferencyjnej.
Jakdojade to jedna z najczęściej używanych przeze mnie aplikacji na telefonie. Na jednym ekranie mam dwa widżety z przystankami, z których najczęściej korzystam. Niestety po wymianie telefonu (Xiaomi Redmi 3S) godziny odjazdów w widżetach przestały być aktualizowane.
Czasami chwilowo pomagało otworzenie obserwowanych przystanków w aplikacji, ale po kilk lub kilkunastu godzinach dane znowu były nieaktualne. Myślałem, że to może być problem z uprawnieniami aplikacji do korzystania z transferu danych, jednak to był błędny trop.
Skuteczne rozwiązanie także było związane z uprawnieniami, ale do innej czynności, a mianowicie autostartu. Po dodaniu aplikacji Jakdojade do autostartu godziny odjazdów w widżetach są regularnie aktualizowane.
Rok temu pisałem o łączeniu staromodnej aplikacji z Laravelem. Po zmianach w konfiguracji środowiska PHP wypłynął nowy problem, a mianowicie Laravelowi nie podobały się identyfikatory sesji generowane przez starą aplikację, więc w ich miejsce generował nowe tym samym skutecznie niwecząc dzielenie sesji.
Identyfikatory generowane przez starą aplikację wyglądały np. tak: mh3e2fj757ed8nnlukqf5ag0f3
. Tymczasem Laravel (konkretnie wersja 5.1) za jedynie słuszne uznaje identyfikatory składające się z 40 znaków (cyfry i litery od a do f). Takie zachowanie zdefiniowane jest w metodzie \Illuminate\Session\Store::isValid()
:
public function isValidId($id) { return is_string($id) && preg_match('/^[a-f0-9]{40}$/', $id); }
Rozwiązaniem tego problemu jest takie skonfigurowanie sesji PHP-owych, by identyfikatory spełniały wymagania Laravela 5.1:
ini_set('session.hash_function', 'sha1'); ini_set('session.hash_bits_per_character', '4');