W Pandas, seria danych to po prostu ciąg wartości. Wartość numer 2 to po prostu element prostego typu. Bardzo podobnie na pierwszy rzut oka wygląda jednokolumnowy DataFrame, ale… pewne różnice są:

numbers=[1, 2, 3, 4]
letters=['A', 'B', 'C', 'D']

Tak powstaje seria danych – dla „zmyłki” indeksem jest kolumna numbers:

ds = pd.Series(data=letters, index=numbers)
ds

oto wynik:

Out[45]: 
1 A
2 B
3 C
4 D
dtype: object

A tak wygląda to, jeśli utworzymy DataFrame, który ma jedną kolumnę i indeks zdefiniowany w oparciu o numbers:

df = pd.DataFrame(data=letters, index=numbers)
df

wynik jest na pierwszy rzut oka podobny:

  0
1 A
2 B
3 C
4 D

Duże różnice pojawią się jednak przy odwołaniu do konkretnej pozycji:

ds.loc[1]
Out[47]: 'A'

a dla DataFrame:

df.loc[1]
Out[48]: 
0 A
Name: 1, dtype: object

Żeby uzyskać dostęp do PostgreSQL, to należy mieć dostęp do tzw. Login role (dawniej user). Jeśli taka rola jest oznaczona jako superuser, to ta rola uzyskuje nieograniczone uprawnienia do serwera bazy danych. Podczas instalacji serwera, taka rola jest tworzona automatycznie i nazywa się postgres. Role mogą też służyć do nadawania uprawnień nie nadając bezpośrednio dostępu do serwera. Role można w sobie zagnieżdżać. Rola, której członkiem są inne role nosi nazwę group role, a jeśli ta rola pozwala też na korzystanie z serwera to jest to group login name. W sumie logiczne 😊

Poniższa komenda tworzy rolę camila z dodatkowym uprawnieniem do tworzenia nowych baz danych

CREATE ROLE camila LOGIN PASSWORD 'Passw0rd’ VALID UNTIL 'infinity’ CREATEDB;

Słowo superuser dodane na końcu polecenia powoduje, że użytkownik staje się pełnoprawnym i „wszechmocnym” administratorem

CREATE ROLE adm_dagmara LOGIN PASSWORD 'P@ssw0rd’ VALID UNTIL '2030-01-01 00:00′ SUPERUSER;

Jeśli rola nie ma służyć do logowania, to należy opuścić słowo LOGIN. Dodane tutaj INHERIT powoduje, że inne role dodane jako członkowie do toli adm_security będą dziedziczyć jej uprawnienia. Ta opcja jest w zasadzie domyślna, więc nie trzeba jej wpisywać jawnie.

CREATE ROLE adm_security INHERIT;

Grant pozwala dodać jedną rolę do innej roli jako członka. W ten sposób camila otrzyma wszystkie przywileje roli adm_security (bez ewentualnego przywileju superuser, bo ten jako jedyny nie podlega dziedziczeniu)

GRANT adm_security TO camila;

Do nadawania przywilejów dla ról należy posłużyć się poleceniem ALTER ROLE

ALTER ROLE adm_security SUPERUSER;

Kiedy użytkownik należy do roli, to może się przełączyć w tą rolę korzystając z SET ROLE

SET ROLE adm_security;

Po wykonaniu takich przełączeń można na bieżąco sprawdzać w jakiej tożsamości w danej chwili się pracuje. Stąd też można odwołać się do zmiennych session_user i current_user. Session_user określa nazwę roli jaka została wykorzystana do początkowego połączenia do serwera, zaś current_user to nazwa tożsamości w jakiej w danej chwili znajduje się użytkownik

SELECT session_user, current_user;

Dodatkowo superuser ma prawo wykonywać polecenie SET SESSION AUTHORIZATION, które  zmieni nawet wpis dotyczący roli używanej na początku do zainicjowania połączenia

SET SESSION AUTHORIZATION ROLE adm_security;

Poprzez przełączanie się miedzy rolami może dojść do… przekrętów. Camila będąc członkiem roli adm_security może zmienić swoją rolę na adm_security. Niestety nie dziedziczy w ten sposób przywileju superuser. Jednak rola adm_security ma przywilej superuser, więc może teraz zmienić swoje konto camila nadając mu uprawnienie superuser. Od tej pory może już robić wszystko!

Każda poważna baza danych musi nie tylko w poprawny sposób zapisywać dane, ale także musi dawać administratorowi możliwość sprawddzania tej aktywności. W przypadku postgresa takim narzędziem jest widok

pg_stat_activity

Dzięki niemu zobaczysz kto skąd, a nawet po co , połączył sie do serwera. Narzędzie może być przydatne podczas śledzenia przyczyn zablokowanych sesji. W kolumnach tego widoku w szczególności można znaleźć opis zakładanych locków. Przy typowym zablokowaniu rekordu na wyłączność przez 2 użytkoników znajdziesz tu np. wpis:

LOCK, transaction_id

co oznacza, że transakcja została zablokowana przez inną transakcje. Pełny wykaz możliwych locków można znaleźć w dokumentacji:

https://www.postgresql.org/docs/9.6/monitoring-stats.html#WAIT-EVENT-TABLE

Jeden z popularniejszych obecnie edytorów kodu to Visual Studio Code Editor. Jego popularność wynika pewnie z tego, że jest niewielki (to zaleta) i można doinstalować do niego rozszerzenia, które powiększają/dodają nowe możliwości tego narzędzia. Np. w VSC można wygodnie pisać kod Pyhona po zainstalowaniu dodatku Python. Co więcej, takich dodatków jest wiele, ale akurat ten wydawany przez Microsoft jest najpopularniejszy. To tyle jeśli chodzi o marketing, tymczasem… po zainstalowaniu dodatków trzeba je nierzadko jeszcze dokonfigurować i o tym chcę tu właśnie napisać.

Załóżmy, że jest już zainstalowany Python i VSC oraz zainstalowano już dodatek Python. Aby rozpocząć pracę nad nowym projektem Pythona można w VSC wybrać polecenie File >> Open Folder. Projekty i związane z nimi ustawienia środowiska są zapisywane w wybranym katalogu, który początkowo może być pusty.

W tym katalogu można teraz utworzyć plik z rozszerzeniem .py tak aby był skojarzony z Pythonem. Czy to jednak wystarczy do tego aby VSC wiedział jak go uruchomić? Niestety niekoniecznie. W ustawieniach należy wskazać jaki interpreter ma być wykorzystywany podczas uruchamiania skryptu. Ma to sens zwłaszcza w przypadku, gdyby na komputerze było zainstalowanych więcej interpreterów, np. różne wersje pythona.

Po wpisaniu kodu, gdy chcesz go uruchomić, teoretycznie wystarczy kliknąć prawym przyciskiem myszy gdziekolwiek w obszarze edytora i wybrać Run file in editor:

W tym momecie może paść pytanie o wybór interpretera. Wskaż jeden z zainstalowanych wcześniej interpreterów Python.

Co jeszcze może pójść nie tak? Może się otworzyć okno terminala, krórym będzie CMD.EXE lup powershell.exe. Zazwyczaj preferujemy, żeby kod był uruchamiany we wbudowanym terminalu w okienku pod edytorem i żeby tym domyślnym terminalem był cmd.exe, a nie powershell.

Jeśli otwiera się specjalne okno, to przejdź do File >> Preferences >> Settings, przejdź do sekcji Features >> Terminal i odszukaj ustawienia Integrated: Windows Enable Conpty. Tą opcję należy wyłączyć. Spwoduje to, że nowe okno terninala nie będzie otwierane jako zewenętrzna niezależna aplikacjia, ale właśnie jako element VSC

Ze zmianą terminala na cmd lub python będzie prościej. Po uruchomieniu terminala (Terminal >> New terminal), w oknie w dolnej części można wybrać typ terminala. Tutaj widać, że zaznaczony jest cmd, ale można by zmienić terminal na powershell, lub wybrać domyślny terminal poprzez „select default profile”.

Lista domyślnych profili jest wyświetlana w górnej części:

Osobiście, chociaż jestem fanem PowerShella, to tutaj wolę pracować z cmd.

Jeśli chodzi o wybór interpretera Pythona, to można to zrobić klikając informację na pasku statusu:

Spowoduje to wyświetlenie w górnej części okna listy z dostępnymi interpreterami:

Jak więc widać, sporo ustawnień konfiguracyjnych jest koniec końców dokonywanych w liście w górnej części okna. To okno można otworzyć skrótami klawiaturowymi

CTR + SHIFT + P

lub

F1

Potem wystarczy wyszukać ustawienia wpisując fragment jego nazwy. Ponieważ ustawień jest sporo to będąc w File >> Preferences >> Settings można wyszukać ustawienia wpisując fragment jego nazwy, a potem… wybierając polecenie „Edit a setting json”, możesz podejrzeć definicję ustawienia w postaci JSON. Takie podejście dla programisty jest dość poręczne i daje duże możliwości kontroli nad narzędziem:

W artykule

Azure: zdalna zmiana rejestru w celu zmiany opcji połączeń zdalnych

opisałem, jak zmodyfikować rejestr maszyny wirtualnej znajdującej się w Azure, w celu odblokowania możliwości połączenia do tej maszyny z komputerów bez uwierzytelnienia klienta. Z czasem jednak, ta metoda delikatnie się zmieniła. Teraz nie można już załadować bezpośrednio pliku skryptu do uruchomienia, tylko trzeba ten plik wybrać ze storage account. Dochodzi więc jeden dodatkowy krok – stworzenie storage account i przegranie tam pliku skryptu.

tak wygląda początkowe okno pobierania skryptu „extension”

Po kliknięciu „browse” należy wybrać storage account. Zakładając, że go nie masz, trzeba kliknąć „+Storage account”

Tutaj tworzysz storage account – najważniejsze to wymyślić unikalną nazwę i wybrać inne parametry – celuj w te tańsze 🙂

Dzięki temu można już wybrać storage account, ale…

jest on pusty. Trzeba najpierw założyć container. W tym celu kliknij „+Container”

Ten kontener można wybrać, ale…

… jeszcze nie ma na nim plików (skryptów), dlatego można kliknąć „upload” i załadować skrypt extension.

Ten skrypt należy następnie wybrać i taddam – jesteśmy w sumie w tym samym miejscu, co w poprzednim artykule!

Niestety takie ciagłe zmiany w Azure, to coś do czego musimy przywyknąć.

Podczas odtwarzania bazy danych przy pomocy narzędzia Tivoli Data Protection pojawil się komunikat:

Failed – Error: RC: 1914
 ACO5422E Received the following from the MS SQL server: Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system cannot find the file specified

No dobrze, ale to jakiego pliku konkretnie brakuje? Pliku wrpawdzie w komunikacie nie ma ale za to jest nazwa pbrakującego pakietu. Dobre i to! Smo to Shared Management Objects. SMO wchodzi w sklad pakietu SQL Features Pack wydawanego osobno dla kazdej wersji SQL. Komunikat mowi o wersji 12, czyli zgodnie z numeracją Mocrosoft SQL 2014. Można go pobrać stąd:

https://www.microsoft.com/en-us/download/details.aspx?id=42295

Ale i tak coś mi tu jeszcze spokoju nie daje. SQL na którym pracuję to SQL 2016. Baza, którą odtwarzam to 2012. Dlaczego mam instalować SMO 2014? Nie chcę śmiecić na serwerze z SQL 2016  instalajami z 2014. Dlatego zacząlem od 2016. Nie pomoglo. Potem zainstalowlem 2012. Nie pomoglo. No to w koncu uzylem 2014 – bingo! Na cale szczescie restarty nie byly potrzebne

Maly pakiet – 6-7 MB, a dal pomyśleć!

Niektóre aplikacje wymagają ustawienia zmiennych środowiskowych. W command line to nie problem:

SET FLASK_DEBUG=1

i gotowe! Jednak coraz częściej to PowerShell jest domyślnym shellem. Jak więc ustawić zmienną środowiskową w PowerShell?

[System.Environment]::SetEnvironmentVariable('FLASK_DEBUG', '1',[System.EnvironmentVariableTarget]::Process)

Nie jest to zbyt proste, ale:

• [SystemEnvironment] pozwala odwołać się do programistycznej klasy, która odpowiada za zarządzanie środowiskiem
• SetEnvironmentVariable – to metoda statyczna w/w klasy, która odpowiada za ustawienie zmiennej środowiskowej
  • pierwszy argument to nazwa zmiennej
  • drugi argument to jej wartość
  • trzeci argument określa zakres widoczności zmiennej. Mamy do wyboru Machine, User albo Process. Process stworzy zmienną tylko na skalę tego jednego procesu i jego procesów potomnych

Jak więc widać… trochę to bardziej skomplikowane. Dla uzupełnienia powiedzmy jeszcze jak ustawić zmienną środowiskową w BASH:

FLASK_DEBUG=1
export FLASK_DEBUG

Sprawdzenie zmiennych środowiskowych:

command line:

echo %FLASK_DEBUG%

PowerShell

$env:FLASK_DEBUG

BASH

echo $FLASK_DEBUG