Tworzenie Aplikacji Dla Systemu iOS (wersja tekstowa)

Pobierz napisy w formacie SRT
Pobierz napisy w formacie VTT
Fundacja Instytut Rozwoju Regionalnego prezentuje Tyflo Podcast.
Poniedziałek, 28 dzień listopada 2022 roku w kalendarzu.
Godzina 19.00, chwilę temu minęła na zegarze, a my rozpoczynamy kolejne spotkanie.
Chociaż pierwsze w tym tygodniu na żywo na antenie Tyflo Radio.
Michał Dziwisz, witam bardzo serdecznie i tych wszystkich, którzy są z nami na żywo,
którzy słuchają nas w różnych miejscach, a być może słuchają nas także w aplikacji Tyflo Centrum,
która jest możliwa do przetestowania, na razie jeszcze oficjalnie jej nie ma,
ale za to jest oficjalnie z nami autor tej aplikacji w dzisiejszej audycji, Arkadiusz Świętnicki.
Dobry wieczór, Arku. Dobry wieczór, witam wszystkich w dzisiejszej audycji.
Dziś taki temat nie był ansbytnie poruszany na łamach Tyflo Podcastu,
co w sumie z jednej strony jest zrozumiałe, z drugiej strony dla mnie jest trochę smutne,
ale dzisiaj porozmawiamy sobie o szeroko pojętym programowaniu,
o tym jak to wygląda z perspektywy, nie chcę powiedzieć osoby niewidomej,
bo wydaje mi się, że każda osoba niewidoma, tak samo jak każda osoba po prostu,
ma na to trochę inne patrzenie, ale postaram się dzisiaj opowiedzieć w taki praktyczny,
przystępny mam nadzieję sposób o tym, jak to wygląda, z czym to się je
i mam szczerą nadzieję, że kogoś uda mi się zainspirować, że ktoś sięgnie po klawiaturę
i z jakimś pomysłem ciekawym wyjdzie i spróbuje coś stworzyć.
Dziś sobie porozmawiamy szczególnie o programowaniu na system iOS,
bo właśnie aplikacja Tyflo Centrum to jest twoje dzieło,
które dało ci trochę różnych doświadczeń, jeżeli chodzi o tworzenie tych aplikacji,
no zresztą nie tylko ta aplikacja, bo też przecież Luomo Toolbox?
Tak, Luomo Toolbox to też projekt, który z kolei uczył mnie tego,
jak współpracować w drużynie, jak zarządzać opiniami od użytkowników,
jak czytać kod innych osób, o tym sobie też porozmawiamy,
natomiast aplikacja Tyflo Centrum jest pierwszą aplikacją, którą napisałem
po pierwsze od zera samemu dla systemu iOS, a po drugie jest to pierwsza aplikacja,
którą napisałem od zera w technologiach typowo dawanych nam przez system,
bo myślę, że nie wiem, czy tak zaczynamy od początku, żebym nie zaczął trochę chaotycznie.
To ja myślę, że o tym sobie powiemy za moment, ale w każdym razie ja po prostu o to zapytałem
dlatego, żeby nasi słuchacze wiedzieli, że coś już udało ci się stworzyć,
że efekty tego są, więc to nie będą takie teoretyczne rozważania,
tylko to będzie kilka słów wypowiedzianych przez praktyka.
Może jeszcze z nie nie wiadomo jakim stażem na tym iOSowym polu,
ale jednak już trochę kodu zdarzyło ci się napisać i o to właśnie dlatego zapytałem.
Jeszcze z takiego wstępu powiem, że nasza audycja jest na żywo,
więc może się odbyć również z waszym udziałem.
Możecie do nas pisać na kontakt.tyflopodkast.net,
możecie do nas pisać na YouTube, na Facebooku
i możecie do nas dzwonić tyflopodkast.net u kośnik Zoom.
Zapraszamy bardzo serdecznie, żebyście to robili.
Jeżeli macie ochotę popróbować programowania,
czy to na iOSa, czy to w jakiś inny sposób,
być może właśnie dzięki tej audycji zainspirujecie się
i popróbujecie swoich sił,
no bo nie zawsze i niekoniecznie musi być to iOS.
Systemów jest dużo, technologii jeszcze więcej,
więc każdy znajdzie coś dla siebie.
Najważniejsze to po prostu zacząć.
No właśnie, Arku.
O co chodzi z tym programowaniem?
Czym to programowanie właściwie jest?
Programowanie to po prostu, to nic innego jak rozmowa z komputerem.
Tak jak ja do ciebie piszę i się ciebie pytam,
czy mogę zrealizować na antenie Tyfloradio jakąś audycję
i ty mi odpowiadasz tak, albo nie, albo może kiedy indziej.
Tak samo jest z programowaniem.
To jest wydawanie komputerowi pewnych instrukcji,
zadawanie komputerowi pewnych pytań,
na które komputer w swój sposób nam odpowiada.
Programowanie polega na odpowiednim formułowaniu zapytań
przy pomocy języków programowania,
tak jak ludzie rozmawiają ze sobą przy pomocy języków naturalnych,
takich jak, nie wiem, polski, angielski, rosyjski.
Tak samo z komputerami rozmawia się przy użyciu
tzw. języków formalnych, czyli języków programowania motadylne.
Tak w gruncie rzeczy w tym najbardziej podstawowym stopniu
to sprowadza się do tego, żeby zrozumieć ten język,
zrozumieć język programowania, zrozumieć to,
w jaki sposób należy pisać ten kod
i w jaki sposób należy zadawać komputerowi pytania,
czy wydawać mu polecenia tak,
aby robił to jak najszybciej i jak najefektywniej.
Bo taką najważniejszą różnicą między człowiekiem a komputerem
w tym kontekście jest fakt,
że człowiekowi nie musimy podawać dokładnie krok po kroku instrukcji,
bo jeżeli człowieka o coś zapytamy, czy poprosimy,
wydamy człowiekowi jakieś polecenie w cudzysłowie,
to człowiek jest powiedzmy zaprogramowany już w taki sposób,
żeby wykonać te instrukcje w jakiejś określonej kolejności.
Z programowaniem tak nie jest,
dlatego być może ludzie trochę się boją tego,
bo tutaj to my musimy wymyśleć tą optymalną kolejność
wykonywania tych zapytań i poleceń dla komputera
w taki sposób, aby ten mógł w miarę szybko dane żądanie spełnić,
żeby mógł w miarę szybko zwrócić daną odpowiedź.
No i tak naprawdę programowanie sprowadza się,
tak reasumując, do nauki języka programowania
i potem do takiego zrozumienia tego,
w jaki sposób należy zadawać komputerowi polecenia,
w taki sposób, aby wykonywał je jak najszybciej
i żeby nie dało się komputera, kolokwialnie mówiąc, zagiąć,
o czym też za chwilę będę mówił,
o takich najpopularniejszych błędach, jakie ja osobiście popełniałem,
bo chciałbym się w sumie skupić nie na tym, co mi wychodziło,
ale na tym, co mi nie wychodziło.
Mówisz, Arku, że programowanie to jest swego rodzaju dialog z komputerem.
Ja odnoszę wrażenie, chociaż programistą jestem marnym
i dawno już nie miałem okazji niczego pisać,
bo zajmuję się teraz zupełnie innymi rzeczami,
ale gdzieś tam czy to na studiach, czy jeszcze trochę po nich
parę linii kodu też zdarzyło mi się stworzyć,
że ten dialog to jest taki dialog trochę na nierównych zasadach.
To znaczy, my się nagadamy, my stworzymy jakąś dużą partię kodu,
a komputer w zasadzie najwięcej ma do powiedzenia wtedy
i to jest rzeczywiście wtedy bardzo solidny dialog,
jeżeli popełnimy jakiś błąd i on czegoś nie rozumie.
To on nam wtedy mówi bardzo dużo na temat tego,
że tu jest taki błąd, a taki, a tutaj jeszcze to wynika z tego
i tak dalej, i tak dalej.
I mamy naprawdę wiele linijek wyplutych dotyczących różnego rodzaju błędów,
które to tak trochę czasami kaskadowo nam się zaczynają pojawiać.
Jak zrobimy jeden błąd, to potem cała fala tych błędów,
ale jeżeli jest wszystko ok, to ten komputer jest raczej małomówny
i po prostu ok, dobrze, robię, no i robi to, co ma zrobić.
No właśnie tak i to jest najtrudniejsze moim zdaniem,
jeżeli chodzi o programowanie, bo tak naprawdę problemy nie zaczynają się wtedy,
gdy podczas kompilacji, o czym jest kompilacja czy interpretacja,
to za chwilę powiem, ale problemem nie jest to,
że my popełnimy jakiś błąd na etapie pisania kodu, nie wiem,
nie wstawimy średnika, średnik to taka kropka w niektórych językach programowania,
nie wiem, nie wstawimy średnika, pomylą się nam słowa kluczowe,
napiszemy coś w nie tej kolejności.
Jeżeli komputer nie zrozumie naszego rozkazu, to to jest jeszcze mały problem,
bo wówczas my będziemy mieli jasną informację,
że tego nie byłem w stanie zrozumieć, tego nie byłem w stanie przetworzyć,
przepisz to.
Problemem jest to, gdy komputer zrozumie nasz rozkaz
i zacznie go wykonywać według tej logiki,
którą notabene my stworzyliśmy,
którą my kazaliśmy komputerowi wykonywać,
bo my podświadomie wymyślamy jakiś algorytm,
algorytm to taka bardzo, bym powiedział naukowo brzmiąca nazwa,
która opisuje bardzo prosty koncept,
bo algorytm to nic innego jak pewnego rodzaju przepis na rozwiązanie danego problemu
i jeżeli my popełnimy błąd w tym algorytmie,
to wówczas znalezienie tego błędu może być naprawdę bardzo trudne,
szczególnie w bardziej złożonych aplikacjach,
gdzie możemy naprawdę bardzo, bardzo się głowić,
dlaczego coś nie działa, albo coś działa jak nie należy,
albo działy się jakieś inne dziwne rzeczy,
które nie powinny w naszym programie mieć miejsca.
Na przykład jeżeli tworzymy program,
który ma za zadanie wypłacać fundusze z konta, dajmy na to,
to musimy stworzyć funkcję, która odejmie od funduszy tych,
które użytkownik posiada na swoim koncie,
ilość tych pieniędzy, jakie chce on wypłacić.
No ale co jeszcze musimy przemyśleć do tego?
Musimy pomyśleć o tym, co mam zrobić, jeżeli użytkownik nie ma na tyle funduszy na swoim koncie,
co mam zrobić, jeżeli użytkownik poda na przykład liczbę ujemną,
czyli że na przykład użytkownik będzie chciał wypłacić minus 300 zł z konta,
co mam zrobić, jeżeli użytkownik wpisze ala makota zamiast liczby rzeczywistej,
co mam zrobić, jeżeli użytkownik poda jakieś działanie matematyczne,
czy mam je przetworzyć, czy mam zwrócić błąd itd.
Co będzie, jeżeli użytkownik na przykład będzie w stanie podać,
tu już trochę dotykamy rzeczy związanych z bezpieczeństwem,
ale co, jeżeli użytkownik poda jakiś fragment kodu w tym polu?
No tak, to już jest taka inna rzecz, której w sumie nie chciałbym tak na początku dotykać,
bo będę niestety robił to, z czym staram się walczyć,
czyli będę straszył ludzi, a nie zachęcać do programowania,
ale tak, Michała ma rację, może się coś takiego zdarzyć.
I właśnie programowanie polega na tym, żebyśmy my jako ludzie przemyśleli tak naprawdę
wszystko to, co może pójść nie tak.
Bo większość ludzi robi to naturalnie.
To nie jest tak, że jak jesteśmy programistami, to musimy być profesorami w okularach,
z siłymi włosami, z długą brodą,
tylko każdy człowiek posiada jakąś tam umiejętność logicznego myślenia,
to jest genetycznie uwarunkowane,
każdy człowiek posiada umiejętność patrzenia na swoje decyzje w retrospektywie,
każdy człowiek ma jakąś tam mniej lub bardziej rozwiniętą zdolność
do patrzenia na to, co jego działania spowodują,
tylko ja uważam, że takim problemem, jaki ludzie mają podczas nauki programowania
jest to, że nie myślą o tym w ten sposób,
tylko myślą o programowaniu jak o jakiejś nauce tajemnej,
która jest tylko dla wybranych i zastanawiają się,
ja tak miałem, że się zastanawiałem, czy to jest dla mnie,
czy kod, który piszę jest optymalny, czy kod, który piszę ładnie wygląda,
czy jest ładnie sformatowany,
a co by powiedział na ten kod jakiś bardziej doświadczony programista
i zamiast skupiać się na tym, żeby myśleć o tym,
jak komputer ma wykonywać te moje rozkazy,
ja zastanawiałem się właśnie nad takimi rzeczami,
które w mojej pracy były kompletnie nieistotne w tym konkretnym momencie.
Ja myślę, Arku, że nad takimi rzeczami, o których ty wspominasz,
to zastanawiają się ludzie, którzy już się zdecydowali,
że oni chcą coś pisać,
a osoby, które dopiero chcą zająć się programowaniem jako takim,
myślą o stworzeniu jakiegoś swojego kawałka kodu,
pierwszego kawałka kodu,
to w ogóle zastanawiają się nad tym,
okej, ja wiem, co ja chcę zrobić,
ja wiem, że ja mam pomysł na jakąś aplikację,
czy nawet jakiś program, który będzie robił to, to i to,
i teraz jak to podzielić na takie malutkie fragmenty,
które ten komputer będzie wykonywał,
czyli jak ja temu komputerowi mam przekazać to,
co tak naprawdę chcę, żeby on zrobił,
bo na takim ogólnym poziomie abstrakcji,
tak jak powiedziałeś, że na przykład mam aplikację,
która ma, dajmy na to, zrobić jakiś przelew z konta,
ma się podłączyć do naszego konta i zalogować się i zrobić przelew.
My wiemy, jak my to robimy,
czyli nawet gdybyśmy chcieli stworzyć taki algorytm,
tak jak my to robimy,
że okej, loguje się na stronę banku,
wchodzę do odpowiedniego formularza,
wpisuję konkretne dane i tak dalej, i tak dalej.
Okej, to ja wiem, jak ja to robię,
ale teraz jak mam to przekazać komputerowi,
żeby on zrobił to samo?
W informatyce jest taka zasada dziel i rząd,
tak się nazywa i to polega na tym,
że mamy jakiś duży problem,
tudzież problem ogólny, tak jak teraz.
Moim zdaniem jest stworzenie aplikacji,
która będzie wykonywała przelewy, to jest duży problem.
I ten duży problem dzielimy na problemy mniejsze,
czyli moim zdaniem jest stworzenie aplikacji,
która zaloguje się na konto użytkownika,
a dopiero potem zrobi przelew.
To jest drugi etap.
Potem znowu rozdzielamy i może nam wyjść takie zdanie.
Moim zdaniem jest stworzenie aplikacji,
która przyjmie od użytkownika login i hasło
i skorzysta z tych danych do tego,
aby zalogować się do banku w celu zrobienia przelewu.
Potem rozdzielamy to jeszcze bardziej
i mamy coś w rodzaju,
moja aplikacja ma za zadanie przyjąć od użytkownika login i hasło,
połączyć się z serwerem banku, zalogować użytkownika,
a następnie pobrać od niego odbiorcę przelewu
oraz jego kwotę, a następnie ten przelew wykonać.
I tak samo potem dalej rozdzielamy,
już nie będę tego powtarzał,
tylko że później zamiast tego wykonania przelewu
mamy sprawdzenie poprawności danych.
Potem rozdzielamy sobie to jeszcze bardziej i jeszcze bardziej,
aż w końcu dotrzemy do naprawdę bardzo prostych
i podstawowych instrukcji.
To może się wydawać, że to jest bardzo żmudny
i ciężki proces.
Ja na początku w ogóle tego nie robiłem
i dlatego może tak późno zaczęło mi się udawać,
coś w tym programowaniu osiągać,
bo tak długo jak mamy duży problem,
no to nie możemy sobie pomyśleć,
ciężko jest nam sobie o tym pomyśleć,
jak ja mam zrobić, żeby w ogóle tego użytkownika zalogować.
Żeby zalogować użytkownika,
no to najpierw muszę mieć jego login i hasło
czy jakieś inne dane, które są w stanie tego użytkownika
jednoznacznie identyfikować.
No i właśnie to jest tego kwestia,
że musimy z dużego problemu
tworzyć problemy elementarne.
Komputer to nic innego jak
troszkę większy i bardziej energożerny kalkulator.
Komputer potrafi tak naprawdę dodawać,
odejmować, mnożyć i dzielić.
Tylko bardzo szybko.
Tylko bardzo szybko.
Tak, to się zgadza.
Więc teraz tak, wspomniałeś o tym dzieleniu
problemów większych na problemy mniejsze
i tak naprawdę na jeszcze mniejsze jakieś problemy.
Osoba widząca bardzo często jest sobie to w stanie rozrysować.
Mamy te różnego rodzaju schematy działania,
schematy blokowe,
to się tak bardzo często określa.
I to z tego, co przynajmniej wiem,
to pomaga.
Jak ty sobie radziłeś z takim
definiowaniem tych problemów,
żeby się w tym wszystkim nie pogubić?
Bo można to sobie oczywiście zapisywać
w jakimś notatniku,
ale potem, żeby mieć do tego jakiś
fajny ogląd na to wszystko,
no to nie jest to chyba najwygodniejsze rozwiązanie.
Chyba, że nie ma rady już po prostu.
Zacząłem od Excela, czyli pisałem sobie
w jednej komórce w A1 duży problem,
potem w B1 i B2 dwa problemy mniejsze,
potem od tych problemów odchodziły dalsze, dalsze i tak dalej.
Ale to było mało optymalne, bo bardziej zacząłem się
skupiać na tym, jak ten arkusz kalkulacyjny ma wyglądać,
a nie na jego treści.
I później wpadłem na pomysł,
na który żałuję, że nie wpadłem dużo wcześniej,
bo naprawdę ktoś może powiedzieć, że to
dużo wolniej jest i w ogóle…
Ale w programowaniu nie chodzi o to, żeby być szybkim.
W programowaniu chodzi o to, żeby być dokładnym.
Aczkolwiek jeżeli ktoś będzie chciał pracować profesjonalnie,
to niestety ta zasada troszkę umrze.
Ale ja później po prostu uruchamiałem
program Reaper, uzbrajałem ścieżkę
i nagrywałem to, co mój program miał robić.
I później odsłuchując tego,
układałem sobie w głowie pewien schemat,
od czego muszę zacząć.
To jest tak, jak budujemy piramidę, że zaczynamy od
raczej fundamentów, a nie od tego
stożka na wierzchu.
I tak samo jest tutaj.
Ja sobie to nagrywałem, wtedy jak sobie słuchałem,
to mój mózg jakoś lepiej był w stanie to przyswajać
i lepiej był w stanie sobie to potem wyobrażać.
I potem ja byłem w stanie to lepiej przetwarzać na kod,
który rozumiał komputer.
No tak, jest taki mit,
przynajmniej on kiedyś pokutował,
że programista, jak chce tworzyć kod,
to on musi być bardzo dobry z matematyki.
Nauki ścisłe to musi być
podstawa, to po prostu najlepiej studiowania matematyki,
to nie ma co w ogóle do programowania nawet
prostego podchodzić.
To jest znowu takie uogólnienie,
którego bardzo nie lubię, to jest jeden z tych mitów
o programowaniu, który działa na mnie bardzo źle,
bo najpierw, żeby w ogóle o tym zacząć rozmawiać,
to musimy sobie powiedzieć, czym jest matematyka,
a czym jest logiczne myślenie, bo matematyka to jest
nauka o liczbach, nauka o liczbach po prostu.
Nieważne, czy mamy do czynienia z geometrią,
z algebra liniową, z równaniami kwadratowymi,
z macierzami, czy z rachunkiem prawdopodobieństwa.
Wszystko tam jest reprezentowane przez liczby.
Działane na liczbach.
Do matematyki jest potrzebne logiczne myślenie,
tak samo jak do programowania jest logiczne myślenie.
Tak naprawdę od tego wszystko odchodzi.
Zresztą to jest człowiek znany w środowisku niewidomych,
ja z nim rozmawiałem,
który mi mówił, że z matematyki jako takiej
to delikatnie mówiąc mu nie szło,
a osiągnął dość dużo w programowaniu.
I właśnie to jest to, bo
musimy umieć na pewno logicznie myśleć,
czyli musimy umieć rozkładać problemy na czynniki pierwsze,
musimy umieć myśleć o wypadkowych pewnych zdarzeń,
w których następstwie coś innego będzie się działo,
ale jako taka wiedza matematyczna
tak naprawdę ogranicza się do tego, czym jest odejmowanie,
dodawanie, mnożenie, dzielenie i dzielenie z resztą
i czym są operatory logiczne takie jak i, lub, i nie.
Co oczywiście nie znaczy, że matematyka w programowaniu
w ogóle się nie przydaje i matematyka bez sensu
w ogóle nie ma się czego, po co tego uczyć.
Bo to jest tak, że to programowanie zależy co chcemy robić,
bo jak na przykład chcielibyśmy stworzyć jakieś oprogramowanie,
które będzie zajmowało się chociażby szyfrowaniem
i my chcemy w tym programie stworzyć chociażby własne metody szyfrowania,
no to tu mam wrażenie, że bez złożonej matematyki
i to takiej naprawdę dość mocno złożonej, to się nie obejdzie.
No tak, tylko że, tylko że właśnie o to chodzi,
że co chce wyrobić, bo większość aplikacji,
z których korzystamy na co dzień, czyli no nie wiem,
Fubar 2000, Reaper, Lten, nie wiem, NVDA czy cokolwiek innego,
to nie są aplikacje, które szyfrują dane, tak?
Czyli my do tworzenia takich programów, takich aplikacji, takich rozwiązań
nie potrzebujemy jako takiej zaawansowanej wiedzy matematycznej,
pomijając oczywiście podstawowe działania i tak dalej, to o czym mówiłem wcześniej.
Tak samo jeżeli na przykład chcemy tworzyć silniki do tworzenia gier,
nawet nie same gry, tylko powiedzmy, że ja chcę stworzyć silnik trójwymiarowy,
no to wówczas co się nam przyda?
Przyda się nam na pewno trygonometria.
No i wiedza z zakresu fizyki też.
No, wiedza z zakresu fizyki, aczkolwiek jest bardzo dużo bibliotek,
o tym też będziemy sobie mówić, to taka abstrakcja programowania.
Jest bardzo dużo bibliotek, mało kto pisze wzory fizyczne,
dlatego że to jest po prostu mało optymalne,
nawet ludzie, którzy teoretycznie by umieli, nie robią tego,
ale o tym za czas jakiś.
Tylko do czego zmierzam?
Tak naprawdę, tym co najbardziej mnie gryzie w tym micie,
że matematyk równa się programista, tudzież programista równa się matematyk,
najbardziej gryzie mnie w tym fakt, że przynajmniej mnie tak uczono,
że ja już muszę umieć matematykę, inaczej, że matematyka nie jest wymaganiem
jakimś tam jednym z wielu, tylko jest wymaganiem podstawowym,
żebym w ogóle mógł osiągnąć ten próg wejścia, czyli próg,
który umożliwi mi robić coś pożytecznego, bo to nie jest tak,
że matematyka jest niepotrzebna, tylko my jako programiści
tak czy tak uczymy się cały czas, o tym też będę mówił,
że to nie jest tak, że my się raz nauczymy i umiemy i wszystko będzie fajnie,
nawet o tym rozmawialiśmy z Michałem przed audycją,
więc jeżeli na przykład w pewnym momencie naszej kariery
zamarzy się nam stworzenie gry, bo na przykład aplikacje
do jakiejś tam produktywności szeroko pojętej czy tam jakieś inne rzeczy
już nas nie cieszą, chcemy się zająć czymś innym,
to nic nie stoi absolutnie na przeszkodzie do tego,
żeby w razie zajścia takiego zdarzenia po prostu usiągnąć do internetu,
sięgnąć do literatury fachowej i nauczyć się tego czy tamtego,
nie wiem, ja ostatnio bardzo zainteresowałem się fizyką wektorową
i trygonometrią, dlatego że zacząłem robić moda,
który udostępnia pewną grę dla osób widzących dla nas
i była mi potrzebna do tego trygonometria,
więc poszukałem odpowiednich materiałów w internecie i zacząłem czytać.
Może to będzie dość kontrowersyjne, co powiem,
aczkolwiek dla mnie największą przeszkodą w nauce programowania
byli bardziej doświadczeni programiści.
Ciężko mi jest to może wyjaśnić, może nie wyjaśnię tego tymi słowami, co trzeba,
ale nie wiem, ja tak miałem z matematykami i z programistami raczej,
że jeżeli ktoś już ma kilkanaście lat stażu, kilkanaście lat doświadczenia,
to zaczyna mu się wydawać, że wie o swojej dziedzinie wszystko
i że próg wejścia w tą dziedzinę jest taki, jaki on reprezentuje,
że on już tam nauczył się tych wektorów powiedzmy,
bo najpierw robił programy do obsługi kanałów RSS,
a potem zamarzyło mu się robić gry 3D i on umie już fizykę wektorową,
no to każdy nowy programista musi nauczyć się fizyki wektorowej.
Ale czy to nie jest, Tarku, też trochę tak, że kiedyś jednak ten próg wejścia,
jeżeli chodzi o programowanie, był znacznie wyższy.
Kiedyś trzeba było umieć znacznie więcej, żeby w ogóle jakkolwiek zacząć.
Dziś tak naprawdę to jest coraz więcej kodu, na którym my możemy sobie poeksperymentować,
z którym my się możemy pobawić.
Jest sporo rzeczy, które tak naprawdę wystarczy trochę o tym poczytać.
To oczywiście nie będzie, nie osiągniemy takiego efektu natychmiastowego.
To się nie ma co na to nastawiać.
– Oczywiście, że nie, to jest bardzo ciężka praca.
– Programowanie czy w ogóle poszukiwanie takich rozwiązań informatycznych,
bo czy to dotyczy programowania, czy dotyczy konfiguracji, czegokolwiek,
to jest w zasadzie nieustanne szukanie.
Szukanie, po pierwsze, czy ktoś już nie miał takiego podobnego poziomu,
bo jeżeli miał, to można znaleźć jego rozwiązanie dosyć szybko,
albo przynajmniej coś podobnego.
Natomiast jeżeli ktoś nie miał takiego problemu, bo tworzymy na przykład coś nietypowego,
co w przypadku osób niewidomych mam wrażenie, że się czasem może zdarzać
i może być to częstsze niż w przypadku osób widzących,
to w takiej sytuacji musimy zrobić to, o czym ty wspomniałeś przed momentem,
czyli ten nasz problem jednak rozbić na te mniejsze elementy
i szukać rozwiązania wśród tych mniejszych elementów
i dopiero może nam się uda złożyć z tego coś, co będzie działać.
– A może być też tak, że nam się nie uda i będziemy musieli wrócić do czegoś po latach.
Ja zacznę od tego, co na początku powiedziałeś, że wcześniej trzeba było więcej umieć.
– Wcześniej, to znaczy w latach 40. i 50.,
bo pierwszymi informatykami byli matematycy tak naprawdę,
bo komputery na początku były maszynami liczącymi,
to komputery powstały dla matematyków tak naprawdę do tego,
żeby im ułatwiać pewne ich zadania,
ale już na przykład w latach 70. czy 80. z komputerami takimi,
jak Apple II czy Commodore 64 były dostarczane podręczniki
do języka programowania BASIC
i ten próg wejścia już wtedy nie był aż tak bardzo wysoki,
był na pewno wyższy, aczkolwiek nie wiem, czy to było tak,
że próg wejścia był wyższy czy był mniejszy dostęp do informacji,
bo to moim zdaniem warto to rozdrowić.
– Też był mniejszy dostęp do informacji oczywiście,
tylko wiesz co, to też nie do końca tak jest,
ja mam wrażenie, że to programowanie,
to nam się tak bardzo uprościło w ciągu ostatnich paru lat,
dlatego że ja ostatnio czytałem taki dosyć interesujący tekst
na temat bodajże kobola, czyli języka programowania
popularnego w latach 60. i popularnego dziś.
To jest język programowania, który jeszcze dziś znajdziemy,
zwłaszcza w Stanach Zjednoczonych i w Kanadzie,
który to język obsługuje bardzo często sektor bankowy,
sektor związany z paliwami,
tam bardzo dużo rzeczy jeszcze stoi na kobolu.
I teraz tak, w dzisiejszych czasach programiści kobola są na wymarciu
i to dosłownie.
Natomiast ja gdzieś znalazłem taki cytat z podręcznika do kobola
czy z jakiegoś takiego artykułu opisującego ten język w latach 60.,
kiedy on był taką rewolucją,
że teraz to w zasadzie wystarczy wziąć człowieka z ulicy,
który nie ma wiedzy na temat programowania,
poświęcić mu trzy miesiące, wysłać go na kurs kobola
i on będzie w stanie programować.
I no, kiedyś tak może istotnie było, nie wiem,
czy to po prostu ludzie byli przyzwyczajeni do innej technologii,
czy bardziej tę wiedzę chłonęli, ale fakt jest faktem,
że teraz programiści takich języków jak kobol, czy jak fortran,
to są takie starsze te języki programowania,
zarabiają duże pieniądze, ale też bardzo często mają powiedzmy siódmy krzyżyk
albo ósmy i jeżeli oni odejdą z tego świata,
to niektóre firmy będą miały naprawdę duży problem,
bo młodych programistów takich archaicznych języków
najzwyczajniej w świecie nie ma.
No tak, tylko z czego ten problem tak naprawdę wynika,
moim zdaniem, przynajmniej ja tak miałem,
ja zacząłem się uczyć, to swoją drogą był jeden z większych błędów,
jakie poprawiłem na swojej ścieżce,
zacząłem się uczyć programowania od języka również stary Nikiego,
a mianowicie od języka C.
I dlaczego ja w języku C jako wówczas dziewięcioletni mały człowiek
nie zaszedłem tak daleko?
Bo myślę, że język C nie dawał mi poczucia spełnienia.
Innymi słowy musiałem wykonać bardzo dużo pracy
do tego, żeby otrzymać bardzo marny i prosty w moich oczach efekt.
I tak samo jest z językami pokroju kobola czy fortrana,
które są stworzone do konkretnych zastosowań
i na przykład, no nie wiem, pisanie tyflocentrum w kobolu
czy w fortranie byłoby dla mnie niemożliwe,
bo te języki są przystosowane do konkretnych, powiedzmy, celów.
To nie są takie języki jak, nie wiem, JavaScript, czy Python, czy Swift,
o którym zaraz pewnie będziemy mówić, jak skończymy ten przydługi wstęp.
Tylko to są języki, które jednak mają nie tyle wysoki próg wejścia,
co mało zają w zamian, w cudzysłowie oczywiście,
bo to nie dywaluuje oczywiście tych technologii,
tylko myślę tak, jak myślałem dawny ja,
ja, który uczyłem się programowania.
Nie wiem, czy się, Michale, ze mną zgodzisz, czy to może o to chodzić?
Całkiem możliwe, to znaczy w ogóle ja mam takie wrażenie,
że dużym problemem dla osób, które zaczynają programować
jest to, że to nie daje takich szybkich efektów.
Bo oczywiście żaden problem jest wypisać w dowolnym języku programowania
jakieś witaj świecie, albo stworzyć program, który doda dwie liczby,
albo odejmie, albo pomnoży.
Z dzieleniem może być problem od czasu do czasu,
to już tak jak mówiłeś o tym dzieleniu zresztą,
to już mogą być czasem jakieś kłopoty.
Natomiast właśnie chodzi o to, żeby jeżeli poświęcamy czemuś czas,
to żeby jednak były tego jakieś efekty.
I tu się jestem w stanie z tobą zgodzić.
Te starsze języki, rzeczywiście one zostały stworzone z myślą
o różnego rodzaju zastosowaniach.
No i raczej nikt nie pisze przynajmniej dziś
jakichś gier w Kobolu czy Fortranie,
chociaż jak ostatnio oglądałem sobie jakiś film
o starych komputerach na przykład na Odrze,
tam chyba Cobol właśnie był używany.
Takie tam gry na kartach perforowanych z Warszawy.
To tam była jakaś gra, ktoś uruchomił taką grę,
zajmująca gra i w ogóle fantastyczna grafika.
Oczywiście grafiki nie było, bo tam był monitor znakowy.
W tej grze polegało to wszystko na tym,
że wpisywało się odpowiednie polecenia, odpowiednią prędkość,
żeby wyhamować przed lądowaniem na Księżycu.
Tam oczywiście żadnych dźwięków nie było, nic innego.
To była taka najzwyczajniejsza w świecie gra tekstowa.
Ale tak, mam wrażenie, że to może być problem
i to może być coś, co ludzi zniechęca dość szybko.
Ale no dobra, ty się zniechęciłeś do C,
do języka, dodajmy, po dziś dzień używanego.
I to jest język, który tak naprawdę, on i jego odmiany,
bo oczywiście no mamy, nie wiem czy w dzisiejszych czasach
tworzy programy w takim zwykłym C,
bardziej pewnie w C++, albo w C-sharpie.
A ja na przykład powiem ci, że teraz używam C, jeżeli nie potrzebuję,
jeżeli nie potrzebuję funkcji C++, takich jak obiektowość,
to ja teraz bardzo lubię czyste C.
Tylko właśnie chodzi o to, że żeby zacząć doceniać jakąś technologię,
to trzeba zacząć od czegoś, co da nam jakieś lepsze efekty.
To jest mniej więcej tak, jakby małemu dziecku,
który ma taką zabawkę, do której to dziecko mówi
i potem ta zabawka odpowiada temu dziecku dać rippera,
czy nie wiem protulsa i mu powiedzieć masz baw się,
bo to jest bardzo profesjonalny i porządny program.
I to ci da dużo frajdy, albo jeszcze lepiej,
nawet pozostając przy tej zabawce,
gdyby temu dziecku zamiast tej zabawki,
już wiem jaka tu mogłaby być analogia,
że mamy dajmy na to zabawkę, która składa się z dwóch elementów,
dajmy na to z głośniczka i z mikrofonu.
Wystarczy ten głośniczek i mikrofon połączyć,
czyli tak jak w programowaniu powiedzmy skorzystać z jakichś dwóch bibliotek
i ewentualnie napisać jakiś własny kawałek kodu,
a gdyby teraz temu dziecku,
które jest w stanie manualnie połączyć sobie ten głośnik z mikrofonem,
bo to jest tam, dajmy na to wkładamy jedno w drugie i to już działa,
ale teraz dajmy na to, że temu dziecku dajemy to, co tam jest w środku,
to znaczy dajemy osobno obudowę, osobno elektronikę,
osobno jakieś kabelki, które jeszcze musiałby na przykład przylutować
i dajemy schemat, no i baw się.
Dokładnie, dla kogoś to może być fajne,
tylko na pewno nie w tym czasie jego rozwoju,
tak samo jak ja zareagowałem na język C,
bo dla mnie na przykład teraz język C jest bardzo fajny,
bo mogę sobie ręcznie zarządzać pamięcią,
czego mi w tych nowszych, prostszych językach programowania brakuje,
no ale dla młodego mnie, dla mnie, który dopiero uczył się programowania,
to nie miało wymiarnego znaczenia,
bo dla mnie problemem było to, że nie umiałem zrobić tego,
co w tym danym momencie było mi potrzebne.
I tak samo jak rozmawiam z ludźmi, którzy studiują informatykę
i dziedziny pokrawne, z ludźmi, którzy dodajmy nie mieli
styczności z programowaniem, bo to jest akurat ważne,
i po kilku takich pierwszych lekcjach z programowania
ci ludzie mówią, że to jednak nie jest dla mnie,
bo my tam uczymy się rzeczy zupełnie niepraktycznych
i teraz ktoś może powiedzieć, no tak, oczywiście trzeba zacząć
od czegoś prostego i ja się z tym zgadzam,
trzeba zacząć od czegoś prostego,
ale proste niekoniecznie oznacza niepraktyczne,
bo możemy napisać program, który, nie wiem, wypisze 10 liczb,
bo znamy już pętlę i instrukcje warunkowe powiedzmy,
ale możemy w zamian tego napisać gra,
która wymyśli sobie jakąś liczbę i my podając liczby
gra będzie nam mówić, czy liczba, którą wymyśliła ta gra
jest mniejsza czy większa od tej zadanej
i to już jest coś bardziej praktycznego,
coś co daje wymiarny bardziej efekt,
wiadomo, że nie jest to nie wiadomo jaka gra,
która podbije rynek, ale jest to coś,
z czym my jako twórcy możemy wejść w interakcje
i tego mi niestety brakuje w bardzo wielu kursach programowania,
zarówno tych starszych, jak i niestety tych dzisiejszych.
Wiesz co, ale chyba widzący nie mają tego aż tak wielkiego problemu z tym,
dlatego, że ja na przykład widząc jakieś kursy programowania
i to jest coś, co mi też trochę przeszkadzało, powiem szczerze,
nie znalazłem takiego jakiegoś fajnego kursu,
który byłby dla mnie z jednego prostego powodu,
bo tam bardzo często było, no to teraz napiszemy sobie grę.
Napiszemy sobie grę, tylko że to nie będzie gra audio,
no bo przecież to był kurs tworzony z myślą o osobach widzących,
więc tam będzie gra, która będzie coś rysowała na ekranie,
która będzie odpowiadała za wyświetlanie jakichś obiektów,
będziemy się tym obiektem poruszali po tym ekranie,
więc okej, sporo fajnej wiedzy, ale dla mnie na ten moment,
kiedy zaczynam z czymś próbować się zmierzyć,
to jest taka wiedza, o której ja w ogóle nie myślę.
Ja bym chciał, żeby to było coś dla mnie takiego,
co ja będę mógł sprawdzić, czy to faktycznie działa,
a obiekt poruszający się po ekranie, no to z całą sympatią do twórcy kursu
to nie jest coś, co będę w stanie zweryfikować.
No dokładnie, to jest jeden problem.
Jest taki, że osoby widzące mają dużo takich narzędzi,
które ułatwiają im życie.
Powiedzmy, że ktoś chce zacząć robić te gry,
no to osoba widząca pobiera sobie z internetu darmowe zresztą Unity,
bierze sobie dowolny kurs z internetu, nawet ten od Microsoftu oficjalny
i już po kilku dniach jest w stanie zrobić w tym coś.
Oczywiście nie będzie to arcydzieło wybitnej jakości i klasy,
ale będzie to gra grywalna, a niestety u nas brakuje takich narzędzi
dla osób niewidomych jak Unity czy jak Godot czy te inne silniki.
Osoby niewidome muszą tworzyć własny silnik do gier przeważnie,
bo nie istnieje coś, co byłoby takie ustandaryzowalne.
Były jakieś próby stworzenia takich rzeczy, ale to się nigdy nie przyjęło,
bo właśnie w programowaniu bardzo ważna jest społeczność.
O tym też będę mówił jeszcze zanim może przejdziemy do tego iOS-a,
ale to jest wszystko bardzo ważne.
Tak, to jest wszystko ważne, żeby w ogóle opowiedzieć o tym,
po co właściwie zaczynać programować i żeby Was tak trochę zachęcić do tego.
Dokładnie, jeszcze opowiem o takim jednym błądzie, który popełniłem.
Później po tym nieudanym spotkaniu z językiem C
się obraziłem na mainstreamowej języki programowania
i zacząłem szukać jakichś prostszych języków,
np. Pure Basic francuski, który wydawał mi się językiem prostym,
fajnym, można było bardzo dużo w nim zrobić w małej liczbie linii kodu.
Ja nie mówię, że to jest coś złego,
tylko że w pewnym momencie ja w tym języku natrafiłem na taki poziom,
że przez to, że ten język miał dość małą bazę użytkowników,
kiedy ja natrafiłem na jakiś problem,
to bardzo ciężko było mi znaleźć pomoc w tym konkretnym problemie,
no bo jeżeli społeczność jest mała, no tak i tych problemów jest mniej.
I oczywiście ja bardzo to ceniam, język Pure Basic,
bo ten język bardzo dużo mnie nauczył w oprogramowaniu i polecam go,
tylko ja ten język mogę polecić tylko pod warunkiem, jeżeli my mamy świadomość tego,
że dość szybko natrafimy na problem,
którego rozwiązanie będzie przekraczało nasze możliwości,
dlatego że nikt inny raczej nie zmierzył się z takim problemem.
Ja później wytłumaczę ten koncept, o co tak naprawdę chodzi,
bo ja opowiadał już o Son Majoesie i o tym, jak powstawało Tyflocentrum
i z jakimi problemami się zmierzyłem podczas tej aplikacji,
jako już ktoś, kto ma pewne doświadczenie
i ktoś, kto już nawet zdarzyło mi się programować odpłatnie powiedzmy.
Arku, to ja zapytam jeszcze o jedną rzecz, o takie konkretne podstawy,
no bo język programowania to możemy tak sobie porównać,
przynajmniej jeżeli chodzi o wydźwięk, o brzmienie tego wyrazu
czy tych wyrazów jako język obcy.
Tego języka trzeba się nauczyć.
No i teraz w przypadku języka owcego,
no to mamy doświadczenia myślę, że nieco większe i więcej osób je ma.
I te osoby, które uczyły się kiedykolwiek jakiegoś obcego języka,
to wiedzą, co w takiej sytuacji się robi.
No przede wszystkim pamięciówka na dobry początek,
bo trzeba jakąś bazę słów sobie zapamiętać.
To jest jedno. Potem jakaś gramatyka.
No tu są różne sposoby na to, żeby tę gramatykę okiełznać.
Ale przede wszystkim słuchanie, czytanie, oswajanie się z tym językiem.
To ja zapytam o taką rzecz,
już abstrahując od konkretnego języka.
Czy to będzie ten Pure Basic, czy to będzie C,
czy to będzie jakikolwiek inny język oprogramowania.
Jak, twoim zdaniem, z twoich doświadczeń,
jak tego języka się w ogóle nauczyć?
Przede wszystkim język oprogramowania to nie do końca język obcy,
bo tak naprawdę najważniejszą umiejętnością,
jaką musi posiadać, czyli inaczej musi posiąść,
prędzej czy później, i niestety z bólem serca mówię,
że w naszym przypadku prędzej niż później,
to umiejętność znajomości języka angielskiego.
Bo nawet jeżeli znajdziemy dokumentację czegoś tam,
czy to jakiegoś języka oprogramowania,
czy to jakiegoś frameworka, czy to jakieś biblioteki,
jeżeli na przykład znajdziemy te dokumentacje w języku polskim,
to wszystkie komendy, jakie składają się na język oprogramowania,
nazwy funkcji i tak dalej, wszystko będzie w języku angielskim.
I to są proste słowa.
Więc ten element pamięciowy trochę odpada, ale trochę nie,
bo też są tak zwane zintegrowane środowiska programistyczne,
z których się korzysta raczej,
i ja polecam z tych środowisk zintegrowanych korzystać,
bo to nie jest tak, że te programy nas wyręczają
i robią wszystko za nas, ale o tym za chwilę.
Ale taką najważniejszą rzeczą,
i tutaj z kolei języki naturalne mają wyższy próg wejścia,
bo najważniejszą rzeczą, jaką trzeba robić, to pisać kod.
I nie bać się tego, że mój pomysł jest głupi,
że w sumie to jest bez sensu,
bo to nie będą i tak programy, które my wypuścimy na świat,
tylko to będą programy, które pozwolą nam przyswoić jakiś koncept.
Na przykład ja, jak uczyłem się już programowania
i poznałem, czym są słowniki,
no to stworzyłem sobie program, który był bardzo prosty,
aczkolwiek bardzo wiele mnie nauczył,
stworzyłem sobie program do bardzo prostych fiszek,
który po prostu odwracał karty z jednej strony na drugą
i to nie było coś, co było gotowe do pokazania światu,
program źle napisany, program miał na sztywno wpisane frazy i tak dalej,
ale najważniejsze było to, że byłem w stanie poćwiczyć jakiś koncept,
bo w programowaniu ja przynajmniej tak miałem i do dziś tak mam,
że bardzo często zapominam różnych konceptów,
bo tego jest mimo wszystko bardzo dużo.
Problemem nie jest to, że my zapominamy czegoś,
bo będziemy zapominać, jest teraz przeważnie dostęp do internetu,
bo większość aplikacji, które piszemy i tak korzystają z internetu i tak,
więc ten dostęp do sieci przyjmijmy, że mamy.
I tak prędzej czy później będziemy po prostu,
i to myślę, że prędzej niż później nastąpi,
będziemy posiłkować się kodem, którego sami nie napisaliśmy.
Dokładnie, ale ważne jest po prostu, żeby te koncepty mieć w głowie
i żeby je rozumieć, a jeszcze ważniejsze jest to,
żeby wiedzieć, gdzie się udać w razie jak czegoś zapomnę,
bo ja wiem, że jak zapomnę, jak obsługiwać,
przyjmijmy, że zapomniałem jak to zrobić, żeby przyspieszać audio,
żeby przyspieszać dźwięk, bo no tak przykład,
nad którym też niedługo będę pracował,
zapomniałem jak przyspieszać dźwięk, a mi to jest potrzebne,
no to ja nie muszę tego wiedzieć, bo nie jestem encykropedią,
nie znam wszystkich funkcji, wszystkich bibliotek,
jakie ktokolwiek kiedykolwiek napisał, ale muszę wiedzieć,
gdzie tego szukać i jak tego szukać, o tym też będę mówił,
jak wyszukiwać informacje odnośnie tego, na co my możemy natrafić
podczas tej naszej przygody z programowaniem.
Wspomniałeś o tym, że język programowania jakikolwiek,
bo nie był to rzecz prostsza niż język naturalny,
niż jakikolwiek język obcy, coś w tym jest,
że jednego język programowania nie wybacza,
co wybacza język naturalny.
Mianowicie jeżeli w jakimś języku, czy angielskim,
czy niemieckim, czy polskim nawet, to popełnimy jakąś literówkę,
gdzieś nie wstawimy przecinka, gdzieś nie wstawimy kropki,
to się absolutnie nic złego nie stanie.
Najwyżej ktoś stwierdzi, że no,
palec mu się omsknął, albo chyba w szkole nie uważał,
bo pisze, nie wiem, że przez rz.
Ale komputer, no to już na tak sformułowane polecenia
wydane do niego w języku, jakimkolwiek, jeżeli zrobimy literówkę,
no to on się pogubi.
Pogubi się i to z jednej strony utrudnia nam pracę,
bo musimy bardzo dokładnie pamiętać o pewnych zasadach,
a z drugiej strony tą pracę nam znacznie ułatwia,
bo wyobraź sobie sytuację, że komputer byłby w stanie zrozumieć,
że przez rz, tylko próbowałby to zinterpretować w jakiś inny,
znany sobie tylko sposób.
To generuje jeszcze więcej problemów związanych z tak zwanymi
zachowaniami niezdefiniowanymi, undefined behaviors,
tak to się po angielsku nazywa.
Nie lubię tego, ale będę się czasami posługiwał angielską terminologią,
bo w programowaniu tak trzeba, bo polskiej nie ma.
I właśnie to jest różnica między językami statycznie typowanymi,
a dynamicznie typowanymi.
To brzmi strasznie, ale nie chcę, broń boże, nikogo stroszyć,
bo to nie o to chodzi.
Chodzi o to, że języki programowania dzielimy na takie dwie grupy,
i jako początkujący programiści musimy wiedzieć,
że języki dynamicznie typowane dają nam troszkę większą swobodę
kosztem szybkości działania naszego programu, to po pierwsze,
oraz kosztem tego, że program przez to, że będzie w stanie więcej nam wybaczyć,
to będzie w stanie też więcej, w cudzysłowie, popsuć.
Takim językiem jest na przykład język Python,
w którym napisany jest przez wiele osób używany program odczytu ekranu NVDA.
Jeżeli w dodatku do NVDA wystąpi jakiś błąd, nawet składniowy,
to jest bardzo duża szansa, że ten dodatek będzie działał,
tylko będzie zachowywał się w sposób niewłaściwy,
podczas gdy w językach statycznie typowanych coś takiego będzie miało
dużo mniejsza szansa na wystąpienie, bo język statycznie typowany
jest bardziej restrykcyjny w tym, na co nam pozwala.
Musimy znacznie bardziej trzymać się jego zasad.
I musimy dokładnie i bardziej precyzyjnie określać, co my chcemy robić
i co tak naprawdę w danym miejscu definiujemy, tak?
Dokładnie. Tak jak na przykład PHP jest językiem dynamicznie typowanym,
to jeżeli ja na przykład napiszę sobie echo prawy nawias zamiast lewy nawias,
cudzysłów to jest test, lewy nawias powiedzmy pod przestawem nawiasy,
ale ten skrypt będzie miał tam ileś, ileś, ileś linijek,
to jest duża szansa, że ja na przykład będę w stanie przesłać formularz
i na problem natrafię dopiero podczas odbierania tych danych od tego formularza.
Dajmy na to, to jest taki przykład, który na razie Wam nic nie będzie mówił,
ale jeżeli będziecie zaczynać się uczyć programowania,
to bardzo szybko zrozumiecie, o co chodzi.
Czyli Twoim zdaniem, którego języka lepiej się uczyć na początek?
Takiego, który wybacza więcej, ale później może nas prowadzić do tego,
że mamy jakieś złe nawyki czy odwrotnie?
Wśród osób niewidomych bardzo popularny jest Python,
no bo chyba dlatego, że MV daje mimo wszystko, tak mi się wydaje przynajmniej,
aczkolwiek ja właśnie w Pythonie nie lubię tego, że on jest dynamicznie typowany
i ja osobiście, to jest tylko i wyłącznie moja prywatna opinia,
bo na przykład L10 jest napisany w Rabin,
L10 też znany wśród osób niewidomych program,
a Rabin też jest językiem programowania dynamicznym
i podejrzewam, że gdyby tu był Dawid Pieper z nami,
to mógłby mieć inne zdanie na ten temat.
Ja osobiście uważam, że na początku dobrze jest się nauczyć języka statycznie typowanego,
takiego jak np. Csharp czy Swift, o którym za chwilę będziemy mówić,
dlatego że oprócz tego bezpieczeństwa, jakie daje nam język statycznie typowany
przez to, że jest bardziej restrykcyjny,
otrzymujemy też niejako w gratisie dostęp do narzędzi debugowania,
tzw. debugowanie to jest proces analizowania tego, w jaki sposób działa nasz program
podczas samego działania tego programu,
podczas jego niezruchomienia na urządzeniu docelowym.
To debugowanie to jest proces, gdzie my podglądamy,
co ten program sobie w cudzysłowie myśli,
czyli jakie są wartości jego zmiennych, jak przebiega wykonanie.
A dawno, dawno temu debugowanie polegało rzeczywiście na usuwaniu pluskwy z obwodów.
To taka ciekawostka i od tego to się w ogóle wszystko wzięło.
W 1948 roku na Harvardzie.
Dawida z nami nie ma, ale jest z nami Grzegorz. Witamy Cię Grzegorzu.
Dzień dobry.
Dobry wieczór, dzień dobry.
Tak słucham, słucham.
Uszom nie wierzę, że jeszcze się znalazł jeden taki,
co wierzy w to, że się niewidomych uda zainteresować podstawami programowania.
Ja też należałem do tych wierzących jeszcze chyba rok temu czy dwa,
jak żeśmy z Dawidem napisali podręcznik podstaw programowania.
To właśnie wasz podręcznik.
Dla niewidomych podręcznik podstaw programowania w Rubym,
akurat dlatego, że tym Rubym to się też wtedy zajmowałem,
trochę zainteresowałem się podstawami, żeby sobie samemu się go nauczyć.
To mi tam pewnie zajęło z dwa weekendy oczywiście w jakimś bardzo podstawowym zakresie.
No ale pomyślałem, że to świetny pomysł, może świetny moment też na to,
żeby te swoje początki zapisać, zrobić takiego tutoriala w ogóle dla wszystkich,
nie tylko dla coś już programujących osób, tylko w ogóle tak jakby zacząć od algorytmu,
od obiektów, od algorytmu i od tych takich wyjaśnianych terminologii
na przykładzie codziennych takich jakby zagadnień,
że to tak naprawdę wszystko, wszyscy są programistami,
o to jest taka teza, którą w jednym z pierwszych rozdziałów.
Tak, widziałem, właśnie wasz kurs był tak naprawdę, to wtedy zrodził się w mojej głowie
taki, taka myśl, że może spróbować jednak w tym Telepodcaście omówić to programowanie.
Super, ale też właśnie chciałem do konkursji, żeby tak jakby nie zmieniać tematu,
no efekt był taki, że zerowy, znaczy to jakby poziom zainteresowania tematem
znikomy, no nie wiem ile osób czytało, pewnie trochę tam czytało,
bo gdzieś tam znajomi później pisali, że coś podczytywali, zaczęli,
no już myślałem, że to jest tak prosto napisane, że każdy może,
każdy trochę przy odrobinie chęci i czasu jest w stanie,
ale się okazuje, że to zerowy odzew praktycznie,
no nie wiem czy na temat jakby samej treści to czy się pojawił,
oprócz jednego gościa gdzieś tam anglojęzycznego,
który ten nasz tutorial po polsku pisany, on sobie translatorem tłumaczył
i ten sposób go czytał, więc był zmotywowany, zdeterminowany,
tu byłem nawet pod wrażenie.
Soją drogą ten człowiek bardzo przekuł naprawdę w praktyczną wiedzę,
wiem o kim Grzegorze mówisz, bo on faktycznie potem zaczął pisać
kod DLT na taka ciekawostka.
No to jest świetnie, czyli może warto było się trudzić
nawet dla tego jednego człowieka, natomiast z polskiej społeczności
odzew jest zerowy, właściwie ani jednego komentarza na temat samej treści,
w sensie jakichś pytań czy komentarzy, oprócz tego, że fajne, nie fajne,
że ktoś tam przeczytał, no to super, albo że mu się podobało,
no to tak jakby nie doczekałem się na żadne pytanie merytoryczne,
jeśli chodzi o treść, albo wytknięcie błędu, chociaż specjalnie tam trochę
zostawiłem takich różnych rzeczy, które aż się prosiły o to, żeby je skomentować,
nawet krytycznie, no ale jakoś tak nie pykło.
Więc no podziwiam, że kolejny człowiek idzie tą drogą.
Może będziesz miał Arkadiuszu więcej szczęścia, natomiast no troszkę,
ponieważ już te sprawy są mi znane, to troszkę się,
no bo to mnie w ogóle Michał Kasperczak zareklamował dzisiaj z audycją,
bo jakoś mi to umknęło, że będzie o programowaniu iOS-a,
myślę, no to zanim się zajmę jeszcze wieczornymi planami, to zadzwonię
i coś tam może, znaczy zadzwonię, posłucham, a może i zadzwonię.
Więc takie krótkie moje pytanka, nie wiem, czy na teraz, czy na później,
do Arka pierwsze, czy testowałeś ten silnik giercany Godot,
no bo to, że Unity jest całkowicie niedostępny, to już się boleśnie
nad tym przepanałem, niestety w ogóle nic tam nie można zrobić,
próbowałem różnych sztuczek, jakieś kompilowanie z konsoli i tak dalej,
to nie działa, znaczy kompilowanie działa, ale dodanie jakiegoś obiektu
na kanwas, czy do sceny jest po prostu rzeczą raczej niemożliwą.
Tak, bo tam, ja nie pamiętam, jakiś pinarny format.
Tak, tak, właśnie o to chodzi.
Jest to Godota, wtyczka, która go jakoś tam udostępnia,
ja tą wtyczkę napisał, żebym teraz nie skłamał, chyba pan,
sprawdzę tylko momencik, tak, pan tu się nazywa Nolan Darilek,
ktoś może go kojarzyć z Linuxowej społeczności,
on napisał wtyczkę, która jakoś tam działa z tym Godotem,
aczkolwiek dla bardzo zdeterminowanych silnikiem, który jest dostępny
i w którym da się coś zrobić, to jest silnik Cocos 2D.
No, to dobrze wiedzieć właśnie, bo jakoś nie miałem czasu nigdy na takie badania,
to może jakiegoś linka gdzieś w komentarzu warto by było.
Ja sobie to zapiszę oczywiście.
Ja też pewnie sobie to jakoś tam znajdę, ale tak może dla ułatwienia.
Teraz tak, druga sprawa, moje pytanie, nie wiem w sumie jaki macie plan na tą audycję,
natomiast jaki jest sens mówienia o programowaniu iOS-a,
skoro jeszcze kiedyś rzeczywiście jak ktoś by celował w niewidomych,
to było tam, że nie wiem, 90% niewidomych to używało tych iPhone’ów,
a teraz to widzę tak jakby nawet po statystykach biblioteki naszego DZDN-u,
że te proporcje się zmieniają, tak, już w stronę nie chcę tu nakłamać,
ale bardziej pół na pół nawet bym powiedział.
Tak, oczywiście.
Ja na przykład bym się nie podejmował, znaczy jakby trochę się też przymierzam,
żeby coś nawet coś tam jakieś takie, że tak powiem, zakulisowo apkę testową
tam jakąś wyrzeźbiłem do przetestowania pewnych koncepcji,
ale nie celowałbym w ogóle w jakąkolwiek jedną z tych platform,
dlatego że to jest po prostu szkoda prądu, jeżeli już to tylko dwuplatformowo,
tylko iOS, Android, a być może jeszcze coś więcej.
I tutaj moje pytania do Arka też właśnie w drugiej, trzecie, czy w tym kierunku?
Znaczy, bo nie wiem, czy będziesz mówił o tym aplowskim strasznym środowisku,
o tym X-Code’ie, czy raczej o jakichś takich międzyplatformowych jednak zagadnieniach?
Właśnie będę mówił o X-Code’ie, aczkolwiek zahaczymy też o Flutter’a.
A dlaczego o X-Code’ie, bo to też jest w sumie ciekawe pytanie,
dlaczego to środowisko wybrałem, bo przecież kto mnie zna to wie,
że i w C-Sharp’ie programowałem i tak dalej,
dlatego że akurat do Swift’a, akurat w o X-Code’ie i akurat o programowaniu na iOSa
powstał pewien tutorial, pewien samouczek,
który moim zdaniem jest naprawdę…
Na AppleVisie czy gdzie indziej?
Nie, nie, nie, hackingwithswift.com
Hackingwithswift.com
Na AppleVisie jest jak tego używać ustrojstwa z VoiceOver’em i nawet się z tym zapoznałem.
I także 15 razy trzeba 3 razy wyjść z interakcji, 7 razy w prawo, 2 razy w głąb i potem gdzieś tam
i dopiero tam jest to okienko, gdzie się z drzewa plików, projektów przechodzi do edytora plików.
A wystarczy Command-1 nacisnąć i potem Ctrl-J, tłucież Voy-J żeby przejść, właśnie to jest problem.
Ale to na AppleVisie, bo to jak ja bym sobie tak wymyślił taką drogę, no to dobra,
nie mądry, ledwo początkujący w tym VoiceOverze, ale na AppleVisie tak napisali.
To ja tam napiłem, czytałem, to znaczy, że to nie ja mam taki wstęp, tylko po prostu oni wszyscy tak to mają.
Właśnie wiem, zastanawiam się z czego wynika.
Ja mam taką teorię, że ludziom się po prostu nie chce skrótów zapamiętywać.
O ile kiedyś rzeczywiście trzeba było tych sporo skrótów zapamiętać, żeby różne programy obsłużyć
i to było faktycznie efektywne,
to w dzisiejszych czasach do wszystkiego można tak naprawdę dojść pod Windowsem,
gdzieś tam powiedzmy tabem, czy strzałkami, czy na Macu, powiedzmy z użyciem wokursora.
I mam wrażenie, że to trochę z tego wynika.
No można tak dojść, tylko właśnie tak, że trzeba wyjść interakcji.
No właśnie, tak, tak, tak.
Tak, jeden razy w głąb, później coś tam.
Także to chodzenie, w ogóle ten, trochę nie chcę tutaj spoilerować i psuć audycji,
natomiast to używanie voice-overa, żeby ktoś pokazał efektywnie,
jak używać w zaawansowanych aplikacjach voice-overa w jakimś podcaście właśnie voice-overa na Macu,
to byłoby ciekawe, bo dla mnie to jest droga przez mękę, jeżeli tak mogę powiedzieć.
To porównywalna z tym, co jest w NVDA, nawigacja obiektowa,
bo to tak nawet właściwie koncepcyjnie to jest bardzo podobne,
nawigacja obiektowa i to wchodzenie w interakcje w voice-overze,
nawigacja obiektowa w NVDA, przy czym nawigacji obiektowej w NVDA to się używa,
jak już zawodzą wszystkie metody, więc bardzo rzadko i w ostateczności
i wszyscy narzekają, że to jest takie trudne i nieintuicyjne,
a nawigacji voice-overem w Macu się w zasadzie używa jako podstawowego sposobu działania
i wszyscy, którzy tego używają, to się zachwycają, jakie to wspaniałe i to mnie,
nie mogę tego pojąć trochę, no dla mnie jest to jakiś taki gwóźdź.
Ja się nie zachwycam voice-overem akurat, ale to już tak trochę poza tematem,
aczkolwiek co ja lubię w Xcode, na przykład to, że możemy bardzo szybko
przechodzić sobie poprzedni, następny breakpoint,
poprzedni, następny komentarz, poprzednia, następna funkcja,
tylko niestety problem, i o tym też będę mówił,
żeby nie było, że jest wszystko usłane różami,
problem w Apple’u, zarówno jak i o to, co, że tak powiem, jest twarzą
do użytkownika końcowego, jak i o to, co jest twarzą do developera,
jest taki, że próżno szukać oficjalnych materiałów na ten temat.
I o tym też będę mówił, i to jest też jeden z powodów,
dla których iOS tak naprawdę, bo tak poniekąd opatrznie trochę,
że jest bardzo, jest relatywnie niski próg wejścia na oprogramowanie na iOS-a,
szczególnie teraz jak jest SwiftUI, ale…
A jak tworzysz, przepraszam, zapytam jeszcze, bo tutaj tego interfejs użytkownika,
bo też na tym się wyłożyłem, że się w sumie jak na tym artykule,
tylko ten artykuł na Apple Visit ja czytałem, no bo w 2018 roku, 4 lata temu,
i tak wyszło, że w zasadzie no nie ma dobrego sporu, można coś programistycznie tam
tworzyć te interfejsy, ale to jest też droga, która jest kolcami usłana,
a nie różami, bo jest to żmudne, trudne i skomplikowane
za tworzenie programistyczne interfejsów z Apple’owskiego.
No i stąd też to mnie tak jakby też spłoniło w stronę pójścia, wyjścia
z tego zrobienia takiego umysłowego jailbreak’a i wyjścia po prostu z tej pułapki,
ograniczania się do iOS-a, żeby trzeba jednak iść dalej, szerzej.
I tu mam pytanko szybkie też jak z tym flatterem sprawa,
bo teraz tutaj trochę na rozdrożu, nie wiem czy się brać za React Native,
czy jednak kopać się troszkę jeszcze z tym Native Script’em, którego używałem wcześniej,
czy możesz się rzucić na głęboką wodę i w ogóle od JavaScriptu odejść daleko
w stronę właśnie flatera, ale pytanie tam trochę robiłem też przymiarki z rok temu,
to tak słabo dosyć z tym coś nawet szybko mi się udało skompilować,
ale się okazało, że o ile do następnej kontrolki to na przykład przechodziło ładnie voice over’em,
to już do poprzedniej kontrolki tam coś był dziwny, jakiś problem,
znaczy takie elementarne dostępnościowe.
Flater 2.10, który się ukazał zdaje się w tamtym roku poprawił bardzo,
ja o tym nawet mówiłem w którymś z cyfroprzenonów, nie wiem czy Michale pamiętasz,
mówiłem o dostępności flatera, flater bardzo mocno się poprawił w tej kwestii.
Ja nigdy JavaScripta nie lubiłem, szczerze powiedziawszy,
z React Native’em mam tylko doświadczenie takie, że kiedyś po prostu czytałem w tym kod
i coś zmodyfikowałem, nie pisałem w nim aplikacji nigdy od zera,
aczkolwiek z czym dla mnie flater wybieraj?
To ten mechanizm, który tam się nazywa Platform Channels
i to jest to, że jeżeli potrzebujesz możesz używać Switcha dla Apple’a,
dla Apple’owskich platform czy Objective-C,
ale możesz też używać Java i Kotlina dla Androida
i tworzyć z tego wtyczki, które będą działały uniwersalnie na tych obu platformach,
zakładając, że napiszesz te niskopoziomowe powiedzmy interfejsy w tych konkretnych językach.
Także ja osobiście bardzo lubię język Dart,
on też jest fajny, ekspresywny dla osób, które by chciały zaczynać z tym programowaniem,
no tylko teraz jak bym o tym mówił, to zaczęłoby się troszkę chyba wszystkim już wymyślać.
Nie, to tak szybciutko tylko taki tak,
trochę przepraszam, że może nie powinien na antenie, może osobiście prywatnie,
ale może też kogoś to jednak zainteresowanych,
trochę bardziej zaawansowanych, zainteresowanych programowaniem właśnie mobilnych aplikacji
to może też zainteresować, więc dlatego na forum publicznym
jeszcze szybciutkie takie pytanie,
jak wygląda interfejsowanie C++ z Dartem właśnie,
czy to trzeba jakoś przechodzić przez te dla iOSa osobne pisać wtyczki
i dla Androida osobne, żeby zinterfejsować jakiś kod w C++
czy można bezpośrednio już bez tych natywnych platform?
Można bezpośrednio i ja na przykład…
No i to duży plus.
Na przykład tyflocentrum jak zaczęło powstawać,
to tyflocentrum zaczęło powstawać we flaterze na początku,
ale niestety Android troszkę pokrzyżował mi plany,
bo ja do obsługi audio używam biblioteki Buzz,
pewnie Grzegorzu kojarzysz, bo to jest znana biblioteka
i jest mechanizm w Dartcie, który nazywa się Dart FFI
i to jest mechanizm, który tworzy automatycznie bindingi z nagłówków C++
i później w tym flaterowskim mechanizmie, o którym już mówiłem,
w tym platform channels to bez problemu można ładować,
jedyne co trzeba to prosty warunek, który sprawdza,
czy ładujemy bibliotekę dynamiczną czy statyczną,
bo jak wiemy iOS nie wspiera bibliotek ładowanych dynamicznie
i to jest taka jedyna trudnostka, która z tego wynika.
Czyli to od tego flatera czyli odszedł w końcu, tak?
Ale w jaką stronę?
W stronę pisania osobne na iOSa w Swiftcie i na Androida w Java?
Od flatera nawet nie odszedłem,
bo tyflocentrum na Androida powstanie we flaterze,
tylko problemem było to, że w Androidzie bardzo dużo rzeczy ostatnio się zmienia,
a mimo wszystko chciałem przetestować koncept,
chciałem sprawdzić czy po prostu ludziom się spodoba tyflocentrum,
spodoba się ten koncept i dlatego napisałem,
słuchajcie flater jest bardzo szybkim też frameworkiem,
to jest chyba najszybszy.
No jest genialne, że kompiluje do kodu maszynowego,
czy do jakiegoś byte kodu jak w tym Xamarinie C-Sharpowym,
czy do jakiegoś dziwnego czegoś,
czy do Java Scriptu tak jak jest to w React Native czy w Native Scriptie.
Tam jest rzeczywiście ten kod armowy, natywny kod maszynowy,
to jest duże ukłony w Stanach Swój.
Rzeczywiście te aplikacje, te apki się uruchamiają błyskiem,
to tam nie ma, nie ma zużyteń.
Tak i naprawdę, no o tym kiedy zdecydować się na programowanie natywne,
a kiedy zdecydować się na programowanie multiplatformowe,
tak bym powiedział, tak naprawdę programowanie to jest tak szeroki temat,
że podczas samej tej rozmowy, rozmowy nasunęło mi się jeszcze
kilkanaście rzeczy, o których chciałbym powiedzieć.
Ja tylko jeszcze powiem tak a propos Reacta,
o którym tu wspomnieliście, że ja kiedyś widziałem,
właśnie też stworzoną, a właściwie tworzoną,
miałem okazję uczestniczyć przy tworzeniu jednej aplikacji
z wykorzystaniem, właśnie jak dobrze pamiętam to był React
i tam były nawet trzy platformy, bo tam był web,
była aplikacja na iOSa i na Androida
i aplikacja powstała bardzo szybko.
Natomiast, no tak się uśmiechnąłem jak słuchałem Ciebie Grzegorzu,
bo okazało się, że właśnie później diabeł tkwi w szczegółach
i o ile komuś nie zależy na tym, żeby ta aplikacja była dostępna,
no to wszystko jest fajnie.
Natomiast z poprawianiem dostępności…
Nie mogę się tu do końca zgodzić, bo weźcie poprawkę na to,
że na przykład Skype, na przykład Facebookowa aplikacja
i chyba też ten niezbyt fortunny, niezbyt przeze mnie lubiany Teams,
to są właśnie rzeczy napisane w React Native.
No Teams mobilny jest w Reakcie,
tylko że po co my programujemy na wiele platform na raz?
Na wiele platform na raz programujemy po to,
jak najwięcej kodów spółdzielić między platformami,
a na przykład teraz w Reakcie to się poprawiło z tego co wiem,
ale kiedyś dostępność trzeba było pisać w tych językach
charakterystycznych dla danych platform.
I wcale z tą dostępnością, Grzegorzu, to tak kolorowo nie jest,
bo na przykład na Facebooku, jak popsuli edycję komentarzy,
ileś wersji temu na iOS-ie, to to dziś nie naprawili.
Dlatego mówię, że diabeł tkwi w szczegółach, że to generalnie jakość działa
i podejrzewam, że sporo rzeczy, jak już się ma doświadczenie
też w pisaniu z myślą o dostępności, to jest okej.
Natomiast z moich obserwacji, jak ta aplikacja była tworzona,
to później ze trzy razy tyle czasu, co zeszło na stworzenie tej aplikacji,
która po prostu działała, która już robiła to, co ma robić,
to zeszło na poprawianie różnego rodzaju błędów dostępności.
Tak, bo na przykład Lumo Toolbox, w którego tworzeniu brałem udział,
Lumo Toolbox jest napisany we flaterze.
A to taka aplikacja, którą stworzyłem z kolegą z Chin,
to jest taka aplikacja, która zawiera w sobie dużo narzędzi,
takich jak OCR, takich jak tłumacz, transkrypcja mowy na tekst
i tam miernik światła, jakaś linijka.
Tam jest po prostu zestaw pewnych narzędzi, takich bardziej może przydatnych.
Ale ta aplikacja też była swego rodzaju testem.
Obydwoje wtedy bardzo testowaliśmy flatera.
Zresztą ten mój kolega przyczynił się do tego, że flater
też jest dostępny na Windowsie z czytnikami ekranu teraz.
Więc to zaszło faktycznie trochę dalej.
Ale też były problemy, których by nie było, gdybyśmy pisali natywnie
tę aplikację na te dwie platformy.
Grzegorzu, czy coś jeszcze?
Konkluzja jest taka, że tego flatera już można uznać
za jakiegoś zawodnika, którym warto się zainteresować
pod kątem programowania dostępnych dla niewidomych aplikacji.
To jest dla mnie dobra wiadomość.
W razie czego też proszę o kontakt, bo na pewno możemy się wymienić
doświadczeniami tutaj o gier tekście.
Nie, nie, nie.
Nie wypowiadaj tego.
Nie było takiego czegoś w ogóle.
Tymczasem w takim razie dzięki chłopaki muszę już lecieć,
ale fajnie, że parę ciekawych rzeczy tutaj się wyjaśniło.
Dzięki bardzo, Marku i Michale.
Dzięki, Grzegorzu.
Nie opowiadajcie za dużo bajek, bo będę krytycznie to jeszcze tam słuchał.
Postaramy się.
Trzymaj się.
Trzymaj się, hej.
No dobrze, czyli podstawy mniej więcej mamy za sobą,
jeżeli chodzi o programowanie.
Mamy przykład typowej dyskusji osób, które jednak się interesują
w tym programowaniu.
To też jest uważne.
Żeby sobie powymieniać uwagi na temat różnych technologii, języków,
osoby, które dopiero w ten świat programowania miałyby zamiar wejść,
to podejrzewam, że nic z tego nie zrozumiały.
Tu jakiś Flutter, tu jakiś React, tu coś, tu coś,
a przecież miało być na iOS-a.
No ale to zanim już tak przejdziemy rzeczywiście do tego iOS-a
i do tego, czym tam programować.
Arku, ty chyba gdzieś tam palcami dotykasz mikrofonu,
z którego mówisz, bo nam tu takie małe zakłócenia się robią od czasu do czasu.
Więc mam nadzieję, że teraz będzie…
…poprawić sprzęt, bo śliska powierzchnia nie sprzyja prowadzeniu audycji,
ale już jest w porządku.
Jasne. No dobrze.
To teraz jeszcze może powiedzmy o tym, jak to się w ogóle dzieje,
tak przynajmniej ogólnie, że ten program zaczyna działać.
OK, my wpisujemy jakiś kod, już nieważne na razie w czym,
nieważne w jakim języku, no i ten komputer zaczyna go sobie tam przetwarzać.
On go może przetwarzać na kilka różnych sposobów, prawda?
Tak, właśnie o tym rozmawialiśmy z Grzegorzem.
To ta kompilacja, jakiś bytecode i tak dalej, interpretacja.
O co chodzi?
Komputer rozumie tak naprawdę tylko cyfry, w dużym oproszczeniu.
Tylko zero i jedynki.
A my, pisząc kod w języku mniej lub bardziej zbliżonym do języka angielskiego,
jednak posługujemy się pojęciami, które dla tego komputera są bardzo abstrakcyjne.
Inaczej, nawet jeżeli nasz kod w języku programowaniem jest w pełni poprawny,
to dla komputera on sam w sobie nie jest zrozumiały.
Jest taki program, ten program nazywa się kompilatorem,
który zamienia ten kod nasz na kod tak zwany kod maszynowy,
tudzież, no tak, kod maszynowy to nie będziemy wprowadzali tutaj innych pojęć.
Kod maszynowy, czyli kod, który jest w stanie rozumieć bezpośrednio procesor,
bo procesor potrafi wykonywać instrukcje takie jak
odłożenie czegoś na stos, wzięcie tego ze stosu,
przeniesienie jakiegoś fragmentu pamięci z jednego adresu do drugiego.
I właśnie o to chodzi, że komputer jest w stanie operować tylko na tych tak naprawdę instrukcjach.
I my na przykład jak łączymy się z serwerem, czy nie wiem, odtwarzamy dźwięk,
czy nie wiem, generujemy wibracje, to dla komputera to jest abstrakcja.
Komputer też, tak samo jak ja mówiłem o rozdzielaniu tego problemu na dużo, dużo mniejsze części,
komputer robi to samo, tylko w dużo bardziej skomplikowany sposób.
Ja nie czuję się tutaj na siłach nawet zacząć tego objaśniać,
bo kompilatory to są programy, nad którymi pisze się prace doktorskie i wyżej.
To jest w informatyce taki koncept jak teoria grafów.
Ale od tego się może trzymajmy z daleka, nie chcę straszyć nikogo jeszcze bardziej niż…
Bo ustaliliśmy na samym początku audycji, że ta matematyka to tak specjalnie na początek w programowaniu,
to nam aż nie będzie przydatna. To może nie straszmy teorią grafów.
Nikt nie pisze kompilatorów raczej. Tak naprawdę, jakby się nad tym zastanowić,
to większość języków korzysta czy to z GCC, czy to z innych kompilatorów.
Oczywiście zdarza się, że są pisane, ale tego nie będą robili ludzie,
którzy są zainteresowani tworzeniem aplikacji konsumenckich.
Więc tutaj nie ma się naprawdę czego bać.
Jest jeszcze jedno podejście, bo ten program może być skompilowany
albo za każdym razem może być przetwarzany do tej postaci binarnej.
Tak jak na przykład język C-Sharp, którego jestem wielkim fanem jeśli chodzi o programowanie na Windowsa.
Język C-Sharp to bardziej technologia.NET, bo to język jest tylko językiem,
ale ten silnik powiedzmy w uproszczeniu.NET działa w taki sposób, że my piszemy kod
i ten kod jest przetwarzany na tak zwany kod pośredni.
I dopiero później podczas uruchomienia, podczas tego jak już program działa,
jest taki komponent w.NET, który nazywa się Just In Time Runtime Framework.
Skomplikowana nazwa, ale chodzi o to, że program odgrywa rolę symultanicznego tłumacza
między kodem, który my rozumiemy, a kodem, który rozumie procesor naszego komputera.
Programy interpretowane są uważane za wolniejsze od programów kompilowanych
i zaiste tak jest, aczkolwiek nie ma się co tym sugerować tak naprawdę,
czy język jest interpretowany, czy język jest kompilowany w tym sensie,
że ta różnica zaczyna być widoczna dopiero przy bardzo zaawansowanych rzeczach,
takich jak kompresja czy szyfrowanie.
Tak rozbudowany program jak Reaper czy Protools to są programy bodajże pisane w C,
nawet w czystym C, nawet nie w C++, tylko w C,
ale to nie znaczy, że nie można by napisać edytora dźwięku w C-sharpie,
który nie jest językiem kompilowanym, interpretowanym,
też nie, ale to już za dużo chyba tych pojęć by było.
I to nie stoi absolutnie na przeszkodzie, bo tak naprawdę w dzisiejszych czasach,
kiedy komputery mają już tak duże te moce obliczeniowe,
że to ta różnica po prostu się poniekąd zaciera.
Jeszcze nie do końca, ale niedługo myślę, że może do tego dojść,
że ta różnica się zatrze w szybkości działania tych programów.
To prawda, chociażby taka ciekawostka ostatnio dosyć często w tyfloprzeglądach na przykład,
mówimy o takim programie jak Whisper, czyli o tym narzędziu,
za pomocą którego jesteśmy w stanie rozpoznawać w dość szybkim tempie mowę
i przekształcać ją na tekst.
Cenk w tym, że ten program wymaga solidnej karty graficznej,
żeby to wszystko nam działało, natomiast ostatnio pojawiła się taka jaskółka
mówiąca o tym, że być może ta karta graficzna za czas jakiś nie będzie aż tak wymagana.
Bo ktoś postanowił, i tu ważna rzecz, Whisper jest stworzony w Pythonie
w oparciu o różne biblioteki i mechanizmy, ale w każdym razie to wszystko to jest Python,
natomiast ktoś postanowił napisać interpretację, implementację właściwie Whispera w C.
No i okazało się, że jak to zrobił, to nagle, gdzie ten Whisper na procesorach
działał do tej pory bardzo wolno i w zasadzie nie było najmniejszego sensu
uruchamiać go na procesorach, więc jeżeli nasz komputer nie miał dobrej grafiki,
to po prostu to działało bardzo, bardzo, bardzo długo,
no to teraz, jak ktoś ma dobry procesor, to nagle okazało się,
że zaczęło działać to ileś razy szybciej.
Więc tu coś rzeczywiście w tym jest, tak jak mówisz, jeżeli mamy dużo różnych obliczeń,
no to ten język taki niższego poziomu, bo też mamy właśnie kwestię tej poziomowości
tych języków, no to tak, to tu właśnie jeżeli język jest niższego poziomu,
jeżeli jest kompilowany, to w tym momencie jest duża szansa na to,
że będzie po prostu wydajniejszy, tylko nie zawsze tej wydajności nam potrzeba,
zwłaszcza w dzisiejszych czasach.
To po pierwsze, a po drugie ja wychodzę z takiego założenia,
że można napisać wolno działający kod w języku niskiego poziomu,
a można napisać bardzo szybko działający kod w języku wysokiego poziomu,
no w języku wysokiego poziomu bardziej chodzi o to, że w języku interpretowanym,
a nie kompilowanym, to też zależy od tego, jak kto pisze kod,
jak kto się stara nad tym, żeby optymalizować i tak dalej, i tak dalej.
Robiłem kiedyś takie ćwiczenie, że napisałem sobie tekst ala Makota
i kopiowałem go sto tysięcy razy.
No tylko oczywiście ta nie jest w tym nic praktycznego,
aczkolwiek doszedłem też do ciekawych wniosków, jak kopiowałem te ciągi znaków,
bo okazało się, że mogłem to zrobić w taki sposób, żeby to trwało kilka sekund praktycznie,
a mogłem to zrobić tak, że trwało to kilka milisekund.
Ale to nie jest coś, czym my jako osoby, które piszą sobie aplikacje konsumenckie,
muszą się jakoś bardzo przejmować, aczkolwiek programowanie to jest taka dziedzina,
że jeżeli już się nią zainteresujemy, to będziemy się chcieli tym przejmować,
bo po prostu będzie nas to interesowało, tak jak widzieliście moją rozmowę z Grzegorzem.
Tak, jeden z moich znajomych miał takie hobby, na przykład związane z pisaniem programu pocztowego
i jego takim wyzwaniem było to, żeby go jak możliwe, jak najbardziej zoptymalizować,
żeby on po prostu jak najszybciej działał, wszelkiego rodzaju obliczenia, żeby były jak najszybsze
i tak naprawdę to jest zabawa, która go chyba od ponad 10 lat pochłania.
Teraz to niedługo będzie blisko 20.
No i ja tak samo optymalizuję tyfrocentrum.
I nie, w tyfrocentrum nie ma zaawansowanych obliczeń matematycznych.
Są obliczenia matematyczne, o czym Grzegorz mówił, to będziemy o tym mówić,
nawet nie obliczenia, tylko po prostu jak obliczyć środek prostokąta,
szerokość przez 2, długość przez 2, mamy punkt środkowy,
jak po niewidomemu radzić sobie z robieniem interfejsów i co nam będzie potrzebne o tym.
Mam nadzieję, że już za chwilę, że za chwilę uda mi się przejść do tego iOSa.
Tak, bo właśnie myślę, że po tej godzinie 30 wstępu to już czas najwyższy,
żeby przejść w ogóle do konkretów.
Ale zanim przejdziemy do programowania takiego faktycznego,
to może kilka słów, co nam w ogóle będzie potrzebne.
Żeby programować na iOSa, to co, to Mac potrzebny w dzisiejszych czasach jest?
Mam być kompletnie zgodny z prawdą, neutralny czy szczery?
Szczery.
Powiem w ten sposób, jeżeli chcemy się pobawić, jeżeli chcemy testować nasze aplikacje,
to możemy wykorzystać z wirtualnej maszyny.
Oczywiście, że tak. Wszelkiego rodzaju hackintosze i inne rzeczy tego typu
można znaleźć w sieci, można się tym pobawić.
Nie do końca jest to chyba zgodne z polityką licencyjną Apple, no ale…
Nawet jeżeli mamy na przykład, tak jak ja mam, do niedawna miałem w swoim posiadaniu
bardzo starego MacBooka z 2009 roku, to okazało się, że mogłem korzystać z hackintosza.
No, mam teraz fizycznego Maca, ale to jest trochę inna historia.
Natomiast jeżeli chcemy wystawić naszą aplikację do App Store’u,
to niestety hackintosh już sobie tu nie da rady.
Tu już jest potrzebny fizyczny Mac.
Albo też istnieją usługi, które te Maci wynajmują.
Tylko problem jest z dostępnością takich usług.
No bo ten dostęp do takiego Maca otrzymujemy po prostu po VNC.
VNC to taki protokół zdalnego zarządzania maszynami.
Przenosi obraz z dźwiękiem gorzej.
No właśnie, o to chodzi, że na Macu oczywiście możemy sobie włączyć voice-overa,
z dźwiękiem jest problem i śmiem zaryzykować stwierdzenie,
że dla mnie łatwiej byłoby napisać aplikację,
niż zmusić później VNC do tego, żeby przesyłało ten dźwięk.
Też się tego obawiam, ale to nie koniec kosztów,
bo jak wiemy komputery Apple, to jest jakaś inwestycja.
Dla jednego będzie drogo, dla innego będzie tanio.
A dla innego to będzie w ogóle cenanie do przejścia,
ale to nie jest jedyne i o tym trzeba pamiętać.
Tworząc aplikacje na iOS musimy mieć konto deweloperskie.
I tak, i nie, znowu tutaj zależy co tworzymy, zależy po co tworzymy
i zależy jaka jest nasza baza użytkowników.
No ja zakładam, że chcielibyśmy stworzyć aplikację,
której będą używać inni, którą będziemy się chcieli z nim podzielić.
To nie chodzi o używanie przez innych,
tylko istnieje możliwość samodzielnego podpisu aplikacji
swoim własnym wygenerowanym w pęku kluczy certyfikatem.
Tak, w ten sposób też można.
I wówczas przez Safari można zaimportować sobie taki profil
i zainstalować, tylko wiadomo, to jest droga,
której Apple bardzo, bardzo nie poleca
i bardzo, bardzo tej drogi nie lubi.
I to konto deweloperskie jednak by się nam przydało,
jeżeli chcemy wystawić aplikację do AppStore.
Koszt konto deweloperskiego to jest 99 dolarów,
czyli na nasze…
No około 500 złotych tak naprawdę.
No 450, chociaż na przykład w okolicach czerwca,
jak jest WWDC, Apple’owskie, to można to konto dorwać
nawet 70% taniej zdarzają się takie akcje.
Trzeba wtedy śledzić, jeżeli jesteśmy tym zainteresowani.
Warto też powiedzieć o tym,
że nieważne w czym piszemy aplikację,
jeżeli piszemy nawet w tym Flaterze czy w Reakcie,
to wówczas tak czy tak po pierwsze będzie nam potrzebny
komputer Mac, czy to fizyczny, czy to wirtualny
do skompilowania tej aplikacji
i do umieszczenia jej w AppStore.
Będzie wówczas już nie wirtualny,
a ewentualnie jakiś wynajęty.
I też nieważne w jakiej technologii my piszemy aplikację,
będzie nam potrzebne konto deweloperskie, bo…
Za które płacimy co rok.
Co rok, tylko że no…
Na aplikacjach można zarabiać na wiele sposobów,
nie tylko robiąc te aplikacje bezpośrednio płatne.
O tym też może sobie porozmawiamy,
jak będę mówił, co zamierzam z Tyflocentrum dalej.
Nie, Tyflocentrum nigdy w życiu nie będzie płatny,
nawet o tym nie myślałem.
Tylko po prostu będę mówił o takich różnych rzeczach.
Natomiast tak, my płacimy nie za technologie,
bo wszystkie technologie takie jak program Xcode,
takie jak Apple Developer Documentation,
czyli dokumentacja deweloperska, takie jak przykłady
i tak dalej, i tak dalej, są do zdobycia za darmo.
My płacimy za prawo do wypuszczenia naszej aplikacji w App Store,
ale nie tylko, bo konto deweloperskie daje nam
bardzo dużo innych rzeczy, które mogą nam ułatwić
naszą przygodę z wydawaniem aplikacji.
Na przykład, no będę się posiłkował Tyflocentrum,
bo to jest aplikacja, którą pewnie niektórzy z Was już znają,
niektórzy ją testują i tak dalej.
Chociażby w tym koncie mam bardzo fajne narzędzia analityczne,
które na przykład informują mnie o tym,
ile aplikacji zajęło czasu połączenia się z serwerem Tyflo Podcastu,
ile czasu zajęło wyrenderowanie artykułu z Tyfle Świata
na urządzenie użytkownika i tak dalej, i tak dalej.
Ja mam bardzo łatwy, przede wszystkim dostępny dostęp do tych narzędzi.
Te dane są w formie tekstowej reprezentowane,
więc ja jako osoba niewidoma jestem w stanie
bardzo łatwo się do nich dostać.
Oczywiście też to nie jest takie różowe,
bo portal deweloperski Appla to jest coś,
o czym by można było napisać cały esej
o tym, jak nie robić stronie internetowej.
Tak, tam już na wejściu są problemy.
Ale bardzo dużo rzeczy teraz można zrobić z Xcode.
Na przykład w Xcode jest funkcja,
która pozwala nam jako osobom,
no wszystkim, nie tylko osobom niewidomym,
na przykład jestem sobie w stanie patrzeć od razu na to,
co mi ludzie wysłali do TestFlighta.
Na opinie z TestFlighta.
Ja mogę sobie oznaczać te opinie, przeglądać je,
oznaczać, czy już zrobiłem, czy nie zrobiłem,
oznaczać sobie ich priorytety.
TestFlight to takie narzędzie do testowania aplikacji,
że nie publikujemy ich jeszcze w sklepie,
bo to jest proces nieco dłuższy
i Apple tu ma swoje wytyczne restrykcje.
Natomiast TestFlight to jest takie narzędzie,
że zanim wypuścimy aplikację,
to możemy sobie ją przetestować na użytkownikach,
którzy mają ochotę podzielić się jakąś informacją zwrotną z nami.
No tak, ja w taki sposób testuję to Teflocentrum.
Jest grupa na TestFlight,
do tej grupy należy określona liczba osób
i wszyscy mogą sobie testować.
Są tacy agenci, którzy nie chcą udostępnić aplikacji w AppStore,
mają procesu tej oceny aplowskiej
i mają aplikacje w nieskończonych betach.
Mówię tu o aplikacji Dystopia,
to taki klient Reddita,
robiony chyba z myślą o osobach niewidomych
i ten klient cały czas,
już od kilku dobrych lat,
jest w becie i nie zamierza z niej wychodzić.
A tam jest jakaś też ograniczona liczba użytkowników.
10 tysięcy osób dla publicznych testerów,
to znaczy testy publiczne wymagają wstępnej weryfikacji przez człowieka.
Ja weryfikowałem Teflocentrum w taki sposób,
żeby móc dać linka, żeby ludzie nie musieli minować swojego adresu e-mail
i otrzymałem odpowiedź zwrotną chyba po trzech dniach
i Teflocentrum jest testowalne teraz z linka.
No to rzeczywiście, czyli ten proces nie jest aż taki straszny,
zobaczymy jak przyjdzie do oficjalnej publikacji,
co to z tego będzie i co będzie wtedy.
Mówię w ten sposób, że już mogę powiedzieć,
że jeżeli będę publikował aplikację,
to postaram się, nie wiem, czy na Twitchu, czy gdzieś,
zrobić takiego streama, gdzie będziemy sobie oczekiwać
na odpowiedź od apy, ale to oczywiście dygresja.
Także tak to wygląda.
Program Xcode to jest program, który jest bardzo dostępny.
Xcode, czyli taki program już do pisania aplikacji konkretnie.
Tak, to jest to, o czym mówiłem wcześniej,
zintegrowane środowisko programistyczne.
Zintegrowane dlatego, że mamy w nim edytor tekstu,
oczywiście w którym wprowadzamy nasz kod,
mamy kompilator, mamy debugger, czyli to narzędzie,
którym możemy badać nasz kod pod kątem tego,
jak działa, jakie są obecne wartości zmiennych,
jak szybko program działa.
Mamy też w Xcode zintegrowany system kontroli wersji.
To jest taka bardziej zautomatyzowana kopia zapasowa
naszego kodu, w dużym uproszczeniu mówiąc.
I mamy w tym Xcode bardzo dużo innych rzeczy,
które mogą nam jakoś tam pomóc w pisaniu naszego kodu.
Ale też Xcode ma kilka rzeczy zrobionych specjalnie z myślą
o użytkownikach niewidomych.
Na przykład, gdy wejdziemy sobie w edytor tekstu Xcoda,
wówczas na pokrętle voice-overa mamy do dyspozycji
kilka elementów, takich jak przejście do poprzedniej
następnej funkcji, do poprzedniego następnego komentarza,
do poprzedniego następnego breakpointu.
To jest takie miejsce w kodzie, gdzie program zatrzymuje się
po to, żebyśmy my mogli zbadać jego stan tym debugerem,
o którym mówiłem.
Także sam Xcode zawiera w sobie dużo takich narzędzi,
które pozwalają użytkownikowi niewidomemu nawigować
jakoś szybko po tym kodzie.
Też Xcode zawiera bardzo dużo skrótów klawiszowych,
o czym też już troszkę wspominałem.
Te skróty dla mnie osobiście są dość logiczne,
a jeżeli nie pamiętamy jakiegoś skrótu,
to taka porada, która chyba przyda się naprawdę wszędzie
i każdemu, kto korzysta z MacOSa,
nie tylko ludziom zainteresowanym programowaniem.
Jeżeli nacisniemy sobie skrót command-?,
czyli command-shift-? to możemy wpisać sobie dowolną frazę
i wówczas system podpowie nam,
jak to zrobić za pomocą klawiatury.
Jeżeli sobie zapomnimy jakiegoś skrótu,
to wówczas możemy sobie w taki sposób o tym przypomnieć.
Teraz kolejna rzecz, czyli w jaki sposób tworzyć interfejsy.
To, o co pytał mnie Grzegorz, to jest bardzo ciekawy temat,
bo jak powstał iOS, to nie było jeszcze języka Swift,
ale o Swiftie zaraz na razie o tych interfejsach.
To był sobie taki, w dużym uproszczeniu oczywiście,
proszę mnie nie zjeść, to jest uproszczenie,
biblioteka do tworzenia interfejsów,
która nazywała się UIKit, czyli User Interface Kit,
czyli zestaw do tworzenia interfejsów użytkownika.
I ta biblioteka pozwalała tworzyć interfejsy użytkownika
z poziomu takiego narzędzia wbudowanego w program Xcode,
w którym my mogliśmy ten interfejs projektować bez pisania go.
Ten interfejs był zapisywany w konkretnych plikach,
a my programowaliśmy tylko jakieś konkretne jego części.
Ale projektować w jaki sposób?
Ustawiać pozycje, nazwy przycisków, domyślny status pól wyboru,
to znaczy w iOSie to są przełączniki,
ustawiać pozycje, kontrolek, niestety nie względem siebie,
co właśnie było dużą przeszkodą dla osób niewidomych,
jeżeli chodzi o programowanie w UIKit.
Ale później, bo na początku aplikacja na iOSa pisała się w języku Objective-C,
który jest w pełni kompatybilnym z językiem C, językiem programowania,
i to wcale nie jest taki prosty i przyjemny język.
Moim przynajmniej zdaniem znam ludzi, którzy wolą Objective-C od tego, co jest teraz,
no ale ja tak uważam.
I później, chyba wraz z premierą iOSa 7, zdaje się,
powstał nowy język programowania stworzony przez firmę Apple,
czyli język Swift, język stworzony z myślą o ludziach,
którzy właśnie uczą się dopiero programować,
język nowoczesny, bez pewnych zaszłości, jakie niósł za sobą język Objective-C,
i tak dalej, i tak dalej.
Ale nadal interfejsy użytkownika, nadal aplikacje były tworzone
w tym stareńkim już frameworku UIKit.
I nadal był problem z oprojektowaniem tych interfejsów przez zasoby niewidome,
bo nie mogliśmy ustawiać kontrolek względem siebie,
tylko ustawialiśmy je, znowu wiem, że to jest uproszczenie,
i ja wiem, że to ma w sobie pewne niące, ale tak jest prościej,
ustawialiśmy wszystkie kontrolki względem lewego górnego rogu ekranu,
co dla osób niewidomych oczywiście może być problematyczne.
Ale wraz z premierą iOSa 13, Apple wprowadziło na rynek nowy framework
do tworzenia interfejsów, stworzony już z myślą o języku programowania Swift,
z myślą o tym, żeby wykorzystywać wszystkie te nowoczesne funkcje tego języka programowania,
i ten framework nosi nazwę SwiftUI, czyli Swift User Interface,
co ma podkreślać to, że jest to język stworzony z myślą o programowaniu w języku Swift.
Oprócz tego, że straciliśmy dostęp do projektora graficznego,
czyli teraz trzeba interfejsy pisać ręcznie, jeżeli programujemy w SwiftUI,
to jest dla niektórych regresja, wiem, że są zewnętrzne narzędzia,
które pozwalają jakoś to robić, ale nie korzystając z tych narzędzi.
O tyle SwiftUI wprowadza coś, co Android miał już od bardzo, bardzo dawna,
czyli tworzenie interfejsów, które opierają się na zasadzie pewnych relatywnych pozycji pomiędzy kontrolkami,
czyli my możemy powiedzieć, ustaw te kontrolki pionowo do siebie,
żeby te kontrolki były jedna pod drugą ustawione w stos pionowy, albo w stos poziomy,
albo zrób listę. I ten framework SwiftUI zerwał z tym takim starym systemem
tworzenia interfejsów aplikacji w ten sposób względem lewego górnego rogu ekranu
i przyjął właśnie taką formę projektowania tych interfejsów relatywnie,
co może i znacznie pomaga dla osobowo niewidomym projektować te interfejsy.
No bo tak, my tworząc taką aplikację, SwiftUI przejmuje pewnego rodzaju formę drzewa,
czyli my najpierw tworzymy okno, okno jest pustym prostokątem,
bo ekran naszego iPhone’a czy iPada jest prostokątny,
następnie na to okno coś nakładamy. I my nie nakładamy tego względem
lewego górnego rogu okna, a mówimy systemowi, żeby nałożył to na środku,
w wyrównaniu do lewej strony, w wyrównaniu do prawej strony.
Mamy tutaj coś, co możemy znać i kojarzyć z edytorów tekstu.
No ale ktoś może powiedzieć, dobrze, ja dalej nie mam takiego wyczucia tego,
jak to może wyglądać i to dalej jest dla mnie trudne.
I w porządku, nie każdy musi sobie umieć to wyobrażać, nie jest to konieczne,
żeby sobie to umieć wyobrażać.
A to zapytam od razu, bo to, co mi przychodzi do głowy,
czego można by spróbować, żeby sobie chociaż jakoś to wyobrazić,
jak to wszystko będzie wyglądało, to popróbować poeksplorować palcem
jakąś dowolną dostępną aplikację, bo wtedy przecież VoiceOver będzie nam czytał,
w jakim miejscu, gdzie znajdują się jakie kontrolki, jakie obiekty.
To prawda. I ja właśnie o tym chciałem teraz mówić,
że SwiftUI ma to do siebie, że łatwo jest taką aplikację przerzucić
bezpośrednio z Xcode’a do naszego iPhone’a.
Nawet nie musimy podpinać iPhone’a kablem do naszego Maca.
Od wersji 9 środowiska Xcode istnieje coś takiego, jak sieciowe debagowanie.
Włączamy to, wchodząc w manager urządzeń Xcode’a,
czyli skrót Command-Ctrl-2, wybierając naszego iPhone’a
i zaznaczając opcję Enable Network Debugging.
Widzicie, a to nie jest takie straszne.
Nie ma żadnego terminala, żadnych jakichś inkantacji,
modlenia się do komputera, tylko to jest naprawdę ludzkie
i coś, co może każdy komuś się tylko chce zrobić.
I po włączeniu tego sieciowego debugowania po prostu naciskamy sobie
Command-Plus-R jak Run i wówczas nasza aplikacja ląduje na ekranie
naszego iPhone’a i możemy sobie ją eksplorować.
Co więcej, sam VoiceOver zawiera w sobie kilka funkcji,
które mogą nam pomóc.
Na przykład, gdy przyciśniemy sobie na środku ekranu
jeden raz trzema palcami, to VoiceOver powie nam informacje takie jak
rozmiar ścianki, relacja elementów względem lewego lub prawej krawędzi ekranu,
czyli czy jest wyrównany do lewej, czy wyjustowany, czy wyśrodkowany itd.
I my mając taki ogląd, jesteśmy w stanie zbudować mniej lub bardziej
przyzwoicie wyglądający interfejs, bo nie zamierzamy nikogo czarować.
My jako osoby niewidome nie stworzymy interfejsu, który będzie rozwalał ludzi
widzących swoim pięknym.
Aczkolwiek powiem Wam szczerze, że SwiftUI naprawdę tutaj czapki z głów
dla ludzi, którzy myśleli nad tym, jak to zrobić, żeby to wszystko miało ręce i nogi,
bo w środowisku SwiftUI można w bardzo fajny, prosty i przede wszystkim dostępny sposób
robić proste, acz efektywne animacje.
Czyli, że na przykład kliwamy sobie jakiś przycisk i powiedzmy jedno okno się odsuwa
nam do góry ekranu, a drugie okno wychodzi z dołu ekranu.
Wówczas osoba widząca ma taką percepcyjną świadomość tego, że jeżeli pociągnie w dół
od góry ekranu, to to okno, które wcześniej wyjechało na górę ekranu, zjeżdża z powrotem na dół.
I my te animacje możemy tworzyć teraz w bardzo prosty sposób.
Nie potrzebujemy do tego wzroku, bo SwiftUI robi bardzo dużo rzeczy za nas.
No to rzeczywiście wygodna sprawa.
No dobrze, mamy stworzony jakiś interfejs, ale czy to jest to, od czego my tak naprawdę
zaczynamy tworzenie tej aplikacji?
Czy przed interfejsem powinniśmy też zrobić coś jeszcze, żeby w ogóle zacząć?
Stworzyć nowy projekt w Xcode’cie i go odpowiednio poustawiać, oczywiście.
Odpowiednio poustawiać w sensie ustawić nazwę aplikacji, ustawić główny język,
w jakim aplikacja jest tworzona, nie programowanie, a język naturalny.
Dlatego, że wraz z Xcode’em może dużo płacimy za to, konta deweloperskie,
ale otrzymujemy rzeczy takie jak…
Nie musimy robić absolutnie nic, żeby naszą aplikację dało się tłumaczyć na inne języki.
Nie musimy jakichś gettextów ładować, jakichś…
Każda aplikacja pisana dla iOSa jest z gruntu tłumaczalna,
chyba że bardzo, bardzo się postaramy.
Ja w Tyflocentrum popełniłem jeden bardzo zasadniczy błąd.
Tyflocentrum straciło tą możliwość, aczkolwiek zrobiłem to specjalnie,
albowiem Tyflocentrum jest aplikacją z myślą, tworzącą głównie z myślą o Polakach.
Inaczej, trzeba znać język polski, żeby tak czy tak z tej aplikacji korzystać,
więc mogłem sobie na to pozwolić, żeby ta aplikacja nie była lokalizowalna.
Ja tak zrobiłem dlatego, że chciałem poeksperymentować troszkę,
ale każda aplikacja pisana z myślą o systemie iOS jest z gruntu lokalizowalna
i dlatego ważne jest, żebyśmy my na początku ustawili sobie
główny język naturalny, w jakim nasza aplikacja jest tworzona,
żeby Xcode mógł tam wykonać pracę, która spowoduje,
że później będziemy mogli tłumaczom dać apliki.
Tłumacze naszych aplikacji na system iOS nie muszą mieć Xcoda,
bo te tłumaczenia eksportują się do plików.xl i.ff,
czyli na przykład aplikacją Poedit można aplikacje iOSowe tłumaczyć.
No tak, a Poedit to jest znana i lubiana przez tłumacze aplikacja.
Arku, znowu gdzieś tam coś…
Wiem, bo znowu spada ten telefon.
Tak, Poedit jest znany w środowisku, jest też na Maca,
jeżeli ktoś chce na przykład sam tłumaczyć,
aczkolwiek można też tłumaczyć aplikację Xcode,
ale znowu dygresja, bo jak już zaczynamy tworzyć aplikację,
to są dwie tak naprawdę szkoły.
Jest jedna szkoła, która mówi, że najpierw tworzymy interfejs,
potem funkcjonalność,
a jest druga szkoła, która mówi, że najpierw tworzymy funkcjonalność,
a potem tworzymy interfejs.
Ja osobiście najpierw wolę tworzyć funkcjonalność,
a potem interfejs.
Ja jestem takim dziwnym stworzeniem,
że ja bardzo nie lubię tworzyć interfejsów użytkownika.
Ja się lepiej czuję, ja właśnie piszę jakieś optymalizacje,
albo jakieś renderery.
Tak jak Tyflocentrum ma swój własny renderer HTML,
bo ubezpieczyło mi się, że Safari jest za wolna
do renderowania artykułów z cyfroświata.
No nieważne.
W każdym razie są takie dwie szkoły.
Ja osobiście tworzę najpierw funkcjonalność, potem interfejs,
aczkolwiek polecam na początku tworzyć
najpierw interfejs, potem funkcjonalność.
Dlaczego?
Dlatego, że stworzenie interfejsu to mniejszy nadpad pracy.
My już wówczas mamy coś pod palcami,
czego możemy dotknąć,
z czym możemy wejść w jakąś tam interakcję.
Nie wiem, poklikać w przyciski,
popisać sobie coś w polach edycji
i może to nie jest dużo,
ale nie mogę oczywiście mówić za wszystkich,
ale moja psychika działa w taki sposób,
czy działała kiedyś,
że coś takiego powodowało,
że mi się chciało robić tą funkcjonalność
i chciało mi się sprawdzać, czy to faktycznie działa
tak jak ja chciałem tego i tak dalej.
To są takie dwie szkoły.
Poza tym mając ten interfejs,
to już też jesteśmy sobie w stanie wyobrazić,
jakiego wyniku finalnego oczekujemy.
Jak ta aplikacja, kiedy sobie poklikamy w te przyciski
i je oprogramujemy,
no to jak ona ma się zachować?
Bo pisząc same funkcje,
które będą realizowane gdzieś tam pod maską,
no to musimy potem je jakoś jeszcze wywoływać,
sprawdzać te parametry,
a jak dodamy je po prostu do tego interfejsu,
no to będzie nam łatwiej.
To tak jak mamy urządzenie,
które ma już jakąś obudowę wyprofilowaną
pod konkretne przyciski i mamy ten środek,
no to oczywiście gdybyśmy tego środka nie mieli,
to możemy zawsze, no nie wiem,
jakąś szpilką albo jakimś ołówkiem
naciskać te przyciski gdzieś tam,
albo zwierać konkretne styki na płytce elektronicznej,
no ale tak jest chyba łatwiej, wygodniej to testować.
Tak, aczkolwiek też później,
nie przejmujcie się tym,
jest w programowaniu takie pojęcie,
które nazywa się code smell
i to jest ten smród kodu,
że czyjś kot śmierdzi, to się tak brzydko mówi,
polega to na tym, że kot jest pisany w sposób nieładny
i, ale jeżeli ktoś zaczyna z programowaniem,
to nie będzie się przejmował tym,
czy jego aplikacja jest testowalna,
czy można na niej wykonać testy jednostkowe.
To jest, że komputer sam sprawdza poprawność programu,
czyli dajemy komputerowi coś do zrobienia
i dajemy mu wynik gotowy, my mu dajemy wynik.
Nie wiem, napiszemy funkcję, która dodaje dwie liczby
i my powiemy, że dla danych wejściowych trzy i dziewięć,
ty masz zwrócić dwanaście
i komputer sprawdza, czy faktycznie zwrócił dwanaście.
Na tym polegają w dużym uproszczeniu testy jednostkowe,
ale nikt na samym początku przygody swojej z programowaniem
nie będzie się zastanawiał nad tym,
czy aplikacja jest testowalna, czy nie.
I powiem więcej, to jest dobre,
że się nie będzie nad tym zastanawiał,
bo jeżeli będziemy się cały czas zastanawiać na tym,
czy nasz kod jest dobrze napisany,
czy nasz kod jest źle napisany,
czy nasz kod jest ładny, czy nasz kod jest brzydki,
to dojdziemy do momentu, gdzie nie będziemy się mogli nad czym,
nie będziemy się mieli nad czym zastanawiać.
Ja bolesną drogę przeszedłem do tego,
żeby to wreszcie zrozumieć,
bo ja tego kiedyś nie rozumiałem
i dlatego miałem, śmiem twierdzić,
dużą wiedzę na temat programowania,
ale nie odważyłem się nigdy niczego zrobić,
nigdy niczego pokazać światu,
bo przecież to jest zabugowane,
to źle działa i tak dalej i tak dalej.
Bardzo długa droga,
bardzo długą drogą było dla mnie
zrozumienie psychologii tych działań.
A tak naprawdę koniec końców
to i tak przede wszystkim chodzi o to,
żeby to po prostu działało.
Oczywiście wiadomo, że programiści,
jak się ze sobą gdzieś tam spotkają,
czy będą dyskutować o jakimś kodzie,
no to będą mówić,
ale ten to napisał jakoś tam nieoptymalnie,
a ten to zrobił tak, a tu jest tak,
a tu by można to było,
to co jest w 10 linijkach, to jedną załatwić.
Oczywiście, że tak,
ale na początku to najważniejsze jest,
żeby to po prostu odpowiednio działało.
Właśnie.
O interfejsu jeszcze tak popytam,
bo mówiłeś o tym, że
już teraz
nie mamy czegoś takiego jak
takiej graficznej paletki,
na której sobie kładziemy te
elementy interfejsu, to znaczy nie mamy
żadnego takiego
generatora tego interfejsu, trzeba
pisać kod po prostu,
żeby ten interfejs się pojawił.
Ale to jest rzeczywiście tak, że to trzeba wszystko z palca?
Czy są jakieś biblioteki,
z której sobie po prostu bierzemy, że ja chcę tu
przycisk, ten przycisk ma się
znajdować tu, ok i już.
Xcode ma w sobie
narzędzia, to jest
tzw. auto completion i to działa
w całym tak naprawdę programowaniu,
że my piszemy sobie
i środowisko nam podpowiada różne rzeczy.
I tak samo jest
i tutaj, na przykład ja to
otworzę sobie notatnik, faktycznie
będę pisał, nie będę pokazywał syntezy,
bo to nie o to chodzi,
ale chcę pokazać,
jak to wygląda,
jeżeli
piszemy sobie bez auto
uzupełnienia, to na przykład
chcę zrobić zwykły tekst,
który się wyświetli
dla użytkownika, wpisujemy sobie
z wielkiej litery słowo text,
otwieramy nawias okrągły,
w cudzysłowie wpisujemy sobie
witaj w świecie,
zamykamy cudzysłów, zamykamy nawias
i możemy sobie wpisać kropkę po tym,
to jest tak zwany modyfikator,
background
color i w nawiasie
kropka red.
I to jest, to oznacza, że
będzie tekst witaj w świecie,
którego kolor będzie czerwony,
to co po kropce
swifty white, to się nazywa modyfikator
i
chcę tutaj pokazać dwie rzeczy,
po pierwsze pisanie tego interfejsu
jest bardzo, ja to nazwałem przy rozmowie
z Grzegorzem, jak rozmawialiśmy o flaterze,
powiedziałem, że to jest ekspresywne, bo to jest ekspresywne,
jeżeli my znamy
język angielski, to
nie musimy wiedzieć,
nie musimy znać
tego frameworka,
żeby wiedzieć, oczywiście mniej więcej,
bo mogą znaleźć pewne niuanse,
tam swifty white jest taka zabawa,
że kolejność tych modyfikatorów ma znaczenie,
no ale to już, jak już się
będziecie uczyć, nie będę wam psuł zabawy, bo
naprawdę swifty white, nawet dla kogoś takiego
jak ja, ja nie lubię tworzyć interfejsów,
uczenie się swifty white to po prostu
była zabawa, to dla mnie
niesamowita, to zaleta,
zasługa też pana Paula Hudson,
o którym będę mówił później, jak
będę wam mówił, gdzie się uczyć,
no ale w każdym razie,
o co chodzi z tą ekspresywnością
języka programowania, czy
jakiegoś frameworka, właśnie o to, że
my znając
i rozumiejąc język angielski,
a nie znając konkretnego
frameworka, czy konkretnej technologii,
jesteśmy w stanie zrozumieć,
aha, czyli tutaj chodzi
o to, że tło tego tekstu,
tego prostokąda, na którym zostaną wyrysowane
znaki, będzie czerwone, tak?
O to właśnie chodzi.
A gdy piszemy to w x-code,
to wpisujemy sobie
po prostu tekst i już
x-code mi tu podpowiada,
tekst i mówi mi dokumentację,
takie jakieś dziwne rzeczy, wpisuję sobie
enter i od razu
podaję ten tekst, który chcę wpisać,
wpiszę sobie
witaj w świecie,
przechodzę strzałką sobie za
cudzysłów, naciskam kropka b
i x-code już mi
mówi background color, naciskam sobie
enter, wpisuję kropka r
i już mam czerwony kolor,
tak? Ok, ale ty musisz
jeszcze nacisnąć jakiś, nie wiem, klawisz tap
albo coś, żeby on to… enterem
uzupełniał? W x-code
potwierdza się to enter. Tak,
enterem potwierdzasz, ale
jak wywołujesz to
automatyczne uzupełnienie? Nie wywołuję.
Ono się dzieje samo. Tak,
wiele osób to wyłącza, jeżeli sobie to
wyłączymy, to wówczas skrótem
kontrol spacja wywołujemy
to auto uzupełnienie,
ale w domyślnych ustawieniach programu
x-code, o którym
jeżeli będzie zainteresowanie, zrobię po prostu
pełnoprawny podcast o samym narzędziu.
Ja myślę, że warto by było
o tym zrobić podcast, żeby po prostu chociaż
jakieś namiastki pokazać, znowu
mikrofon gdzieś ci o coś…
Ja cały czas muszę poprawiać ten telefon.
No niestety.
Takie uroki nadawania trochę
z terenu. Tak jest.
Chyba.
Niestety nie mogę się na Zoomie nasłuchać. Tak,
żeby samo narzędzie pokazać,
jak to wygląda.
Też Apple
oferuje taką
bibliotekę
nie programistyczną, biblioteka w sensie
poniekąd dosłownym nazywającą
się SF Symbols.
To są symbole różnych
rzeczy, takie ikony, nie wiem,
głośników,
radia, nie wiem, książek,
gazety i tak dalej.
W x-code jest bardzo fajna
wyszukiwarka tych SF symboli.
Do czego to
służy? Do czego to służy?
Do tego, że
iPhone’y, nawet
największe iPhone’y to są ekrany
jednak dość małe. To, że
Pan na przykład program czyta
pausa przycisk, stuknij dwukrotnie,
aby aktywować to nie znaczy,
że osoba widząca widzi ten
komunikat na ekranie. To by było fizycznie
niemożliwe. Albo nawet, że widzi
pausa przycisk. No tak.
Albo nawet, że widzi pausa.
No bo to, że przycisk to widzi
okrągła kontrolka.
I właśnie o to chodzi.
My tworząc aplikację
możemy oczywiście
podawać etykiety przycisków
takie, żeby osoby
widzące je widziały, ale
dużo bardziej
powszechną praktyką i dużo lepiej
widzianą praktyką jest dodawanie
tych ikon,
tych SF
symbols. Możemy też dodawać
własne ikony, własne obrazki,
ale te SF symbole
przez to, że są robione przez Apple, to
automatycznie się skalują do rozmiarów
tam różnych iPhone’ów, Maców,
iPadów i wszystkiego innego.
Stąd te różnego rodzaju
nieporozumienia, jak na przykład
osoba niewidoma tłumaczy
coś o sobie widzącej, jeżeli
chodzi o
voice over’a, to znaczy
nawet nie voice over’a, obsługę jakiejś aplikacji.
I często to jest tak, no kliknij
na więcej.
Ale ja tu nie mam więcej.
Względnie zębatka. No właśnie.
I o to chodzi. I to też
programowanie
samo w sobie nie
tylko nauczyło mnie samej umiejętności
programowania, tworzenia aplikacji, ale też
dało mi taki
wgląd na to, jak
z komputera korzystają osoby widzące.
I przez to też
jestem w stanie chociażby
zajmować się jakąś pomocą techniczną.
Ale co do tych SF symboli, to
dlaczego o nich mówię? No dlatego, że jeżeli
naciśniemy sobie ten skrót command plus shift plus
l jak library, to
wówczas pisząc sobie
na przykład
ja sobie piszę na przykład
speaker
to program od razu mi mówi
speaker device
ile sobie w dół
speaker person
te ikony są
opisane w taki sposób, żebyśmy my
jako osoby niewidome
mogli je świadomie
wstawiać, żebyśmy
wiedzieli tak naprawdę co wstawiamy
na przykład
aplikacji tyflocentrum
podcasty mają ikonę
radia, a artykuły
mają ikonę gazety.
Zakładki.
Te zakładki mają też opis tekstowy
no bo zakładki są
prostokątne
dłuższymi
bokami do góry, czyli mamy
miejsce, żeby coś tam napisać
na tych zakładkach. Przeciski są okrągłe
więc dla nich tego miejsca jest mniej
o tym też warto wiedzieć
ale to przyjdzie z czasem
też warto się pytać
osób widzących, im dana osoba wie mniej
o takich rzeczach tym
lepiej. Ja jak
zaczynałem swoją przygodę ze SwiftUI
to napisałem aplikację
właśnie żeby zrozumieć jak działają
animacje w SwiftUI
i tam w tej aplikacji było kilka przycisków
od 0 do 8 chyba, bo tam 8
rzeczy chciałem sprawdzić
i osobie, która jest w ogóle nietechniczna
pokazałem to i przez to, że
ta osoba mi to opisywała
w sposób nietechniczny, ja jako
osoba niewidoma byłem w stanie zrozumieć
w jaki sposób te animacje działają.
A to
może być naprawdę przydatne
i to nie tylko właśnie tak jak mówisz
dla programistów, także i
w naszym takim codziennym życiu w ogóle też
na ten temat myślę, że przydałaby się
kiedyś jakaś audycja, to już kiedyś
ten temat był
podnoszony i myślę, że faktycznie fajnie by było
wytłumaczyć
osobom niewidomym, jak
w ogóle ten
interfejs
iOS-a
i różnego rodzaju kontrolki, jak to właściwie
wygląda, bo to…
Nie tylko iOS-a nawet, bo to jest bardzo uniwersalne
mimo wszystko właśnie
ja też
myślałem nawet o takiej audycji, tylko
ja też nie mam aż takiej
wiedzy na ten temat. No ty się dopiero tego
uczysz, tak.
To by musiał faktycznie być ktoś widzący, bo
ja jako osoba niewidoma nigdy nie będę miał takiej
wiedzy.
I to też sobie trzeba powiedzieć, nie ma się co czerować,
że dużo jesteśmy w stanie
zrobić i naprawdę ludzie z Apple’a,
którzy stworzyli tą bibliotekę SF Symbols
i zrobili te opisy dla tych
dla tych ikonek
naprawdę to czapki z głów,
ale mimo wszystko nadal
zostaną pewne problemy, których
nie rozwiążemy
przez to, że nie widzimy. Na przykład ja
teraz pracuję nad
wsparciem przewijania w
tyflocentrum i
tam jest taki eliptyczny
kształt, który się przechyla
podczas przewijania.
I ten…
Ja jako osoba niewidoma nie wpadłem
na to, podejrzewam, że gdybym
widział, od razu bym to zauważył, że jak
ta elipsa się przechyla, to ona
w pewnym momencie będzie nachodziła
na przycisk
do zatrzymywania otworzenia.
I też
takie rzeczy się zdarzają i takie rzeczy
się dzieją praktycznie na co dzień,
że gdyby ktoś mi nie zwrócił na to
uwagi, to bym o tym być może
nie wiedział, być może bym się domyślił później.
No tak, bo dla nas to nie problem,
ale dla kogoś, nawet i słabowidzącego,
kto by z tego korzystał,
to już jest kłopot.
No tak.
Swift UI jest takim cebulowym,
takim cebulowym,
bym powiedział,
tworem, bo jeżeli
możemy te kontrolki
na sobie
wkładać i
jeżeli nałożymy na siebie dwa przyciski,
to kliknięcie w jeden przycisk sprawi,
że najpierw kliknie się ten przycisk
na górze, a potem kontrola
przejdzie do przycisku tego pod spodem.
Także też takie niuanse się dzieją,
tylko w Swift UI trzeba
chcieć nałożyć na siebie dwa przyciski.
Trzeba specjalnie to zrobić.
Tego raczej się nie robi.
Na przykład
ja potrzebowałem aplikacji
do przycinania screenshotów na system MacOS.
To też było coś,
co pisałem w ramach swojego
ćwiczenia właśnie ze Swift UI,
czyli jestem w stanie zrobić interfejs,
w którym rozczyta się osobowidząca.
I mój trik polegał na tym,
że miałem sobie napisany tekst.
Kliknij tutaj, aby
wybrać obraz do zawadowania.
I jak wybrało się ten obraz,
to ten obraz
wjeżdżał na ten tekst.
Co spowodowało to, że tekst
przestał być widoczny,
bo tekst był niejako pod tym obrazem
i było widać ten obrazek,
na którym potem ja mogłem sobie operować,
już dam swoimi metodami,
żeby tam przyciąć do konkretnych rozmiarów iPhone’a.
To narzędzie też powstało
w sumie dla Tyflocentrum,
żeby zrobić screenshoty
do AppStore’a.
No nie?
I właśnie o to chodzi.
Ta ekspresyjność tego środowiska
sprawia, że my jako osoby niewidome
naprawdę oczywiście nie jesteśmy
w stanie wszystkiego zrobić,
ale jesteśmy w stanie zrobić bardzo, bardzo dużo.
To się zgadza.
O czym jeszcze
chciałbym powiedzieć?
No nie wiem.
Apple daje nam na przykład
bardzo fajny, prosty
silnik
do tworzenia
haptyki, czyli
tych takich lepszych wibracji
można to tak nazwać.
I to jest już coś,
z czego my możemy naprawdę
w pełni korzystać
i osobom widzącym też to pomaga.
Zawsze ten system sam generuje sygnały haptyczne
i tak dalej.
Ten silnik jest naprawdę potężny,
żeby te wibracje sobie łączyć w różne kompozycje
i tak dalej, i tak dalej.
I ja mówię o tym
nie dlatego, żeby powiedzieć,
że iOS to ma, a inne platformy
tego nie mają, bo inne platformy to też mają.
Nie o to mi, broń gorzej, tutaj chodzi.
Tylko chodzi mi o to,
że naprawdę można
mieć z tym frajdę, że to nie jest tak, że
my siedzimy tylko i robimy
jakieś rzeczy, z których nikt nigdy nie skorzysta
i zajmujemy się tylko teorią.
Tylko naprawdę, no nie wiem,
iOS ma
jakieś w sobie funkcje
do wizualizacji muzyki.
I na przykład ktoś mógłby chcieć zrobić program,
który
wibrowałby telefonem
w rytm muzyki, tak, no bo
jest to możliwe,
da się to zrobić
i jest to do osiągnięcia, tylko trzeba
chcieć. Ja mam teoretycznie
pomysł, jak coś takiego zrobić,
a nie jestem matematykiem, lubię matematykę,
ale nigdy z niej jakoś
dobre nie były, no nie? Taki przykład.
Mamy tutaj
taki komentarz
od słuchacza, który się podpisuje
lurek24
o i tak
warto by było zrobić audycję o tym
narzędziu. Pozdrawiamy lurka
w takim razie, no i widzisz, już masz głos
za.
Domyślam się, że chodzi o Xcode’a,
żeby zrobić audycję na temat Xcode’a.
Pewnie o tym była mowa.
Też powiedzieliśmy sobie
trochę o tym, jak zrobić, żeby aplikacja wyglądała,
a teraz jak zrobić, żeby
coś oprócz tego wyglądu tam było.
Żeby aplikacje działały.
Rzecz,
którą się
słyszy bardzo często,
i ja też tak miałem, jak się uczyłem programowania,
ja wychodziłem z założenia, że
ja muszę wszystko napisać sam,
co by aplikacja miała nie robić, to musi
korzystać tylko i wyłącznie z systemowych
bibliotek, z tego, co znajduje
się w systemie,
bo tylko to, co
jest w systemie,
jest zoptymalizowane i dobre
do użycia.
No i tak, na początku
nauki, ja się dalej
zgadzam z tym swoim poglądem,
ale nie zgadzam się z tym,
teraz jak bym się uczył programowania,
albo jak bym kogoś uczył programowania,
to na pewno
nie mówiłbym mu
tego w taki sposób,
bo owszem, biblioteki,
które są w systemie, dobrze
ich używać, wtedy wiemy, jak coś działa
bardziej, ale
potem są biblioteki, potem są tak zwane
zależności, żebyśmy
my, jako programiści, mogli
z nich korzystać.
Są biblioteki, które ułatwiają pewne sprawy
nam, no nie wiem,
jest na przykład taka biblioteka
RevenueCat, to jest biblioteka,
która służy do zarządzania
mikropłatnościami w aplikacji, jeżeli
nie chcemy korzystać z
oficjalnej biblioteki
Appla, czyli bodajże
StoreKit się to nazywa,
no to możemy z tego RevenueCata
korzystać, który
i tak korzysta z tej biblioteki
aplowskiej. Ale co nam to daje w praktyce?
W praktyce daje nam to to, że
przepraszam bardzo, niektóre
biblioteki systemowe
są dość
skomplikowane, przez to,
że realizują bardzo dużo
szerokich zastosowań.
Podczas gdy na przykład
taka biblioteka jak RevenueCat
jest stworzona z myślą
o tym, żeby jak najbardziej
to wszystko uprościć, czyli
na przykład jeżeli my
robimy coś
bezpośrednio w samym StoreKicie,
to musimy najpierw wymienerować
fakturę, bo
w Appleu nawet jeżeli pobieramy coś
za darmo, to kupujemy to po prostu za 0 zł.
Swoją drogą dlatego wymagane
jest hasło przy pobieraniu
z AppStore, między innymi,
bo pobranie darmowej aplikacji to też jest
zakup, czyli generujemy najpierw
fakturę, potem generujemy
jakby komunikat
do serwera,
że użytkownik chce kupić takie
i taki przedmiot, system
daje użytkownikowi ten komunikat,
użytkownik płaci i my
jako programieści musimy
później odpowiednio
zachować się
w zależności od tego, czy
użytkownik dokonał płatności
i ta płatność zakończyła się sukcesem,
czy użytkownik dokonał płatności,
ale płatność nie zakończyła się
sukcesem, bo na przykład użytkownik
nie miał środków na karcie,
czy użytkownik dokonał płatności, ale jej status
jest nieznany, bo
użytkownik zapłacił metodą płatności,
która wymaga trochę czasu do przetworzenia,
a może użytkownik
na tym ekranie płatności
zrezygnował z tego zakupu.
Mamy bardzo dużo rzeczy,
o których musimy pamiętać
i biblioteki, które upraszczają nam
w jakiś sposób działanie
z kodem
właśnie tego służą, żebyśmy
my mogli skupić się na
dostarczaniu jakiejś funkcjonalności
albo na
innych
rzeczach.
Czyli to jest tak,
upraszczając całą sytuację,
w programie, który
korzysta z tej dodatkowej biblioteki
skupmy się na tym procesie płatności.
Ty opowiedziałeś o kilku
rzeczach, które się
mogą zadziać i teraz gdybyśmy
korzystali z tej oficjalnej
biblioteki
do obsługi płatności
oferowanej przez Apple, to każdy
taki przypadek
musielibyśmy oprogramować sobie
sami. Musielibyśmy napisać
nasze własne zdarzenia, co w danym momencie
się ma zadziać. A jeżeli
dobrze rozumiem to, o czym mówisz,
to jeżeli skorzystamy
z takiej gotowej biblioteki,
to my w zasadzie tylko w naszym programie
gdzieś umieszczamy informację,
że tu jest płatność
i ta płatność ma być obsłużona
przez tę dodatkową bibliotekę
i my w zasadzie nic więcej się nie musimy martwić,
bo tymi wszystkimi nietypowymi
przypadkami to już zajmie
się ta biblioteka. Dobrze ja to rozumiem?
Dokładnie w taki sposób
delegujemy zdarzenia do tej
biblioteki. Jest na przykład
biblioteka wbudowana w system,
nazywa się GameKit i to jest biblioteka,
która integruje tą Apple’ową
usługę Game Center,
czyli program do zespołowego
grania, ale biblioteka
GameKit ma też kilka
innych funkcji, na przykład
bardzo
zaawansowane funkcje
związane z dystrybuowanym losowaniem
albo funkcje
z tworzeniem sztucznej inteligencji
do gier. Jeżeli byśmy
nie korzystali z tej biblioteki,
to my musielibyśmy to wszystko pisać
ręcznie, musielibyśmy
mieć wiedzę matematyczną,
niekiedy fizyczną
i jakąś jeszcze inną, żeby to pisać,
a my
niekiedy mamy już te rozwiązania
po prostu gotowe, ktoś napisał,
ktoś przetestował.
Warto też myśleć o tym w takim pragmatycznym
sensie, że być może
jeżeli na przykład korzystamy
z jakiejś dużej biblioteki,
to osoby, które ją pisały
miały dużo większy budżet
i miały dużo większą wiedzę niż my,
bo było tych osób po prostu więcej.
Więc to nie jest tak, że
pisanie,
korzystanie z bibliotek zewnętrznych
to jest okazanie jakiejś programistycznej
słabości, tylko to jest
wykorzystanie narzędzi, które
ktoś nam
udostępnił. Inaczej, jeżeli
chcemy przybić gwoździa, to nie tworzymy
sami młotka, raczej.
Jest druga strona tego
medalu, to znaczy taka, że
te pewne
rzeczy, które delegujemy
na zewnątrz, to mogą się
zachowywać tylko w taki sposób,
w jaki je ktoś zaprogramował.
Ciężko mi sobie wyobrazić
sytuację, w której
biblioteka do płatności
miałaby nam się nie przydać,
ale domyślam się,
że może być trochę takich różnych
sytuacji, w których chcielibyśmy
zrobić coś jednak inaczej,
a ta biblioteka, z której
korzystamy, pozwoli nam na
wykonanie tego w taki jeden konkretny
sposób. No tak.
Jest taki przykład,
jest taka biblioteka, która nazywa się
SwiftyJson, to jest biblioteka
do obsługi właśnie standardu JSON.
JSON
to sposób
reprezentacji danych taki.
A propos JSONa,
odsyłam do mojego artykułu
na moim eltenowym blogu
odnośnie pisania aplikacji
Teflopodcastu, tam objaśniłam trochę na czym
ten JSON palada, no ale
teraz abstrahując, jest
ta biblioteka SwiftyJson, która
pozwala nam jakoś tym JSONem
zarządzać, jakoś go tam
jakoś tam go modyfikować
i tak dalej, i tak dalej, ale ta biblioteka
pozbawia nas
takich rzeczy, jak na przykład
sortowanie wartości w tym JSONie,
pozbawia nas możliwości kompresowania
tego JSONa,
pozbawia nas możliwości rzutowania
obiektów, i tak dalej,
i tak dalej, także
trzeba wiedzieć, kiedy
takich bibliotek nie używać,
trzeba też mieć świadomość tego,
że te biblioteki
mogą być pisane albo bardzo
dobrze, albo bardzo źle. Może ktoś
na przykład nie napisał tej biblioteki
dobrze i będzie ona spowalniała działanie
naszego programu.
I to wszystko też nie ma
co nad tym myśleć jakoś
za długo, jak zaczynamy dopiero,
bo ja uważam, że takie rzeczy
przyjdą z doświadczeniem.
Ja mówię,
największym błędem, jaki ja popełniłem podczas
swojej nauki programowania, było to, że tłukłem
teorię cały czas i zastanawiałem
się, myślałem,
a nie robiłem o w ten sposób
i to do niczego nie prowadziło. I tak samo
jest tutaj. Jeżeli my
nie umiemy czegoś zrobić,
na przykład powiedzmy, że ktoś nie
zna tych systemowych bibliotek
do obsługi Jasona, to znajdźcie sobie w
internecie Swift i Jason.
Ta biblioteka
jest ważniejsza od biblioteki
systemowej, bo Swift i Jason
to jest biblioteka, która powstała
zanim Swift sam w sobie
otrzymał natywne wsparcie Jasona.
Ta biblioteka
jest faktycznie prościutka
jest fajna, nie odejmuje
jej tego, nie ewaluuje jej,
ale chodzi po prostu o to, że
jeżeli znajdziemy sobie coś takiego
i to narzędzie nam pomoże osiągnąć jakiś cel,
to
należy po prostu z niego skorzystać
i się nie zastanawiać, ale
warto już,
gdy skończymy coś robić
i naprawdę nas to interesuje,
to warto sięgnąć trochę głębiej
i zobaczyć, a może to
systemowe rozwiązanie jest lepsze, może
jest szybsze, może to
rozwiązanie mnie czegoś nauczy.
Dowiedzieliśmy się trochę
o bibliotekach, tylko ja nadal
mam takie podstawowe pytanie.
Załóżmy, że coś o językach
programowania wiem, w tym
momencie ciężko byłoby nam w ogóle
tłumaczyć te podstawy programowania,
bo to też jest taka
rzecz, że warto sobie
poczytać o tych podstawowych konstrukcjach,
jakieś funkcje warunkowe,
pętle, czym są
te różne struktury,
typu jakieś tablice, listy
i tak dalej, i tak dalej, ale załóżmy, że to
wiem, ale
chciałbym się
zabrać za tworzenie czegoś
właśnie w
Swifcie, tylko ja tego języka
nie znam. Kupiłem sobie Maca,
zainstalowałem sobie XCoda,
otworzyłem aplikację,
coś tam sobie poklikałem jakiś
interfejs, no i teraz co?
Jak ja w ogóle mam zacząć?
Jest bardzo
wiele sposobów,
jest książka,
zacznę od materiałów darmowych,
zacznę od
materiałów oficjalnych, jest książka
Getting Started
with Swift and Swift.py,
to jest książka napisana przez Apple,
jest do pobrania za darmo
z Apple Books, też do niej dam
linka, pozwól, że sobie zapiszę,
żeby później nie zapomnieć.
Jest to
książka, która opisuje,
jak działa Swift,
jest też
dokumentacja deweloperska Apple,
ale to już jest taki zbiór
suchych faktów, taka
Wikipedia na temat wszystkich,
a raczej większości,
API firmy Apple, czyli tutaj już trzeba mieć jakieś
pojęcia o języku programowania,
ale jeżeli chcemy się uczyć,
to jest
też kilka sposobów,
jeden z nich jest oficjalny,
aplikacja Playgrounds,
też pod firmę Apple,
aplikację tą możemy pobrać
albo na Macu, albo na iPadzie,
niestety na iPhone nie możemy jej pobrać,
musimy tutaj zrozumieć,
iPhone mają na tyle mały ekran,
że faktycznie jeżeli
postawimy się w sytuacji osób
widzących, to to by było
niemożliwe, ale aplikacja
Playgrounds to
taka aplikacja, która
uczy nas programowania poprzez
interaktywne
ćwiczenia, w których najpierw mamy
coś opisane, później wykonujemy jakieś ćwiczenia
i przechodzimy sobie dalej,
dalej, dalej, coraz trudniejsze,
nam gra muzyczka,
odtwarzamy sobie dźwięki, chodzimy sobie jakimś
potworkiem, wszystko jest ładnie dostępne,
voice over
bardzo, bardzo ładnie sobie radzi,
jest tych playgroundów,
czyli tych
takich
jakby to powiedzieć, plansz
bardzo dużo, możemy też je dociągać,
bo tam jest kilkanaście chyba ich wbudowanych,
tam od takich absolutnych
podstaw, czyli czym jest zmienna,
czym jest stała, czym jest funkcja,
przez podstawy SwiftUI
aż do rzeczy
typu sieciowość i wielowątkowość,
także naprawdę to jest
bardzo dobry zasób, jeżeli ktoś
chce zostać z Applem
i
uczyć się z oficjalnych środowisk, to naprawdę
z całego serca mogę polecić aplikację
Playgrounds.
A to wszystko jak rozumiem w języku angielskim?
Tak, tak, no to
niestety, można próbować
z tłumaczem, ale ten angielski
i tak kiedyś się dla nas
odezwie. Tak jest.
Także to jest
tyle, jeżeli mogę
polecić o zasoby oficjalne,
a teraz uwaga,
nie, to nie jest materiał sponsorowany,
to jest moja prywatna opinia
i ktoś może się z tym nie zgodzić, ale
bardzo, bardzo
wspominam już o tym któryś, któryś raz
na przestrzeni wielu audycji
chyba to się przewijało
hackingwithswift.com i
pan Paul Hudson, który naprawdę
zrobił.
No,
moim zdaniem, czytałem
dużo książek o programowaniu,
zarówno na darmowych, jak i płatnych,
bo też interesuje mnie
ta literatura od strony
takiej, jak to jest pisane i jak
ludzi się uczy programowania
i moim zdaniem, to co zrobił
pan Paul Hudson
na tej swojej
stronie Hacking with Swift,
to jest najlepszy
zestaw
artykułów, samouczków,
książek, bo on tego naprodukował
masę, nie tylko
do Swifta, ale i do całego
no, nie widziałem lepszego zasobu
ogólnie, jeśli chodzi o języki programowania.
I tak,
pana Paul Hudson
możemy sobie podzielić na trzy części,
w sensie jego twórczość.
Pierwsza,
od której można zacząć,
jeżeli ktoś lubi formę
interaktywną, taką bardziej zabawową,
to aplikacja Unwrap, którą
możemy pobrać ze sklepu Outdoor.
Unwrap, U-N-W-R-A-P.
To jest
aplikacja,
ona też,
ale też tylko na Maca
i iPada.
O, to fajnie.
Także, jeżeli ktoś chce zacząć się uczyć
na iPhone’ie,
to ma tą aplikację Unwrap.
I ta jest aplikacja, która
jest takim
wstępem do Swifta, aczkolwiek
nie tylko, mamy
cały kurs od podstaw do takich
zaawansowanych funkcji
języka, jak na przykład delegaty.
Ale to jest tłumaczone zarówno
w formie tekstowej,
w formie artykułów,
pod koniec których mamy testy.
A jeżeli
ktoś woli słuchać, to jest
też format
wideo, gdzie naprawdę
pan Paul Hudson wszystko
opisuje,
do tego stopnia, że mówi nawet
co pisze. Nie jestem pewien,
czy to jest specjalnie robione
z myślą o dostępności, czy po prostu
tak ma.
Ale w każdym razie
tak wygląda.
Na końcu każdego modułu mamy taki
test, gdzie mamy
pytanie typu, prawda, fałsz,
jakieś tam układanie puzli z kodu.
Jest to dostępne z
VoiceOver’em, wszystko ładnie czyta.
Aplikacja ma wsparcie dla VoiceOver’a,
widać, że tutaj
pan Paul Hudson się postarał.
Mamy
wsparcie dla VoiceOver’a, możemy układać te puzle.
Oprócz tego mamy
taką
zakładkę Challenges, gdzie
każdego dnia
jest jakieś
takie małe wyzwanie do wykonania,
czy to jakiś test, czy to jakaś
aplikacja do napisania. Oczywiście
przez to, że to jest wszystko automatycznie weryfikowane,
to czasami my możemy
zrobić coś dobrze, a automat tego nie puści.
Ale mimo wszystko, naprawdę
bardzo inspirująca aplikacja.
Mamy tę zakładkę Challenges, w której możemy sobie
wypełnić te wyzwania.
No i ja sprawdzę automat, więc może być,
może coś tam się nie udać, ale
ale tak
ogólnie
no raczej ten automat
dobrze sobie radzi z tym.
Druga część twórczości
pana Paula Hudson’a to,
jak już mówiłem, HackingWithSwift.com
i cykl
100 Days
of SwiftUI
i to jest cykl,
który uczy nas w podstawie języka
programowania Swift. Takich całkowitych
podstaw. Tam jest założone, że my
nie wiemy o programowaniu absolutnie nic.
I
ten kurs jest napisany
tak, że jest on
podzielony na dni i my
w każdym dniu mamy za zadanie przejść
przez jedną lekcję tego kursu
i czegoś
konkretnego się nauczyć. Kurs jest podzielony
na 100 dni. Pierwsze 14 dni
to
podstawy Swift’a.
A później
od dnia
15 do dnia setnego
to jest uczenie różnego
rodzaju projektów. Od rzeczy
pokroju, pisanie aplikacji do
rozdzielania napiwków
czy do rozdzielania kosztów
za jakieś tam
potrawy
przez aplikację
do
nie wiem
do patrzenia sobie
na to kto brał udział
w jakich tam konkretnych misjach
Apollo, pisanie jakichś
gier językowych itd.
Oprócz tego mamy też
takie dni,
w których to my mamy za zadanie
napisać konkretną aplikację według
jakichś tam wytycznych.
To już
oczywiście nie podlega sprawdzaniu
no bo nie dałoby się tego
zrobić.
Aczkolwiek kurs jest naprawdę prowadzony w
bardzo, bardzo fajny, przystępny
sposób.
Tak samo jak
w przypadku aplikacji Unwrap, o której
mówiłem, mamy do wyboru
formę tekstową i mamy do wyboru
formę wideo.
Trzecia
część.
No właściwie to można podzielić na cztery części.
Trzecia część to książki,
które sam autor
czyli pan Paul Hudson
poleca kupować po skończeniu
tego jego kursu.
To są książki Advanced IOS
pierwsza, druga część
Pro Swift
czyli o takim
faktycznie pisaniu kodu z głową, tam jest
o takich
niuansach już bardziej zaawansowanych.
Pro Swift UI
czyli o tym jak
w tym Swift UI
robić naprawdę już bardzo
abstrakcyjne rzeczy.
On ma bardzo dużo tych
książek.
I czwarta i ostatnia rzecz jeżeli chodzi
o tego autora to Hacking
with Swift Plus.
To jest subskrypcja,
za którą płacimy
20 dolarów miesięcznie.
Dużo, niedużo, może
trochę dużo, ale
tam są już takie rzeczy,
które przydadzą się
nam
już faktycznie do zarabiania
pieniędzy. Także to jest sprawiedliwa
inwestycja. Mamy bardzo
dużo materiału darmowego,
naprawdę tysiące tych artykułów.
Z ciekawości.
Ty na jakim jesteś etapie?
A jak rozumiem z panem Paulem
zdecydowałeś się tego Swift
uczyć?
Ja jestem subskrybentem
Hacking with Swift Plus.
Aczkolwiek
nie nawet z konieczności
jako takiej, bo naprawdę on
nawet takie bardzo zaawansowane rzeczy
udostępnia za darmo, a Hacking with Swift Plus
to na przykład rzeczy po kraju
on tam co miesiąc streamuje jak buduje
jakąś aplikację i objaśnia jak to robi
albo tam o jakichś
takich algorytmach,
takich typowych już
strukturach danych itd.
Ale po prostu
subskrybuję, bo naprawdę
no bo
żeby wesprzeć autora. Zwaliło mnie to
z nóg po prostu. Duże rzeczy widziałem
jeśli chodzi o programowanie. Wielu
autorów naprawdę też
się postarało jeśli chodzi o inne języki
programowanie. Na przykład
kimś kto
nie jest porównywalny do pana Paula Hudson’a
ale odnośnie C Sharp’a i.NET
Framework’a to pan Tim Corey.
No ale to naprawdę
jest content
bardzo wysokiej jakości.
Ja to mogę powiedzieć, ja mam doświadczenie
w programowaniu w różnych językach.
No
wiem jak
powinno się pisać dobry kod.
No bo
no po prostu też
lata mniej lub bardziej praktycznego
doświadczenia i naprawdę mogę z czystym
sumieniem polecić
Hacking with Swift
i podpisać się pod
tym poleceniem, bo
możemy naprawdę bardzo
dużo wynieść.
Ja programowałem
wcześniej, ale
z iOS’em to właśnie zacząłem
z panem Paulem Hudsonem
i mniej więcej
na czterdziestym siódmym
dniu
tego
kursu
napisałem
dość podstawowy
acz funkcjonalny edytor
równań na iPhone’a, który miał problemy
natury takiej, że
nie przemyślałem i projekt poszedł do kosza
aczkolwiek naprawdę
jest to kurs na tyle dobrze prowadzony, że
ktoś byłby w stanie coś takiego zrobić
po mniej więcej połowie tego kursu, jeżeli
oczywiście by się do tego przyłożył.
No to rzeczywiście robi to
wrażenie, to
to trzeba przyznać.
Ok.
To w takim razie ja myślę, że
teraz jeszcze warto porozmawiać
o tym, czego też się uczyłeś
czego też
się uczyłeś przy okazji
luomo, czyli
współpraca.
Bo aplikacje możemy
pisać sami,
ale jest taki moment,
że jednak to jest
na jednego człowieka za dużo.
No tak.
Przede wszystkim
moim zdaniem, przynajmniej dla mnie
mi dużo praściej było
nauczyć się pisać kod, niż
czytać cudzy kod.
Z jakiegoś powodu, jak czytałem
coś, co napisał ktoś inny,
to wydawało mi się to bardzo
enigmatyczne i zagmatwane.
Co też
generowało pewne problemy
i to jest też taka
teraz, jakbym miał
sobie
sobie z przeszłości
mówić o tym, co zrobić,
to na pewno więcej
czytać cudzego kodu, więcej czytać
artykułów o programowaniu,
bo oczywiście praktyka to najważniejsza
rzecz, trzeba pisać,
cały czas trzeba mieć
styczność z tym kodem, ale też
więcej czytać artykułów, patrzeć jak ludzie
piszą kod, patrzeć jak ludzie
piszą źle kod, też są takie strony,
gdzie specjalnie jest coś popsute,
żebyśmy mogli,
żebyśmy mieli antyprzykłady,
też zresztą na Hacking with Swift
jest kilkanaście takich artykułów,
gdzie jest pokazane, jak czegoś
nie robić i dlaczego i jak
robić, więc
trzeba mieć tą
styczność z tym kodem, żeby
mieć taki ogląd na to, jak
różne problemy można rozwiązywać, jak
różni ludzie rozwiązują
różne problemy. To jest
taka psychologiczna,
socjologiczna, taki
psychologiczno-socjologiczny aspekt
tego wszystkiego,
a po drugiej stronie mamy aspekt
techniczny, czyli narzędzia kontroli
wersji, takie jak Git,
które pozwalają nam
współpracować z innymi
deweloperami nad
tą samą bazą kodową,
baza kodowa, czyli nic innego jak
program.
Czy Xcode ma wsparcie takie
natywne do Git, czy tam jest jakiś inny
system kontroli wersji?
Git ma wsparcie do GitHuba, możemy sobie
dodać nasze konta, możemy przeglądać
pull requesty, możemy komitować
zmiany, czyli po prostu wysyłać
zmiany do repozytorium.
Też Git to bardzo obszerny temat,
ale w gruncie rzeczy chodzi o to, że jak
chcemy coś zrobić, to robimy nową gałąź
na repozytorium, my na tej gałęzi sobie
robimy, to jest gałąź nasza,
ona nie wpływa na to, co mają inni
deweloperzy i jak jesteśmy gotowi,
to łączymy te gałęzie ze sobą
i jak wszystko dobrze pójdzie,
to te gałęzie łączą się bezkonfliktowo,
czyli jedna gałąź może
w pełni zostać połączona do drugiej, bo
się tam nic nie wyklucza
no i mamy współpracę,
można sobie w tym Git’cie tworzyć
tzw. issues, czyli
problemy, jakieś dyskutować
o tym kodzie, aczkolwiek
naszą główną platformą,
my obydwoje
jesteśmy na bardzo porównywalnym
poziomie, jeśli chodzi o programowanie
i my nie korzystaliśmy
tak bardzo z tego Git’a, tylko do wymiany
kodów, a rozmawialiśmy o tym wszystkim
na kuku zwyczajnym,
no bo
no bo jednak
aczkolwiek wiem, że ludzie, którzy się
profesjonalnie zajmują, to naprawdę korzystają z tego
Git’a, Git też ma
automatyzowane akcje, czyli
że możemy, nie wiem, automatycznie
testować ten kod, kompilować,
robić te tak zwane snapshoty i tak dalej,
to już jest poza moją
wiedzą, jakby ja
nie czuję się po prostu na siłach
o tym mówić,
ale właśnie
te systemy kontroli wersji warto
znać w jakimś podstawowym
stopniu, nawet jeżeli nie współpracujemy
z kimś,
ja wiele projektów
moich umarło
dlatego, że popełniłem jakiś błąd
i nie umiałem
potem go naprawić, nie umiałem się cofnąć,
a właśnie system kontroli wersji
rozwiązuje ten problem, bo jeżeli coś zepsujemy,
to my mamy pełną oś czasu
tego projektu, oczywiście nic się
samo nie dzieje, jeżeli tego nie
pilnujemy, no to nie mamy tej ości czasu, ale jeżeli
robimy regularnie
komity, opisujemy je,
co zmieniliśmy,
no to wówczas mamy pełną, prawną
oś czasu naszego projektu
i możemy się
cofać do
konkretnych zmian, ja na przykład
teraz parę dni temu
w Teflocentrum dodawałem
czynności voice overa, zepsułem
fragment interfejsu,
który działał wcześniej dobrze
i udało mi się dodać
te czynności koniec końców
i dzięki temu, że korzystałem z
systemu kontroli wersji, to złączyłem
to, co działało dobrze z tym, co
działało mniej dobrze i dzięki temu
powstało coś, co faktycznie
działa dobrze, a
gdybym nie korzystał z tego systemu
kontroli wersji, no to mogłoby być
tylko, no bo jednak
ciężko jest zarządzać
projektem, który tak
w przypadku Teflocentrum to jest
obecnie 84 pliki
tekstowe z kodem.
No właśnie, bo to jest
też ważne, że
o ile takie proste
aplikacje, to jest zazwyczaj
jeden plik z
naszym kodem, o tyle
coś bardziej złożonego, to już później
dzielimy na
i znowu Arku gdzieś tam z tym mikrofonem
poprawiam go właśnie
dzielimy na wiele plików
też są różne szkoły
a propos dzielenia na pliki
jedne języki programowania wymuszają
to dzielenie na pliki, inne nie
inne mają takie
dobre praktyki
kiedy to dzielić
w Swift UI to wygląda tak, że każdy element
interfejsu, który jest samodzielnym
bytem, jest w osobnym
pliku, przynajmniej ja to tak mam
to jest w
folderze z interfejsem, mam też
folder backend, w którym mam
funkcję do obsługi audio, funkcję do
renderowania HTMLa, funkcję
dołączenia się z serwerami, tyfropodcastu
i tak dalej
mam folder tests
w którym mam testy jednostkowe tej aplikacji
czyli te testy automatyczne
i to jest tak sobie dzielone po prostu
na takie kategorie
ja sobie to tak dzielę, każdy ma
podejrzewam swój styl
jak to robić
natomiast co jeżeli
Swift by na to nie pozwolił
znaczy pozwoliłby, ale byłoby z tym bardzo dużo
pracy, ale taki hipotetyczny przykład
co by się stało gdybyśmy wszystko
pisali w jednym pliku
no po pierwsze
byłoby bardzo
ciężko o tym nawigować
bo owszem można przeszukiwać
można przeszukiwać pliki
pod kątem jakiejś frazy
czy nawet wyrażeń regularnych
ale mimo wszystko jeżeli mamy coś
w jednym wielkim monolicie
to
jest bardzo ciężko
po prostu o tym zarządzać
i o ile raczej
zrozumiałem to, że tam
nie trzeba wszystkich tych
dobrych praktyk
wszystkich tych dobrych praktyk
przestrzegać na samym początku
o tyle umiejętność
mądrego dzielenia na pliki
naszej aplikacji to jest bardzo ważna umiejętność
bo po prostu tak jest nam
prościej pracować, na przykład ja mam
listę, taką specjalną
lista zasobów
która ma tam jakiś swój
wygląd, ma na główek
i ma treść, na przykład
czy to opis podcastu czy
jakiś fragment artykułu, jeżeli to jest
tyfleoświat i to jest w osobnym pliku
jest to w osobnym pliku dlatego, że używam tego
w różnych miejscach
interfejsu, bo używam tego
w zakładce nowości, jak pokazuję
najnowsze podcasty
używam tego
w wyszukiwarce
podcastów, jak
wpiszę jakąś frazę to też ta lista się pokazuje
tylko jest ona krótsza
używam tego w zakładce z artykułami
i jeżeli
dzieje się coś takiego, że widzimy, że
używamy czegoś
oj wysiada głos
jednak sporo mówienia
przepraszam za to
jeżeli widzimy, że
używamy czegoś cały czas
w różnych miejscach naszego programu
to jest bardzo dobry kandydat
do tego, żeby
wydzielić to do osobnego pliku
jeszcze jedną taką rzeczą
której warto przestrzegać
już na samym początku
naszej nauki programowania
to taka zasada
którą określa się
w żargonie DRY
czyli Don’t Repeat Yourself
czyli
musimy pisać kot w taki sposób
żeby nie było w nim
powtórzeń, tak jak w języku naturalnym
na przykład nie mówię zdania
mam kota
mój kot jest piękny
i bardzo lubię się bawić z moim kotem
bo to generuje
to zdanie jest
zrozumiałe, to zdanie jest
odczytywalne i wiadomo
o co w tym zdaniu chodzi
ale trzy razy użyłeś słowa kot
ale dokładnie i nie musiałem tego robić
mogłem użyć innych słów, które skróciłyby
ten zapis
i które sprawiłyby, że zdanie
zostanie przede wszystkim szybciej
wypowiedziane i tak samo jest tutaj
jeżeli ja na przykład
w aplikacji Tyflocentrum pisałbym
osobną funkcję do odtwarzania
Tyflopodcastu
takiego już nagranego
do odtwarzania Tyflaradia
to miałbym dwie funkcje, które w sumie
robią dokładnie to samo, a jedynym
co je wyróżnia jest to
z jakiego zasobu one odtwarzają
ja mówię o tym dlatego
że my
pisząc aplikację, pisząc
program musimy
zwracać, powinniśmy zwracać uwagę
na takie rzeczy
a jeżeli już dojdzie do takiego
powtórzenia, no to
tam kiedyś w wolnym czasie
jak już na przykład testerzy będą mieli
co testować, osiągniemy jakiś kamień milowy
i po prostu będziemy
chcieli sobie trochę posprzątać
kod, no to wtedy przysiadamy
patrzymy sobie, ja na przykład sobie wypisuję
mam taki plik w folderze z
projektem z Tyflocentrum
i tam też jest kilka takich rzeczy
które bym odkurzył, bo na przykład
ja tam popełniłem taki błąd
że zrobiłem
osobne
modele, modele czyli
to są takie
szablony, które opisują
jakieś dane. Ja zrobiłem
osobny model dla podcastu
i osobny model dla artykułu
z Tyfla Świata, potem
zobaczyłem, że w sumie
tak naprawdę jedyne co wyróżnia
Tyflo Podcast od artykułu to to, że
Tyflo Podcastu można posłuchać
i Tyflo Podcast jest
opisywany przez jakiś plik MP3, a artykuł
nie można posłuchać, więc
zapisałem sobie, żeby to
potem jakoś złączyć
w jeden model, co na przykład
sprawi, że
będzie można pokazywać zarówno podcasty
jak i artykuły na jednej liście
nowości.
I właśnie o to chodzi, że
pisząc program
my myślimy o takich rzeczach
i też nie zawsze będzie
tak, że od razu
już widzę błąd, jeszcze go nie popełnię
a już widzę, że on będzie, bo to
nie na tym polega.
I dopiero po jakimś czasie
pewne rzeczy stają się jasne.
Wraz z tym, jak nasze doświadczenie
wzrasta.
I też
ja mam taki pogląd na to, że
jak zaczynamy jakąś nową
aplikację, to zawsze
jesteśmy nowicjuszami.
Inaczej, ja jak zaczynałem
pisać Tyflo Centrum,
to musiałem
uczyć się nawigacji
po swoim umyśle po raz kolejny.
To brzmi dość abstrakcyjnie,
ale pisząc
tą aplikację Tyflo Centrum
na nowo musiałem sobie przemyśleć
jak będą wyglądały moje
dane, jak będzie wyglądał
interfejs, jak rozdzielę
ten projekt na foldery, jak będą
wyglądały modele, czy podcast
i artykuł to tak naprawdę to samo, czy
może jednak trochę co innego.
W pracy programisty
dla niektórych to może być
demotywujące,
dla niektórych nie.
Każdy
zawsze jest na początku
poniekąd, bo możemy
umieć coraz więcej, możemy umieć
pisać coraz lepszy kod,
coraz bardziej optymalny kod,
kod, który działa coraz szybciej,
sprawniej i możemy umieć robić
coraz bardziej zaawansowane rzeczy,
ale w takiej
dalekosiężnej perspektywie
my dalej
poniekąd
jesteśmy na początku jakiejś drogi.
No i też trzeba pamiętać, że
zmieniają się technologie, rzadko, który
programista ogranicza się do jednego
języka. My dziś
tak zatytułowaliśmy tę audycję
o programowaniu
na iOS, natomiast
tu bardzo… To jest przykład jak widzieliście
nawet, my omówiliśmy
bardzo dużo języków i
to też nie jest tak, wiele osób
myśli, że boże, jak ktoś zna
6-7 języków programowania
to jakiś geniusz musi być, bo nauka
jednego języka programowania zajęła
mi kilka miesięcy.
Nauka pierwszego języka programowania
może zajmować
kilka miesięcy, ale
jeżeli już mamy opanowane takie
rzeczy typu instrukcje warunkowe,
pędle zmienne, stałe, tablice
itd. są elementy,
które występują
we wszystkich
językach programowania
i to jest właśnie coś, co
sprawia, że moim zdaniem
języki programowania
są dużo
prostsze od języków
naturalnych, bo języki programowania
mają ze sobą we pozorach
bardzo, bardzo dużo cech wspólnych
i tak jak np.
tyflocentrum.
Ta aplikacja nie mogłaby wstać
w samym Swift, bo
będę musiał napisać
fragment tej aplikacji w języku
PHP, żeby użytkownicy
mieli bardzo fajne powiadomienia
push o audycjach.
I nie można się
ograniczać do jednego języka, jednej
technologii, bo zawsze
będziemy mieli jakiś
niekompletny
obraz,
niekompletną wizję, co też może
demotywować, jeżeli umiemy zrobić np.
90% tego, co sobie założyliśmy,
a tych 10% nie umiemy, bo
aczkolwiek można
napisać w Swiftcie
programy serwerowe,
tylko
niestety to jest to, co mówiłem wcześniej
o Pure Basic’u,
że Swift
na serwerze to jest coś bardzo nowego
i jest mało osób,
które się tym zajmuje.
Jeżeli ja
nie znałbym w ogóle
Swift’a
i chciałbym zacząć
pisać programy serwerowe
w Swift’cie, a nie w PHP, bo Swift jest
fajniejszy np.
to poległbym, bo nie miałbym
od kogo
prosić o takie w miarę podstawowe
rzeczy, albo jakieś nawet
mniej podstawowe
rzeczy, które są
typowe dla mojego konkretnego
problemu.
A teraz, gdy ja już znam Swift’a,
to mam pewne narzędzia
w swoim arsenale, które
pozwalają mi sobie radzić z większą liczbą
problemów samemu, co nie
znaczy,
że
też nie pytam o pomoc, bo
pytam. A propos tego, gdzie
pytać o pomoc,
jeżeli chodzi o Swift’a,
to też pasowałoby
o tym powiedzieć,
bo tak, niestety też
głównie są to źródła
anglojęzyczne, aczkolwiek tutaj
mogę polecić forum
4programmers.net
4programmers.net
Bardzo znane
forum dla programistów polskich.
Jedni to forum
wspominają dobrze, inni
trochę gorzej.
Zależy na kogo się trafi, jak wszędzie w
internecie.
Ale można tam pytać w języku polskim.
Jest subreddit
w serwisie reddit.r
slash swift.
Naprawdę tam są
pasjonaci, widać programowania
i tam jak się pyta i jak
się okaże jakąś inicjatywę,
że się szukało, no to ludzie
odpowiadają. Jest też
subreddit r slash ios
programming.
To jest subreddit
nie tylko o Swift’cie, ale też
i o UI Kit’cie
i nawet o Objective-C, bo
dalej w tym języku też trochę się pisze,
więc to jest taki bardziej ogólny
subreddit, ale tam też można
pisać. Jest
forum
hacking with Swift oczywiście,
gdzie można też zadawać
pytania.
No i słynny stack overflow.
Ale to
zostawiłem na koniec. Ja
na stack overflow nie odważyłem się nigdy
zadać pytania, tam są drakońskie
zasady, jeśli chodzi o zadawanie pytań,
ale na stack overflow
na większość
problemów można znaleźć rozwiązanie.
To prawda. Ja zastanawiam się
ilu u programistów
nagle zaczęłoby
mieć poważne problemy, gdyby tak
stack overflow padło.
Oj, był o tym bardzo
duży wątek na reddicie i
wiele osób takich znanych
jest taki pan,
to jest
jeden z byłych
pracowników Microsoftu, który pracował
nad językiem C Sharp
i dla mnie to było pan John Skitter
i dla mnie to też było takie
inspirujące. On mówił, że
stworzyłem język programowania, ale
gdyby nie stack overflow,
to prawdopodobnie nie umiałbym zrobić
w języku, który sam stworzyłem mniej więcej
60% rzeczy. No i to jest
coś, co bardzo dobrze
podsumowuje programowanie. Bo tam
bardzo często wygląda to tak, że wpisujemy
w Google jakieś
pytanie. Ja to bardziej znam od tej strony
takiej administracyjnej
na przykład, czy
jakiejś programowej, że coś
się wysypało gdzieś
i dostaję jakiś komunikat i
w sumie co ja mam z tym zrobić?
Jak wpisujemy
gdzieś tam w Google
takie zapytanie,
kawałek tego komunikatu o błędzie
na przykład, to jednym z pierwszych wyników,
który nam się pojawia, to jest stack overflow
i wątek
na forum, bo tam już ktoś
taki problem miał i jeszcze mało
tego, tam są odpowiedzi,
które mają
ilość takich
punktów, bo tam można
dodawać
swoje gwiazdki jakieś, czy
plusiki do tych odpowiedzi
i im więcej ma
pozytywnych opinii dana odpowiedź,
to tym większe prawdopodobieństwo, że
ona po prostu działa. I z reguły jest
tak, że ta pierwsza odpowiedź, która
rozwiązała czyjś problem, rozwiązuje też i mój.
Dokładnie, ja też
się pod tym podpisuję,
taka porada, jeżeli chcecie szukać
stack overflow,
to w Google wpisujecie sobie
site site
dwukropek stackoverflow.com
spacja, wasze zapytanie
i wówczas macie dużo
mniej wyników, macie wyniki tylko
ze stack overflow.
Wielu osobom wiem, że to pomaga,
więc o tym
mówię.
Oprogramowanie to jest temat rzeka.
Jak chyba widzicie, jestem wielkim pasjonatą
i mógłbym o tym mówić
bardzo długo.
Mówimy o tym już trzy godziny, więc myślę,
że powoli będziemy
zbliżać się do końca
naszego dzisiejszego spotkania,
ale jeżeli zainteresował was
ten temat, jeżeli chcielibyście jeszcze posłuchać
o programowaniu, to
czekamy na wasze wypowiedzi w komentarzach.
Zapraszam do dyskusji w komentarzach,
czy próbowaliście na przykład
chociażby z robieniem skryptów
w Baczu, albo
chociaż nie, bo Grzegorz mówił,
że będzie słuchał tej audycji. Czy robiliście
kiedyś gry w gier, tekście?
Jeżeli tak, to naprawdę
proszę o komentarz.
Albo w BGT, to taki też język
do tworzenia gier.
Tak, i to niestety też taki
język do tworzenia gier,
który trochę się ciągnie dalej
za audiogrami. To jest bardziej
temat spogranicza programowania
gier.
No, ale tam też było coś takiego,
czy tworzyliście, w czym
tworzyliście i co tworzyliście
i co sądzicie o tej audycji,
bo to jest taki eksperymentalny
format, ja raczej
w tu su podcastie bardziej pokazuję niż
gadam, a dzisiaj gadałem.
Ale może fajnie czasem pogadać
i może właśnie
takie tematy
was gdzieś zainspirują, jeżeli
chcecie się podzielić swoimi
jakimiś programami
na przykład, jeżeli swoim
jakimś dorobkiem, to
też śmiało oczywiście podrzucajcie
linki chociażby
do githuba na przykład, jeżeli
macie coś tam wystawione.
Bo może akurat, tak Grzegorz
mówił o tym, że próbował
zainspirować
użytkowników
niewidomych LTN-a
programowaniem.
I to jest moim zdaniem bardzo
dobra inicjatywa, natomiast
zastanawiam się czy
to, że ona tak trochę
nie wyszła poza LTN-a
to
nie spowodowało właśnie tego, że
ona po prostu
nie uzyskała aż takiego
zainteresowania.
Tam Grzegorz i Dawid
pisali artykuły i
moim zdaniem te artykuły
na blogu, on się
bodajże nazywał, Zaprogramujmy
LTN-a, to to były bardzo fajne
artykuły, bardzo się to fajnie czytało.
Przede wszystkim były praktyczne.
To o czym ja zawsze mówię, że
kursy programowania mają taki problem, że
piszemy program wyliczający
n plus 1 liczb
z ciągów i ponad czjego.
To jest prawda. Z reguły
się właśnie operuje bardzo
często na tych działaniach matematycznych
i jeżeli ma być ok, program,
który ma dodać do dwóch
to super, natomiast
jakieś już bardziej zaawansowane rzeczy, to potem
nam się to kojarzy, że to tylko
ta matematyka, to to programowanie to tylko
do tej matematyki i ta matematyka wszędzie
tam musi być.
No i nie musi być, bo
mówię, jeżeli uda mi się, jeżeli
typocentrum wyląduje w AppStore
i Michał się zgodzi, to zrobię
osobną audycję w otworzeniu tej aplikacji,
bo to też jest ciekawe
z wielu względów, na przykład właśnie
ze względu na to,
co tak naprawdę było mi potrzebne
i czego się musiałem nauczyć, bo
na przykład nigdy nie myślałem,
że do stworzenia
tyflocentrum będę
potrzebował wiedzy
o tym, jak WordPress
komunikuje się z bazami danych na przykład,
a potrzebowałem tej
wiedzy, ale to na kiedy indziej.
Dokładnie i
myślę, że tym
możemy zakończyć to nasze
dzisiejsze spotkanie.
Ja myślę, że spokojnie jeszcze moglibyśmy
parę ładnych godzin tu porozmawiać,
aczkolwiek myślę, że
zostawmy sobie coś jeszcze na przyszłość.
Dajcie znać, czy temat Was zainteresował,
czy próbowaliście, czy
chcecie popróbować
swoich sił w programowaniu,
czy to w Swift, czyli
w systemie
iOS, czy na przykład w jakimś
innym języku programowania.
Tylko w iOSie, bo Swift to
wszystkie platformy Apple’a
i macOS, i watchOS,
i tvOS,
i iPadOS, który jest w sumie iOSem
podmienioną nazwą, tak że naprawdę
możliwości jest sporo. Ja mówiłem
to na przykładzie iOSa, bo
akurat w tym teraz coś robię
i w tym robię coś, co mam nadzieję, że się
spodoba Wam.
Ale większość
tego, co powiedziałem, tyczy się
innych języków. To jest piękne
programowanie, że to jest taka wiedza
przenośna, że my możemy sobie to
przenosić między platformami.
Na przykład to, co ja powiedziałam
o Swift, nie wiem, o tym rozdzielaniu
na pliki, to to samo tyczy się
flatera, czy nie wiem, WPF, a jeżeli
piszemy coś na Windowsa.
I właśnie o to w tym chodzi
i mam nadzieję, że
choć trochę Was zainteresowaliśmy
tematem i zapraszam do
dzielenia się jakimiś uwagami i spostrzeżeniami.
Dziękuję Ci, Arku, bardzo
za udział w dzisiejszej audycji.
Arkadiusz Świętnicki opowiadał
o programowaniu.
Myślę, że do tematu
jeszcze kiedyś wrócimy. Dzięki
raz jeszcze.
Ja także dziękuję za uwagę.
Michał Dziwisz, kłaniam się do usłyszenia
do następnego spotkania na antenie
Tyflo Radio.
Był to Tyflo Podcast.
Pierwszy polski podcast dla
niewidomych i słabowidzących.
Program współfinansowany ze środków
Państwowego Funduszu Rehabilitacji
Osób Niepełnosprawnych.