On Thu, 18 Jul 2013 08:16:48 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:


>Tylko wiesz, sysadminowi na wiele się nie przydaje, przynajmniej na
>razie, a tymczasem mam inne materiały do nauki, takie, które mi się
>rzeczywiście przydadzą (np. Attiya, Welch, "Distributed computing").
>

Nie widze dlaczego ta ksiazka mialaby byc potzrebna do pracy sysadmina

>A swoją drogą, może tak dla odmiany odnieś się do argumentu? Nie
>ograniczaliśmy się do żadnego konkretnego biznesu, w szczególności
>biznesu, który ty widzisz, a którego nie opisujesz, bo zasłaniasz się
>podpisanymi NDAs.
>
>

Widze ze to NDA cie cholernie kluje. NDA zaslanialem sie gdy ktos
pytal mnie o szczegoly projektu. A czym sie zajmuje? Prosze bardzo,
zadna tajemnica. Ostatnie 19 lat spedzilem w amerykanksim pzremysle, w
telekomunikacji, przemysle naftowum i logistyce. Pzrez ostatnie wiele
lat zajmowalem sie optymalizacja procesow w syststemach dostaw (supply
chain), w szczegolnosci w systemach transportowych i wspolpraca
systemow transportowych z magazynami. Od niejakiego czasu przy moim
tytule firmowym jest nalepka "principal". Polowa transportu
amerykanskiego uzywa moich algorytmow i spora czesc europejskiego, w
tym prawie cala Skandynawia. Teraz usiluje te algorytmy
zaimplementowac w Polsce.

No i co, zaspokoiles ciekawosc?

A.L.

do góry

On 2013-07-18, A.L <a...@a...com> wrote:
> On Thu, 18 Jul 2013 08:16:48 +0000 (UTC), "Stachu 'Dozzie' K."
><d...@g...eat.some.screws.spammer.invalid> wrote:
>
>
>>Tylko wiesz, sysadminowi na wiele się nie przydaje, przynajmniej na
>>razie, a tymczasem mam inne materiały do nauki, takie, które mi się
>>rzeczywiście przydadzą (np. Attiya, Welch, "Distributed computing").
>>
>
> Nie widze dlaczego ta ksiazka mialaby byc potzrebna do pracy sysadmina

To mało sysadminów widziałeś, mój drogi. Nie wszyscy zajmują się samym
aktualizowaniem systemu operacyjnego i dokładaniem dysków w bazie
danych.

A dlaczego Prolog miałby się przydać, skoro nie widzisz zastosowania dla
teorii obliczeń rozproszonych?

>>A swoją drogą, może tak dla odmiany odnieś się do argumentu? Nie
>>ograniczaliśmy się do żadnego konkretnego biznesu, w szczególności
>>biznesu, który ty widzisz, a którego nie opisujesz, bo zasłaniasz się
>>podpisanymi NDAs.
>>
>>
>
> Widze ze to NDA cie cholernie kluje. NDA zaslanialem sie gdy ktos
> pytal mnie o szczegoly projektu.

Kłuje jedynie wtedy, gdy wyciągasz argument, że ty coś robiłeś, ale nie
możesz powiedzieć co, bo masz NDA, więc dyskutant powinien uwierzyć na
słowo.

> A czym sie zajmuje? Prosze bardzo,
> zadna tajemnica. Ostatnie 19 lat spedzilem w amerykanksim pzremysle, w
> telekomunikacji, przemysle naftowum i logistyce. Pzrez ostatnie wiele
> lat zajmowalem sie optymalizacja procesow w syststemach dostaw (supply
> chain), w szczegolnosci w systemach transportowych i wspolpraca
> systemow transportowych z magazynami. Od niejakiego czasu przy moim
> tytule firmowym jest nalepka "principal". Polowa transportu
> amerykanskiego uzywa moich algorytmow i spora czesc europejskiego, w
> tym prawie cala Skandynawia. Teraz usiluje te algorytmy
> zaimplementowac w Polsce.
>
> No i co, zaspokoiles ciekawosc?

Zasadniczo tak.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Thu, 18 Jul 2013 14:14:17 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:

>On 2013-07-18, A.L <a...@a...com> wrote:
>> On Thu, 18 Jul 2013 08:16:48 +0000 (UTC), "Stachu 'Dozzie' K."
>><d...@g...eat.some.screws.spammer.invalid> wrote:
>>
>>
>>>Tylko wiesz, sysadminowi na wiele się nie przydaje, przynajmniej na
>>>razie, a tymczasem mam inne materiały do nauki, takie, które mi się
>>>rzeczywiście przydadzą (np. Attiya, Welch, "Distributed computing").
>>>
>>
>> Nie widze dlaczego ta ksiazka mialaby byc potzrebna do pracy sysadmina
>
>To mało sysadminów widziałeś, mój drogi. Nie wszyscy zajmują się samym
>aktualizowaniem systemu operacyjnego i dokładaniem dysków w bazie
>danych.
>
>A dlaczego Prolog miałby się przydać, skoro nie widzisz zastosowania dla
>teorii obliczeń rozproszonych?

Do tego do czego ksiazka Welsha: do rozwoju intelektualnego. Akurat
ksiwazke Welsha znam - neizla ksiazka, ale dosyc teoretyczna.
Niespecjalnie wiem po co PRAKTYCZNIE adminowi teoria rozproszonych
algorytmow wzajemnego wykluczania.

Co nei znaczy ze uwazam za niewlasciwe studiowanie Welsha - wrecz
pzreciwnie. Wszsystkim polecam

A.L.

do góry

On 2013-07-18, A.L <a...@a...com> wrote:
> On Thu, 18 Jul 2013 14:14:17 +0000 (UTC), "Stachu 'Dozzie' K."
><d...@g...eat.some.screws.spammer.invalid> wrote:
>
>>On 2013-07-18, A.L <a...@a...com> wrote:
>>> On Thu, 18 Jul 2013 08:16:48 +0000 (UTC), "Stachu 'Dozzie' K."
>>><d...@g...eat.some.screws.spammer.invalid> wrote:
>>>
>>>
>>>>Tylko wiesz, sysadminowi na wiele się nie przydaje, przynajmniej na
>>>>razie, a tymczasem mam inne materiały do nauki, takie, które mi się
>>>>rzeczywiście przydadzą (np. Attiya, Welch, "Distributed computing").
>>>>
>>>
>>> Nie widze dlaczego ta ksiazka mialaby byc potzrebna do pracy sysadmina
>>
>>To mało sysadminów widziałeś, mój drogi. Nie wszyscy zajmują się samym
>>aktualizowaniem systemu operacyjnego i dokładaniem dysków w bazie
>>danych.
>>
>>A dlaczego Prolog miałby się przydać, skoro nie widzisz zastosowania dla
>>teorii obliczeń rozproszonych?
>
> Do tego do czego ksiazka Welsha: do rozwoju intelektualnego. Akurat
> ksiwazke Welsha znam - neizla ksiazka, ale dosyc teoretyczna.

Szkoda że jeszcze nie znasz Welch, bo ma na imię Jennifer. Ale to
niemerytoryczna uwaga. A z książki jestem zadowolony właśnie dlatego, że
teoretyczna. Za książkami popularnoinformatycznymi nie przepadam, zwykle
wygodniej mi przejrzeć fafnaście samouczków w internetsach.

> Niespecjalnie wiem po co PRAKTYCZNIE adminowi teoria rozproszonych
> algorytmow wzajemnego wykluczania.

Przygotowuję się do prac nad pewnym pomysłem (bazą), który będzie
korzystać z tego obszaru, a że silnik jeszcze nie istnieje, to najpierw
by wypadało trochę umieć.

--
Secunia non olet.
Stanislaw Klekot

do góry

Użytkownik "Adam Klobukowski" napisał w wiadomości grup
dyskusyjnych:8cf2e6da-5b46-4658-9844-ecbbaad8298b@go
oglegroups.com...

>Pierwsze testy powinny sprawdzać czy cokolwiek się liczy oraz warunki
>brzegowe. W późniejszym okresie dodaje się testy na dane wejściowe które
>wygenerowały błędy.

Czy cokolwiek się liczy to widać: program działa, sam z siebie się kończy i
nawet są jakieś wyniki inne niż NAN czy INF. Do tego akurat "specjalne
testy" nie są potrzebne.

>Metodologie Agile (bo jest ich wiele) zakładają że w projekcie, aktywnie
>bierze udział reprezentant klienta. Jednocześnie krótkie okresy iteracji
>projektu powodują dobrą widoczność >zaawansowania. Zmianę wymagań można
>rozegrać na wiele sposobów, ale podstawową zasadą Agile jest to że
>wymagania się zmieniają. W momencie zmiany, reprezentant klienta dowiaduje
> >się czy trzeba coś zmienić w już wykonanych elementach i albo to
>zaakceptuje (i przez to dodatkowy budżet) albo nie. Nie mam w tym mowy aby
>firma tworząca system robiła coś za darmo.

Sorry, ale Agile to nie metodologia, ale metodyka. Metodologią jest
dyscypliną badającą metodyki, w tym sensie możliwa jest metodologia metodyk
zwinnych.

Ad rem: swego czasu pomagałem komuś przepisać jego twórczość literacką do
postaci pliku wymaganego przez redakcję. Ponieważ był to przyjaciel, to
znosiłem cierpliwie fakt, że gdy przepisałem kolejne 100 stron, to ów
humanista domagał się aby 50 z nich zastąpić zupełnie innym tekstem (całość
miała stron kilkaset). I tak wiele, wiele razy. Oczywiście gdy pracowaliśmy
nad stronami od 360 do 490... to "koncepcja się zmieniała" i trzeba było
wyrzucić to strony od np. 30 do 190... bo tam przyjdzie zupełnie nowy tekst.
Nie pamiętam ile to trwało, rok, czy trochę dłużej. Jednym z zasadniczych
problemów polegał bowiem na tym, iż ów literat nie płacił, więc nie odczuwał
jakiegokolwiek przymusu ogarnięcia się co do organizacji pracy. Wprost
powiedzieć żeby poszedł szukać innego naiwnego nie było można, bo obraziłaby
się rodzina, ksiądz proboszcz i lokalna społeczność. Zresztą to był
przyjaciel.

Jeżeli w Agile zakłada się "przyjacielski" kontakt producenta software (a
wręcz programistów) z zamawiającym dzieło klientem, to naprawdę wątpię, czy
udaje się uniknąć podobnych sytuacji.

do góry

Użytkownik "Adam Klobukowski" napisał w wiadomości grup
dyskusyjnych:3e898997-4438-4dc0-a895-f82da449ba62@go
oglegroups.com...

>W przypadku Agile, klient jest włączony w cały proces powstawania systemu,
>[...]

Możemy chyba się zgodzić, że dla oprogramowania "sweterkowego", tj. jakieś
Linuksy, GNU, akademickie projekty (bynajmniej nie dezawuuję) - to Agile
może być niezłym sposobem organizacji pracy, nieco bardziej formalnym niż
brak jakiejkolwiek organizacji.

Możemy się zgodzić, że jeżeli dział IT jest w jakimś dużym zaibatsu, to
Agile też jest ok - bo nad "klientem" i nad "programistami" jest ten sam
uber-szef (lub uber-szefowa). I jakby coś było bardzo nie tego, to wszyscy i
tak płyną w tej samej łodzi. Dotyczyć może to m.i. branży gier
komputerowych.

Możemy się także zgodzić, że Agile może nie być najlepszą metodą dla
"pewnego typu projektów". Tzn. że jeżeli ktoś WIE czym jest Agile i
ŚWIADOMIE nie używa - to widocznie jest to z jego strony spostrzegane jako
racjonalna decyzja... i naprawdę nic nam do tego.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ks5dga$ei6$...@s...invalid...

>Kto tak napisał? I jak to argumentował?

Rozdział 4.,
http://helion.pl/ksiazki/czysty-kod-podrecznik-dobre
go-programisty-robert-c-martin,czykod.htm

>Mylisz testowanie z formalną weryfikacją. Ideą testowania (tak w ogóle, nie
>tylko w agile) jest to, że sprawdzenie działania programu na próbie

Nie mylę. Po prostu trolluję. Nota bene, nie jest tak źle: liczb jest nie
1E38, ale około 2^56, bo tyle różnych mantys może być. Ale to tak na
marginesie.

>bardziej, i dla konkretnego przypadku twoim zadaniem jest wykombinować,

Ajtam moje zdanie. Moje zdanie to tylko moje zdanie. Problem zaczyna się
wtedy, gdy wychodzi "brzydka prawda" - np. błąd FDIV w CPU Pentium "trochę
kosztował" firmę Intel.

Czy testy + nisko kwalifikowana niedbała kadra mogą przed tym zabezpieczyć
lepiej niż po prostu staranność, myślenie, zatrudnianie fachowców? Testy
jednostkowe (czy jakiekolwiek) nie sprawdzają się - moim zdaniem - jako
proteza IQ i umiejętności. Ale to jest tylko moje zdanie.

>podstawie wiedzy jak wewnętrznie działa to, co jest testowane. W tym
>przypadku jako programista piszący testy wiesz, jakiego algorytmu będziesz
>używał do implementacji dzielenia i na tej podstawie możesz

Problem jaki powstaje - to zwiększenie złożoności. Testy. Testy do testów.
Moduł testowy testujący moduł weryfikujący. Całość robi się... no właśnie,
jaka?

Wszystko to zabiera czas i zasoby (ludzkie, nie komputera). A tych zasobów
jest ograniczona ilość.

>Których podręczników? W tych podręcznikach, które znam, zaleca się
>stosowanie kontraktu typu time&materials, wtedy nie ma tego problemu -
>klient chce zmiany specyfikacji, robi się szacunek kosztu tej zmiany i
>klient decyduje, czy woli płacić za to, czy za co innego, czy też przestać
>płacić i odebrać produkt taki, jaki jest. Z czytanych przeze

O to klawo jak cholera - time nieskończony (bo czemu nie?), z materiałami
gorzej (ale przecież możemy wmówić klientowi, że np. potrzebujemy
zajefajnego sprzętu, ton papieru, pięciu pięter w biurowcu, dodatkowego
personelu).

Czy jednak nie możemy? Dlaczego nie możemy?!

do góry

On 18/07/2013 21:12, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ks5dga$ei6$...@s...invalid...
>
>> Kto tak napisał? I jak to argumentował?
>
> Rozdział 4.,
> http://helion.pl/ksiazki/czysty-kod-podrecznik-dobre
go-programisty-robert-c-martin,czykod.htm

To jest tłumaczenie Clean Code? Z wrażenia aż zdjąłem z półki i
sprawdziłem, i albo nieuważnie przeczytałeś, albo masz bardzo złe
tłumaczenie. WWłaśnie notki copyrightowe i licencje tam, gdzie jest to
wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
komentarze są bez sensu.

>> bardziej, i dla konkretnego przypadku twoim zadaniem jest wykombinować,
>
> Ajtam moje zdanie. Moje zdanie to tylko moje zdanie. Problem zaczyna się
> wtedy, gdy wychodzi "brzydka prawda" - np. błąd FDIV w CPU Pentium
> "trochę kosztował" firmę Intel.

Można po pierwsze zwrócić uwagę, że to problem sprzętowy, a nie
software'owy. Metodologie tworzenia oprogramowania nie mają zastosowania
- chociaż zdaje się unit testy są inspirowane rozwiązaniami z
elektroniki. Ja w każdym razie nie znam się na tyle, żeby doradzać
Intelowi, jak testować procesory.

Tak czy inaczej, firma Intel jak ostatnio sprawdzałem to jescze istniała.

> Czy testy + nisko kwalifikowana niedbała kadra mogą przed tym
> zabezpieczyć lepiej niż po prostu staranność, myślenie, zatrudnianie
> fachowców? Testy jednostkowe (czy jakiekolwiek) nie sprawdzają się -
> moim zdaniem - jako proteza IQ i umiejętności. Ale to jest tylko moje
> zdanie.

To, co przedstawiasz, to fałszywa alternatywa. Albo zatrudniasz
fachowców i wtedy masz wybór między zatrudnianiem fachowców i
testowaniem a zatrudnianiem fachowców i nie testowaniem, albo z jakiegoś
powodu wolisz zatrudnić nisko kwalifikowaną niedbała kadrę, i wtedy też
masz wybór między taką kadrą i testami albo taką kadrą i brakiem testów.

>> podstawie wiedzy jak wewnętrznie działa to, co jest testowane. W tym
>> przypadku jako programista piszący testy wiesz, jakiego algorytmu
>> będziesz używał do implementacji dzielenia i na tej podstawie możesz
>
> Problem jaki powstaje - to zwiększenie złożoności. Testy. Testy do
> testów. Moduł testowy testujący moduł weryfikujący. Całość robi się...
> no właśnie, jaka?

Jakie testy do testów? Do testów nie piszesz testów przecież. Co to jest
w tym przypadku "moduł weryfikujący"? Testy jednostkowe (a także
acceptance tests) są testowane w metoldach TDD ręcznie w bardzo prostu
sposób - zaczynasz od pisania testu, jeśli test przechodzi, znaczy że
jest źle napisany. Następnie implementujesz to, co test testuje i
regularnie zapuszczasz testy, jeśli testy przejdą zanim skończysz, to
znaczy że test jest źle napisany. Jeśli skończysz, a test nie
przechodzi, to dedukujesz tradycyjnymi metodami dlaczego i albo
znajdujesz błąd w kodzie, albo w teście.

> Wszystko to zabiera czas i zasoby (ludzkie, nie komputera). A tych
> zasobów jest ograniczona ilość.

Oczywiście, ale konsekwencje braku unit testów (i innych testów
automatycznych) często zabierają więcej czasu i zasobó niż pisanie tych
testów.

>> Których podręczników? W tych podręcznikach, które znam, zaleca się
>> stosowanie kontraktu typu time&materials, wtedy nie ma tego problemu -
>> klient chce zmiany specyfikacji, robi się szacunek kosztu tej zmiany i
>> klient decyduje, czy woli płacić za to, czy za co innego, czy też
>> przestać płacić i odebrać produkt taki, jaki jest. Z czytanych przeze
>
> O to klawo jak cholera - time nieskończony (bo czemu nie?), z
> materiałami gorzej (ale przecież możemy wmówić klientowi, że np.
> potrzebujemy zajefajnego sprzętu, ton papieru, pięciu pięter w biurowcu,
> dodatkowego personelu).
>
> Czy jednak nie możemy? Dlaczego nie możemy?!

Czas w time and materials jest taki, za jaki klient chce zapłacić. Chce
płacić w nieskończoność to może. Część "materials" jest zwykle wpisana w
umowę, czym może być, czym nie może - zazwyczaj to są rzeczy typu
pokryci kosztów podróży i takie tam.

Znowu - możesz sobie zawrzeć taką umowę, na jaką się zgadzasz z drugą
stroną (chyba że nielegalna albo nieważna).

do góry

On Thu, 18 Jul 2013 06:55:29 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>
>> Zasadą metodyk Agile jest to że wymagania są płynne i mogą się zmienić.
>
>Tak. Ale jednocześnie niejawnie sugeruje, że te zmiany są tanie. Tymczasem nie są.


Zmiany tanie nie sa. Potwierdzam.

Gdy sie umawia z klientem na wykonanie projektu, to trzeba wiedziec
ile projekt bedzie kosztowal. Ustala sie to na podstaawie dokumentu
wysylanago pzrez klienta do potencjalnych wykonawcow. gdzie sa
wyspecyfikowane wymagania dotyczace projektu. Firmy wyceniaja i klient
wybiera firme ktora chce. Niekoniecznie najtansza. Normalka.

Teraz, jak sie podpisze kontrakt, to jest obopolne porozumienie ze a)
klient nie bedzei wymagal wiecej niz jest w kontrakcie, ani inaczej
niz jest w kontrakcie b) dostawca dostarczy produkt zgodznie ze
specyfikacja, w budzecie i w czasie.

Wszelkie zmiany dotyczace zakresu projektu natychmiast rodza pytanie:
"kto za to zaplaci". Bo wykonawcanei widzi powodu - tej dodatkowej
funkcjonalnosci nie bylo w specyfikacji. Dodatkowo, takie extra
wymagania naruszaja "timing" projektu - projektu nei da sie wykonac na
czas, a za opoznienia moga byc kary umowne. Wiec co bedzie z tymi
karami?

Obie wysokie strony musza sie dogadac - w sparwie pieniedzy i w
sprawie terminow.

Byc moze w sytuacji gdy caly projekt polega na "pierdyknieciu bazki
szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa Kanalizacyjnego" i
jest robiony pzrez pojedynczego junior developera, mozna sobie
swobodnie agilowac. Ale obawiem sie ze nawet Przedsiebiorstwo
Kanalizacyjne nie wmontowaloby sie w projekt bez ustalenia ile
kosztuje i kiedy bedzie zrobiony. I na pewno Pzredsiebiorstwo
Kanalizacyjne nie wydeleguje swojego pracownika zeby siedzial z owym
deweloperem i patrzal mu na rece. Parcownicy Pzredsiebiorstwa
Kanalizacyjnego musza sie bowiem zajmowac kanalizacja

Zeby bylo konkretnie - bylem swiadkiem projektu w ktorym dodanie pol
strony do specyfikacji kosztowalo zleceniodawce cwierc miliona
dolarow. I nie bylo to nic takiego nadzwyczajnego

A.L.

do góry

On Thu, 18 Jul 2013 08:09:35 -0500, A.L. <a...@a...com> wrote:
> Wszsystkie "niowoczesne methodologie" typu Agile, Extreme
Programming
> itede maja jeden glowny cel: dupochron dla firmy robiacej soft.

No więc ja pracuję w firmie ktora buduje cos czego nikt inny przedtem
nie zrobil, i wymagania wobec systemu zmieniają sie praktycznie co
tydzień w miarę jak uczymy sie nowych rzeczy o tym czego potrzeba
klientom, czego klienci myślą ze im potrzeba i jakie sa warunki
przyrodnicze w których to ma byc zrealizowane. I Agile jest w
zasadzie jedynym rozwiązaniem: żeby przeżyć i osiągnąć swoj cel,
firma nie moze reagować na zmianę wymagań i uwarunkowań z
parotygodniowym opóźnieniem potrzebnym na uzgodnienie aneksu do
umowy.

RW

do góry