Andrzej Jarzabek wrote:

>> Mało prawdopodobne, aby w wyniku zwykłej pomyłki a nie celowego psucia
>> rozdzielić taką sekwencję do osobnych bloków:
>>
>> int fd = jakas_tam_metoda_tworzenia_fd();
>> fd_guard_t fd_guard(fd);
>
> Nie jest to aż tak mało prawdopodobne, żeby dla wielu takich mało
> prawdopodobnych zdarzeń te prawdopodobieństwa nie skumulowały się do
> czegoś zbliżonego do pewności.
>
>>> albo ktoś gdzies wstawi zamykanie tego deskryptora ręcznie.
>>
>> Opakowanie deskryptora w obiekt też wiele na to nie pomoże, bo np. dalsza
>> część funkcji chciała coś wysłać przez deskryptor, a on zamknięty.
>
> Kompilator wyłapie, że obiektu nie ma w zakresie.

Wyolbrzymiasz bardzo mały problem.
A pozbycie się tego małego problemu nie jest pozbawione kosztów.

>>> streambuf ma buforowanie, więc tak to właśnie raczej powinno działać.
>>> Jednak musisz przyznać, że z punktu widzenia kogoś, kto chce
>>> sfotmatować komunikat i przesłać go po połączeniu albo z kolei
>>> odczytać komunikat zakończony np. CR-LF, niekoniecznie takie szczegóły
>>> implementacyjne są interesujące.
>>
>> Są interesujące, jeśli nie chce aby użytkownik przy jego programie
>> ćwiczył swoją cierpliwość - gdy akurat przywiesiło się połączenie.
>
> No więc z punktu widzenia sensowności organizacji kodu (i co za tym
> idzie niezawodności, maintainability itd.) to mieszanie obsługi
> przywieszonego połączenia z logiką obsługi tego, o czym program jest
> informowany albo o czym informuje za pomocą tego połączenia to tragedia.

Wolę "tragedię" z punktu widzenia organizacji kodu, z jednoczesnym poprawnym
działaniem programu, zamiast kiepskiego działania a za to świetnej
organizacji.

>> Albo załóżmy, że mamy prosty protokół, gdzie każda ze stron, na przemian
>> wysyła po jednej lub więcej linii tekstu. Za pomocą interfejsów istream
>> tego się nie odbierze, bo nie wiadomo ile linii zostało przysłanych.
>
> Sensowne protokoły mają zwykle jakiś sposób zaznaczania końca komunikatu.

Rzućmy innym przykładem: IMAP. Zanim serwer skończy obsługę poprzednich
żądań, można już mu wysłać kolejne.

>>> Sensowniejsze o tyle, że masz rodzieloną logikę mówiącą jak na jakieś
>>> zdarzenie trzeba reagować z samą obsługą i rozstrzyganiem tego, na co
>>> jak trzeba zareagować. W związku z tym komuś dodającemu nowy typ
>>> zdarzenia do obsługi trudniej będzie zepsuć jakiś aspekt istniejącej
>>> logiki, niż jeśli modyfikuje dużą pętlę z 'jeśli sygnał to tamto,
>>> jeśli coś na sockecie to śmamto, jeśli minęło tyle czasu to owamto".
>>
>> Wszystko zależy od przypadku. Czasem lepiej widać co się dzieje, gdy
>> wszystkie te zdarzenia obsłużone są w jednym miejscu.
>
> Być może, ale to "czasami" według mnie w większości odnosi się do
> niewielkich programów.

Jeśli chodzi o użycia sygnałów, to też mam wrażenie że do dużego programu to
się nie przyda.

>>> W rzeczywistości wątków się używa bo to wydajny i elastyczny sposób na
>>> zrównoleglenie aplikacji. W przypadku stosowania oddzielnych procesów
>>> samo kszta związane z narzutem na ich odpalanie, IPC itd. często
>>> zabijają wszelkie korzyści ze zrównoleglenia.
>>
>> Pamięci dzielonej da się używać także między procesami. Jedyne
>> ograniczenie: nie można między jednym a drugim przekazywać wprost
>> wskaźników. Czy tak często jest to problemem... nie wiem.
>
> Bardzo wiele struktur danych zawiera w sobie wskaźniki. Można oczywiście
> zrobić ich odpowiedniki bez wskaźników, ale to jest dodatkowa
> komplikacja, gorsza wydajność i im więcej tego robisz, tym więcej ci
> wraca problemów, które masz z wątkami.
>
> Pracowałem z takimi systemami, gdzie zamiast wątków robiło się wiele
> procesów operujących na pamięci dzielonej działającej jako prosta baza
> danych, i skalowanie tego było bardzo problematyczne.

Czy po przestawieniu z procesów na wątki stało się mniej problematyczne? Nie
sądzę aby problemy ze skalowaniem wynikały z wyboru procesów zamiast wątków.
Raczej z innych przyczyn.

>> Narzut odpalania występuje także dla wątków.
>
> Znacznie mniejsze.

Masz w pamięci jakieś wyniki pomiarów?

>> Nieprzypadkowo istnieją thread-pool, więc mogą i process-pool.
>
> Można, ale masz dodatkową komplikację opisu każdego zadania i każdego
> rodzaju danych który chcesz przekazać. Na wątkach można po prostu
> przekazać jakiegoś dowolnego funktora.

