Co ona oznacza? Jakie inne opcje oprócz inline są możliwe do uruchomienia?
Odpowiedź w skrócie: rysując wykres, możesz go uzyskać w dodatkowym okienku, które otworzy się, kiedy ten wykres pokazujesz, ale można też umieścić wykres bezpośrednio w Notebooku. Opcje domyślne się zmieniają – w starszych notebookach wykresy domyślnie generowały sie w ekstra oknie, a w nowszych są wbudowywane w notebook.
Jeśli chcesz się pobawić i zobaczyć, jak inaczej można by generować wykresy uruchom:
I sorry za brak kompentencji hahah, ale nie znam znaczenia wszystkich tych opcji 🙂 Część z nich u mnie w ogóle nie działa 🙂
Ale wykonałem takie oto próby, które powinny pomóc w zrozumieniu, jak z tym pracować. Co bardzo ważne – kernel notebooka należy przed uruchomieniem tego kodu zrestartować, tak, aby ten kod uruchomił się jako pierwszy. Ten kod otworzy nowe okno:
import numpy as np
import matplotlib.pyplot as plt
%matplotlib qt
# evenly sampled time at 200ms intervals
t = np.arange(0., 5., 0.2)
# red dashes, blue squares and green triangles
plt.plot(t, t, 'r--', t, t**2, 'bs', t, t**3, 'g^')
plt.show()
Po restarcie i zmianie kodu na:
import numpy as np
import matplotlib.pyplot as plt
%matplotlib inline
# evenly sampled time at 200ms intervals
t = np.arange(0., 5., 0.2)
# red dashes, blue squares and green triangles
plt.plot(t, t, 'r--', t, t**2, 'bs', t, t**3, 'g^')
plt.show()
Wykres jest umieszczany poniżej komórki, w której kod został uruchomiony.
No i bardzo ważne – zależnie od narzędzia jakiego używasz (Spyder, Jupyter, VSC, …) coś może zadziałać, albo nie, bo komendy rozpoczynające się od % działają nisko na poziomie modułu, który modyfikują.
Jeśli jesteś zainteresowany szczegółami poczytaj tu: https://www.scaler.com/topics/matplotlib-inline/
Visual Studio Code pozwala na korzystanie ze środowisk wirtualnych tworzonych w Pythonie. Takie środowisko bywa czasami uparte i nie chce sie automatycznie uruchomić. Oto jak udało mi się skłonić VSC do automatycznego uruchamiania wybranego środowiska.
– otwórz nowy pusty folder (projekt)
– otwórz terminal i stwórz nowy environment
python -m venv myenv
– dodaj do projektu plik z kodem pythonowym (wystarczy żeby miał w sobie cokolwiek, np. print(’hello’))
– naciśnij Ctrl+Shift+P i wyszukaj w palecie polecenia „Select Python interpreter”
– wskaż na interpreter z utworzonego wcześniej environment (w podkatalogu myenv)
Teraz jeśli uruchomisz nowy terminal, to ten terminal automatycznie aktywuje środowisko myenv (uruchamiając terminal miej już otwarty plik .py)
Jeśli uruchomisz skrypt, VSC też aktywuje to środowisko.
Bywa, że chcesz, żeby w menu Windows pojawiła się nowa pozycja, której program instalacyjny sam z siebie nie zainstalował. W końcu menu, to tylko zbiór skrótów do programów, wydaje się więc, że powinno być możliwe dodanie tam czegokolwiek. I rzeczywiście!
Menu można modyfikować globalnie dla wszystkich użytkowników komputera poprzez modyfikacje w
C:\ProgramData\Microsoft\Windows\Start Menu
Jeśli masz problem ze znalezieniem tego miejsca, albo w następnych wersjach Microsoft miałby je umieścić gdzie indziej, to można sprawdzić lokalizację menu z PowerShella:
[Environment]::GetFolderPath('CommonStartMenu')
a korzystając z komendy:
ii "$([Environment]::GetFolderPath('CommonStartMenu'))"
można ten folder od razu otworzyć w windows explorer!
Menu dla użytkownika znajduje się w katalogu:
C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu
Ścieżka do tego katalogu może być zwrócona przez polecenie PowerShell:
[Environment]::GetFolderPath('StartMenu')
a folder otworzysz w Windows Explorer korzystając z:
ii "$([Environment]::GetFolderPath('StartMenu'))"
Teraz pozostaje tylko umieszczać w tych katalogach podkatalogi, skróty do programów, a menu Windows będzie te zmiany prezentować.
IBM Tivoli Data Protection to jedeno z rozwiązań ciągle używanych do wykonywania kopii zapasowej baz danych SQL. Narzędzie ma swoje wady i zalety, ale robi to co ma robić i chwała mu za to.
Dokumentacja produktu jest stworzona w dość typowy dla IBM pokrętny sposób. Niby wszystko tam jest, ale znalezienie sensownej informacji – to już jest najwyraźniej „out-of-scope” największej korporacji.
Tym razem zmierzyłem się z odtwarzaniem bazy danych master na serwerze SQL. Jak należało się spodziewać, wszelkie udogodnienia stworzone dla administratora w tym momencie przestają działać: przystawka mmc dedykowana dla Tivoli, owszem łączy sie do systemu backupowego i do serwera, ale po uruchomieniu odtworzenia operacja kończy się błędem.
Przystawka wykorzystuje „pod spodem” komendy powershella, które szczęśliwie wyświetla użytkownikowi, dzięki temu można przyjrzeć się parametrom, jakie udało się wyklikać w GUI. Jeśli jednak ktoś liczy na to, że uruchomienie powershella i owej komendy załatwi sprawę podczas odtwarzania, to się myli.
Podczas odtwarzania bazy danych, serwer SQL pracuje w trybie Single User Mode. Oznacza to, że jest możliwe TYLKO jedno aktywne połącznie. Polecenie Powershellowe najwyraźniej otwiera sobie tych połączeń więcej, więc samo się blokuje. Czemu tak to zostało zrobione? Bo IBM miał taki kaprys 🙂
Ale jest metoda! Należy skopiować polecenie powershell i przejrzeć jego argumenty. Następnie te argumenty należy przełożyć na argumenty polecenia tdpsqlc.exe. Kończymy uruchamiając polecenie tdpsqlc.exe z tak skonstruowanymi parametrami, np.:
Podsumowując, do poprawnego odtworzenia bazy danych master można:
0. Jeśli trzeba – odbudować uszkodzoną bazę master
1. Wyklikać operację odtworzenia bazy danych master, ale nie uruchamiać, tylko skopiować polecenie powershell i przerobić je na wersję tdpsqlc.exe
2. Uruchomić SQL Server w trybie single user (przełącznik -m dla programu sqlsrv.exe uruchamianego z katalogu binn w instancji)
3. Uruchomić przygotowane polecenie tdpsqlc.exe
Linki do dokumentacji IBM:
https://www.ibm.com/docs/en/tsmfd/7.1.1?topic=files-restoring-master-database
https://www.ibm.com/support/pages/apar/IC97413
Kolumna RoleId to identyfikator użytkownika (liczba, która wskazuje na nazwę użytkownika przechowywaną prawdopodobnie w innej tabeli).
Kolumna PermissionId to identyfikator uprawnienia (również liczba, która wskazuje na nazwę uprawnienia przechowywaną w innej tabeli).
Chodzi o skopiowanie uprawnień jednego użytkownika, a ponieważ pracujemy na tabelach, to należałoby powiedzieć skopiowanie wybranych rekordów z tej tabeli do tej samej tabeli ale podmieniając wartość w kolumnie RoleId.
Załóżmy, że w tabeli mamy takie oto dane: Czytaj dalej »
W DevOps próbujemy zrobić rzecz niemożliwą. Chcemy mieć zespół technicznych ludzi, którzy znają sie na wszystkim: począwszy od programowania, zarządzania kodem, administrowania systemem, chmury, automatyzacji, a kończąc na aplikacji. Dodajmy do tego jeszcze znajomość procedur obowiązujących w organizacji, raportowania statusu projektu i dojdziemy do wniosku, że cała sprawa jest nie do opanowania i dlatego… wprowadzamy model wspólnej odpowiedzialności za wszystko. Trochę to utopia, ale… jeśli takiego celu nie da się osiągnąć, to może chociaż można się do niego zbliżyć?
Każda implementacja DevOps jest trochę inna, ale można zaobserwować kilka trendów budowy takich zespołów.
Komandosi – Zróbmy jeden zespół zajmujący się DevOpsem
Ten model najmniej narusza istniejącą już w organizacji strukturę wyspecjalizowanych działów. Tworzymy po prostu jeden nowy dział i dajemy mu zadanie pracy nad automatyzowaniem budowy rozwiązania IT. Taki zespół będzie pewnie mniej znał szczegóły samej aplikacji, programowania, systemów operacyjnych, ale wyspecjalizuje się w budowie PipeLine budującego i testującego aplikację. Zespół osiągnie sprawność w zakresie specyficznych narzędzi i technologii, które są przez wykorzystywane przez budowaną aplikację.
Niestety, będzie to kolejny silos w organizacji i rozpocznie się na nowo… przepisywanie tematów z zespołu do zespołu. Żeby zrobić krok dalej, trzeba będzie uzyskać zgody i uprawnienia od innych zespołów. Sam zespół DevOps też może tworzyć blokady dla innych zespołów. Dlaczego niby mamy coś zautomatyzować, jeśli zadanie można przepisać do zespołu DevOps, który będzie przeciążony?
Desant – Dodajmy do każdego zespołu inżyniera DevOps
Jeśli w istniejącym zespole zaproponujemy zbudowanie automatyzacji opartej o DevOps, to spowoduje to oczywisty problem przeciążenia zespołu. Przecież do tej pory, każdy miał już swoje zadania i poświęcał na nie czas. Rozwiazaniem tego problemu może być dodanie do zespołu nowego człowieka, który dostanie zadanie automatyzacji – proste co? Na dodatek szukając takiego specjalisty można znaleźć kogoś, kto rzeczywiście dobrze orientuje się w specyfice DevOps. Na pewno cały zespół się ucieszy, bo oto jest „kozioł ofiarny”, któremu można oddelegować zadania związane z samym budowaniem aplikacji, a samemu skupić się na dalszym programowaniu.
Niestety i tu jest problem. Kiedy z jakiegoś powodu tego człowieka zabraknie, albo jeśli zatrzyma się on na jakimś problemie, to praca utknie w miejscu. Ma sie to nijak do modelu wspólnej odpowiedzialności za projekt. Mimo wszystko wydaje się, że może to być przynajmniej dobry początek. Trzeba tylko zadbać o dobry przepływ wiedzy, a takie „desantowe” podejście może się udać.
Przegrupowanie – połączmy dev i ops w jeden zespół
DevOps wymaga intensywnej współpracy między dev i ops. Jeśli do tej pory nad rozwojem 3 aplikacji pracowało 9 programistów i 6 administratorów, to można by podzielić zespół nie ze względu na specjalności ale ze względu na tworzoną aplikacje. Będziemy mieć (matematycznie ujmując) 3 zespoły i w każdym z nich 3 developerów i 2 administratorów. W tych nowych zespołach developerzy musią zacząć rozumieć adminów, a admini developerów. Każdy może się uczyć na błędach innych, korzystać z doświadczeń kolegów.
Jednak i tu jest problem. Czy na prawdę chcemy, aby developer uczył się administracji zamiast pogłębiać wiedzę programistyczną? Czy chcemy, aby adminstrator uczył się pisać koślawy kod zamiast rozwijać się w zakresie administracji systemami? Niestety, wyglada na to że tak, a to jednak mimo wszystko trochę zwariowany pomysł, ale… w tym kierunku idziemy.
Jest jeszcze jedna bolączka. Łatwiej się rozwijać np. w temacie programowania pracując w zespole z wieloma innymi doświadczonymi programistami niż w zespole, gdzie tylko kilku kolegów zna się na programowaniu, a reszta to admini. Właśnie takie wzajemne podciąganie się w poznawaniu technologii było i jest plusem pracy w „silosach”.
DevOps to szerokie pojęcie, ale kilka reguł odnajdzie się w każdej implementacji tej metody.
Shared responsibility / Shared ownership
To chyba jeden z ważniejszych punktów. Zespół musi się dzielić odpowiedzialnościa, a co za tym idzie, nawzajem się wspierać. Nie ma tak, że to Project Manager zwany często Scrum Masterem albo może Product Ownerem odpowiada za wszystko. Budowa nowoczesnego oprogramowania jest tak trudna, że obarczenie jednej osoby takim zadaniem jest nierozsądne. Tutaj każdy raczej bierze dla siebie zadania z puli zadań (backlog), niż przerzuca zadanie do kogoś innego!
Automatyzacja
Automatyzacja to w sumie drugie imię DevOpsa. W tej automatyzacji chodzi bardziej o automatyzację budowy aplikacji. W DevOps nie automatyzujemy np. produkcji raportów o capacity (no chyba, że to jest cel aplikacji, jaką tworzymy). W procesie produkcji oprogramowania chcemy często budować i testować oprogramowanie, a to dość pracochłonne zadania. Stąd ta automatyzacja.
Feedback
Po co wykonujemy częsty build i test tworzonej aplikacji? Głównie po to, aby szybko dowiadywać się co nie działa, albo lepiej – że coś działa! A to właśnie jest feedback. Feedback to również np. raport dotyczący wydajności aplikacji po wykonaniu zmian. Jeśli coś jest nie tak – trzeba bedzie dokonać odpowiednich zmian
Wiedza technologiczna
Tak! Ta wiedza jest krytyczna! Na dodatek tak DevOps tak został zbudowany, że nie wystarczy mieć dużo wiedzy w jednym temacie. Trzeba znać system operacyjny, chmurę, języki programowania, języki skryptowe, git-a, bazy danych, wirtualizację i konteneryzację… trzeba wiedzieć może nie „wszystko”, ale „o wszystkim” i ciagle się uczyć. Na początek wystarcza dość podstawowa wiedza aby „nie utonąć”. W miare pracy nad konkretnym zadaniem, tą początkową ogólna wiedza musi być pogłębiana. Do wykonania jest więc w zasadzie zadanie niewykonywalne. Wiedza którą lata temu podzielono między specjalistów poszczególnych technologii, teraz musi zostać opanowana przez jednego człowieka, a tak się raczej nie da – jeśli ta wiedza miała by być na tym najgłębszym poziomie. Stąd to ograniczenie – na początku trzeba znać wszystko, ale dość ogólnie. Na szczegóły przyjdzie czas.
