Jedno hasło ważne przez 9999 dni? To nie jest dobry pomysł:

sudo chage --list testuser
Last password change                                    : Jun 06, 2024
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : Aug 31, 2024
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Na szczęście na Linuxie można zmieniać daty ważności hasła i wymaganą częstotliwość zmian.

Żeby haslo było ważne jeszcze tylko przez 90 dni użyj:

sudo chage --expiredate $(date -d +90days +%Y-%m-%d) testuser

Dodatkowo, można jeszcze określić politykę zmiany hasła dla użytkownika:

• wymuś zmianę, co 180 dni (to i tak dużo)
• ostrzegaj o wygasaniu hasła 14 dni wcześniej
• pozwól na ponowną zmianę hasła dopiero po 3 dniach od poprzedniej zmiany:

sudo chage --mindays 3 --maxdays 180 --warndays 14 testuser

Teraz konto wygląda tak:

sudo chage --list testuser
Last password change                                    : Jun 06, 2024
Password expires                                        : Dec 03, 2024
Password inactive                                       : never
Account expires                                         : Oct 14, 2024
Minimum number of days between password change          : 3
Maximum number of days between password change          : 180
Number of days of warning before password expires       : 14

Ogólnie git diff wymaga wskazania CO z CZYM ma być porównane:

git diff <commit_hash> <commit_hash> <file_name>

Ponieważ branch można postrzegać jako ostatni commit w zadanej gałęzi kodu, to zadziała również:

git diff <branch_name1> <branch_name2> <file_name>

Czasami jednak opuszczamy CO ma być porównane i regulujemy to wyłącznie opcjami. Oto takie przypadki:

Zobacz czym różni się kod w working directory od kodu w staging area:

git diff <file_name>

Czym różni się kod w staging area od skommitowanego kodu w repo

git diff --staged <file_name>
git diff --cached <file_name>

Czym różni się kod w working directory od skommitowanego kodu w repo:

git diff HEAD <file_name>

Jeśli jesteś ofiarą błędu „Server execution failed”, to

• otwórz Managera zadań (Ctrl+Shift+Esc),
• przejdź na „szczegóły”
• odszukaj procesu „Windows Media Player” i zakończ go

Jest szansa, że po tej akcji, pliki będą sie poprawnie odtwarzać 😉

Zacznijmy od tego, że się trzeba zalogować. Można to zrobić na różne sposoby, ale powiedzmy, że wykonamy polecenie:

az login

i dokończymy logowanie w przeglądarce.

Istotne jest, aby mieć odpowiednie uprawnienia. W przeciwnym razie dostaje się komunikat podobny do poniższego:

You do not have the required permissions needed to perform this operation.
Depending on your operation, you may need to be assigned one of the following roles:
„Storage Blob Data Owner”
„Storage Blob Data Contributor”
„Storage Blob Data Reader”
„Storage Queue Data Contributor”
„Storage Queue Data Reader”
„Storage Table Data Contributor”
„Storage Table Data Reader”

Jeśli dodasz sobie uprawnienia, bo były za niskie, to poczekaj chwilę przed kolejną próbą. Azure nie od razu widzi nadane uprawnienia. Dla pewności można sie nawet wylogować i zalogować ponownie. Polecenie do wylogowania to:

az logout

No i przechodzimy do esencji, czyli kopiowania pliku. Odpowiednia komenda to az storage blob copy start. Polecenie trochę długie, ale ma sens. Na początku az, czyli nazwa komendy. Potem storage, bo pracujemy ze storage. Blob, bo kopiowanie ma się odbyć na blob service, dalej copy, bo chcemy przekopiować plik i ostatecznie start, bo to polecenie jest asynchroniczne – komenda się wykona, a kopiowanie może nadal trwać w tle. Dodatkowe parametry do przekazania to:

• –destination-blob <filename> – określa nazwę, pod jaką plik ma się pojawić na blobie
• –destination-container <containername> – określa nazwę kontenera, do którego plik ma być przesłany
• –account-name <storageaccountname> – tutaj podaj krótką nazwę storage account. Nie trzeba podawać długiej nazwy, bo Azure już wie, że chodzi o blob service, a krótka nazwa i tak musi być unikalna globalnie w skali całego świata
• –source-uri <uri> – określa adres źródłowy, pod jakim znajduje się plik do przekopiowania
• –authmode login – mówi, że żądanie ma być uwierzytelnione w oparciu o EntraID – właśnie dlatego ten przykład zaczął się od zalogowania do Azure

Oto przykład pełnej komendy, która „kradnie” plik z wikipedii i umieszcza na twoim storage account

az storage blob copy start --destination-blob comp1.jpg --destination-container test_container --account-name stoacc7635442 --source-uri https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/IMac.jpg/330px-IMac.jpg --auth-mode login

Znajomość zapytań w pracy z SQL Server to już bardzo dużo, ale jeszcze więcej można osiągnąć znając procedury, triggery i funkcje. Dlaczego?

• Procedury są efektywniejsze, bezpieczniejsze, pozwalają zapisać w bazie danych oprócz samych rekordów również logikę, która decyduje o tym, jak dane mają być przetwarzane
• Dzięki parametrom procedury i funkcje mogą wykonywać różne operacje, w zależności od tego jak zostały uruchomione
• Triggery pozwalają z kolei na wykonywanie rzeczy, które inaczej byłyby niemożliwe do zrobienia: propagacja danych, aktualizacja widoków, kontrola danych – na wyższym logicznym poziomie itp.

Znajomość SQL Server przyda się nie tylko programistom i administratorom SQL, ale też analitykom danych i inżynierom Data Science.

Sporą porcję wiedzy właśnie na ten temat znajdziesz na kursie SQL Server #5: Procedury, triggery i funkcje, dostępnym na Udemy. Kurs zawiera kilka godzin materiału video, podzielonego na przyjemne kilkuminutowe lekcje, podręcznik PDF z notatkami do każdej lekcji, zadaniami do rozwiązania, propozycjami rozwiązań i repozytorium kodu na GitHub. Aktualne kody promocyjne znajdziesz na stronie www.kursyonline24.eu

Praca z Jupyter Notebook daje fajną izolację od tego co dzieje sie na poziomie systemu operacyjnego. Co jednak zrobić, kiedy chcesz dowiedzieć się z jaką wersją modułu lub pythona pracujesz? Prosto:

Żeby sprawdzić numer wersji Pythona użyj:

import sys
sys.version_info

Żeby sprawdzić numer wersji modułu skorzystaj z :

import pandas as pd
pd.version

Aktualizacja KB5034441 na Windows 10 może kończyć się błędem jeśli partycja recovery jest zbyt mała (np. rozmiar 445 był zbyt mały, ale już 799 jest ok).

Poradnik opisujący, jak zmienić rozmiar partycji dodając do niej 250 MB znajduje się tutaj i zadziałał dla mnie idealnie:

KB5028997: Instrukcje ręcznej zmiany rozmiaru partycji w celu zainstalowania aktualizacji WinRE – Pomoc techniczna firmy Microsoft

Oto, jak wyglądało wykonanie wszystkich kroków:

Czytaj dalej »