wtorek, 19 lipca 2022 o 14:49:23 UTC+2 Mateusz Viste napisał(a):
> 2022-07-19 o 00:40 -0700, Dawid Rutkowski napisał:
> > A na serio wdrażam się do git (w wydaniu bitbucket) - "intuicyjne" to
> > nie jest, ale jak zobaczyłem w wiki, że napisał to w dwa dni/miesiąc
> > sam Linus Torvalds, to kredyt zaufania urósł niebotycznie.
> Tylko po co? Tzn. jeśli zarządzasz lub bierzesz udział w projekcie z
> setkami rozproszonych programistów... no to może mieć jakiś sens. W
> przeciwnym razie svn jest dużo trafniejszą opcją, bo w pełni
> scentralizowaną i łatwiejszą w codziennej obsłudze.

Klient ma i wymaga.
W skrócie firma oferuje "chmurowy" system czujników.
Nie wiem dokładnie, jak to sprzedają/fakturują, ale w każdym razie u klienta
umieszcza
się tylko czujniki (na ATmega) oraz "gatewaye" - bramki pomiędzy radiową siecią
czujników (xbee albo lora) a "internetem" - a wszystkie dane idą do serwerów firmy,
tam są przetwarzane i udostępniane przez przeglądarkę - nie ma czegoś takiego jak
"serwer u klienta".

No i używają gita - nie wiem, dlaczego git, a nie svn - i twierdzą, że cały system
chmurowy pięknie
tego używa - ale dla "projektów w C" - czy oprogramowania ATmeg w czujnikach - jakoś
nie daje rady się tego wdrożyć.
I rzeczywiście - póki co dla każdego z tych projektów jest tam tylko repozytorium
plików,
które można sobie pobrać i na lokalnym dysku rozpakować, żeby otworzyć w microchip
studio i skompilować.
Jak zaczęliśmy to oglądać to nawet udało się utworzyć branch - ale nie wiedzieliśmy,
w co kliknąć,
żeby w tym branchu podmienić pliki.
No bo chyba nie trzeba używać tylko wbudowanego w bitbucket edytora?
Wczoraj mieli u klienta pokazać koledze, jak to się robi.
Ale do takich cudów jak merge gałęzi to pewnie jeszcze daleko, nie wyobrażam sobie,
że to może dobrze działać,
ale może sam sobie życie utrudniam.
I zastanawiam się też, jak wyglądają pliki wynikowe takiego merge i jak się potem z
nimi pracuje?

Np. w takiej sytuacji - jest jakieś urządzenie produkowane i sprzedawane w jakimś tam
tempie,
na to tempo są robione zapasy magazynowe.
I nagle się okazuje, że przychodzi jakieś wielkie zamówienie.
Oczywiście sytuacja dodatkowa taka jak teraz - okazuje się, że producent używanego
dalmierza
nagle wprowadza nowy model, inaczej obsługiwany, nie można dokupić chipów
inklinometru (cokolwiek by to było;)
ale na szczęście jest jakiś inny - no i żeby było jeszcze ciekawiej, brakuje
mikrokontrolerów
dajmy na to to ATmega324P (i nie ma też innych ATmegaxx4 - no, może są ATmega164P,
ale programu nie zmniejszysz), ale można kupić ATmega3209, bo microchip ma taki
kaprys.
A wielkie zamówienie oczywiście musi być "na teraz".
No to zaczynasz produkcję z tego, co w magazynie tam jeszcze masz,
ale na hurra trzech programistów (bo szybko musi być) bierze się za robotę - jeden
opanowuje nowy dalmierz,
drugi inklinometr, a trzeci przerabia wszystko specyficznie dla ATmega324P na
ATmega3209 (mogłem
dla utrudnienia kazać zamienić ATmega324P na jakiegoś STMa, bo ATmeg nie ma w ogóle
;).
W miedzyczasie jakoś trzeba sobie testować to, co się pisze - a płytki tylko w dwóch
(ATmega324P, dalmierz A,
inklinometr A i ATmega3209, dalmierz B, inklinometr B) a nie w 8 wersjach.
Pomoże coś tutaj programowanie strukturalne - wróć - VCS - czy jednak potrzebny jest
talent?

Takie problemy też miałem, jak sobie założyłem, że program dla uC w unifonach do
systemu domofonowego będzie jeden,
niezależnie od tego, czy będzie to unifon ze słuchawką czy głośnomówiący oraz
niezależnie od tego,
z jakim systemem domofonowym będzie współpracował.
Problemy oczywiście wtedy, gdy po dłuższym czasie się okazuje, że pojawia się pomysł
na nową funkcję,
która ma być dodana do dawno wersji sprzętu, dla której dawno nie zmieniano programu
- albo,
co jeszcze lepsze, niemożliwa do zintegrowania z inną funkcją - albo też trzeba tą
zmianę zrobić
na działającym już od długiego czasu bezawaryjnie systemie (bo to jest problem, jak
coś działa,
a potem nagle zonk, to jest 100 razy głośniej niż jak ludzie są przyzwyczajeni, że
nie działa ;)
Dobrze, jeśli choć możesz dostać hexa, którymi programowano urządzenia na ten obiekt
- i potem
szukaj wersji plików, z których tego hexa skompilowano.
Albo najbliższych - a potem szukaj w hexie różnic i wymyślaj, co zmienić w źródle,
żeby tak samo się
kompilowało.

I jeszcze jedno.
Jest sobie SVN, będący podobno ulepszonym CVS, który był RCSem rozszerzonym o
projekty (i dlatego pewnie
nie był atomowy) - i jest git - no i jeszcze kilka innych systemów.
No ale są przynajmniej dwa. Dlaczego?
Czy jak Linux pisał gita to jeszcze nie było SVNu (bo jednym z założeń gita było -
rób odwrotnie jak w CVS)?
A potem git okazał się zbyt skomplikowany dla rzeczy dużo prostszych niż kernel
Linuxa - który i tak jedzie
na #ifdefach, bo inaczej i tak się nie da?

W takim razie czy SVN nie ma gdzieś szklanego sufitu, przy którym przestaje się
skalować?
Jak np. podobno (tfu) mssql który działa do 100k rekordów a potem się zatyka?
Ja z bazy (pgsql) usuwam co kilka miesięcy kilka milionów rekordów (a z drugiej
tabeli
kilkanaście - 8 razy więcej - bo ktoś przeklęty chyba się w głowę uderzył i wymyślił,
że jeśli w komunikacie, oprócz innych pól, jest 8 odchyłek od rozkładu jazdy,
to będzie "postaciowo-normalnie", że dla tych odchyłek zrobi osobną tabelę,
w której będzie wpisywał identyfikator komunikatu - spory string, numer odchyłki -
int,
oraz samą odchyłkę - bajt...).
Troszkę to trwa, na szczęście udało się wyszarpać opcję, aby komunikaty nie były
wpisywane
do tych tabel - więc nie ma konfliktu między delete+vacuum+reindex a insertami
i system może sobie na bieżąco działać.
Ostatnio wziąłem się za inną tabelę, nieruszaną od 2015, bo miała już 30GB - a index
drugie 30GB - tylko
że tu niestety nie ma takiej fajnej opcji - więc delete poszło, ale jak puściłem
vacuum,
to po pół godziny zadzwonili, że system nie działa ;>
A że jest praktycznie bezawaryjny (taaa, chyba że mam urlop - to najpierw podłączą
kamery jakieś i dadzą jednej z nich IP twojego serwera - całe szczęście, że udało się
podłączyć drugi
kabel, ale jak potem obserwowałem tcpdumpem, że serwer widzi pakiety ze swoim IP
i w ogóle na nie nie reaguje, to się mocno zastanawiałem, czy to mi covid rozwalił
mózg
czy powaliło Linuxowi kernel - ale w końcu przyszło mi na myśl, żeby zobaczyć, jakie
są MAC
w tych pakietach i sprawa się wyjaśniła - a potem znów dzwonią z rana że system
zdechł - a to gdzieś
prąd mignął i jakiś router wszedł w stan nieustalony - ciekawostką było, że na pingi
nie odpowiadał,
ale udało się go zdalnie zresetować - i może przez to wcześniej wydawało się, że
działa w porządku)
Ufff, dobrze, że to pgsql i można vacuum momentalnie scancelować.
Potem jeszcze szybko sprawdziłem, że przy reindex tak samo się blokuje.
Tak że drogie dzieci, nie naśladujcie wujka (Wujcia Wariatuńcia ;) i pamiętajcie -
nie testujemy na produkcji.
A jak nie chcecie mieć kłopotów z bazą danych, to bierzcie pgsql - tabela i index
mogą mieć po 30GB
i nie wpływa to na pracę systemu (chyba że się dysk zapcha).

Żeby ostatecznie dobić mssql to pani księgowa ma na nim niestety płatnika - i chyba
nigdy nie zapomnę
siedzenia nad jeziorem drugiego dnia urlopu i przypominania sobie kolejności
kliknięć, żeby ten
serwer uruchomić w sytuacji, kiedy z jakiegoś nieznanego powodu (dzieje sięto co
jakiś czas)
przestanie się uruchamiać przy starcie windows...
Oczywiście ten drugi dzień urlopu to był jakiś 8 czy 9 dzień miesiąca...
Więc mogło się mssqlowi odwidzieć już sporo wcześniej - ale płatnika zwykle używa się
raz w miesiącu.