Na ten temat mam zdanie zgodne z książką "The art of Unix programming":
http://www.catb.org/~esr/writings/taoup/html/ch07s03
.html#id2923889

Zacytuję fragment:
Threads are a fertile source of bugs because they can too easily know too
much about each others' internal states. There is no automatic
encapsulation, as there would be between processes with separate address
spaces that must do explicit IPC to communicate. Thus, threaded programs
suffer from not just ordinary contention problems, but from entire new
categories of timing-dependent bugs that are excruciatingly difficult to
even reproduce, let alone fix.

>> W samym Linuksie dodawane są też wywołania systemowe, które nowej
>> funkcjonalności tak na prawdę nie wprowadzają, tylko zapewniają inny
>> interfejs do funkcjonalności już istniejących. Np. timerfd_create,
>> signalfd. Dla frameworka to bez większej różnicy, natomiast jest różnica
>> dla programów operujących bezpośrednio na tym API.
>> [Wymienione przeze mnie przykłady są Linux-specific, ale w końcu to też
>> [jest
>> uniksowego API].
>
> Drugi problem, o którym miałem napisać, ale zapomniałem, to że te
> interfejsy systemowe są zazwyczaj w C, a to język wyjątkowo kiepsko
> nadający się do wyrażania jakichkolwiek abstrakcji.

Abstrakcja deskryptora plików wyrażona jest świetnie.

do góry

On 5-10-2011 16:10, Andrzej Jarzabek wrote:
> On Oct 4, 2:15 pm, "Sarr."<s...@g...pl> wrote:
>> On 29-9-2011 2:20, Andrzej Jarzabek wrote:
>
>> podalem swoje stanowisko w tej kwestii bazujac na swoich
>> informacjach, nie wprowadzilem nikogo w blad. podalem tez wczesniej
>> dlaczego uwazam, ze w grach jest wiecej miejsca dla innowacji. moze nie
>> mam szczescia miec znajomych, ktorzy pracuja w innowacyjnych startupach,
>> takich jakich masz ty.
>
> Akurat jeśli chodzi o innowacyjne startupy i inne innowacyjne
> działania poza branżą gier to moje informacje nie pochodzą raczej od
> znajomych, tylko z tzw. rozeznania rynku. W dużym skrócie polega to na
> tym, że czasem się dowiaduję z różnych źródeł (np. w związku z tym co
> robię zawodowo albo od potencjalnych pracodawców szukających
> pracownika) że robi się albo że wyszedł jakis produkt mający takie lub
> inne ficzery i czasem nawet rozumiem z tego na tyle dużo, że wiem, że
> dany ficzer jest innowacyjny. Z jednej strony oceniam te informacje z
> takiej perspektywy, że ani za bardzo nie śledzę branży, ani się
> szczególnie dobrze na tym nie znam, więc zapewne nawet w tej branży
> istnieje ogromna ilość innowacji o których nie wiem, lub nie wiem, że
> są innowacjami. Z drugiej strony wiem, że jak ktoś nie siedzi w
> branży, to ani nigdy nie usłyszy nawet o tych innowacjach, o których
> ja wiem, ani też, gdyby nawet usłyszał, nie wiedziałby czy i na ile
> to, o czym słyszy jest rzeczywiście innowacyjne.
>
> Ja oczywiście mam taki sam problem z innymi branżami - nie mam na
> przykład pojęcia, czy w ERPach czy innych CRMach jest innowacja, ile
> jej jest i na czym polega. Ale zakładam, że skoro nie wiem, to nie
> wiem, bo się nie znam, a nie że skoro nie wiem, to nie ma (albo jest
> jej mniej). Dlatego też jeśli ktoś twierdzi, że skoro branża, w której
> sam siedzi, jest szczególnie innowacyjna, to ciekawi mnie, skąd on to
> wie.

dobrze, podejme sie sprostowania raz jeszcze. wezmy pod uwage innowacje
wewnatrz samej branzy. nie porownujmy do innych.

chodzilo mi o to, ze w grach, wiele jest przypadkow, kiedy robi sie cos
nowego czego nie bylo do tej pory - latwo znalezc calkiem sporo
przykladow - a co czesto nie wypala. w przypadku kiedy jest duza szansa
na to, ze moze nie wypalic, mozna optowac za minimalizacja kosztow,
placac mniej. niekiedy, jesli zespol sie na to zgodzi, z roznych
powodow. na przyklad: panowie koderzy, cos nam nie idzie ostatnio, same
nudy, sprobujmy tak, nie dam wam podwyzki ale za te pieniadze
zorganizujemy sobie licencje na konsole XXX, kupimy dev kity i zrobimy
taka gre, o ktorej sie ludziom nie snilo. jak wypali, to dostaniemy
projekt za lepsze pieniadze i dostaniecie podwyzke, jak nie, to niestety
nic nie moge obiecac, ale moze doswiedczenie z konsola XXX moze sie wam
przydac, co wy na to? wiec, czasem zespol pojdzie na taki uklad.
szczegolnie jezeli rzeczywiscie same nudy, a takie rozwiazanie wprowadzi
troche swiezosci z perspektywami na lepszy pieniadz. to mialem na mysli
- wiedza, ze beda robic cos ciekawego, co moze nie wypalic, wiec na
jeden projekt mozna dac szanse i zacisnac pasa.

w to, ze takie zaciskanie sie moze przeciagac i szefostwo moze
wykorzystywac sytuacje nie wnikam, o tym juz sobie poopowiadalismy.

>> [znowu] sie nie zamierzacm, wiec skonczmy i tutaj, skoro nie chcesz
>> uzasadnic swojej tezy o tym, że innowacji w różnych innych dziedzinach
>> jest też sporo.
>
> No ale jeszcze raz: jak sobie wyobrażasz takie uzasadnienie? Ja
> twierdzę, że jest sporo w różnych branżach o których coś słyszę -
> głównie, choć nie tylko, tej, w której sam pracuję - i potrafię lepiej
> lub gorzej to ocenić, ale jeśli do kogoś te informacje nie docierają
> albo nie zna się na temacie, to nie będzie potrafił nic o tym
> powiedzieć. Tak samo jak ja nic nie potrafię powiedzieć o
> innowacyjności w bardzo wielu innych branżach.

ostatnio czytalem o australijskim studiu, ktore pracowalo nad l.a. noire
-
http://geek.pikimal.com/2011/10/08/team-bondi-owes-e
mployees-1-million-being-taken-to-cleaners/
- wlasnie o takie przyklady mi chodzi, takie rzeczy dzieja sie czesto w
branzy gier, firmy padaja, bo sie przeliczyli. jezeli dalej trwasz przy
swoich racjach, ze ryzyko jest wliczone w development to dlaczego takie
rzeczy sie zdarzaja? oczywiscie pytanie retoryczne.

ja widze kolejny przykald studia, ktore postawilo na innowacje, cos
nowego - nie na skale porownywania tego z innymi branzami ale na nowosc
w branzy - chcieli miec zaawansowana mimike twarzy postaci, zeby calosc
wygladala jak film, zainwestowali w technologie... i w rezultacie studio
pada zadluzone na ciezkie sumy... ktos popelnil blad? oczywiscie, pewnie
nawet niejeden. ale efekt jest jaki jest, zagrano vabank, nie udalo sie.
pewnie pracownicy tego studia mieli poobiecywane bonusy i kto wie co
jeszcze - teraz nie maja nic, i czeka ich troche stresu, zeby cos dostac.

to jest ten mechanizm, napedzany musem nowosci/innowacyjnosci, zawsze
trzeba wymyslic cos nowego, zeby utrzymac sie na topie, co kilka
miesiecy wychodza produkty lepsze, od ktorych trzeba byc jeszcze
lepszym, inaczej traci sie klientow. chodzoilo mi o to, ze nie slyszalem
o takim pedzie w innych branzach, dlatego podalem teze, ze istnieje
tylko w grach. zaden z moich znajomych nie byl w stanie przytoczyc
podobnych historii z innych branzy. takich historii jest duzo, studia
padaja z mniejszych albo wiekszym hukiem - a szeregowy joe, czesto
wybierze brak podwyzki i prace niz bonusy obiecane na papierze i brak
pracy.

>> ostatni raz. pracujac dla potentatow, kodujac najnowsze gry pod
>> najnowszy sprzet, mozesz miec szanse doswiedczenia innowacji, nowosci
>> technicznych, ktore beda na rynku za n miesiecy. realna mozliwosc
>> uzywania nowosci, zapoznania sie z parametrami technicznymi ze swiata
>> gier i multimediow, testowanie prototypow, wyrazania swoich opinii,
>> ktore moga byc uwzglednione w kolejnej iteracji. to sa innowacje, ktore
>> mialem na mysli. to wszystko jest cenione przez niektorych bardzo
>> wysoko. tak wysoko, ze przymykaja oko na same zarobki. dziala to na
>> podobnej zasadzie jak release gry o pewnej godzinie i n setek [czy
>> tysiecy] graczy czekajacych na ten termin zeby wcisnac download i
>> jaknajszybciej zagrac, albo kolejki po najnowsze gadzety do konsol -
>> niektorzy po prostu cenia sobie obcowanie z nowosciami i innowacjami
>> wszelkiej masci.
>
> No przecież właśnie w tym przypadku nie wszelkiej maści, tylko tej
> konkretnie maści. Przecież te same osoby mogą być kompletnie obojętne
> wobec obcowania z nowym rodzajem instrumentów finansowych albo z nową
> technologią zaworów w stacji uzdatniania wody.

tej konkretnie masci. nie bez powodu studia oferujace prace z 'cutting
edge technology' licza na to, ze do nich beda chcieli sie dostac mlodzi
koderzy, ktorzy chca z ta technologia obcowac.

> Jeśli komuś przede wszystkim zależy na innowacji, i jest dobry, to bez
> problemu znajdzie sobie lepiej płatną (albo chociaż potencjalnie
> lepiej płatną) pracę gdzieś, gdzie będą inne rodzaje innowacji z
> którymi obcowanie będą sobie cenić.

innowacja innowacji nie rowna. ja na przyklad wybralbym prace przy
srednio-innowacyjnej grze, niz pisanie oprogramowania pod najbardziej
innowacyjna nawet maszyne do utylizacji odpadow badz prace nad systemem
bankowym jedynym w swoim rodzaju. dokadnie, to zalezy od tego jak bardzo
cenisz sobie pewne srodowisko pracy. dla mnie srednia innowacja w grach
jest bardziej cenna niz super innowacja w bankowosci. to jest czesc
odpowiedzi na to, dlaczego programisci gier dosc pozno uciekaja do
innych branzy.

> A jeśli kogoś interesują konkretnie tylko innowacje z dziedziny gier
> czy nawet ogólniej multimediów, to raczej podchodzi to pod powód "są
> miłośnikami gier i bardzo chcą pracować przy grach" niż "branża
> bardziej innowacyjna niż inne".

branza jest innowacyjna w bardziej medialny sposob, to tez dosyc wazny
argument. to bardziej przyciaga ludzi, wiekszosc przynajmniej. jezeli
ktos jest expertem i zalezy mu na tym, zeby na tym zarabiac, moze
pracowac nad najnowszymi innowacyjnymi zabezbieczeniami systemow obslugi
kart kredytowych - bez watpienia bedzie trzaskal kase. ale wielu wybralo
by zamiast tego prace nad najnowszym ipodem, za mniej niz to co mogli by
dostac gdzie indziej.

>> mysle, ze takie onfo z pierwszej reki, jego odpowiedz na to pytanie
>> miala by szanse wniesc sporo do tej dyskusji.
>
> Jeśli chodzi o moich znajomych, którzy zostali w tamtym studio, to
> nawet bez pytania mogę dać info wnoszące sporo do dyskusji. Na
> przykład ze ząden z nich nie ma rodziny.

sluszna uwaga. mlody, chce sie uczyc, nie ma wygorowanych potrzeb, dac
mu pole do popisu i mozna placic mniej. standard. niestety.

>>> Jeśli mówimy o "programiści w branży gier wideo zarabiają mało" to
>>> raczej jednak mówimy przede wszystkim o robieniu takich gier. To, ile
>>> zarabiają programiści robiący gry na iPhone czy gry indie to jakby
>>> osobny temat.
>>
>>> Według Wikipedii _średnie_ koszta produkcji gry wideo w ubiegłym roku
>>> wynosiły 20 milionów dolarów.
>>
>> nie rozumiem dlaczego wedlug ciebie powinnismy brac pod uwage przede
>> wszystkim produkcje AAA.
>
> Wikipedia podaje, że to są średnie koszta produkcji gry wideo, nie
> średnie koszta "produkcji AAA".
>
> Rozumiem, że skoro mówimy o tym jak płacą w danej branży to nie mówimy
> o ludziach, którzy te gry pisza hobbystycznie albo wystawiają na App
> Store bo liczą, że może zarobi, bo to nie jest ani prawdziwa branża,
> ani nie da się porównywać tego z zarabianiem z tytułu wykonywania
> pracy, a nawet jeśli uznać to za branże, to jest to kompletnie osobna
> branża.

moze wypadalo by zaczac od tego, ze koszty programistow to kropla w
morzu kosztow produkcji gier AAA. nie mozna na tej podstawie powiedziec,
ze programisci powinni dobrze zarabiac. wiekszosc idzie na content - gry
musza wygladac ladniej, lepiej, ma byc lepsza muzyka, trzeba zatrudnic
znanych tworcow, designerow, maja byc efekty specjalne, wiec tuzin
grafikow i animatorow, do cut-scenes trzeba wziac rezyserow, aktorow do
podkladania glosow pod bohaterow, inwestowac w nowe technologie [patrz
l.a noire wspomniane powyzej], do tego marketing, ktory tez sporo
kosztuje...

>>> A dlaczego nie są w stanie powiedzieć "ok, przymknę oko na same zarobki,
>>> bo wiem, że nie ma gwarancji, że produkt finalny przyniesie zysk, ale za
>>> to gdyby jednak przyniósł zysk, to chciałbym mieć na papierze
>>> zagwarantowany bonusik odpowiedni do tego zysku"? Według mnie nie są w
>>> stanie, bo nie mają pozycji przetargowej.
>>
>> jesli mozesz zapomniec na chwile o samych produkcjach korporacji i AAA,
>> to powiem, ze sa studia, male, malutkie, ktore pracuja nad malymi
>> projektami, malo placa pracownikom, ale maja ambicje. jesli w studiu
>> panuja stosunki partnerskie, to ci ktorzy w nich pracuja, wiedza, ze
>> szefa nie stac na to, zeby przystal na takie warunki o jakich piszesz,
>
> Ale to przecież bzdura, że go nie stać. Stać go jak najbardziej, z
> definicji, bo są to przecież bonusy uzależnione od _zysków_. Natomiast
> mimo że go stać, to tego nie zrobi, bo pracownicy zgodzą się pracować
> i bez tego, a gdyby to zrobił, to uszczupliłby zyski kapitalisty. A
> rolą szefa jest maksymalizacja zysków kapitalisty, i jeśli w tym celu
> musi skłamać, że "nie stać go", i jeśli musi dla sprzedania tego
> kłamstwa stworzyć iluzję "stosunków partnerskich", to tego właśnie
> wymaga od niego stanowisko.

<sarkazm> znakomity przyklad bonusow uzaleznionych od zyskow mamy
sytuacji l.a. noire - pewnie teraz bardzo ciesza sie z wynegocjowanych
dodatkow </sarkazm>

>>>>> * W związku z tym sądzę, że kapitał, który finansuje studia po prostu
>>>>> liczy się z ceną rynkową wszystkich kosztów, w tym pensji programistów.
>>>>> Gdyby ta cena była wyższa, to kapitał na taką też cenę by przystawał -
>>>>> bo w to, żeby się przestało opłacać robić gry to raczej nie wierzę.
>>>> gdyby tak bylo, to studia by nie padaly ;]
>>
>>> Nieprawda. Ryzyko padnięcia studia też jest wliczone w kalkulację.
>>
>> coz, twoje uzasadnienie tez nie poraza argumentami.
>
> A masz może jakieś porażające argumenty na to, że nie jesteś
> wielbłądem?

nie mam garba ;]
a powaznie, wytlumacz mi wiec wspomniane juz nie raz l.a. noire.
przepraszam, ze naduzywam tego przykladu, ale to jest ostatnia tego typu
sytuacja, o ktorej slyszalem. jezeli chcesz, moge podac inne przyklady
gdzie za padem studia krylo sie innowacyjne [w swietle gier]
rozwiazanie, ktore w ogolnym rozliczeniu nie oplacilo sie. a ty
sprobujesz wyjasnic, dlaczego jednak ryzyko nie bylo wliczone w kalkulacje.

>> ja z kolei powiem
>> tak: czesto male studia, ktore 'ledwo odrosly od ziemi', biora sie za
>> cos, czemu nie moga sprostac [oczywiscie nie wiedzac o tym], sa
>> przekonane, ze to jest ich szansa na sukces, lukratywna propozucja, moze
>> organizuja sponsorow, czesciowo sa finansowane, pracuja ale nie sa w
>> stanie wykonac tego co zaplanowaly, sponsorzy sie orientuja, ze nie jest
>> rozowo, przestaja finansowac, bez finansowania, studio uszczupla zaloge,
>> brak sily roboczej, nie moze wywiazac sie z umowy, i w rezultacie
>> zostaje zamkniete.
>
> No ale sponsorzy jednak te pieniądze wykładają, z czego wynika, że
> wartość oczekiwana przedsięwzięcia jest większa niż zero.

oczekiwana tak. z wynikiem bywa juz niestety troche inaczej.

> Można się oczywiście z drugiej strony zastanawiać, na ile kultura
> wpływa tu tak, że pracownikom oferuje się niskie wynagrodzenia i
> długie godziny, więc starsi, bardziej doświadczeni pracownicy idą
> gdzie indziej, więc zatrudnia się ludzi bez doświadczenia i/lub z
> niskimi umiejętnościami, z czego bezpośrednio wynika to, że "biorą się
> za coś, czemu nie mogą sprostać" i "nie są w stanie wykonać tego, co
> zaplanowali". Bo raczej trudno, żeby student ułożył sensowny plan,
> albo wiedział co można zrobić w danym czasie i jak. Nawet jeśli akurat
> świetnie się zna na procesorze Nintendo DS.

jak wszedzie, nie wszystko jest czarne i biale jak to tutaj opisales.
ale troche racji masz. czasem efekt koncowy zalezy od zupelnie innych
czynnikow. czesto zle rozegrany marketing kladzie rewelacyjny produkt na
lopatki, na co programista ma sredni wplyw. niekiedy ogolna sytuacja na
rynku - pracowalem kiedys nad gra, maly zespol, zrobilismy demo w 1/2
roku, chcielismy zainteresowac nim wydawcow. pech chcial, ze zaczal sie
kryzys, i okazalo sie, ze sam model rozgrywki byl na tyle inny
[innowacyjny to moze zbyt silne slowo jezeli rozpartywalibysmy samo
demo] od obecnych gier - w efekcie czego wydawcy mimo, ze byli
zainteresowani, nie byli sklonni zainwestowac w pelen produkt - bo nie
ma pewnosci, ze sie sprzeda. z mojej perspektywy, koszty 1/2 roku
oplacania malego zespolu szlag trafil bo nie mielismy z tego zadnego
zysku. oczywiscie mozna gdybac. gdyby nad tym demo pracowal caly zespol,
moze sposobalo by sie wydawcom na tyle, ze ktos by jednak zaryzykowal i
zainwestowal? moze jednak nie, i wtedy studio padlo by jak wiele innych?
w takiej sytuacji programista niestety niewiele moze...

>>> Ja na kontrprzykład mogę powiedzieć, że w moim anegdotycznym studio,
>>> które padło, była z kolei sytuacja, że na potrzeby gry, która ich tak
>>> utopiła, kierownictwo zdecydowało się ograniczyć pracę nad różnym
>>> rzeczami, zamiast tego wykorzystując bez zmian kod z poprzednich projektów.
>>
>> to mogl byc jeden z tych bledow o ktorych wspomnialem powyzej. nie wiem
>> czy tak bylo w tym przypadku, ale niekiedy wszyscy placa za blad jednostki.
>
> Ciekawi mnie w takim razie, czy skoro normą w studiach produkujących
> gry jest że ludzie na stanowiskach kierowniczych to niekompetentne
> patałachy (z czego wynika że studia te padają dostć często), to ich
> zarobki są również bardzo niskie (wliczając to dodatkowe wynagrodzenie
> uzależnione od wyników firmy). Czy może jednak są zdecydowanie wyższe,
> bo pomimo że wszystkie argumenty, które przytoczyłeś, stosują się
> również do nich, to jednak nie dają się oni tak bardzo dymać, jak
> programiści?

zawsze myslalem, ze norma jest to, ze ludzie na stanowiskach
kierowniczych zazwyczaj zarabiaja wiecej. jezeli dobrze zrozumialem,
bardzo odwazna teoria - czy wedlug ciebie jezeli programista zarabia
mniej niz jego CEO, zaczy ze daje sie 'dymac'?

>>>> ogolnie jest tak, ze w trakcie
>>>> produkcji wyjdzie kilka innych tytulow, od ktorych trzeba bedzie byc
>>>> lepszym, wiec wymagania/featuresy nie sa stale a ewoluuja w czasie - w
>>>> grach praktycznie nie istnieje finalna wersja design dokumentu...
>>
>>> Co to ma do rzeczy? Jako programista nie jesteś przecież opłacany za
>>> zaimplementowanie dokumentu, tylko dostajesz pensję i ewentualnie (o
>>> czym tutaj mówię) negocjujesz jakieś dodatkowe korzyści zależne od
>>> sprzedaży czy zysków z produktu, przy którym pracujesz.
>>
>> tyle ma do rzeczy, ze po roku czy 2, jestes w sytuacji, gdzie cala praca
>> ktora wlozyles, ma szanse nigdy nie ujrzec swiatla dziennego. jest to o
>> tyle wazne, ze jesli planowales szukac lepszej posady, a ten projekt
>> mial byc twoja karta przetargowa [na przyklad jest czeste wymaganie,
>> praca przy wydanej grze multiplatformowej badz AAA] - to nie masz nic do
>> pokazania, co bardzo wydatnie moze zmniejszyc twoje szanse na dobra
>> posade gdzie indziej. wiec starasz sie zrobic tak, zeby zwiekszyc szanse
>> na sukces.
>
> No i co, uważasz, że jeśli programista wynegocjuje sobie premię
> wypłacaną _w przypadku sukcesu_, to zmniejsza szansę produktu na
> sukces?

nie uwazam. uwazam natomiast, ze nie jest norma w kazdej firmie dawanie
kazdemu pracownikowi, ktory sie o to upomni, premii zaleznej od sukcesu
przedsiewziecia.

>>> Ale ja przecież mówię o premiach czy innych formach wynagrodzenia
>>> zależnych od tego jak się _rzeczywiście_ sprzedało, a nie od tego, jak
>>> się myślało, że się sprzeda. Ja mówię o tym, że programista mówi
>>> pracodawcy "ok, czasem się nie sprzeda tak, jak by się myślało, ale
>>> jakby się jednak tak sprzedało, to ja chcę 60tys premii (zakładając
>>> roczny czas trwania projektu), a jakby się sprzedało 5 razy lepiej, to
>>> chcę 120 tysięcy.
>>
>> czy w polsce naprawde norma jest takie podejscie? szefie, chce zarabiac
>> tyle i tyle, ale cos mi sie widzi, ze ten nowy projekt co to go mamy
>> zrobic to bedzie niezle cacko, to jak bedzie cacko, to ja chce extra
>> 100k, ok? a szef na to ok? i tak kazdemu pracownikowi?
>
> Nie wiem jak jest w Polsce, taka jest norma w startupach. Przy czym to
> raczej wygląda tak "szefie, dlaczego mam właściwie pracować tutaj,
> skoro gdzie indziej dają dwa razy tyle?" "Nie możemy dać więcej bo
> jesteśmy tylko skromnym startupem realizującym ryzykowny projekt z
> ograniczonym budżetem, ale możemy to skompensować udziałami, które,
> jeśli projekt wypali, mogą być warte setki tysięcy/miliony". Są też
> branże, gdzie nawet duże firmy wypłacają znaczące bonusy uzależnione
> od wyników jednostki organizacyjnej, jako sposób skuszenia i
> zmotywowania najlepszych pracowników. Czasem/często jest tak, że te
> premie nie są zagwarantowane w kontrakcie, ale i tak pełnią swoją
> rolę, bo firma czy branża ma taką reputację, że je wypłaca.

ok, z mojej strony moge powiedziec, ze nie trafilo mi sie pracowac w
takiej firmie. owszem, dodatki tzw. okolicznosciowe na koniec roku,
nazywane niekiedy premiami za efektywnosc owszem. udzialy, w pewnej
formie, ale kokosy to niestety nie byly.

startupy zaczaynaja male grupy, w ktorych pracuja wspolzalozyciele, wiec
wiadomo, ze jesli odniosa sukces - kazdy z nich na tym zyska, wiec nic w
kontraktach nie musza sobie dopisywac. produkcje indie tez przynosza
zyski. wydaje mi sie jednak, ze w kwestii gier AAA, ktore chcesz
rozpatrywac, nie ma szans na startup - produkcje AAA kosztuja ciezkie
pieniadze, zaden startup sie tego nie podejmie. wielkie koncerny
natomiast nie oferuja bonusow z racji zyskow.

>>> Na ogół wygląda tak, że się lepiej zarabia. A jak się chce pracować w
>>> startupie, który gorzej płaci, bo nie ma kapitału, to oczekuje się w
>>> zamian dodatkowej formy wynagrodzenia zależnej od sukcesu tego startupu:
>>> premii zależnej od dochodów albo jakiejś formy udziałów w firmie.
>>
>> no to dodatkowa forma wynagrodzenia jest to, ze robi sie to co sie lubi
>> [jesli tak jest]. inna, niepewna, po ewentualnym sukcesie jest mozliwosc
>> przejecia przez wieksza firme, i szanse na robienie tego co sie lubi,
>> plus wieksze pieniadze, jesli to akurat wierci nam dziure w brzuchu.
>
> W każdej branży jest tak, że jak popracujesz dłużej, to dostajesz
> większe pieniądze.

tak, tylko, ze w branzy gier to nie zawsze jest zaleznosc liniowa.
powiedzuialbym nawet, ze zazwyczaj wlasnie nie jest. jeden zauwazony
produkt moze katapultowac male studio do przodu. stawka jest wysoka,
male studia czesto graja ryzykownie.

>> jesli pracujesz w studiu, ktoremu grozi
>> zamkniecie, masz do splacenia kredyty to nie interesuje cie jak ma sie
>> branza w ogolnym rozrachunku. jasne, ze mozna powiedziec, ze sa zyski,
>> jest super. przeciez nikt nie wchodzi w nic jesli nie rokuje to dobrze.
>> ty podchodzisz do tematu globalnie, ja staram ci sie podawac blizsze
>> zyciu przyklady i na ich podstawie cos wnioskowac. ale cos chyba
>> odchodzimy od tematu.
>
> No ale właśnie dlatego, że nie patrzysz globalnie, to szef może cię
> okłamywać, że nie stać go, żeby płacić ci więcej, a ty mu wierzysz, bo
> to taki fajny koleś, z którym razem gracie w counterstrike'a.

bardzo chcialbys zeby bylo czarno i bialo, ale nie jest. oczywiscie ze
moze oklamywac, takie jego kapitalistyczne prawo. juz o tym pisalem,
wszystko gra do pewnego momentu - do kiedy programista stwierdza, ze nie
lubi miejsca pracy az tak bardzo, zeby godzic sie na takie pieniadze. to
bardzo plynna granica, dla kazdego wyglada inaczej - zalezy jak bardzo
cenisz sobie to co akurat robisz. nic w tym dziwnego. a to, ze
programisci gier moga cenic sobie to czym sie zajmuja wysoko, moze
prowadzic do tego, ze moga zarabiac mniej.

>>> Teraz wydaje mi się, że ty mierzysz innych swoją miarą, a konkretnie
>>> przez pryzmat znanego tobie biznesu growego. Bo ja mam takie wrażenie,
>>> że to strasznie hermetyczne środowisko, ale biznes aż taki nie jest.
>>> Jeśli np. dobrze znasz C++, struktury danych, programowanie
>>> wielowątkowe, dobre praktyki itd., to możesz liczyć na nieźle płatną
>>> pracę i dość szybką progresję zarobków.
>>
>> ale ja nie mowie, ze nie mozesz liczyc. wszystko co wspomnialem, to to,
>> ze programista gier moze miec w braki w pewnych zagadnieniach, ktore sa
>> wazniejsze z punktu widzenia potencjalnego pracodwcy. doszkalanie sie w
>> tych zagadnieniach moze troche potrwac a doswiadczenia i tak nie da sie
>> nauczyc. gorsza pozycja startowa, ale niekoniecznie przegrany wyscig.
>
> Ta "gorsza" pozycja startowa objawia się tylko tym, że płacą ci mniej.
> Ale jeśli i tak płacą lepiej niż przy grach, to ona wcale
> niekoniecznie jest taka znowu "gorsza".

gorsza czy lepsza - zalezy od osoby. czy podwyzka n% zrekompensuje mi
nudna prace w innej branzy/miejscu? odpowiedz twierdzaca dla kazdgo
zaczyna sie od innej wartosci n.

problem w tym, ze przez brak oczekiwanego w innej branzy doswiadczenia,
mozesz przy takim przejsciu zaczac nizej finansowo niz dostajesz w
grach, do tego dojdzie ci koszt przeprowadzki i inne takie - wiec w
ogolnym rozliczeniu, nie oplaca sie. to wcale nie jest nieprawdopodobny
scenariusz.

> Z drugiej strony mam swoje przypuszczenie, że z brakami w "pewnych
> zagadnieniach" jest raczej tak, że te zagadnienia to niekoniecznie
> brak znajomości SAP czy czegotam, tylko np. umiejętność pisania
> programów tak, żeby się nie wywalały. Nie ujmując niczego dobrym i
> kompetentym programistom gier, którzy wiem, że istnieją, to sam fakt,
> że takie zdarzenie w grze jest czymś, na co producent może sobie
> pozwolić (bo najwyżej wyda patcha), powoduje, że "programista gier
> może mieć braki" w programowaniu tak w ogóle. Dlatego też nie ma
> pozycji przetargowej, bo ze swoimi umiejętnościami wcale nie znajdzie
> dobrze płatnej pracy gdzie indziej. Z kolei doświadczony programista,
> jeśli chce pracować przy grach, musi konkurować cenowo z takim
> patałachem, bo jak zażąda więcej, to pracodawca zatrudni zamiast niego
> patałacha. W branżach, gdzie oprogramowanie nie ma prawa się zbyt
> często wywalać, nie da się tego zrobić, dlatego doświadczony
> programista - pomijając nawet jego obycie z tą czy inną specyficzną
> technologią czy dziedziną biznesu - ma dobrą pozycję przetargową, już
> z samego tego tyułu, że kod pisany przez iego rzadziej się wywala.

rzuce troche swiatla na te kwestie. wywalanie sie gier to sliski temat.
jezeli znasz 100% specyfikacje systemu, mozesz pisac konkretny kod,
ktory sie nie wywali. konfiguracji komputerow, kart graficznych,
pamieci, driverow jest praktycznie nieskonczona ilosc. do tego doloz
sobie zaleznosci od innych bibliotek, czy engine'ow ktore uzywasz, a
ktore tez ewoluuja niezaleznie od ciebie. w efekcie prowadzi czesto do
tego, ze twoja gra moze sie zaczac wywalac bo ktos uaktualnil sobie
drivery. jest zbyt duzo zmiennych, zeby zawsze przewidziec co sie
stanie. dlatego sa patche. oprocz bugow w finalnej wersji, ktore sa
zazwyczaj usuniete w dniu premiery pierwszym patchem [process wydawniczy
trwa tyle, ze dodatkowe stress testy pozwalaja wykryc i naprawic usterki
zanim produkt trafio do gracza] - crashe po finalnej wersji pojawiaja
sie w wielu przypadkach z przyczyn niezaleznych od programistow, a to
nvidia wypusci nowy PhysX niezgodny z poprzednim, a to drivery przestaja
supportowac pewne tryby, na ktorych polegasz, itd. to sa sytuacje, nie
do zaakceptowania w bankowosci dajmy na to, a z ktorymi trzeba sie
liczyc w grach.

>>>> bez przesady, zaczeli kodowac pod x360 i ps3 co bylo naturalnym krokiem
>>>> w ich karierze...
>>
>>> Na ile rozumiem to są jednak zupełnie inne architektury i tricki też są
>>> inne?
>>
>> jezeli jestes swietnym inzynierem to mozesz spokojnie przejsc z ferrari
>> do boeinga i krzywda ci sie nie stanie. jasna sprawa, ale to nie zmienia
>> faktu, ze lepiej odlanazlbys sie przechodzac na przyklad do lamborghini.
>> szczegolnie jesli naprawde lubisz samochody sportowe.
>
> Tym bardziej, dlaczego inżynier pracujący w Ferrari miałby dostać
> lepszą ofertę od Boeinga niż od Lamborghini?

kontynuujac hipotetyczne historie, moglby sam sie do boeinga zglosic i
dostac 'lepsza' oferte niz od ta 'gorsza' lamborghini. uzywam ' bo to sa
kwestie subiektywne.

>> nie, to nie tak. jezeli lubisz samochdy sportowe, to nie bedziesz sie
>> przejmowal tym, ze kolega z boeinga za rozpracowywanie konsoli pilota
>> czy aurodynamiki ogona dostaje wiecej niz ty, bo ty za mniejsze
>> pieniadze bawisz sie w rozpracowywanie optymalnego ksztaltu maski i
>> spojlera - plus, robisz tak, zeby bylo ladne, a nie tylko funkcjonalne.
>> mozesz isc do boeinga i o tym wiesz, ale jesli boeing placi 10% wiecej?
>> nie warto. 20% wiecej? 30% moze, zalezy od tego jak bardzo cenisz sobie
>> prace z tym co lubisz, i jak bardzo twoja sytuacja zyciowa ci na to pozwala.
>
> I dlatego też ludzie, którzy pracują przy rozpracowaniu optymalnych
> kształtów dla samochodów sportowych są znacznie słabiej opłacani niż
> ich koledzy na podobnych stanowiskach w Boeingu. Tylko że chyba jednak
> nie?

pomijajac to, ze niekiedy nie da sie znalezc 'podobnego stanowiska' w
dwu rozych branzach, to moze byc tak, ze dla ludzi pracujacych dla
ferrari, samo to, ze efekt ich pracy jest bardziej medialny rekompensuje
to, ze moge byc oplacani gorzej.

> Also, z mojej orientacji wynika, że dla kogoś przechodzącego z gier do
> biznesu będzie raczej więcej niż 30%. Naturalnie o ile jest kolesiem,
> który potrafi pisać program, który się nie wywala co chwila.

odwazna teoria. mozesz podac zrodla? az mnie korci, zeby zrobic
experyment ;]

BR,
Sarr.

do góry