eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPorównanie różnych języków
Ilość wypowiedzi w tym wątku: 151

  • 91. Data: 2011-12-18 15:40:28
    Temat: Re: Porównanie różnych języków
    Od: Andrzej Jarzabek <a...@g...com>

    On 18/12/2011 15:28, A.L. wrote:
    > On Sun, 18 Dec 2011 10:41:42 +0000, Andrzej Jarzabek
    > <a...@g...com> wrote:
    >
    >>> Bez odpowiedniej
    >>> formalizacji procesu projektowania i dokumentowania wymagan dla
    >>> programisty ow programista nei mialby zielonego pojacia co
    >>> programowac, a projekt skutkowalby tym samym czym skutkowala proba
    >>> bucowy Wiezy Babel
    >>
    >> Otóż jednak istnieją inne sposoby na to, żeby programista miał pojęcie.
    >
    > Dyc o tym pisze. DOKUMENTACJA.

    A ja piszę - cytuję - "istnieją inne sposoby". Z kontekstu wynika, że
    inne niż dokumentacja.

    > Juz pisalem, ze w jednym z projektow w
    > ktorych biore udzial, same "requitements" maja ponad 3000 stron

    I o czym to ma niby świadczyć?


  • 92. Data: 2011-12-18 15:40:57
    Temat: Re: Porównanie różnych języków
    Od: A.L. <l...@a...com>

    On Sun, 18 Dec 2011 12:14:48 +0000, Andrzej Jarzabek
    <a...@g...com> wrote:

    >On 17/12/2011 22:43, A.L. wrote:
    >>
    >> Nie ma sie Pan co obawiac. To jest "metodologia Agile". Ponoc jedynie
    >> sluszna.
    >>
    >> Ciekawe jak "agilowcy" wyobrazaja sobie projekt w ktorym pracuje,
    >> powiedzmy, 50 programistow, i owi programisci nigdy nie kontaktuja sie
    >> z przyszlym uzytkownikiem systemu?
    >
    >Po pierwsze, nie ma czegoś takiego jak "metodologia Agile". Można
    >ewnetualnie rozpatrywać konkretne metodologie jak XP czy Scrum, albo
    >zastanawiać się nad ogólnym podejściem Agile do tego tematu - ale w tym
    >drugim przypadku trzeba wziąć pod uwagę, że istnieją metodologie czy
    >procesy, które mieszczą się nadal w ogólnym nurcie Agile, ale stosują
    >pewne rozwiązania spoza tego nurtu.
    >
    >Więc po pierwsze temat kontaktów z przyszłym użytkownikiem: generalnie
    >nie jest konieczny. XP zaleca, żeby w miarę możliwości "on-site
    >customer" był przedstawicielem typowego użytkownika systemu, ale nie
    >jest to jedyna możliwość. Podstawą jest to, żeby ludzie występujący w
    >rolach "customer representative" albo "product owner" rozumieli potrzeby
    >użytkownika, ewentualnie mieli możliwość szybkiego dowiedzenia się jakie
    >one są w szczególnym przypadku.
    >

    PROGRAMISCI kontaktuja sie z uzytkownikiem gdy tzreba pierdyknac bazke
    danych szlauchow i kaloszy. W duzych projektach, programiste od
    klienta dzieli dobre pare warstw organizacji i kudzi.

    Ciekawe ile jescza razy trzeba bedzie to powtarzac?

    A.L.


  • 93. Data: 2011-12-18 15:56:10
    Temat: Re: Porównanie ró?nych jezyków
    Od: "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid>

    On 2011-12-18, A.L <l...@a...com> wrote:
    [...]
    > Jezeli Kolega powtarza to co Kolege nauczyli na studiach, to powinien
    > Kolega poprosic o zwrot kosztow edukacji. Jezeli zas kolega jest
    > praktykiem, to w celu uwierzytelnienia Kolegi pogladow - to znaczy ze
    > Kolega do nich doszedl na podstawie wlasnej praktyki - proponuje aby
    > Kolega opublikwoal swe resume z lista projektow i ich szczegolowa
    > charakterystyka.

    Ja wiem że A.L ma mnie w KF, ale nie mogę się zwyczajnie powstrzymać.

    A.L, neich Kolega opublikuje swe resume z lista projektow i ich
    szczegolowa charakterystyka. Chyba że Kloedze "NDA" nie pozwalaja, bo,
    zdaje się, to jest typowa dla Koelgi wymwoka?

    > Inaczej mi to wyglada jak przyslowiowe opowiesci slepego o kolorach.

    Mnie przypomina to przypowieść o belce i źdźble.

    --
    Secunia non olet.
    Stanislaw Klekot


  • 94. Data: 2011-12-18 16:02:21
    Temat: Re: Porównanie różnych języków
    Od: Andrzej Jarzabek <a...@g...com>

    On 18/12/2011 15:38, A.L. wrote:
    > On Sun, 18 Dec 2011 11:52:26 +0000, Andrzej Jarzabek
    > <a...@g...com> wrote:
    >
    >> Ale moment, ty to sobie wyobrażasz na zasadzie "kazanie" - programiści
    >> siadają wszyscy w sali i klient im mówi od początku do końca jak program
    >> ma działać, po czym bierze walizeczkę i idzie do domu?
    >
    > W projektach wiekszych niz jednoosobowe klient nic nie mowi do
    > programistow.

    Klient często w ogóle nie mówi do nikogo, bo jest instytucją. Natomiast
    w projektach większych niż 5 i mniejszych niż 50 osób osoby
    reprezentujące klienta jak najbardziej mówią do programistów.

    > Podobnie jak osoba zamawiajaca budowe mostu przez Wisle
    > nic nie mowi do spawaczy. Most projektuje architekt, na podsatwie
    > wymagan klienta ktorym to klientem sa wladze miasta, potem projekt
    > bierze inzynier budowlany i okreska szczegoly konstrukcji - sposob
    > realizacji przesel, grubosc belek itede oraz organizacje procesu
    > budowy. Na podstawie tego powsztaje dokumentacja i dopiero wtedy
    > spawacze (czytaj: programisci) dostaja polecania aby zepsawac to z
    > tamtym.
    >
    > Dokladnie tak samo wyglada realizacja pzredsiewziec programistycznych.

    W waszej firmie. W innych firmach wygląda to inaczej. Wychodzi na to, że
    w niektórych firmach oprogramowanie tworzy się metodami do tworzenia
    oprogramowania, a w innych firmach metodami do tworzenia mostów.

    > Programista ma niewielki wplyw na postac produktu koncowego, bo to nie
    > programista decuduje jak ten produkt bedzie wygladal. Z wyjatkiem
    > pierdykniecia bazki danych szlauchow i kaloszy.

    W opisywanej przeze mnie metodologii też nie programiści decydują o tym.
    W szczególności decyduje o tym product owner albo klient.

    > Jezeli Kolega powtarza to co Kolege nauczyli na studiach, to powinien
    > Kolega poprosic o zwrot kosztow edukacji. Jezeli zas kolega jest
    > praktykiem, to w celu uwierzytelnienia Kolegi pogladow - to znaczy ze
    > Kolega do nich doszedl na podstawie wlasnej praktyki - proponuje aby
    > Kolega opublikwoal swe resume z lista projektow i ich szczegolowa
    > charakterystyka.
    >
    > Inaczej mi to wyglada jak przyslowiowe opowiesci slepego o kolorach.

    Przykro mi, nie odczuwam żadnej potrzeby uwierzytelnienia się przed
    kolegą. A może by kolega opublikował swoje resume w celu
    uwierzytelnienia swoich poglądów, np. że programowanie buduje się
    właśnie tak, jak mosty.


  • 95. Data: 2011-12-18 16:11:25
    Temat: Re: Porównanie różnych języków
    Od: Maciej Sobczak <s...@g...com>

    On Dec 18, 1:18 pm, Andrzej Jarzabek <a...@g...com>
    wrote:

    > >> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
    > >> co jest bugiem, a co nie.
    >
    > > Bingo.
    >
    > Czyli jeśli zachowując się zgodnie z dokumentacją program doprowadza do
    > wybuchu elektrowni ataomowej, to nie ma buga, po prostu to właśnie miał
    > zrobić?

    Jak na ironię, dokładnie tak tłumaczy się przypadek Ariane V. Kupa
    dymu, bo program zadziałał zgodnie ze specyfikacją.

    Żatry na bok, ale w powyższym przypadku jest bug w dokumentacji. Jej
    zaletą jest fakt, że łatwiej znaleźć buga w dokumentacji, która
    istnieje, niż w dokumentacji, która nie istnieje. W szczególności,
    dokumentacja jest materiałem, który odtwarza się w posób powtarzalny,
    podczas gdy rozmowy z OSCR mogą zawierać składnik stochastyczny
    zależny od tego, ile kawy OSCR w danym dniu wypił.
    Dlatego dokumentację można np. powielić i dać do audytu. Nawet
    równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.

    Nadal wolę dokumentację, zwłaszcza w przypadku elektrowni atomowej.

    > > No właśnie. Bo jeśli program działa niezgodnie z istniejącą
    > > dokumentacją, to coś należy poprawić. Ale jeżeli działa niezgodnie z
    > > nieistniejącą dokumentacją, to projekt jest w ciemnej d*pie. I to jest
    > > właśnie ta perspektywa, której się obawiam.
    >
    > Jeżeli działa niezgodnie z nieistniejącą dokumentacją, to nie przechodzi
    > testów i nie może zostać zreleasowany.

    Jakich testów? Tych, które powstały na podstawie nieistniejącej
    dokumentacji i są z tą nieistniejącą dokumentacją niezgodne?

    --
    Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com


  • 96. Data: 2011-12-18 16:15:27
    Temat: Re: Porównanie różnych języków
    Od: A.L. <l...@a...com>

    On Sun, 18 Dec 2011 15:40:28 +0000, Andrzej Jarzabek
    <a...@g...com> wrote:

    >On 18/12/2011 15:28, A.L. wrote:
    >> On Sun, 18 Dec 2011 10:41:42 +0000, Andrzej Jarzabek
    >> <a...@g...com> wrote:
    >>
    >>>> Bez odpowiedniej
    >>>> formalizacji procesu projektowania i dokumentowania wymagan dla
    >>>> programisty ow programista nei mialby zielonego pojacia co
    >>>> programowac, a projekt skutkowalby tym samym czym skutkowala proba
    >>>> bucowy Wiezy Babel
    >>>
    >>> Otóż jednak istnieją inne sposoby na to, żeby programista miał pojęcie.
    >>
    >> Dyc o tym pisze. DOKUMENTACJA.
    >
    >A ja piszę - cytuję - "istnieją inne sposoby". Z kontekstu wynika, że
    >inne niż dokumentacja.
    >
    >> Juz pisalem, ze w jednym z projektow w
    >> ktorych biore udzial, same "requitements" maja ponad 3000 stron
    >
    >I o czym to ma niby świadczyć?

    O tym ze poziom "bicia piany" w tym watku osiagnal prog taki przy
    ktorym watek blokuje pzred dalsza "dyskusja"

    A.L.


  • 97. Data: 2011-12-18 16:22:04
    Temat: Re: Porównanie różnych języków
    Od: Maciej Sobczak <s...@g...com>

    On Dec 18, 2:46 am, Andrzej Jarzabek <a...@g...com>
    wrote:

    > > Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
    > > kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
    > > krótką listą zakupów, ale dłuższe opisy mi się urywają.
    >
    > Sprzedam ci niezły patent: notatki.

    Zaraz, zaraz. Pisałeś na początku, że dokumentacji ma nie być. Teraz
    piszesz, że ma być?

    Czyli rozumiem, że w Agile chodzi o to:

    - Drogi kliencie, po co będziemy marnować N miesięcy na pisanie
    dokumentacji. Zrezygnujmy z niej w imię oszczędności i przyśpieszenia
    projektu.
    - OK! Oszczędności i przyśpieszenie to jest to, co lubimy najbardziej!
    - Fajnie. Kupiliśmy zapas kawy i cisteczek na N miesięcy. Zapraszamy
    do naszego biura, spędzimy ten czas na pisaniu notatek. Jak tych
    notatek będzie bardzo dużo, to zepniemy do segregatora.

    Coś jakby mi sprzedawca samochodów wciskał, że jak kupię u niego auto,
    to przez następne 10 lat nie będę musiał *w ogóle* płacić za benzynę.
    Tyle, że będę musiał płacić za olej napędowy. Słaby pomysł (zwłaszcza
    teraz).

    Sorki, ale na czym polega postęp? Na wciskaniu ludziom kitu, czy na
    tym, że słowo "notatki" albo "user stories" jest bardziej cool, niż
    "dokumentacja"?
    (fakt, że krótsze słowa prędzej się zmieszczą w Twitterze - może o to
    chodzi?)

    I przede wszystkim - w jakiż to sposób zapewnimy, że notatki będą
    zgodne z rzeczywistością, że się nie rozjadą i że i tak dalej - tutaj
    wstaw *wszystkie* zarzuty, które miałeś do dokumentacji a nagle
    problemu cudownie nie ma przy notatkach?
    Czary mary?

    --
    Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com


  • 98. Data: 2011-12-18 16:25:22
    Temat: Re: Porównanie różnych języków
    Od: Andrzej Jarzabek <a...@g...com>

    On 18/12/2011 15:40, A.L. wrote:
    > On Sun, 18 Dec 2011 12:14:48 +0000, Andrzej Jarzabek
    > <a...@g...com> wrote:
    >>
    >> Więc po pierwsze temat kontaktów z przyszłym użytkownikiem: generalnie
    >> nie jest konieczny. XP zaleca, żeby w miarę możliwości "on-site
    >> customer" był przedstawicielem typowego użytkownika systemu, ale nie
    >> jest to jedyna możliwość. Podstawą jest to, żeby ludzie występujący w
    >> rolach "customer representative" albo "product owner" rozumieli potrzeby
    >> użytkownika, ewentualnie mieli możliwość szybkiego dowiedzenia się jakie
    >> one są w szczególnym przypadku.
    >
    > PROGRAMISCI kontaktuja sie z uzytkownikiem gdy tzreba pierdyknac bazke
    > danych szlauchow i kaloszy. W duzych projektach, programiste od

    Jak rozumiem dla kolegi duży projekt to jest taki,w którym pracuje 50
    programistów i więcej. Więc ja powtórzę - te metodologie sie stosuje, i
    moje doświadczenia dotyczą niedużych projektów - mniej więcej od 6 do 20
    programistów. Nie mam pojęcia, jakiej wielkości są projekty tworzenia
    baz danych szlayuchów i kaloszy, bo przyznam, że w tej akurat dziedzinie
    doświadczenia żadnego nie mam, ale takie wielkości projektów, o których
    mówię, to są np. market data systems, tradig platforms, order routing,
    algorithmic trading, securities finance, różne systemy middle i back
    office itd.

    > klienta dzieli dobre pare warstw organizacji i kudzi.

    Dodatkowo, w wielu organizacjach struktura jest taka, że klientem
    jednego zespołu jest inny zespół w tej samej firmie. Na przykład
    klientami dla systemu podającego dane z giełdy może być kilka zespołów
    tworzących produkty korzystające z tych danych.

    > Ciekawe ile jescza razy trzeba bedzie to powtarzac?

    Nie ma potrzeby - bez kwatyfikatora to zdanie ma zerową wartość
    informacyjną.


  • 99. Data: 2011-12-18 16:54:01
    Temat: Re: Porównanie różnych języków
    Od: Andrzej Jarzabek <a...@g...com>

    On 18/12/2011 16:22, Maciej Sobczak wrote:
    > On Dec 18, 2:46 am, Andrzej Jarzabek<a...@g...com>
    > wrote:
    >
    >>> Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
    >>> kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
    >>> krótką listą zakupów, ale dłuższe opisy mi się urywają.
    >>
    >> Sprzedam ci niezły patent: notatki.
    >
    > Zaraz, zaraz. Pisałeś na początku, że dokumentacji ma nie być. Teraz
    > piszesz, że ma być?

    Jeśli wynotowanie sobie czegoś podczas rozmowy na kartce papieru to już
    "dokumentacja" to się nie zrozumieliśmy. Oczywiście w ramach powiedzmy
    XP jak najbardziej notuje się rzeczy na kartkach papieru.

    > Czyli rozumiem, że w Agile chodzi o to:
    >
    > - Drogi kliencie, po co będziemy marnować N miesięcy na pisanie
    > dokumentacji. Zrezygnujmy z niej w imię oszczędności i przyśpieszenia
    > projektu.
    > - OK! Oszczędności i przyśpieszenie to jest to, co lubimy najbardziej!
    > - Fajnie. Kupiliśmy zapas kawy i cisteczek na N miesięcy. Zapraszamy
    > do naszego biura, spędzimy ten czas na pisaniu notatek. Jak tych
    > notatek będzie bardzo dużo, to zepniemy do segregatora.

    Nie, nie ma żadnych N miesięcy na pisanie notetek i nie ma wpinania
    notatek do segregatora. Notatki służą do tego, żeby pomiędzy rozmową z
    OSCR-em a zakodowaniem uzyskanej informacji rozmawiający nie zapomniał.
    Ten czas, to bardzo rzadko więcej niż dzień, nigdy więcej niż 3-4 dni.

    > Sorki, ale na czym polega postęp? Na wciskaniu ludziom kitu, czy na
    > tym, że słowo "notatki" albo "user stories" jest bardziej cool, niż
    > "dokumentacja"?
    > (fakt, że krótsze słowa prędzej się zmieszczą w Twitterze - może o to
    > chodzi?)

    Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
    piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
    przez OSCR-ów są priorytetyzowane na początku każdej iteracji i według
    ich ważności i szacowanego czasu wykonania wybierany jest zestaw do
    wykonania w czasie następnej iteracji (np. tygodnia). Wszystkie user
    stories, które nie są zaplanowane na kolejną iterację, mogą do następnej
    iteracji zostać wykreślone albo zmienione. Z kolei w ciągu tego tygodnia
    mogą zostać stworzone nowe stories, które dla klienta będą ważniejsze
    niż te, które są już w backlogu. Co tydzień kolejna iteracja planowana
    jest na zasadzie: wybiera się stories, które są najważniejsze do
    zrobienia; programiści szacują, ile zajmie zrobienie każdej story, po
    czym product owner w porozumieniu z ewentualnymi OSCR-ami decyduje co
    będzie robione w kolejnej iteracji. W ramach kompletowania danej story
    oczywiście może powstawać dokumentacja końcowa, w której jest napisane,
    że program ma daną funkcjonlaność i jak ona działa.

    > I przede wszystkim - w jakiż to sposób zapewnimy, że notatki będą
    > zgodne z rzeczywistością, że się nie rozjadą i że i tak dalej - tutaj
    > wstaw *wszystkie* zarzuty, które miałeś do dokumentacji a nagle
    > problemu cudownie nie ma przy notatkach?
    > Czary mary?

    Przede wszystkim czas - czas życia notatki mierzony jest raczej w
    godzinach, od momentu zrobienia do momentu zapisania odpowiedniej treści
    w postaci testów i (potencjalnie jeszcze nie działającego) kodu. Potem
    już nikogo nie obchodzi, że się rozjedzie, bo będzie w koszu na śmieci.


  • 100. Data: 2011-12-18 17:05:24
    Temat: Re: Porównanie różnych języków
    Od: Andrzej Jarzabek <a...@g...com>

    On 18/12/2011 16:11, Maciej Sobczak wrote:
    >
    > Żatry na bok, ale w powyższym przypadku jest bug w dokumentacji. Jej
    > zaletą jest fakt, że łatwiej znaleźć buga w dokumentacji, która
    > istnieje, niż w dokumentacji, która nie istnieje. W szczególności,
    > dokumentacja jest materiałem, który odtwarza się w posób powtarzalny,
    > podczas gdy rozmowy z OSCR mogą zawierać składnik stochastyczny
    > zależny od tego, ile kawy OSCR w danym dniu wypił.
    > Dlatego dokumentację można np. powielić i dać do audytu. Nawet
    > równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.

    Acceptance tests mają takie ficzery.

    >> Jeżeli działa niezgodnie z nieistniejącą dokumentacją, to nie przechodzi
    >> testów i nie może zostać zreleasowany.
    >
    > Jakich testów? Tych, które powstały na podstawie nieistniejącej
    > dokumentacji i są z tą nieistniejącą dokumentacją niezgodne?

    Testów, które powstały na podstawie rozmowy z OSCR-em i zostały przez
    tego OSCR-a zatwierdzone.

strony : 1 ... 9 . [ 10 ] . 11 ... 16


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: