eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaRynek pracy STM32
Ilość wypowiedzi w tym wątku: 355

  • 161. Data: 2022-07-19 15:00:30
    Temat: Re: Rynek pracy STM32
    Od: Piotr Gałka <p...@c...pl>

    W dniu 2022-07-19 o 14:48, heby pisze:
    > On 19/07/2022 14:18, Cezar wrote:
    >> Oczywiście, główną własnością schematu (poza jego poprawnością) jest
    >> jego czytelność więc trzeba by mieć wielką wyobraźnię żeby go "napisać"
    >
    > Jeśli "napiszesz" schemat, to istnieje spore prawdopodobieństwo, że
    > pojawią się bloki funkcjonalne, hierarchicznie. A jeśli tak, to
    > zrozumienie działania nie wymaga gapienia się w kreski na schemacie a
    > jedynie na połączenia w kodzie źródłowym grubych bloków między sobą. To
    > wcale nie jest bardzo trudne, programiści robią to od dawna.

    Ale schemat jest pod pewnymi względami mało hierarchiczny.
    Jak do programu dołożysz wewnątrz procedur wiele różnych goto gdzieś do
    wnętrza innej procedury to program przestanie być czytelny.
    P.G.


  • 162. Data: 2022-07-19 15:07:07
    Temat: Re: Rynek pracy STM32
    Od: heby <h...@p...onet.pl>

    On 19/07/2022 14:54, Piotr Gałka wrote:
    > Pytanie wzięło się stąd, że napisałeś, że jak jest taka kontrola wersji
    > to nie będzie pytania: Jak on TO do cholery kompilował.

    Nie będzie. Wszystkie możliwe narzędzia, opcje, wyjątki itp sa w kodzie.

    Rownież, jesli robisz to porządnie, to same polecenia wystartowania
    kompilacji z odpowiednimi ifdefami będzie tamteż dostępne, w kontekście
    hardware które budujesz. Więc nie tylko nie ma mowy o pomyłkach ale
    można to środowisko odtworzyć po latach bez zmian.

    Wiec nie, choć trochę tak.

    Kwestia higieny.

    >> A w celu redukcji #ifdef, można by się zainteresować statycznym
    >> polimorfizmem. Ale to już cieżki C++.
    > On jest na etapie C.

    Nie ma takiego eatpu. Jeśli jesteś w C to jesteś też na początku C++.
    Niech zacznie od zmiany kompilatoa z gcc na g++ i nazwy kliku z foo.c na
    foo.cpp i już koniec tranzycji na C++. Reszta to darmowy obiad.

    > Ale stosuje go jakoś inaczej niż mi by przyszło do głowy. Ma na przykład
    > w każdym projekcie plik h o jednej wspólnej nazwie i wczytuje go we
    > wszystkich plikach c używanych w wielu projektach. W ten sposób te pliki
    > (jakby biblioteczne) generują dla każdego projektu inny obj.

    Czyli emuluje templates z C++ używając sztuczek z inkludowaniem.

    To jest ogólnie niebezpieczne jak jasna cholera. W większych projaktach
    takie rzeczy są zabronone. Po pierwsze dlatego, że są trudne w
    utrzymaniu, po drugie dlatego, że od tego są templates w C++.

    Każdy programista C wynajduje po latach kwadratowe koła tego typu,
    broniąc się przez przejściem do C++ gdzie statyczny polimorfizm jest
    częścią jezyka.

    > Ja jestem na etapie C++ (ale Ty nazwiesz to C z klasami). Kupiłem kilka
    > lat temu książkę Stroustrupa i trochę poczytałem, ale kompilator,
    > którego głównie używam (Builder 5) nie ma nawet tego co jest w C++11.

    Nie używaj więc Buildera. Nikt tego nie sprawdza.

    > A wiedza nie używana wylatuje, więc wszystko co tam wyczytałem mi
    > wyleciało.

    Tak jak mówiłem, nie czytaj instrukcji ;)


  • 163. Data: 2022-07-19 15:08:25
    Temat: Re: Rynek pracy STM32
    Od: "Grzegorz Niemirowski" <g...@g...net>

    Mateusz Viste <m...@x...invalid> napisał(a):
    > 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.
    > Mateusz

    Niby tak. Z drugiej strony jak we wszystkich pracach mam gita oraz w
    projektach Open Source, do których czasem coś dopisuję, to nawet dla samego
    siebie użyłem git zamiast przypominać sobie SVN po 15 latach od ostatniego
    użycia.

    --
    Grzegorz Niemirowski
    https://www.grzegorz.net/


  • 164. Data: 2022-07-19 15:09:22
    Temat: Re: Rynek pracy STM32
    Od: heby <h...@p...onet.pl>

    On 19/07/2022 15:00, Piotr Gałka wrote:
    >> Jeśli "napiszesz" schemat, to istnieje spore prawdopodobieństwo, że
    >> pojawią się bloki funkcjonalne, hierarchicznie. A jeśli tak, to
    >> zrozumienie działania nie wymaga gapienia się w kreski na schemacie a
    >> jedynie na połączenia w kodzie źródłowym grubych bloków między sobą.
    >> To wcale nie jest bardzo trudne, programiści robią to od dawna.
    > Ale schemat jest pod pewnymi względami mało hierarchiczny.

    Opisany w języku VHDL/Verilog jest *skrajnie* hierarchiczny. Tam
    wszystko w zasadzie jest podporządkowane hierarchi.

    Używanie takiego języka wlaśnie wymusza porządek. Schemat to zazwyczaj
    płaski zbiór kresek, gdzie bloki funkcjonalne trzeba wydłubywać gapiąc
    się pół godziny, a w *HDL masz je ładnie nazwane.

    > Jak do programu dołożysz wewnątrz procedur wiele różnych goto gdzieś do
    > wnętrza innej procedury to program przestanie być czytelny.

    To nie używaj goto ;) Proste.


  • 165. Data: 2022-07-19 15:14:46
    Temat: Re: Rynek pracy STM32
    Od: heby <h...@p...onet.pl>

    On 19/07/2022 15:08, Grzegorz Niemirowski wrote:
    >> 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.
    >> Mateusz
    > Niby tak. Z drugiej strony jak we wszystkich pracach mam gita oraz w
    > projektach Open Source, do których czasem coś dopisuję, to nawet dla
    > samego siebie użyłem git zamiast przypominać sobie SVN po 15 latach od
    > ostatniego użycia.

    Mimo to, jeśli ktoś ma startować z tematem od zera, svn będzie
    nieskończenie bardziej intuicyjny niż git.


  • 166. Data: 2022-07-19 15:25:02
    Temat: Re: Rynek pracy STM32
    Od: Piotr Gałka <p...@c...pl>

    W dniu 2022-07-19 o 14:58, heby pisze:
    >> Sądzę, że jeszcze trochę potrwa zanim powiesz programowi, że płytka
    >> będzie w obudowie nie ekranowanej a mimo ma spełnić taką a taką normę
    >> EMC i on już się tym zajmie.
    >
    > ASICe "same się routują". Czemu PCB nie miałyby? Przynajmniej częściowo.
    > Wrzucasz komponenty krytyczne a reszta drobicy sam się gdzieś wciśnie.

    Napisałem 'jeszcze trochę' a nie 'jeszcze długo'.

    Jak projektuję PCB to 90% roboty to jest rozmieszczenie elementów.
    Ale ja sobie tę robotę robię bo nie chce mi się przerzucić na 4 warstwy,
    a na 2 warstwowej wymagam aby 100% bottom było GND. Więc (poza GND)
    wychodzi mi projekt jednowarstwowy i rozplątanie tego (takie położenie,
    aby dla każdego połączenia przewidzieć drogę którędy pójdzie) zajmuje
    najwięcej czasu. Potem pociągnięcie ścieżek to już po prostu realizacja
    tego, co się brało pod uwagę przy rozmieszczaniu.

    > Nie o szybkosc pracy chodzi, ale o intuicyjność. Te same operacje w CAD
    > oznaczają coś innego niż w resztcie świata. Sama selekcja w
    > KiCAD/Eagle/Protel jest zupełnie inna, nieintuicyjna, a to dopiero
    > początek przygody.

    Jestem bardziej przyzwyczajony do Protela i KiCada niż do tej reszty
    więc szybciej uznam, że to tam jest nieintuicyjnie.
    Ale nie kojarzę na czym polega ta odmienność przy selekcji.

    > Głupie usunięcie routingu ścieżek zajmuje mi w KiCADdzie zazwyczaj koło
    > 5 minut szukania. Za każdym razem po miesięcznej przerwie. To jest tak
    > nieintuicyjnie, że niemożliwe do zapamiętania w mięśniach od klikania.

    Nie kojarzę problemu.
    W Protelu 3 była łatwa możliwość Unroute całej płytki, ale nie używam go
    już od 5 lat.
    Modyfikacja ścieżek była ciężka, dlatego najłatwiej było usunąć i
    narysować od nowa. Jak pamiętam była tam taka dla mnie bardzo fajna
    rzecz - każdą operację dawało się rozszerzyć na inne elementy wybierane
    według określanego w danym momencie klucza (bardzo szeroka gama możliwości).

    W KiCadzie chyba faktycznie trudniej jest usuwać ścieżki. Ale mnie to
    raczej nie boli, bo jest z kolei duża łatwość ich modyfikacji - to jest
    miodzio jak to działa. Jeden gość mocno aktywny na forum KiCada pisze,
    że on w ogóle nie zwraca uwagi jak się mu ścieżki prowadzą. Jak wszystko
    jest połączone to potem je przesuwa tak aby było tak jak mu pasuje.
    Ja się jeszcze aż do tego stopnia nie przełamałem i czasem wojuję z
    KiCadem aby poprowadził dokładnie tak jak ja chcę a on szczególnie przy
    podłączaniu do padów ma jakieś swoje widzimisię. Ale piszę o V5, bo pod
    V6 na razie zaprojektowałem 0 płytek.
    P.G.


  • 167. Data: 2022-07-19 15:29:34
    Temat: Re: Rynek pracy STM32
    Od: heby <h...@p...onet.pl>

    On 19/07/2022 15:25, Piotr Gałka wrote:
    > Jestem bardziej przyzwyczajony do Protela i KiCada niż do tej reszty
    > więc szybciej uznam, że to tam jest nieintuicyjnie.
    > Ale nie kojarzę na czym polega ta odmienność przy selekcji.

    Zaznaczanie ramką *zazwyczaj* zamiast zaznaczać, ciągnie mi elementy już
    zaznaczone lub wykonuje inne akcje.


  • 168. Data: 2022-07-19 15:43:02
    Temat: Re: Rynek pracy STM32
    Od: Piotr Gałka <p...@c...pl>

    W dniu 2022-07-19 o 15:07, heby pisze:
    >> Ale stosuje go jakoś inaczej niż mi by przyszło do głowy. Ma na
    >> przykład w każdym projekcie plik h o jednej wspólnej nazwie i wczytuje
    >> go we wszystkich plikach c używanych w wielu projektach. W ten sposób
    >> te pliki (jakby biblioteczne) generują dla każdego projektu inny obj.
    >
    > Czyli emuluje templates z C++ używając sztuczek z inkludowaniem.

    Nigdy nie opanowałem templates, ale tak jak ja je sobie wyobrażam to
    chyba to jest jednak coś innego.

    U niego raczej chodzi o to, że w pliku jest na przykład komunikacja ze
    scalakiem RFID. Ale to jak ona jest faktycznie realizowana zależy od
    tego pliku h o wspólnej nazwie dla wszystkich projektów a tam jest
    informacja jaki procesor i jak jest podłączony dla danej wersji płytki.
    Funkcjonalność, która jest w danym projekcie niezbędna też pewnie jest w
    tym pliku (czytamy tylko ID karty, czy pełna komunikacja z kartą Desfire.
    Ale nie jestem pewien tego co piszę.

    Ja (okolice 1990) emulowałem klasy za pomocą wskaźników na funkcje.

    > To jest ogólnie niebezpieczne jak jasna cholera. W większych projaktach
    > takie rzeczy są zabronone. Po pierwsze dlatego, że są trudne w
    > utrzymaniu, po drugie dlatego, że od tego są templates w C++.
    >
    > Każdy programista C wynajduje po latach kwadratowe koła tego typu,
    > broniąc się przez przejściem do C++ gdzie statyczny polimorfizm jest
    > częścią jezyka.

    Muszę poszukać co to hasło oznacza. Może wiem, tylko nie wiem, że tak
    się nazywa.

    > Nie używaj więc Buildera. Nikt tego nie sprawdza.

    Nie rozumiem.
    P.G.


  • 169. Data: 2022-07-19 15:50:59
    Temat: Re: Rynek pracy STM32
    Od: Dawid Rutkowski <d...@w...pl>

    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.


  • 170. Data: 2022-07-19 15:54:37
    Temat: Re: Rynek pracy STM32
    Od: heby <h...@p...onet.pl>

    On 19/07/2022 15:43, Piotr Gałka wrote:
    >> Czyli emuluje templates z C++ używając sztuczek z inkludowaniem.
    > Nigdy nie opanowałem templates, ale tak jak ja je sobie wyobrażam to
    > chyba to jest jednak coś innego.
    > U niego raczej chodzi o to, że w pliku jest na przykład komunikacja ze
    > scalakiem RFID. Ale to jak ona jest faktycznie realizowana zależy od
    > tego pliku h o wspólnej nazwie dla wszystkich projektów a tam jest
    > informacja jaki procesor i jak jest podłączony dla danej wersji płytki.

    Tak. To statyczny polimorfizm. Wykonuje się go w C++ za pomocą
    templates. Dokładnie tak jak opisujesz - umożliwia np. rozdzielenie
    implementacji hardwareowej UART od kodu implementującego protokół bez
    ani jednej nadmiarowej instrukcji asm.

    To się też da zrobić dynamicznym polimorfizmem (polimorficzne klasy z
    metodami wirtualnymi), ale ktoś może marudzić, że to zajmuje cenne cykle
    zegarowe na indirect call. Dlatego istnieje też polimorfizm statyczny,
    który nie generuje dodatkowego kodu.

    > Ja (okolice 1990) emulowałem klasy za pomocą wskaźników na funkcje.

    W '95 pisałem w SasC na Amidze kod C++. Wtedy był on w tle konwertowany
    przez kompilator na goły C i dopiero kompilowany. Wtedy nikomu bym go
    nie polecał, ale od tamtego czasu jednak troche się zmieniło. Obecnie
    wiele technik pisania w C++ jest najzwyczajniej lepszych niż kwadratowe
    koła wymyślane przez programistów C.

    >> Nie używaj więc Buildera. Nikt tego nie sprawdza.
    > Nie rozumiem.

    Napisałeś, że nie możesz używać C++ bo używasz Buildera. A po co używac
    Buildera?

strony : 1 ... 10 ... 16 . [ 17 ] . 18 ... 30 ... 36


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: