-
130. Data: 2021-09-01 16:14:33
Temat: Re: rzadki bład w programie w C++
Od: Maciek Godek <g...@g...com>
środa, 1 września 2021 o 15:23:00 UTC+2 Mateusz Viste napisał(a):
> Nic się zupełnie nie znam na pisaniu pod androida, kojarzę luźno że to
> chyba Java (albo kiedyś tak było) i na tym kończy się moja wiedza.
Tak. Java, ale nie odpalana na JVM, tylko w autorskiej googlowskiej maszynie
wirtualnej (Dalvik albo ART, w zależności od wersji)
> Nie ma na to jakiegoś emulatora, który pozwalałby odpalać pisane
> programy na PC?
Jest.
Domyślny workflow pisania apek na Androida to "Android Studio", darmowe IDE na bazie
IntelliJ.
Na moim kompie było strasznie zasobożerne - przy 2GB RAM w ogóle nie dało się używać,
więc dokupiłem do 4GB, i się dało "ledwo ledwo".
Pewnie gdybym miał taką wiedzę, jaką mam teraz, to bym mógł budować apki bezpośrednio
z terminala, ale to też by się wiązało z dodatkowymi upierdliwościami (choćby
konieczność kopiowania pliku na telefon)
Natomiast co do emulatora, to Android Studio dostarcza takie coś, tyle że z mojego
doświadczenia symulowanie 10 palców za pomocą myszy jest raczej niedoskonałe
> Alternatywnie - może po ssh zalogować się z peceta na telefon aby pisać
> na ekranie (i klawiaturze) PC, ale zapisując wszystko bezpośrednio na
> telefonie?
Tak też na pewno by się dało.
Tylko kwestia taka, że telefon mieści się w kieszeni albo w jednej ręce, i mam go
praktycznie zawsze ze sobą. Laptopa mam ze sobą dużo rzadziej, i nie mieści się
w jednej ręce. Ale nawet jak testowałem taki workflow, to była pewna upierdliwość
z przeskakiwaniem między urządzeniami. Jak mam jedno urządzenie, to tej
upierdliwości nie ma.
> Nie chcę oczywiście szukać Ci na siłę rozwiązań, ot dzielę się myślami
> które mi przez głowę przechodzą, ale z pewnością masz to wszystko już
> dawno przećwiczone.
Tak. Sądzę, że jedną z przyczyn, dla których większość apek w Appstorze jest taka
beznadziejna, to właśnie ów workflow, który oddala programistę od uzyskiwanego przez
niego efektu.
-
133. Data: 2021-09-01 20:13:14
Temat: Re: rzadki bład w programie w C++
Od: Maciej Sobczak <s...@g...com>
> Ale ja na codzień właśnie na połowie ekranu pracuję
Przypomniał mi się stary dowcip o inżynierze, który zgłosił wniosek
racjonalizatorski, że skoro nigdy nie zużywamy rysika w ołówku do końca, to można
zaoszczędzić wpychając do ołówków krótsze rysiki. Nagroda.
Po jakimś czasie zauważył, że skoro i tak rysik jest krótszy, to nie ma po co
marnować drewna i robić takich długich ołówków. Znowu nagroda.
> > Ale na biurku to zwykle widuję u ludzi po dwa monitory +24".
> Też widuję. I różne inne rzeczy widuję "u ludzi", ale co to za
> argument? Ludzie to nie ja.
Chodziło mi o to, że to jest trochę taki "industry standard". Nawet w tym sensie, że
jak inżynier dostał niedawno nową pracę, zdalnie, to pracodawca po prostu przysłał
inżynierowi kurierem na chatę 2x takie monitory w ogóle nawet nie pytając, czy chce
je mieć. No i stoją w pudłach, bo akurat nie chciał.
Nie dziwi mnie to, bo duże firmy nie kupują sprzętu pojedynczo, tylko hurtem. I wtedy
24" jest takim samym "industry standard" jak format A4 na papier w drukarce.
Może nawet jest w tym jakiś zbieg okoliczności, bo tak się śmiesznie składa, że na
monitorze 24" można wyświetlić dokument przeznaczony do druku A4 w skali 1:1. I jest
to najmniejszy rozmiar monitora, który na to pozwala. Przyłóż kartkę, to zobaczysz.
Nie, nie upieram się, że wyświetlanie czegokolwiek w skali 1:1 ma jakąkolwiek wartość
dodaną. Ale miało być WYSIWYG, to proszę bardzo.
> No więc mi właśnie o to całe "BHP" od początku chodzi. Jakieś normy w
> tym temacie? Badania?
https://www.google.com/search?q=recommended+monitor+
size
U mnie wylatuje systematycznie +24".
> Przepisy BHP?
Nie sądzę, bo są różne ekrany. Np. w kasie sklepowej też jest ekran.
Ale monitor 24", oddalony na odległość wyciągniętej ręki, całkiem zgrabnie wypełnia
pole widzenia bez zmuszania do niepotrzebnych napięć mięśni. Mi to wszystko razem
akurat pasuje.
> Tego jestem ciekaw - bo reszta to
> zwyczajne przekomarzanie się o to kto jakie ma przyzwyczajenia
No to nie przekomarzajmy się na ten temat. Bo zaraz będzie o krzesłach i innych
meblach.
--
Maciej Sobczak * http://www.inspirel.com
-
132. Data: 2021-09-01 20:13:14
Temat: Re: rzadki bład w programie w C++
Od: Maciej Sobczak <s...@g...com>
> Ale ja na codzień właśnie na połowie ekranu pracuję
Przypomniał mi się stary dowcip o inżynierze, który zgłosił wniosek
racjonalizatorski, że skoro nigdy nie zużywamy rysika w ołówku do końca, to można
zaoszczędzić wpychając do ołówków krótsze rysiki. Nagroda.
Po jakimś czasie zauważył, że skoro i tak rysik jest krótszy, to nie ma po co
marnować drewna i robić takich długich ołówków. Znowu nagroda.
> > Ale na biurku to zwykle widuję u ludzi po dwa monitory +24".
> Też widuję. I różne inne rzeczy widuję "u ludzi", ale co to za
> argument? Ludzie to nie ja.
Chodziło mi o to, że to jest trochę taki "industry standard". Nawet w tym sensie, że
jak inżynier dostał niedawno nową pracę, zdalnie, to pracodawca po prostu przysłał
inżynierowi kurierem na chatę 2x takie monitory w ogóle nawet nie pytając, czy chce
je mieć. No i stoją w pudłach, bo akurat nie chciał.
Nie dziwi mnie to, bo duże firmy nie kupują sprzętu pojedynczo, tylko hurtem. I wtedy
24" jest takim samym "industry standard" jak format A4 na papier w drukarce.
Może nawet jest w tym jakiś zbieg okoliczności, bo tak się śmiesznie składa, że na
monitorze 24" można wyświetlić dokument przeznaczony do druku A4 w skali 1:1. I jest
to najmniejszy rozmiar monitora, który na to pozwala. Przyłóż kartkę, to zobaczysz.
Nie, nie upieram się, że wyświetlanie czegokolwiek w skali 1:1 ma jakąkolwiek wartość
dodaną. Ale miało być WYSIWYG, to proszę bardzo.
> No więc mi właśnie o to całe "BHP" od początku chodzi. Jakieś normy w
> tym temacie? Badania?
https://www.google.com/search?q=recommended+monitor+
size
U mnie wylatuje systematycznie +24".
> Przepisy BHP?
Nie sądzę, bo są różne ekrany. Np. w kasie sklepowej też jest ekran.
Ale monitor 24", oddalony na odległość wyciągniętej ręki, całkiem zgrabnie wypełnia
pole widzenia bez zmuszania do niepotrzebnych napięć mięśni. Mi to wszystko razem
akurat pasuje.
> Tego jestem ciekaw - bo reszta to
> zwyczajne przekomarzanie się o to kto jakie ma przyzwyczajenia
No to nie przekomarzajmy się na ten temat. Bo zaraz będzie o krzesłach i innych
meblach.
--
Maciej Sobczak * http://www.inspirel.com
-
135. Data: 2021-09-02 09:30:41
Temat: Re: rzadki bład w programie w C++
Od: Mateusz Viste <m...@x...invalid>
2021-09-01 o 11:13 -0700, Maciej Sobczak napisał:
> I wtedy 24" jest takim samym "industry standard" jak format A4 na
> papier w drukarce. Może nawet jest w tym jakiś zbieg okoliczności, bo
> tak się śmiesznie składa, że na monitorze 24" można wyświetlić
> dokument przeznaczony do druku A4 w skali 1:1. I jest to najmniejszy
> rozmiar monitora, który na to pozwala.
Fajnie, tylko że to nieprawda jest. Do wyświetlania dokumentów A4 w
skali 1:1 wystarczy pionowo postawiony ekran 17". Takie ekrany
widywałem zresztą u tzw. "technical writerów", kiedy - dawno temu -
zdarzyło mi się pracować w biurze. Tzn. były to normalne ekrany 17",
ale z funkcją ustawienia pionowego.
Źródłem problemu jest format dzisiejszych ekranów. 16:9 to fajna rzecz
do kina czy jakichś gier, bo zgodniejsze z naturalnym polem widzenia
człowieka, lecz do pisania podłużnych dokumentów nadaje się słabo. W
efekcie płacę za duży ekran 15.6" w laptopie, ale pożytecznie
wykorzystuję z niego tylko obszar ok. 10".
> Mi to wszystko razem akurat pasuje.
I chyba tylko taki można wyciągnąć z tego wniosek.
> No to nie przekomarzajmy się na ten temat. Bo zaraz będzie o
> krzesłach i innych meblach.
Od krzesła preferuję fotel bujany przy kominku. Ale znów - co kto lubi.
Mateusz
-
134. Data: 2021-09-02 09:30:41
Temat: Re: rzadki bład w programie w C++
Od: Mateusz Viste <m...@x...invalid>
2021-09-01 o 11:13 -0700, Maciej Sobczak napisał:
> I wtedy 24" jest takim samym "industry standard" jak format A4 na
> papier w drukarce. Może nawet jest w tym jakiś zbieg okoliczności, bo
> tak się śmiesznie składa, że na monitorze 24" można wyświetlić
> dokument przeznaczony do druku A4 w skali 1:1. I jest to najmniejszy
> rozmiar monitora, który na to pozwala.
Fajnie, tylko że to nieprawda jest. Do wyświetlania dokumentów A4 w
skali 1:1 wystarczy pionowo postawiony ekran 17". Takie ekrany
widywałem zresztą u tzw. "technical writerów", kiedy - dawno temu -
zdarzyło mi się pracować w biurze. Tzn. były to normalne ekrany 17",
ale z funkcją ustawienia pionowego.
Źródłem problemu jest format dzisiejszych ekranów. 16:9 to fajna rzecz
do kina czy jakichś gier, bo zgodniejsze z naturalnym polem widzenia
człowieka, lecz do pisania podłużnych dokumentów nadaje się słabo. W
efekcie płacę za duży ekran 15.6" w laptopie, ale pożytecznie
wykorzystuję z niego tylko obszar ok. 10".
> Mi to wszystko razem akurat pasuje.
I chyba tylko taki można wyciągnąć z tego wniosek.
> No to nie przekomarzajmy się na ten temat. Bo zaraz będzie o
> krzesłach i innych meblach.
Od krzesła preferuję fotel bujany przy kominku. Ale znów - co kto lubi.
Mateusz
-
136. Data: 2021-09-02 20:57:34
Temat: Re: rzadki bład w programie w C++
Od: Maciej Sobczak <s...@g...com>
> Fajnie, tylko że to nieprawda jest. Do wyświetlania dokumentów A4 w
> skali 1:1 wystarczy pionowo postawiony ekran 17".
Cały dzień wisiało mi nad głową, że ktoś to napisze...
Ale na pionowym ekranie ciulowo się ogląda filmy.
Tak, wiem, że najwyższym osiągnięciem w historii kinematografii są pionowe filmiki z
TikToka, ale wciąż...
No i to nadal nieprawda jest. Bo przecież można też robić poziome dokumenty A4.
> Źródłem problemu jest format dzisiejszych ekranów. 16:9 to fajna rzecz
> do kina czy jakichś gier, bo zgodniejsze z naturalnym polem widzenia
> człowieka,
No wreszcie: *naturalnym polem widzenia*. I to wyczerpuje temat monitorów.
--
Maciej Sobczak * http://www.inspirel.com
-
137. Data: 2021-09-03 09:18:09
Temat: Re: rzadki bład w programie w C++
Od: Mateusz Viste <m...@x...invalid>
2021-09-02 o 11:57 -0700, Maciej Sobczak napisał:
> Ale na pionowym ekranie ciulowo się ogląda filmy.
A ja, durny, myślałem że my tu sobie o programowaniu snujemy. :)
> No wreszcie: *naturalnym polem widzenia*. I to wyczerpuje temat
> monitorów.
Wniosek z tego można chyba wyciągnąć taki, że to, co robimy
(programowanie, albo szerzej - tworzenie pionowych dokumentów) jest
wbrew naszej naturze. I jak tu żyć?
Mateusz
-
138. Data: 2021-09-03 16:40:59
Temat: Re: rzadki bład w programie w C++
Od: a...@h...invalid (Arnold Ziffel)
Mateusz Viste <m...@x...invalid> wrote:
>> Pisywałem programiki nawet w mcedit.
>
> mc czy msedit? Bo ten drugi to niezły kawałek softu.
mc, edytor z Midnight Commandera. Choć jak wpisuję w Google, to wyskakuje
głównie edytor poziomów (?) do MineCrafta.
> W którejś wersji MS-DOS (6.0? nie mam pewności) msedit był zintegrowany
> z IDE interpretera QBASIC.
Na pewno był w 6.22. Tak naprawdę edit.com uruchamiał qbasic.exe z jakąś
opcją.
--
Trzy lwy spotkały się na pustyni. Pierwszy jęcząc mówi:
- Zjadłem Amerykanina z wrzodem żołądka i od wczoraj jestem chory.
Drugi odzywa się:
- Trzy dni temu zjadłem Polaka i do dziś meczy mnie kac.
Natomiast trzeci:
- A ja zjadłem Rosjanina i od tygodnia wymiotuje medalami.
-
139. Data: 2021-09-03 20:21:20
Temat: Re: rzadki bład w programie w C++
Od: Maciej Sobczak <s...@g...com>
> Wniosek z tego można chyba wyciągnąć taki, że to, co robimy
> (programowanie, albo szerzej - tworzenie pionowych dokumentów) jest
> wbrew naszej naturze. I jak tu żyć?
To zależy. To, że program "wykonuje się" z góry na dół to tylko jedna z możliwych
konwencji. Dlaczego stała się popularna? No nie wiem, bo np. dawno temu drukowano
programy na papierze? I to jeszcze takim składanym, na krótszym boku, z dziurkowanym
marginesem wzdłuż całej paczki?
Program dla szkolnej maszyny Turinga to cienka długa taśma. Może być poziomo. Albo na
rolce.
Ale już program zapisany jako model w jakiejś graficznej formie bardzo naturalnie
wygląda od lewej (wejścia) do prawej (wyjścia). To jest też popularna konwencja w
schematach elektronicznych. Czy taki model będzie bardziej pionowy, czy poziomy,
zależy od wielu czynników, ale zdecydowanie to, co mamy teraz z kodem źródłowym to
chwilowa anomalia a nie ponadczasowy pewnik.
Albo wyobraź sobie, że plik źródłowy nie leci ciurkiem od góry do dołu, funkcja po
funkcji, tylko np. ma osobne kolumny. I każdą funkcję w osobnym pliku (to jest nawet
teraz tu i ówdzie obowiązującym standardem kodowania). Niech będzie, że tekstowe, ale
w kilku kolumnach. Np. w każdej kolumnie osobno: parametry, pre-conditions, zmienne
lokalne, reguły przetwarzania, post-conditions. Ładnie by to wyglądało.
To, że piszemy kod źródłowy jak by to był papier toaletowy to tylko nasza wina. Nie
jest to w żadnym razie jakaś inherentna cecha programowania w ogóle.
--
Maciej Sobczak * http://www.inspirel.com
-
140. Data: 2021-09-03 21:45:35
Temat: Re: rzadki bład w programie w C++
Od: Maciek Godek <g...@g...com>
piątek, 3 września 2021 o 20:21:21 UTC+2 Maciej Sobczak napisał(a):
> > Wniosek z tego można chyba wyciągnąć taki, że to, co robimy
> > (programowanie, albo szerzej - tworzenie pionowych dokumentów) jest
> > wbrew naszej naturze. I jak tu żyć?
> To zależy. To, że program "wykonuje się" z góry na dół to tylko jedna z możliwych
konwencji. Dlaczego stała się popularna? No nie wiem, bo np. dawno temu drukowano
programy na papierze? I to jeszcze takim składanym, na krótszym boku, z dziurkowanym
marginesem wzdłuż całej paczki?
W Europejskiej kulturze kierunek tekstu to jest "od lewej do prawej, od góry do
dołu".
Są kultury, w których ten kierunek poziomy jest odwrócony, tzn. czyta się "od prawej
do lewej, od góry do dołu".
Czasem też w kulturach azjatyckich można się spotkać z taką inwersją, że najpierw
czyta się w pionie, a potem w poziomie, ale chyba zawsze jest "z góry na dół".
Może ma to związek z grawitacją, i z tym, że jesteśmy uczeni, że rzeczy "same z
siebie" raczej ciągnie w dół, niż do góry?
> Program dla szkolnej maszyny Turinga to cienka długa taśma. Może być poziomo. Albo
na rolce.
> Ale już program zapisany jako model w jakiejś graficznej formie bardzo naturalnie
wygląda od lewej (wejścia) do prawej (wyjścia). To jest też popularna konwencja w
schematach elektronicznych. Czy taki model będzie bardziej pionowy, czy poziomy,
zależy od wielu czynników, ale zdecydowanie to, co mamy teraz z kodem źródłowym to
chwilowa anomalia a nie ponadczasowy pewnik.
Stosunkowo niedawno natrafiłem na tę prezentację, przedstawiającą środowisko
programistyczne jako "pochodnię w jaskini", i proponujące dość ciekawą alternatywę:
https://www.youtube.com/watch?v=Ps3mBPcjySE
> Albo wyobraź sobie, że plik źródłowy nie leci ciurkiem od góry do dołu, funkcja po
funkcji, tylko np. ma osobne kolumny. I każdą funkcję w osobnym pliku (to jest nawet
teraz tu i ówdzie obowiązującym standardem kodowania).
Albo że nie trzymasz programu w ogóle w plikach, tylko to są obiekty w pamięci, które
ewentualnie możesz na wiele sposobów zrzutować na system plików. Hmm, brzmi jak
Smalltalk albo Interlisp, albo "programowanie intencjonalne" :)
> Niech będzie, że tekstowe, ale w kilku kolumnach. Np. w każdej kolumnie osobno:
parametry, pre-conditions, zmienne lokalne, reguły przetwarzania, post-conditions.
Ładnie by to wyglądało.
Nieco dawniej natrafiłem na tę "rodzinę prezentacji", skupiającą się na typografii
kodu źródłowego (jak by powiedziała Debbie Reynolds, "if you've seen one, you've seen
them all")
https://hilton.org.uk/presentations/beautiful-code
Ja sam nie jestem do końca przekonany. Moim zdaniem programy powinny wyglądać jak
instrukcje montażu mebli z Ikei.
> To, że piszemy kod źródłowy jak by to był papier toaletowy to tylko nasza wina. Nie
jest to w żadnym razie jakaś inherentna cecha programowania w ogóle.
Nie wiem, czy jak papier toaletowy.
Większość środowisk "hipertekstualizuje" programy w tym sensie, że można np. kliknąć
na symbol, żeby przejść do jego definicji.
Nie spotkałem się z taką możliwością u swojego papieru toaletowego.
Ale faktycznie, "programowanie w ogóle" nie ma zbyt wielu silnie określonych cech.
Większość z nich to raczej nawyki naszych umysłów.