programy

#307. Z życia urzędnika cz.11

Myślałem ostatnio o tym, o czym można by było napisać w serii notek o urzędniczej pracy. Niestety mój nowy dział jest na tyle sprawny i zorganizowany, że omijają mnie niektóre biurowe problemy. Nie to, że za nimi tęsknię. Jest wprost przeciwnie. Cieszę się, że te małe absurdy zostały za mną gdzieś daleko w tyle i nie spadają na mnie niczym lawina nieszczęść, kiedy ja za pięć minut mam zacząć zbierać się do domu.

Są jednak takie aspekty, które nigdy się nie zmienią. No dobra – może w jakiejś dalekiej przyszłości ktoś wynajdzie panaceum na typowo biurowe choroby, ale postawmy sprawę jasno: to nie wydarzy się w ciągu najbliższych kilku lat, ani nawet w ciągu najbliższych dziesięcioleci.

Problem spędzający mi sen z oczu to nic innego jak oprogramowanie. Może nie ono samo, bo zdaję sobie sprawę, że programista raczej nie miał na myśli doprowadzenie biurowych stworzeń do depresji, ani też pozbawienie urzędników resztek chęci do życia, ale bardziej chodzi mi o moment, kiedy program zaczyna nawalać i musimy się zmierzyć z konsekwencjami tego, co ma się wydarzyć.

Bo przecież program nie wywali się, kiedy zapiszemy postęp, prawda? On będzie czekał jak ostatnia menda, aż kursor zacznie zbliżać się do magicznego “zapisz”. I kiedy będą nas dzielić dosłownie piksele od tej bezpiecznej przystani, od naszej kwestii życia i śmierci, pół ekranu zawali nam informacja tak dosadna w przekazie, że możemy się równie dobrze powiesić. “Wystąpił błąd i program został zamknięty”.

Nawet kiedy staramy się być sprytniejsi od kodu i zapisujemy plik co sekundę, aby uniknąć porażki, na sam koniec okazuje się, że format pliku jest jakiś nie taki i Word, ten sam Word, w którym tenże plik przed chwilą zapisywałem, otworzy go jak puszkę Pandory, wysypie mi na twarz całe to zło składające się z bliżej nieokreślonych kwadracików. □□□□□.

Arkusze kalkulacyjne często wprowadzają mnie w stan niepewności, że jest mnie więcej niż jeden. Ilekroć staram się otworzyć jakiś konkretny plik na współdzielonym przez mój dział dysku, to jest on przez kogoś zajęty. Nie będzie to jednak nikt z moich współpracowników, ani żaden z naszych szefów. Przed twarz wyskoczy mi komunikat, że nie mogę otworzyć pliku, bo już go używam. I nie wiem, co mam w takich momentach robić. Zaakceptować fakt, że jest mnie więcej niż jedna osoba i akurat oboje uparliśmy się na otwieranie tego pliku w tym samym momencie? Co by było, jakby nas było troje?! Walka na arenie, aby uzupełnić tabelki w Excelu?!

Odsuńmy jednak produkcję plików na bok. W końcu w urzędach mamy specjalistyczne programy, robione pod “nasze” potrzeby (przy czym nikt nie sprecyzował, kto kryje się pod słowem “nasze”). Pomimo iż stada programistów polerują kod do perfekcji, to i on nie jest wolny od skaz.

Zdarza się, że ekran ładowania zawiesi się i zostaję ja oraz kręcąca się w kółko ikona ładowania. Już po kilku minutach wpatrywania się w ekran wiem, że mam dwie opcje. Odświeżyć stronę i liczyć się z tym, że dostanę w twarz komunikatem w stylu “wystąpił błąd”, a moja praca pójdzie na marne albo zrobić sobie jednoosobową imprezę w mojej głowie i przez resztę czasu śpiewać you spin me right round, baby, right round, bo przecież nie czekam tak pierwszy raz i mam do reszty zryty beret!

Praca urzędnika na każdym polu potrafi być ciekawa. A jak jest u Was w pracy?

Mefisto

#307. Z życia urzędnika cz.11 Read More »

#158. Santa Tracker

Google jak zawsze zaskakuje i tym razem zbudowało swoje miasteczko Świętego Mikołaja, gdzie możemy tworzyć swoje elfy, czy uczyć je tańczyć. Miasteczko składa się z masy mini gierek, które, poza zapewnieniem zajęcia w nudne wieczory, są dobrym początkiem do nauki programowania poprzez zabawę!

Nie sprawdziłem wszystkich gier, ale jest ich tam wystarczająco, aby każdy znalazł coś dla siebie. Zapraszam do miasteczka. 🙂

Mefisto

#158. Santa Tracker Read More »

#149. Kącik Techniczny nr 3

Skoro ostatnio było o Protonie, to teraz warto by było wspomnieć o małym projekcie, który wiele osiągnął, a mianowicie o WINE, którego rozwinięcie brzmi Wine Is Not Emulator.

Początkowo wydano go 4 lipca 1993, czyli jest nieco starszy niż ja. Zapoczątkował go Eric Youngdale, a od 1994 po dziś dzień prowadzi go Alexandre Julliard.

Zadaniem WINE jest dosłownie duplikować zachowanie Windowsa w stosunku do danego programu/gry – jest zakładką tłumaczącą zachowanie programu dla Linuxa. Twórcy dokonują tego przez implementacje WindowsAPI, czyli interfejsu programistycznego, graficznego, czy bibliotek do WINE. Chociaż jest to dosyć ciężkie zadanie, bo nie wszystko ma otwarty kod źródłowy, aby tak po prostu przestudiować, jak zostało to zrobione. Przykładem jest Directx11, który przez długi czas pozostawał poza zasięgiem.

W 1996 powstali CodeWeavers, którzy wpierw zajęli się konsultacją, a potem sprzedażą komercyjnej i nieco bardziej dopracowanej wersji WINE o nazwie CrossOver. Są oni głównym sponsporem WINE, który, w przeciwieństwie do CrossOver, ma pozostać darmowy. Wsparcie mają też od Google, które, poza komercyjnym sponsoringiem, często dofinansowuje ich w ramach Google Summer of Code.

Pierwsza stabilna wersja WINE (1.0) wyszła po 15 latach od pojawienia się programu, czyli w 2008, a obecnie wydawane są wersje 3.xx.

Moja przygoda z WINE zaczęła się w 2012 roku z wersją 1.6, kiedy to po stracie laptopa Smok przekonał mnie do spróbowania Linuxa, potem WINE i tak to się jakoś potoczyło. Chociaż wtedy było więcej zachodu z odpaleniem gry (nie każdej, ale jednak) to moją pierwszą windowsową grą odpaloną na Linuxie było Knights of the Old Republic. Potem zacząłem grać w Star Wars The Old Republic, które wtedy potrzebowało specjalnego skryptu, aby się uruchomić, a dziś działa bez problemu i nie wymaga już takich rozwiązań (niedawno ściągałem to miałem okazję sprawdzić ;)).

W mniej więcej 2015/2016 zacząłem używać wine-staging, która jest wersją z licznymi łatkami, a tym samym z usprawnionym działaniem. Dzięki temu miałem dostęp do gier lub programów z ograniczoną funkcjonalnością przy zwykłym WINE. Takim przykładem jest np. platforma Uplay. 🙂

Od sierpnia 2018, do gier na Steamie, używam Protona, o którym był już osobny wpis. 🙂

WINE posiada coś takiego, jak butelka (bottle) lub prefix. To jest coś w rodzaju osobnego folderu z ustawieniami programu. Dzięki temu możemy testować gry bez narażania naszej głównej butelki na uszkodzenie (co może się zdarzyć, jeśli zaczniemy doinstalowywać biblioteki, programy, itd.). Butelki mogą mieć 32-bitową lub 64-bitową architekturę, co pozwala manewrować między różnymi wymaganiami gier lub programów. Daje to spore poczucie bezpieczeństwa, kiedy chcemy (nawet bardzo drastycznie) coś sprawdzić, ale nie chcemy namieszać w obecnych ustawieniach.

Moje doświadczenie z WINE jest jak najbardziej pozytywne. Nie jest to idealny program, ale biorę pod uwagę ile przeciwności musi pokonać, aby dostarczyć coś, co pozwala mi zagrać w grę na systemie, który nie był do tego przeznaczony. Nie zliczę ile razy byłem zły, bo coś mi nie działało, ile razy cieszyłem się, bo przy nowej wersji naprawiano błędy uniemożliwiające mi rozgrywkę, ile razy pękałem z dumy, bo rozwiązałem problem. W pewnym momencie sam zacząłem wynajdywać rozwiązania i udzielać porad innym graczom.

Z tego, co słyszałem, WINE zapragnęli także niektórzy użytkownicy Windowsa, bowiem zapewnia on większe możliwości, jeśli chodzi o obsługę starszych gier niż tryb kompatybilności w Windowsie. Prośba jak na razie nie została spełniona i nie zapowiada się, aby twórcy poszli kiedykolwiek w tym kierunku – najpewniej dlatego, że już teraz mają wystarczająco do zrobienia.

Gdyby nie WINE to ten blog mógłby tak po prostu nie powstać. W końcu ten “buntownik” w tytule nie odnosi się tylko do jednej rzeczy. 😉

Mam nadzieję, że ten wpis, choć taki trochę chaotyczny, to jednak się podobał. Zamierzam wrzucić z czasem kilka porad i rozwiązań, które mogą przydać się początkującym użytkownikom. 🙂

Mefisto

#149. Kącik Techniczny nr 3 Read More »

Scroll to Top