eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingprocedura tworzenia programów
Ilość wypowiedzi w tym wątku: 130

  • 121. Data: 2012-02-21 11:05:34
    Temat: Re: procedura tworzenia programów
    Od: Andrzej Jarzabek <a...@g...com>

    On Feb 20, 6:15 pm, Bronek Kozicki <b...@s...net> wrote:
    > On 19/02/2012 19:23, Andrzej Jarzabek wrote:
    >
    > >> różnica polega na tym, że każdy z członków zespołu może w danym momencie
    > >> pracować nad innym zadaniem, i tylko okazjonalnie poświęcić swoją uwagę
    > >> zadaniom kolegów.
    >
    > > W takiej sytuacji jest kilka problemów:
    >
    > > Skoro kolega zajmuje się czymś innym, to niekonieczenie ma orientację w
    > > tym, co robisz, żeby jakkolwiek pomóc. Więc musi się wdrożyć w tematem,
    >
    > widzisz, cały zespół (mały, ale zespół) zajmuje się pielęgnacją
    > *jednego* programu, jeden z celów takiej polityki jest taki że dowolny
    > członek zespołu potrafi poprawić program/ocenić pracę innego/dodać nowe
    > features. Oczywiście niektórzy znaję pewne miejsce programu lepiej od
    > innych, ale to kwestia praktyki. GUI jest pielęgnowane przez inny zespół
    > (i w innym języku).
    >
    > Ponadto na ten konkretny problem każdy z członków zespołu już wcześniej
    > się natknął, tylko dopiero niedawno zaczęło to przeszkadzać użytkownikom.

    No ale sam widzisz, masz taki konkretny problem i taką specyfikę
    projektu.

    W innych projektach często jest tak, że poszczególne problemy są mocno
    rozstrzelone, np. jedna osoba robi interfejs do JMS, inna optymalizuje
    zużycie pamięci, a inna jeszcze moduł komunikacji z bazą danych.

    Nawet jeśli założenie jest takie, że każdy ma móc pracować nad
    dowolnym kawałkiem programu i programiści są rotowani między
    komponentami, to nadal masz ten problem: inny programista w danym
    momencie zajmuje się czymś zupełnie innym; nad twoim komponentem może
    kiedyś pracował, ale to mogło być wiele miesięcy temu. Musiałby sobie
    przypomnieć. Poza tym nawet jak się orientuje w danym komponencie, to
    nie orientuje się w tym, co ty akurat próbujesz z nim zrobić. Więc
    musisz mu to wytłumaczyć - czasem będzie to proste, ale czasem sprawa
    jest bardziej skomplikowana i tak jak ty poświęciłeś kilka godzin na
    czytanie dokumentacji, rozmowy z analitykami itd. żeby to zrozumieć,
    tak może teraz będziesz musiał poświęcić kilka godzin swojego i kolegi
    czasu na wytłumaczenie mu tego.

    > > Kolejną istotną sprawą jest czas przestawienia się, zmiany kontekstu.
    > > Jeśli twój kolega pracuje nad czymś innym, ale odrywa się od swojej
    >
    > z mojego doświadczenia zmiana kontekstu jest stosunkowo tania jeżeli
    > cały czas dotyczy programowania, w ramach tego samego programu.
    > Spotkania za to, czy zmiana projektu .... to już inna para kaloszy.

    Z mojego doświadczenia w ramach jednego projektu możesz mieć problemy
    tak rozbieżne, że równie dobrze mogłyby dotyczyć zupełnie innego
    projektu.


  • 122. Data: 2012-02-21 11:08:42
    Temat: Re: procedura tworzenia programów
    Od: Andrzej Jarzabek <a...@g...com>

    On Feb 20, 6:28 pm, A.L. <l...@a...com> wrote:
    > On Mon, 20 Feb 2012 16:27:20 +0100, bartekltg <b...@g...com>
    >
    > >> Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.
    >
    > No a 100 facetow to bylby jeden blysk

    No bo to zawsze tak działa. Jeśli np. wnoszę kanapę na trzecie piętro
    i mi ciężko idzie, to zanim poproszę drugą osobę o pomoc zawsze
    stawiam sobie pytanie: czy pułk wojska wniósłby tę kanapę w kilka
    sekund? Oczywiście, że by nie wniósł, więc proszenie drugiej osoby o
    pomoc równiez nie ma sensu.


  • 123. Data: 2012-02-21 12:08:06
    Temat: Re: procedura tworzenia programów
    Od: Andrzej Jarzabek <a...@g...com>

    On Feb 20, 4:32 pm, bartekltg <b...@g...com> wrote:
    > W dniu 2012-02-20 17:09, Andrzej Jarzabek pisze:
    >
    > >> Programiści akurat doskonale wiedzą, że zysk ze zrównoleglenia
    > >> rzadko jest liniowy;-)
    > > Jest szafa, kanapa, duży materac, trzeba wnieść po schodach na trzecie
    > > piętro. Dwóm osobom wniesienie każdej z nich zajmie pięć minut, jednej
    > > osobie zajmie po kilka godzin a pewnie jeszcze uszkodzi.
    >
    > I o to chodzi. 'Roboczogodzina' nie zawsze jest dobrym
    > przelicznikiem.

    Zgoda, jednak to, czego programiści mogą nie wiedzieć, to to, że w
    innych kwestiach niż zrównoleglanie obliczeń na wielu procesorach,
    zysk ze zrównoleglenia może być większy niż liniowy. Jeśli jest
    większy niż liniowy, to to, co pisałem, jest również prawdą.

    Ja nie wiem, jak w tym przypadku jest. Domyślam się, że raz jest tak,
    raz jest inaczej, a w dodatku trudno to dokładnie określić, bo na
    ostateczny długoterminowy zysk wpływają różne rzeczy.

    > > Czy twoje programistyczne doświadczenie mówi ci, że to kompletnie
    > > nierealistyczne, bo robienie czegoś wspólnie przez kilka osób działa
    > > zawsze tak samo, jak zrównoleglanie programu na kilka procesorów?
    >
    > Cześć zadań da się idealnie zrównoleglić. Cześć nie.

    Ale ty znowu myślisz o zrównoleglaniu obliczeń, gdzie
    "idealnie"="liniowo". W życiu robienie czegoś wspólnie z innymi ludźmi
    to niekoniecznie jest "zrównoleglenie" w takim sensie.

    > Trzeba sie konsultować (to akurat czasem możę przyszpieszyć:)
    > Napiszą program i teraz sie kompiluje a potem testuje/liczy.
    > I tu już para nie pomogła.

    Wiesz, jeśli każdy z nich z osobna będzie robił coś, co będzie
    wymagało długiej kompilacji i/lub obliczeń, to i tak każdy z nich z
    osobna będzie miał taki moment, kiedy ich kawałek się kompiluje czy
    też liczy.

    Oczywiście w takiej sytuacji para może nadal zazwyczaj coś robić przy
    programie, np. zrobić sobie sesję projektowania, refaktoryzować kod,
    albo rozpocząć analizę następnego kawałka roboty.

    > Chciałem tylko zauważyć, że 'dwa razy więcej pracowników'
    > nie musi oznaczać 'dwa razy szybciej' jak sugerowałeś.

    Ale właśnie o to chodzi, że nie sugerowałem, że musi. Chodziło mi o
    to, że cały wywód A.L. że albo a) dwa razy drożej, albo b) za połowę
    pensji opierał się na nieuzasadnionym założeniu, że 'dwa razy więcej
    pracowników' oznacza 'tak samo szybko'. Jest to tak samo nieuzasanione
    co 'dwa razy szybciej', ale póki nie mamy uzasadnienia w którąkolwiek
    stronę, możemy tylko powiedzieć, że nie wiemy, czy dwóch praccowników
    zrobi to samo zadanie tak samo szybko czy więcej lub mniej niż dwa
    razy szybciej.

    Moje doświadczenie z pracą solo i bardzo sporadyczną pracą parami
    wskazuje, że przypieszenie może być znaczne, nawet więcej niż
    dwukrotne, w szczególności jeśli się wlicza czas nie tylko
    bezpośrednio samego kodowania danego kawałka kodu, ale też korzyści
    czasowe z mniejszej ilości błędów, lepszego projektu i szybszego
    transferu wiedzy.

    > > A przykład ze statkami? Czemu nie? Można np. uzupełnić brakujące
    > > informacje.
    >
    > A choćby czekanie na informacje zwrotną. Od klijenta,
    > od komputera (wynik programu, wynik testów).
    > Testem może być 'doba podłączenia do sieci' i wtedy
    > większa liczba komputerów nie pomaga.
    >
    > >> Jeden statek wiezie chiński badziew do europy 3 miesiące.
    > > Chińskiego badziewia jest tysiąc ton, a statek może na raz zabrać 200.
    > >> Ile zajmie transport badziewia 5 statkami.
    >
    > Ale tu już inne zadanie;)

    To jest to samo zadanie, tylko uzupełnione o brakującą informację. :)

    Oczywiście domyślam się, że w zadaniu chodziło ci o to, że statek
    bierze całe badziewie na jeden raz i w związku z tym w te 3 miesiące
    wykonuje tylko jedną podróż, ale jeśli dopiszesz to do zadania, to
    powstaje pytanie, dlaczego akuat twoje, a nie moje warunki mają być
    adekwatną analogią do pracy parami?

    Ja oczywiście uważam, że w ogóle to zadanie nie jest adekwatne. W
    ogólności jeśli postawisz pytanie tak: "jeden X wykonuje Y w p godzin,
    w ile godzin wykona Y n X-ów?" to odpowiedź brzmi "zależy od X, Y, n i
    p". Dla statków może być tak, dla sprzątaczek może być inaczej, dla
    wnoszenia meblli po schodach może być jeszcze inaczej, a dla
    programistów może to nawet zależeć od tego jaki program piszą, jakie
    mają chechy osobowości i od pierdyliona innych czynników. Ludzie to
    nie procesory, nie działają do końca racjonalnie i o ich zachowaniu
    decyduje tzw. psychologia.

    > Serio, meliska, bo sie nerwowo na grupie robi.

    E tam nerwowo.


  • 124. Data: 2012-02-21 12:59:57
    Temat: Re: procedura tworzenia programów
    Od: Wojciech Jaczewski <w...@o...pl>

    Andrzej Jarzabek wrote:

    > Moje doświadczenie z pracą solo i bardzo sporadyczną pracą parami
    > wskazuje, że przypieszenie może być znaczne, nawet więcej niż
    > dwukrotne, w szczególności jeśli się wlicza czas nie tylko
    > bezpośrednio samego kodowania danego kawałka kodu, ale też korzyści
    > czasowe z mniejszej ilości błędów, lepszego projektu i szybszego
    > transferu wiedzy.

    Czy w tej parze miałeś człowieka z podobnym do swojego doświadczeniem, czy z
    całkowicie innym?


  • 125. Data: 2012-02-21 13:45:32
    Temat: Re: procedura tworzenia programów
    Od: Andrzej Jarzabek <a...@g...com>

    On Feb 21, 12:59 pm, Wojciech Jaczewski <w...@o...pl> wrote:
    > Andrzej Jarzabek wrote:
    > > Moje doświadczenie z pracą solo i bardzo sporadyczną pracą parami
    > > wskazuje, że przypieszenie może być znaczne, nawet więcej niż
    > > dwukrotne, w szczególności jeśli się wlicza czas nie tylko
    > > bezpośrednio samego kodowania danego kawałka kodu, ale też korzyści
    > > czasowe z mniejszej ilości błędów, lepszego projektu i szybszego
    > > transferu wiedzy.
    >
    > Czy w tej parze miałeś człowieka z podobnym do swojego doświadczeniem, czy z
    > całkowicie innym?

    Raczej podobnym, ale jeszcze raz powtórzę, że było to bardzo
    sporadyczne - na studiach miałem może ze dwa kursy gdzie tak
    pracowaliśmy, w działalności zawodowej to było raczej dosłownie kilka
    posiadówek po parę minut - z ludźmi o różnycm doświadczeniu, czasem
    podobnym do mojego, czasem nie.


  • 126. Data: 2012-02-21 16:43:54
    Temat: Re: procedura tworzenia program?w
    Od: "R.e.m.e.K" <g...@d...null>

    Dnia Mon, 20 Feb 2012 22:26:37 +0100, Wojciech Jaczewski napisał(a):

    > W C++ długotrwałe obliczenia wolałbym wyrzucić do osobnego procesu - bo
    > proces w przeciwieństwie do wątku, zawsze daje się zatrzymać/ubić - gdyby
    > użytkownik stwierdził że jednak mu to obliczenie niepotrzebne.

    Watku niby nie da sie zatrzymac, gdy sie go _dobrze_ napisze?

    --
    pozdro
    R.e.m.e.K


  • 127. Data: 2012-02-21 17:28:48
    Temat: Re: procedura tworzenia program?w
    Od: Wojciech Jaczewski <w...@o...pl>

    R.e.m.e.K wrote:

    > Dnia Mon, 20 Feb 2012 22:26:37 +0100, Wojciech Jaczewski napisał(a):
    >
    >> W C++ długotrwałe obliczenia wolałbym wyrzucić do osobnego procesu - bo
    >> proces w przeciwieństwie do wątku, zawsze daje się zatrzymać/ubić - gdyby
    >> użytkownik stwierdził że jednak mu to obliczenie niepotrzebne.
    >
    > Watku niby nie da sie zatrzymac, gdy sie go _dobrze_ napisze?

    Czyli pewnie w wątku muszę raz na jakiś czas przerywać obliczenia, aby
    sprawdzić czy aby drugi wątek nie ma ochoty z nich zrezygnować?
    W przypadku procesu NIE MUSZĘ tego robić a proces i tak będzie się dało
    ubić.


  • 128. Data: 2012-02-21 21:50:55
    Temat: Re: procedura tworzenia program w
    Od: Andrzej Jarzabek <a...@g...com>

    On 20/02/2012 21:38, Wojciech Jaczewski wrote:
    > Andrzej Jarzabek wrote:
    >
    >>> Wolę message passing na procesach.
    >>> Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma
    >>> bardzo poważne - jak dla mnie - wady:
    >>> - pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym
    >>
    >> A do czego byś chciał używać tej funkcji, że ci to robi różnicę?
    >
    > Włącza się jakieś urządzenie, które mogło być ileś dni wyłączone, więc ma
    > zegar rozsynchronizowany o kilka minut. Synchronizacja nastąpi wtedy, gdy
    > będzie łączność z internetem, a ta może być od razu, a może za pół godziny.
    >
    > Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
    > poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.

    Ale pthread_cond_timedwait nie jest po to, żeby odmierzać czas!

    >> Można to łatwo zrobić tworząc osobne wątki, które czekają na zdarzenie
    >> i generują komunikat czy warunek, na który czeka "główny" wątek.
    >
    > I w ten sposób zwiększyć komplikację programu, bo pojawia się więcej
    > równoległych wątków niż byłoby w wersji z potokami/gniazdami.

    Większa ilość wątków nie oznacza większej komplikacji - te wątki są
    zresztą bardzo proste. A ponieważ - zwłaszcza jeśli się martwisz o
    komplikację programu - masz to schowane za warstwą abstrakcji, to nie
    robi to żadnej różnicy - po prostu tworzysz Warunek i rejestrujesz
    Zdarzenia, które powodują jego spełnienie.


  • 129. Data: 2012-02-21 22:21:49
    Temat: Re: procedura tworzenia program w
    Od: Wojciech Jaczewski <w...@o...pl>

    Andrzej Jarzabek wrote:

    >> Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
    >> poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.
    >
    > Ale pthread_cond_timedwait nie jest po to, żeby odmierzać czas!

    To po co w takim razie jest tam czas jako argument? I po co w ogóle istnieje
    ta funkcja, skoro jest pthread_cond_wait?
    Po prostu chciałem użyć pthread_cond_timedwait zgodnie z jej przeznaczeniem:
    poczekaj na zdarzenie lub upływ czasu. I w moich warunkach - nie mogę.

    > Większa ilość wątków nie oznacza większej komplikacji - te wątki są
    > zresztą bardzo proste. A ponieważ - zwłaszcza jeśli się martwisz o
    > komplikację programu - masz to schowane za warstwą abstrakcji, to nie
    > robi to żadnej różnicy

    Do czasu, gdy nie pojawia się błąd - być może w zupełnie innej części,
    którego nie mogę wypatrzeć - wtedy nie mogę sobie na ślepo przyjąć
    założenia, że inne części, działające w innych wątkach są OK - w ramach
    szukania przyczyny błędu muszę zajrzeć także do nich. To, że zostało to
    schowane za warstwą abstrakcji wiele nie zmienia.


  • 130. Data: 2012-02-21 23:23:15
    Temat: Re: procedura tworzenia program w
    Od: Andrzej Jarzabek <a...@g...com>

    On 21/02/2012 22:21, Wojciech Jaczewski wrote:
    > Andrzej Jarzabek wrote:
    >
    >>> Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
    >>> poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.
    >>
    >> Ale pthread_cond_timedwait nie jest po to, żeby odmierzać czas!
    >
    > To po co w takim razie jest tam czas jako argument? I po co w ogóle istnieje
    > ta funkcja, skoro jest pthread_cond_wait?
    > Po prostu chciałem użyć pthread_cond_timedwait zgodnie z jej przeznaczeniem:
    > poczekaj na zdarzenie lub upływ czasu. I w moich warunkach - nie mogę.

    Ta funkcja, jak i wszystkie inne 'timed' nie jest po to, żeby jej używać
    do normalnych czynności. Do tego, co próbujesz robić, powinieneś znowu
    odpalić osobny wątek, który odczekuje odpowiednią ilość czasu i
    sygnalizuje zmienną warunkową.

    Funkcje 'timed' służą do zaimplementowania timeoutu, generalnie do
    uniknięcia sytuacji, kiedy program by 'zwisał' albo zostawiał zbędne
    wątki. Przykładowo jeśli wątkami realizujesz jakieś równolegle
    działające komponenty w danym programie, to możesz chcieć mieć w tym
    programie moduł monitorujący te komponenty, pozwalający użytkownikowi na
    podglądnięcie, co program w danej chwili robi. I żeby taki moduł
    wiedział, że dany wątek nadal żyje i czeka na cośtam, ten wątek może co
    np. sekundę przerywać czekanie i wysyłać monitorowi komunikat 'nadal
    żyję i czekam'. Inna możliwa sytuacja jest taka, że pewne wątki mogą
    przestać być potrzebne - jako alternatywę dla pthread_cancel można
    zaprojektować je tak, żeby periodycznie sprawdzały, czy powinny jeszcze
    istnieć i jeśli nie, to się same zamykały.

    >> Większa ilość wątków nie oznacza większej komplikacji - te wątki są
    >> zresztą bardzo proste. A ponieważ - zwłaszcza jeśli się martwisz o
    >> komplikację programu - masz to schowane za warstwą abstrakcji, to nie
    >> robi to żadnej różnicy
    >
    > Do czasu, gdy nie pojawia się błąd - być może w zupełnie innej części,
    > którego nie mogę wypatrzeć - wtedy nie mogę sobie na ślepo przyjąć
    > założenia, że inne części, działające w innych wątkach są OK - w ramach
    > szukania przyczyny błędu muszę zajrzeć także do nich. To, że zostało to
    > schowane za warstwą abstrakcji wiele nie zmienia.

    Właśnie wiele zmienia, bo pozwala na wnioskowanie o poszczególnych
    częściach programu w izolacji. Oczywiście jeśli twój program ma UB, to
    teoretycznie wszystko jest możliwe, ale w tym przypadku też można
    dedukować przyczyny po objawach. Poza tym im prostszy dany element, tym
    mniejsze prawdopodobieństwo, że ma UB. Np. funkcja typu void, która
    blokuje aż będzie coś na wejściu czy innym sockecie, jest bardzo prosta.
    Funkcja, która wywołuje zadaną funkcję typu void i ustawia zmienną
    warunkową jest również bardzo prosta (a tę jedną funkcję możesz
    wykorzystać do obsługi wszystkich interesujących cię zdarzeń,
    wymieniając tylko która funkcja ma być wywołana.

    Oczywiście do tego wszystkiego dobrze mieć jeszcze język wspierający
    abstrakcję, a jeszcze lepiej do tego sensowne biblioteki, a nie grzebać
    się w gołych pthreadsach. W ogóle jedyny racjonalny powód, jaki widzę,
    żeby cokolwiek robić w pthreadsach, to napisanie Nowej Jeszcze
    Zajebistszej Od Wszystkich Istniejących Biblioteki Do Wątków
    (zajebistszej pod jakimkolwiek interesującym nas względem naturalnie).

strony : 1 ... 12 . [ 13 ]


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: