Preferowany student ostatnich lat (4-5 rok), praca jak kto chce i ma
czas - 20h tygodniowo, a może 30? Kwestia do uzgodnienia. Osobiście
pracuję 20h, wtedy gdy nie mam zajęć. Część pracy można robić zdalnie,
jeśli ktoś lubi przynosić pracę do domu :)
Wymagania:
- bardzo dobra znajomość Pythona
- znajomość przynajmniej 10 dowolnych modułów biblioteki standardowej
- znajomość dowolnego distro Linuksa
- fascynacja językiem Python
- dobra znajomość j. angielskiego - praca w między narodowym zespole.
Mile widziane:
- doświadczenie z Django
- obycie z Eclipse PyDev
- znajomość dowolnego systemu kontroli wersji (najlepiej z HG)
- obycie ze sprzętem elektronicznym
Oferujemy:
- biurko o powierzchni 2m kwadratowych :)
- laptop + drugi monitor
- wygodny fotel
- zadowalające zarobki
- możliwość zdobycia elitarnej wiedzy na temat branży M2M i telemetrii
Zainteresowanych proszę o przesłanie CV i 2-3 zdań na temat tego,
dlaczego chciałbyś pracować.
Adres: p.szy...@telic.pl
Odpowiadamy na wszystkie zgłoszenia!
A j. polskiego nie trzeba znac? Bo pisze sie "miedzynarodowynm". Jakbym
wysylal oferte pracy, to przynajmniej napisalbym ja poprawnie. Nie ma to
jak polski, olewczy stosunek do wszystkiego...
Marek Magrys napisał(a):
"miedzynarodowynm" ??? Nie znam takiego slowa.
Jak widzisz o pomylke jest bardzo latwo, wiec daruj sobie takie uwagi.
Nie zauwazylem zadnego "olewczego stosunku" w tym poscie.
Jesli juz sie do czegos czepiac, to moze do tych "zadowalajacych
zarobkow", ale to zupelnie oddzielny temat.
RW
Oj nie moj drogi, o literowke jest bardzo latwo, owszem, ale to co
napisal inicjator watku to cos zupelnie innego - najzwyczajniejszy na
swiecie ort. Aczkolwiek przepraszam i smagam sie biczykiem za moj blad :)
> Nie zauwazylem zadnego "olewczego stosunku" w tym poscie.
Nie chodzi bynajmniej o sam ton postu, ale wlasnie o blad. Po prostu
wyglada to jak ogloszenie pisane "na kolanie" - u mnie firma od razu ma
minus. Chodzilo o 'olewczy' stosunek do rekrutacji.
Generalnie nie mam ochoty inicjowac flame'a i czepiac sie detali,
irytuja mnie takie niedorobki, a widuje takowe w ogloszeniach o prace
coraz czesciej. Przykre, ze informatycy (generalizuje) przykladaja
wiecej wagi do jezykow programowania niz do jezyka ojczystego.
> Przykre, ze informatycy (generalizuje) przykladaja
> wiecej wagi do jezykow programowania niz do jezyka ojczystego.
Jak to z zyciu...
Obaj z Wolfe-m (?:) macie 'conieco' racji :)
AK
> Wymagania:
> - znajomość przynajmniej 10 dowolnych modułów biblioteki standardowej
To zawartosc tych modulow trzeba recytowac przez sen jak wierszyk w
podstawowce? Mam rozumiec, ze z dokumentacji w pracy tez nie mozecie
korzystac?
--
Uważam, że określanie znajomosci języka np. w skali 1-10 jest
niemiarodajne. Podobnie określenia w stylu: trochę, zaawansowany,
doświadczony, również nie niosą ze sobą informacji. Nie muszę chyba
tłumaczyc, że jeśli ktoś miał w życiu okazję poznac kilka modułów, to
coś już sobą reprezentuje.
Inicjator wątku przyznaje otwarcie, że była to literówka.
> Nie chodzi bynajmniej o sam ton postu, ale wlasnie o blad. Po prostu
> wyglada to jak ogloszenie pisane "na kolanie" - u mnie firma od razu ma
> minus. Chodzilo o 'olewczy' stosunek do rekrutacji.
"Olewczy" stosunek do rekturacji byłby wtedy, gdybym tu już nic więcej
nie odpisał (to chyba norma).
"Olewczy" stosunek do rekturacji byłby również wtedy, gdybym zawarł
klauzulę "odpowiadamy tylko na wybrane zgłoszenia".
"Olewczy" stosunek do rekrutacji byłby także wtedy, gdybym spamował
wszędzie tym ogłoszeniem - a ono trafiło tylko i wyłącznie do Was.
> Przykre, ze informatycy (generalizuje) przykladaja
> wiecej wagi do jezykow programowania niz do jezyka ojczystego.
Ok, to ma sens.
Chyba rozumiesz ze nikt nie zna na pamiec zawartosci 10 modulow,
potrafisz chociaz wymienic WSZYSKIE metody klas: string, double, int --
to sa bardzo podstawowe klasy i tylko trzy, a jestem pewien ze nie
wymienisz ich wszystkich metod, wiec wymog co do znajomosci 10 modulow
jest poprostu...
zreszta kontynuujac twoja mysl mowiaca o tym ze bezsensu jest oceniac w
jakiejs skali, to jak masz zamiar ocenic czy ktos zna modul czy nie?
> zreszta kontynuujac twoja mysl mowiaca o tym ze bezsensu jest oceniac w
> jakiejs skali, to jak masz zamiar ocenic czy ktos zna modul czy nie?
Sulsa , czy Ty nie wyczules ze cale ogloszenie zostalo napisane 'na luzie' ?
Ja to odczulem w ten sposob ze ten 'luz' byl zamierzony (tzn szczery) gdyz
wskazuje wyraznie (student, dowolna ilosc godzin pracy itp) ze nie chodzi
od razu o super-fachowca (i tez mozna domniemywac ze na super-zarobki
nie ma co liczyc), ale tez jak na warunki dla 'pracy dorywczej' firma
zapewnia
calkiem, ale to calkiem niezle.
Byc moze juz maja super-goscia(i) a poszukuja do 'odstawy' (czytaj pomocy
w pracach do ktorych super-gosc zwyczajnie sie _nie oplaca_ ?)
Byc moze jednak (jak wiekszosc firm z ogloszen niestety:) chca bazowac
na SBD (student-base development) ?.
Jednak w przeciwienstwie do wiekszosci ogloszen Patryk nie owija w bawelne
'powagi' i 'korporacyjnosci' itp starej informatycznej rekrutacyjnej
nowomowy.
Slowem (byc moze sie myle o 180, wspomniane SBD ktore mi sie z praktyki
fatalnie kojarzy :) to ogloszenie (mimo swego luzu) sprawia wrazenie
sympatycznego,
nienadetego i _niezafalszowanego_.
To ostatnie wazne bo powoduje ze od razu bym sie z poprzedniej pracy nie
zwolnil,
ale na prace u Patryka spojrzal z zainteresowaniem i wzajemna zyczliwoscia
:)
PS: Mowiac ..bym mam na mysli raczej Ciebie a nie siebie /jamci za stary juz
/ :)
AK
Poza tym jesli ktos jeden ze swych glownych produktow nazywa:
Katharina das Grosse
to chyba jednak ma niezle poczucie humoru :)
AK
> "Olewczy" stosunek do rekturacji byłby wtedy, gdybym tu już nic więcej
> nie odpisał (to chyba norma).
Niestety tak (norma) i dlatego odpowiadanie/dyskusje bardzo Ci sie
powinno chwalic.
AK
Nie mówiłem o recytowaniu na pamięc zawartości 10 modułów, tylko
"znajomośc".
Zdradzę Ci mały sekret - nie będę tego oceniac.
Po przeczytaniu mojego pierwszego posta, jeśli napisałeś już parę
aplikacji i miałeś okazję przedzierac sie przez dokumentację,
stwierdzisz że po drodze poznałeś jej sporą częśc i wyślesz CV.
Jeśli natomiast jedynie próbowałeś zahaczyc o Pythona, to ten punkt
wymagań odstraszy cię - i słusznie.
Widzisz - rozmowa rekrutacyjna to nie jest jakiś egzamin żebym
kogokolwiek oceniał. Osobiście czułbym się źle będąc ocenianym podczas
rozmowy rekrutacyjnej przez jakiegoś czubka po drugiej stronie stołu.
W mojej małej karierze odwiedziłem już kilka rozmów kwalifikacyjnych
jako aplikant i mam dośc rozmów, gdzie pani z HRu opowiada ci historię
firmy po angielsku, a potem woła jakiegoś pana "technicznego", który
zadaje ci pytania kompletnie z sufitu. W pewnym momencie zaczynasz się
zastanawiac czy ktoś w ogóle przeczytał twoje CV :/
True
> Byc moze juz maja super-goscia(i) a poszukuja do 'odstawy' (czytaj pomocy
> w pracach do ktorych super-gosc zwyczajnie sie _nie oplaca_ ?)
Niet, potrzebuję "partnera". Firma szybko się rozwija i muszę się jak
najszybciej podzielic z kimś projektami.
A jak ją ocenisz, przecież odrzucasz stopniowanie czy zna ktos dobrze
czy zle? Pozatym co rozumiesz przez znajomosc, wiedze ze takie moduly
istnieją, czy znajomosc 50% klas i funcji z tych modlowo?
--
Coś ty taki zformalizowany - przecież tu chodzi o człowieka, a nie o
opracowanie wzoru przez którego będziemy przepuszczać czyjeś
kompetencje.
Pytanie powinno brzmieć: co Ty (jako potencjalny kandydat) rozumiesz
przez znajomość technologii X. Spójrz na siebie z trochę innej
perspektywy. Sam zadaj sobie pytanie "jak ocenić moje zdolności/moją
wiedzę?" i pomyśl nad tym.
W tym momencie, dyskusja pomiędzy nami, straciła dla mnie sens. Mam
nadzieję, że się tylko ze mną drażniłeś.
Pozdrawiam!
> Sam zadaj sobie pytanie "jak ocenić moje zdolności/moją
> wiedzę?" i pomyśl nad tym.
Jak można oceniać coś czego nie ma? :)
Wiedza u Sulsy jest bliska zeru. Pewnie dlatego
się tak stresuje ewentualnymi rozmowami o
prace.
> W tym momencie, dyskusja pomiędzy nami, straciła dla mnie sens. Mam
> nadzieję, że się tylko ze mną drażniłeś.
>
Nie tylko Ty doszedłeś do tego wniosku. Patrz pl.sci.ai ;)
Pozdrawiam
--
[ Wit Jakuczun <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions http://www.wlogsolutions.com ]
> Pytanie powinno brzmieć: co Ty (jako potencjalny kandydat) rozumiesz
> przez znajomość technologii X. Spójrz na siebie z trochę innej
> perspektywy. Sam zadaj sobie pytanie "jak ocenić moje zdolności/moją
> wiedzę?" i pomyśl nad tym.
Więc odpowiem ci na to pytanie bardzo prosto, pythona znam dobrze i
duzo w nim pisze, ale nie przeszedl bym przez twoj filtr bo nie znam
10 modulow z biblioteki standardowej na tyle zeby uzywac ich bez
dokumentacji.
> W tym momencie, dyskusja pomiędzy nami, straciła dla mnie sens. Mam
> nadzieję, że się tylko ze mną drażniłeś.
Mnie interesuje kwestja jak zweryfikujesz znajomosc dziesieciu modolow.
Kazesz wyresytowac 50% procent funkcji/klas wraz z metodami z tych
modolow? Czy moze zadasz 10 losowych jak to sie mowi z dupy wzietych
pytan o te funkcje? Taki sposob weryfikacji wydaje mi sie zupelnie
bezsensu, na potwierdzenie tego sporoboj wyrecytowac chociaz 50% metod
tak podstawowych obiektow jak float, int, string, list, dict i wez pod
uwage ze 50% to za malo zeby zaliczyc klasowke czy kolowkium, a daje
glowe ze 90% *dobrych* programistow pythona z tródem wyrecytuje ponad
50% tych funkcji, a tu masz odpowiedz dlaczego(pod nia jest dalszy
ciag posta):
>>> l = [dict, list, map, str, float]
>>> dir(l)
['__add__', '__class__', '__contains__', '__delattr__', '__delitem__',
'__delsli
ce__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__',
'__gets
lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
'__iter__',
'
__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
'__reduce__',
'__r
educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__',
'__setitem__
', '__setslice__', '__str__', 'append', 'count', 'extend', 'index',
'insert',
'p op',
'remove', 'reverse', 'sort']
>>> l = [dict, list, map, str, float]
>>> for i in l: dir(l)
...
['__add__', '__class__', '__contains__', '__delattr__', '__delitem__',
'__delsli
ce__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__',
'__gets
lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
'__iter__',
'
__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
'__reduce__',
'__r
educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__',
'__setitem__
', '__setslice__', '__str__', 'append', 'count', 'extend', 'index',
'insert',
'p op',
'remove', 'reverse', 'sort'] ['__add__', '__class__', '__contains__',
'__delattr__', '__delitem__',
'__delsli
ce__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__',
'__gets
lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
'__iter__',
'
__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
'__reduce__',
'__r
educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__',
'__setitem__
', '__setslice__', '__str__', 'append', 'count', 'extend', 'index',
'insert',
'p op',
'remove', 'reverse', 'sort'] ['__add__', '__class__', '__contains__',
'__delattr__', '__delitem__',
'__delsli
ce__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__',
'__gets
lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
'__iter__',
'
__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
'__reduce__',
'__r
educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__',
'__setitem__
', '__setslice__', '__str__', 'append', 'count', 'extend', 'index',
'insert',
'p op',
'remove', 'reverse', 'sort'] ['__add__', '__class__', '__contains__',
'__delattr__', '__delitem__',
'__delsli
ce__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__',
'__gets
lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
'__iter__',
'
__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
'__reduce__',
'__r
educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__',
'__setitem__
', '__setslice__', '__str__', 'append', 'count', 'extend', 'index',
'insert',
'p op',
'remove', 'reverse', 'sort'] ['__add__', '__class__', '__contains__',
'__delattr__', '__delitem__',
'__delsli
ce__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__',
'__gets
lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
'__iter__',
'
__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
'__reduce__',
'__r
educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__',
'__setitem__
', '__setslice__', '__str__', 'append', 'count', 'extend', 'index',
'insert',
'p op',
'remove', 'reverse', 'sort']
a teraz sproboj zrobic to samo dla 10 modolow, ktore najlepiej znasz i
bedziesz wiedzial dlaczego tak mecze cie z tym punktem. Mnie on
odstraszyl odrazu bo nie wyobrazam sobie zeby ktos mnie przepytywal o
zawartosc tych modolow.
> Dnia Mon, 28 Apr 2008 07:02:30 -0700 (PDT)
> Patryk Szymczak <patryk....@gmail.com> napisał(a):
>
> > Sam zadaj sobie pytanie "jak ocenić moje zdolności/moją
> > wiedzę?" i pomyśl nad tym.
> Jak można oceniać coś czego nie ma? :)
> Wiedza u Sulsy jest bliska zeru. Pewnie dlatego
> się tak stresuje ewentualnymi rozmowami o
> prace.
Za to wiedza u wicia jest bliska nieskonczonosci, co widac po jego
merytorycznych wypowiedziach.
EOT
--
Pozdro... Tupteq
> Jak można oceniać coś czego nie ma? :)
No to przywaliles Wit niczym ee... A.L ;)
PS: Nie mowie ze sie mijasz z prawda ;)
AK
Dzięki za uznanie. Niestety nie mogę tego powiedzieć
o Tobie z przyczyn, które wyłuszczyłem w poprzednim poście.
> Za to wiedza u wicia jest bliska nieskonczonosci
No wiesz... moze nie az tak, ale jak widze jego
inne wypowiedziach na tej i innych grupach hm...
to ze tak powiem asymptotycznie sie zbliza ;)
PS: Dla mnie stajesz natomiast powoli mistrzem w...
unikaniu zatrudnienia :)
AK
> Użytkownik "Wit Jakuczun" <w...@mefisto.hades> napisał:
>
> > Jak można oceniać coś czego nie ma? :)
>
> No to przywaliles Wit niczym ee... A.L ;)
>
Dziękuję ;)
> PS: Nie mowie ze sie mijasz z prawda ;)
>
Koń jaki jest każdy widzi :D
> - znajomość dowolnego systemu kontroli wersji (najlepiej z HG)
Co to jest HG?
> - możliwość zdobycia elitarnej wiedzy na temat branży M2M i telemetrii
Co to za branża M2M?
--
Pozdrawiam
Krzysztof Szynter
> Witam
>
>> - znajomość dowolnego systemu kontroli wersji (najlepiej z HG)
>
> Co to jest HG?
Mercurial.
http://www.selenic.com/mercurial/wiki/
Polecam, bardzo wygodny.
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
More sad are those we daily see: it is, and hadn't ought to be.
> Mercurial.http://www.selenic.com/mercurial/wiki/
> Polecam, bardzo wygodny.
Czy jako początkujący, zrobi mi różnicę, jeśli zainteresuję się
rozproszonym
Mercurial'em zamiast serwerowym Subversion? Niby jednostkę jako serwer
mam do dyspozycji i nie pytam tutaj 'który z w/w jest lepszy'.
--
KSZ
Teraz "na topie" jest svn., ale niedlugo moze to byc, ktorys z
rozproszonych sytemow wersji.
Wydaje mi sie, ze wszystko zalezy od osobowsci i stylu pracy.
Osobiscie nie moglem sie zmusic do uzywania CVSa lub Subversion --
jesli bylo to wymagane, to wlasciwie uzywalem ich tylko jako narzedzie
do sciagania kodu.
Natomiast w momencie kiedy poznalem Mercuriala zycie stalo sie prostrze
i na co dzien korzystam z dobrodziejstw kontroli wersji -- nawet kiedy
tylko pisze jakis drobny programik albo artykul -- "hg init" prawie nic
nie kosztuje.
Linus Torvalds on git:
http://www.youtube.com/watch?v=4XpnKHJAok8
Odnoszę wrażenie, że lepiej zaczynać od nowoczesnych VCS, a to oznacza
raczej systemy rozproszone jak Git i Mercurial, niż SVN.
.pk.
nowoczesniejsze to chyba zle slowo, one poprostu cechuja sie innym
podejsciem do tematu.
Wątpię. Rozproszone mają sens tylko dla pryszczerskich projektów.
bart
--
"Panowie, żarty się skończyły!" (c) JMD
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
> Rozproszone mają sens tylko dla pryszczerskich projektów.
Takich jak jądro Linuksa, Netbeans czy sunowska Java? :)
--
Jarosław Zabiełło
http://blog.zabiello.com
http://git.or.cz/gitwiki/GitProjects
http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial
nawet słaby w porównaniu z dwoma poprzednimi bazaar ma się czym
pochwalić
http://bazaar-vcs.org/WhoUsesBzr
Czasami odnoszę wrażenie że nie wszyscy czytają to co napisali przed
wysłaniem, a ilość przedkładają nad jakość. Obym się mylił.
Nie
Dla projektów nie-opensource systemy rozproszone nie mają żadnego sensu
chyba, że wprowadza je firma, która "pozwala" zabrać pracę na weekend do
domu (ale wtedy też można po prostu użyć szyfrowanego SVN).
Jedyną zaletą jest tworzenie swoich prywatnych commitów, ale w SVN też
można mieć prywatne gałęzie, a przynajmniej wszystko jest zawsze
backupowane na centralnym serwerze.
Pozdrawiam,
Wojciech Malinowski
zaletą jest szybkość.
do zdalnego repozytorium nigdy nie będziesz miał tak szybkiego dostępu
jak do lokalnego.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
3 uwagi:
1. Zauważ, że pisałem o projektach nie-opensource, realizowanych głównie
w siedzibach firm. Nie wydaje mi się, żeby w firmach developerskich
używane było cokolwiek gorszego niż 10Mb LAN. W takich warunkach
odpowiedź z centralnego serwera może być szybsza niż z Twojego własnego
komputera, jako że maszyny developerskie potrafią być mocno obciążone
różnymi eclipsami, debugerami, lokalnymi testowymi bazami danych itp.
2. Nawet jeśli lokalne repozytorium będzie szybsze to co tak naprawdę
zyskujesz? 3 sekundy w ciągu dnia? Sam używam kilku repozytoriów SVNa na
cienkim łączu i nigdy nie miałem problemów z szybkością jego działania.
Odpalam commit albo update i zajmuję się innymi sprawami.
3. Nawet jeżeli masz cienkie łącze do serwera SVN i musisz cały dzień
siedzieć i np. oglądać diffy z zupełnie różnych branchy to rozproszony
VCS nic Ci w tym nie pomoże. Tak czy siak - przy takim scenariuszu
musisz łączyć się z innymi komputerami żeby dostać te inne gałęzie.
Używając SVNa przynajmniej będziesz wiedział gdzie ich szukać.
Pozdrawiam,
Wojciech Malinowski
Dziwne sa te uwagi, widze ze kolega raczej rozproszonego systemu nigdy
na serio nie uzywal. Po pierwsze, 3 sekundy robia gigantyczna roznice
w stylu pracy: przestaje to byc jeden commit dziennie, commitujesz
praktycznie kazda spojna zmiane, przy okazji przed commitem oczywiscie
testujesz, wiec duzo drobniejsze zmiany per commit i duzo latwiej Ci
sie potem na przyklad wycofac z czegos.
Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich calkowicie
prywatnych klonow repozytorium, ktorych nikt nigdy nie musi ogladac i na
ktorych mozesz eksperymentowac ile dusza zapragnie bez zadnego wstydu. Do
tego zrobienie nowego to jest mgnienie oka, a nie uzeranie sie z firmowymi
adminami.
Po trzecie, nie ogladasz diffow z kazdego commita i nie zbierasz ich
z roznych maszyn -- nie wiem skad ten pomysl. Rozproszone repozytoria maja
za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na synchronizacje
dwoch repozytoriow -- najczesciej Twojego lokalnego i centralnego,
firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy
maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego
commita).
Wydaje mi sie, ze komentarz o "pryszczerskich projektach" to cos w rodzaju
hasla "sikajac z wiaterm idziesz na latwizne" :)
No tak. Zapomniałem, że SVN ma wbudowane zabezpieczenia przed więcej niż
jednym commitem na dzień.
> Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich calkowicie
> prywatnych klonow repozytorium, ktorych nikt nigdy nie musi ogladac i na
> ktorych mozesz eksperymentowac ile dusza zapragnie bez zadnego wstydu.
Z punktu widzenia firmy (a o tym właśnie pisze) to wstyd możesz sobie
schować do kieszeni przed wejściem do budynku i wyjąć z powrotem przy
wyjściu. Przypomnę, że piszę o projektach nie-opensource.
Nie rozumiem poza tym jak można się wstydzić własnego kodu. Chyba będę
musiał zaprzestać organizowania code reviews, bo może ktoś się wstydzi
poddawać pod komentarze swój własny kod.
Przecież wiadomo, że nikt nie tworzy od razu pięknego kodu. Jeśli
piszesz tracer bullet to go wrzucasz do VCS z komentarzem, że to tracer
bullet (w prywatnej gałęzi). Jak zadziała to jeśli jesteś dobrym
programistą to go przepisujesz już poprawnie, jeżeli słabym to nigdy go
poprawnie nie napiszesz. Będziesz go wtedy ukrywał na zawsze w prywatnym
repozytorium?
> Do
> tego zrobienie nowego to jest mgnienie oka, a nie uzeranie sie z firmowymi
> adminami.
Przecież w standardowym projekcie w SVNie masz trzy katalogi: trunk,
branches i tags. Nie chcesz mi chyba powiedzieć, że masz zabronione
tworzyć sobie nowe prywatne gałęzie w branches?
> Po trzecie, nie ogladasz diffow z kazdego commita i nie zbierasz ich
> z roznych maszyn -- nie wiem skad ten pomysl.
To był tylko przykład czegoś co może być wolne przy użyciu zdalnego
serwera VCS, ale pokazałem, że przy użyciu rozproszonego VCS będzie to samo.
> Rozproszone repozytoria maja
> za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na synchronizacje
> dwoch repozytoriow -- najczesciej Twojego lokalnego i centralnego,
> firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy
> maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego
> commita).
A jak to się różni od złączenia dwóch gałęzi w SVNie?
> Wydaje mi sie, ze komentarz o "pryszczerskich projektach" to cos w rodzaju
> hasla "sikajac z wiaterm idziesz na latwizne" :)
Przeczytaj jeszcze raz wątek, bo to nie moje słowa.
Pozdrawiam,
Wojciech Malinowski
sugestia: sprawdź.
nie będę cię na siłę do niczego namawiał.
po prostu zobacz jaka jest różnica w pracy z svn'em, a z mercurialem czy
gitem.
potem możemy pogadać o tym co jest szybsze.
> 2. Nawet jeśli lokalne repozytorium będzie szybsze to co tak naprawdę
> zyskujesz? 3 sekundy w ciągu dnia? Sam używam kilku repozytoriów SVNa na
> cienkim łączu i nigdy nie miałem problemów z szybkością jego działania.
> Odpalam commit albo update i zajmuję się innymi sprawami.
idea jest taka, że ultra-szybka praca systemu kontroli wersji zmienia
cały model działania.
w repozytoriach z centralnym serwerem - commitujesz relatywnie rzadko -
max kilka razy dziennie. jak masz repozytorium typu git, to możesz
commitować co sekundę. i to się przydaje. ponieważ commitujesz *sobie*,
to możesz bezstresowo commitować nawet niedziałający kod - jako backup,
czy "work in progress".
> 3. Nawet jeżeli masz cienkie łącze do serwera SVN i musisz cały dzień
> siedzieć i np. oglądać diffy z zupełnie różnych branchy to rozproszony
> VCS nic Ci w tym nie pomoże. Tak czy siak - przy takim scenariuszu
> musisz łączyć się z innymi komputerami żeby dostać te inne gałęzie.
> Używając SVNa przynajmniej będziesz wiedział gdzie ich szukać.
powtórzę: zamiast zgadywać dlaczego to vcs się nie nadaje - sprawdź.
Po co mam sprawdzać jak używam czegoś co działa i w pełni odpowiada moim
potrzebom? Tylko dlatego, że jest teraz taki hype?
Dodam, że śledzę sobie zmiany w jednym projekcie OpenSource
przechowywanym w Mercurialu (sam nie commituję) i nie widzę w jaki
sposób jest to lepsze od scentralizowanych systemów.
> idea jest taka, że ultra-szybka praca systemu kontroli wersji zmienia
> cały model działania.
>
> w repozytoriach z centralnym serwerem - commitujesz relatywnie rzadko -
> max kilka razy dziennie. jak masz repozytorium typu git, to możesz
> commitować co sekundę. i to się przydaje. ponieważ commitujesz *sobie*,
> to możesz bezstresowo commitować nawet niedziałający kod - jako backup,
> czy "work in progress".
To nie jest zupełnie nowy model działania. Istnieje już bardzo długo
tylko pod inną nazwą - prywatne gałęzie.
>> 3. Nawet jeżeli masz cienkie łącze do serwera SVN i musisz cały dzień
>> siedzieć i np. oglądać diffy z zupełnie różnych branchy to rozproszony
>> VCS nic Ci w tym nie pomoże. Tak czy siak - przy takim scenariuszu
>> musisz łączyć się z innymi komputerami żeby dostać te inne gałęzie.
>> Używając SVNa przynajmniej będziesz wiedział gdzie ich szukać.
>
> powtórzę: zamiast zgadywać dlaczego to vcs się nie nadaje - sprawdź.
Sprawdziłbym jakbym widział chociaż cień szansy, że polepszy się od tego
moje życie jako programisty.
Świetnie mi jednak cała dyskusja pasuje do dzisiejszego wpisu na blogu
Joela Spolsky'ego.
Pozdrawiam,
Wojciech Malinowski
> w repozytoriach z centralnym serwerem - commitujesz relatywnie rzadko -
> max kilka razy dziennie. jak masz repozytorium typu git, to możesz
> commitować co sekundę. i to się przydaje. ponieważ commitujesz *sobie*,
> to możesz bezstresowo commitować nawet niedziałający kod - jako backup,
> czy "work in progress".
>
Ja tam się nie znam, ale czym to niby się różni od commitowania do
mojego prywatnego brancha?
>> sugestia: sprawdź.
>> nie będę cię na siłę do niczego namawiał.
>> po prostu zobacz jaka jest różnica w pracy z svn'em, a z mercurialem
>> czy gitem.
>> potem możemy pogadać o tym co jest szybsze.
> Po co mam sprawdzać jak używam czegoś co działa i w pełni odpowiada
> moim potrzebom? Tylko dlatego, że jest teraz taki hype?
> Dodam, że śledzę sobie zmiany w jednym projekcie OpenSource
> przechowywanym w Mercurialu (sam nie commituję) i nie widzę w jaki
> sposób jest to lepsze od scentralizowanych systemów.
Ja się przyglądam mercurialowi z dwóch względów (w pracy używamy
subversion): zdarza mi się pracować 'w terenie' bez dostępu do sieci,
oraz potrzebuję czegoś jako 'brudnopisu' po to, żeby móc commitować
niedziałający kod i w każdej chwili móc wrócić do wcześniejszej wersji
(szkoda by było zaśmiecać repo svn). Znalazłem skrypty pozwalające
współdziałać z svn, więc jest nadzieja. Brakuje mi tylko jakiegoś
dobrego GUI do tego (porównywalnego chociażby do kdesvn).
--
<:> Roger, MoonWolf Out <:>|You live it or lie it!
(::) (::)|
(:)JID:moonwolfATjabberpl.org(:)| http://karakkhaz.prv.pl
Wypróbuj gita. git-svn zapewni współpracę z SVN, qgit - wygodne GUI.
.pk.
Widze, ze narazilem sie na ogien zaporowy. Jednak niektore ze stwierdzen
zawieraja w sobie ukryte dosc ciekawe pytania, wiec sprobuje odpowiedziec.
> Radomir 'The Sheep' Dopieralski wrote:
>> Dziwne sa te uwagi, widze ze kolega raczej rozproszonego systemu nigdy
>> na serio nie uzywal. Po pierwsze, 3 sekundy robia gigantyczna roznice
>> w stylu pracy: przestaje to byc jeden commit dziennie, commitujesz
>> praktycznie kazda spojna zmiane, przy okazji przed commitem oczywiscie
>> testujesz, wiec duzo drobniejsze zmiany per commit i duzo latwiej Ci
>> sie potem na przyklad wycofac z czegos.
> No tak. Zapomniałem, że SVN ma wbudowane zabezpieczenia przed więcej niż
> jednym commitem na dzień.
Zabezpieczen nie ma, ale ma roznice owych "3 sekund" (czy ile tam to trwa)
i koniecznosci dostepu do sieci. To jest naprawde gigantyczna roznica z
psychologicznego punktu widzenia -- a to wlasnie takie roznice zmieniaja
styl pracy.
>> Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich calkowicie
>> prywatnych klonow repozytorium, ktorych nikt nigdy nie musi ogladac i na
>> ktorych mozesz eksperymentowac ile dusza zapragnie bez zadnego wstydu.
>
> Z punktu widzenia firmy (a o tym właśnie pisze) to wstyd możesz sobie
> schować do kieszeni przed wejściem do budynku i wyjąć z powrotem przy
> wyjściu. Przypomnę, że piszę o projektach nie-opensource.
>
> Nie rozumiem poza tym jak można się wstydzić własnego kodu. Chyba będę
> musiał zaprzestać organizowania code reviews, bo może ktoś się wstydzi
> poddawać pod komentarze swój własny kod.
Jesli nikt nie wstydzi sie wlasnego kodu (lub nie powinien sie wstydzic),
to nie widze sensu organizowania przefgladow kodu -- bo to chyba wlasnie
jest ich celem, zeby sklonic ludzi do pisania ladniejszego kodu. Wstyd
jest tutaj czynnikiem motywacyjnym. Mozesz sobie pisac jak to nie obchodzi
Cie co sobie o Twoim kodzie mysla inni i ze nie ma sie czego wstydzic --
na pewno wszyscy sobie pomyslimy jaki wspanialy macho jestes. Ale wachanie
jest zawsze, nawet jesli ukrywane pod maska bezczelnosci.
> Przecież wiadomo, że nikt nie tworzy od razu pięknego kodu. Jeśli
> piszesz tracer bullet to go wrzucasz do VCS z komentarzem, że to tracer
> bullet (w prywatnej gałęzi). Jak zadziała to jeśli jesteś dobrym
> programistą to go przepisujesz już poprawnie, jeżeli słabym to nigdy go
> poprawnie nie napiszesz. Będziesz go wtedy ukrywał na zawsze w prywatnym
> repozytorium?
Jak nigdy nie zadziala, to po pewnym czasie prywatne repo skasuje albo
przeniose do archiwum i tyle. Osobiscie nie wierze w przepisywanie kodu
od zera -- probowalem tego kilka razy (pare razy nie mialem wyboru, bo
w gre wchodzila zmiana jezyka) i nigdy nie bylo to latwa. W sumie, patrzac
wstecz, to chyba nawet nigdy do konca nie bylo to przepisanie. Sam piszesz
ze nikt od razu nie napisze dobrego kodu -- zatem piszesz kiepski
i stopniowo ulepszasz. A jak juz jest wystarczajaco dobry zeby twoi
wspolpracownicy sobie nie wydrapali oczu, to laczysz z repozytorium
"glownym" i tyle.
[snip]
>> Rozproszone repozytoria maja
>> za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na synchronizacje
>> dwoch repozytoriow -- najczesciej Twojego lokalnego i centralnego,
>> firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy
>> maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego
>> commita).
>
> A jak to się różni od złączenia dwóch gałęzi w SVNie?
Roznica w zasadzie jest tylko taka, ze robisz to kilkanascie razy dziennie
jako czesc normalnej pracy, a nie od swieta i z bolem tak wielkim, ze
wygodniej jest dana rzecz napisac od nowa.
>> Wydaje mi sie, ze komentarz o "pryszczerskich projektach" to cos w rodzaju
>> hasla "sikajac z wiaterm idziesz na latwizne" :)
>
> Przeczytaj jeszcze raz wątek, bo to nie moje słowa.
Ale przeciez ja nie twierdze ze sa Twoje. Nie prowadze tej dyskusji
wylacznie z Twoja osoba, nawet Cie nie znam -- staram sie przyczynic
do pokazania roznic miedzy tradycyjnym i rozproszonym systemem wersji
oraz pokazac zalety tego drugiego. Nie ma w tym nic osobistego.
Chcialem zaznaczyc, ze osobiscie nie mam nic do uzytkownikow SVN-a,
i cieszy mnie, ze rasowi wyjadacze potrafia uzyc tego poteznego
narzedzia do skonstruowania sobie czegos na ksztalt wspolczesnych
rozproszonych systemow zarzadzania wersjami -- uzywajac prywatnych
galezi i podobnych mechanizmow. Osobiscie jednak latwiej mi jest
se nauczyc samych tylko podstwa systemu ktory juz ma to wbudowane.
szybkością.
> Dnia 01.05.2008 Wojciech Malinowski <vir...@wp.pl> napisał/a:
>> 1. Zauważ, że pisałem o projektach nie-opensource, realizowanych głównie
>> w siedzibach firm. Nie wydaje mi się, żeby w firmach developerskich
>> używane było cokolwiek gorszego niż 10Mb LAN. W takich warunkach
>> odpowiedź z centralnego serwera może być szybsza niż z Twojego własnego
>> komputera, jako że maszyny developerskie potrafią być mocno obciążone
>> różnymi eclipsami, debugerami, lokalnymi testowymi bazami danych itp.
>
> sugestia: sprawdź.
> nie będę cię na siłę do niczego namawiał.
> po prostu zobacz jaka jest różnica w pracy z svn'em, a z mercurialem czy
> gitem.
> potem możemy pogadać o tym co jest szybsze.
W tym przypadku prościej zacząć od svk.
eloy
--
-------e-l-o-y----------------------------e-l-o-y-@-k-o-f-e-i-n-a-.-n-e-t------
jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej
Dokładnie.
bart
--
"The first version of iBook looked a bit too much like toilet seat" (c)Newsweek
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
> http://git.or.cz/gitwiki/GitProjects
> http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial
> nawet słaby w porównaniu z dwoma poprzednimi bazaar ma się czym
> pochwalić
> http://bazaar-vcs.org/WhoUsesBzr
>
> Czasami odnoszę wrażenie że nie wszyscy czytają to co napisali przed
> wysłaniem, a ilość przedkładają nad jakość. Obym się mylił.
No, jak pisałem, długie listy pryszczerskich projektów. Przecież to
wszystko są projekty Open Source. I owszem, w przypadku takich
projektów to ma sens. Nie bardzo widzę sens, żeby firma robiąca
komercyjne, zamknięte aplikacje używała rozproszonego VCS.
Ba, powiedziałbym wręcz, że widzę sens w tym, aby nie używała
rozproszonego.
bart
--
"Nie musisz mi tlumaczyc szanowna kolezanko czym jest internet - dysponuje
laczem stalym i wiem cos na ten temat !!!" - (c)Dariusz Kaminski
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Może jak się robi edycję grafiki czy coś w ten deseń, to to ma jakiekolwiek
znaczenie. W przypadku kodu źródłowego nie ma żadnego. Zmiany będą miały
nie więcej niż kilka KB i to przed kompresją. Więc będzie działać szybko,
nawet jeśli używasz modemu 14,4kbps ;-P
bart
--
"Nie ma czegoś takiego jak brak snu, najwyżej brak kawy." (c) D. Simmons
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Branches w SVN to twoim zdaniem do czego służy?
> Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich calkowicie
> prywatnych klonow repozytorium, ktorych nikt nigdy nie musi ogladac i na
> ktorych mozesz eksperymentowac ile dusza zapragnie bez zadnego wstydu.
Możesz mieć swój prywatny branch.
> Do tego zrobienie nowego to jest mgnienie oka, a nie uzeranie sie
> z firmowymi adminami.
Do zrobienia brancha w SVN trzeba firmowego admina?
> Po trzecie, nie ogladasz diffow z kazdego commita i nie zbierasz ich
> z roznych maszyn -- nie wiem skad ten pomysl. Rozproszone repozytoria maja
> za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na synchronizacje
> dwoch repozytoriow -- najczesciej Twojego lokalnego i centralnego,
> firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy
> maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego
> commita).
Super. A gdzie jest *centralny* backup tego wszystkiego?
bart
--
"Big Duke Six to Eagle Thrust, put on heading 270, assume attack formation"
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
> 50% tych funkcji, a tu masz odpowiedz dlaczego(pod nia jest dalszy
> ciag posta):
>
>>>> l = [dict, list, map, str, float]
>>>> dir(l)
Co wy chcecie? len(dir((dict,list,map,str,float))) to w sumie tylko 27
metod. Pikuś.
Sama klasa String w Ruby ma ich 77. A podobna lista,
(Array.methods + Hash.methods + String.methods + Numeric.methods
+ Float.methods).size
to 387 metod. Nie wiecie, co to jest dużo. Rozpieścił was Python swym
minimalizmem. :-D
Nie rozumiem jaki byłby sens zabraniać czegoś takiego. W ogłoszeniu
napisałem o tym że można pracować częściowo zdalnie - w tym momencie
rozproszone repo nabiera ogromnego znaczenia.
Popieram Radomira w całej rozciągłości - ale zmiana nastawienia to nie
jedyna rzecz.
Rozproszone repo jest konieczne jeśli pracujemy trochę w domu, trochę
w podróży, w pociągu, w samolocie, na uczelni, na wyjeździe. Słowem -
tam, gdzie akurat wylądujemy z laptopem. Warto wspomnieć, że nie każdy
ma dostęp do sieci w domu i wtedy można robić commita jak przyjdzie na
to ochota, a pusha np. na rynku głównym albo w jakimś lokalu, przy
browarku :)
W imię braku problemów po wycieku kodu, kradzieży laptopa, itd...
Michał
Zauważ, że napisałem pozwala w cudzysłowie. Nie wszystkim podoba się
wymuszanie zabierania pracy do domu.
Jeśli w czasie wolnym odpoczywasz (ładujesz akumulatory) to nie
interesują Cię żadne rozproszone systemy kontroli wersji. A na rynek
główny, czy na piwo (tak jak napisałeś w innym poście) zabierasz
kobietę, a nie laptopa z projektem, nad którym pracujesz.
Pozdrawiam,
Wojciech Malinowski
> Dnia 28-04-2008 o 15:36:32 Sulsa <su...@dontmail.me> napisał(a):
>
> > 50% tych funkcji, a tu masz odpowiedz dlaczego(pod nia jest dalszy
> > ciag posta):
> >
> >>>> l = [dict, list, map, str, float]
> >>>> dir(l)
>
> Co wy chcecie? len(dir((dict,list,map,str,float))) to w sumie tylko 27
> metod. Pikuś.
Co ty gadasz wykonales przeciez dir na tupli a nie na tych wszystkich
klasach:
>>> dir((dict,list,map,str,float))
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__ge__', '__getattribute__', '__getitem__',
'__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__',
'__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__',
'__setattr__', '__str__']
Commit do serwera stojącego w piwnicy trwa poniżej sekundy... nawet 1000x
szybciej nic tu nie wniesie.
pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
AeLizm.
Jak JVM Suna jest pryszczerskim projektem, to wszystko poza sterowaniem
Boeingiem 777, elektorwnią atomową czy systemem antyrakietowym jest
pryszczerskim projektem.
Rozproszone mają po prostu sens dla projektów developowanych "rozproszenie"
co nie ma nic do pryszczerstwa. Ale tam gdzie chodzi się do pracy i
commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a
straty są istotne (nadużywanie branchów i wynikające z tego zdarzające się
od czasu do czasu błędy merdżowania, utrata istotnych danych bo pudełko pod
biurkiem zdechło, itp).
W rzeczywistej pracy (zawodowej) nie ma żadnej bariery psychologicznej. Po
sieci 100Mbs to nie ma znaczenia.
Za to zasadnicze znaczenie mają ewentualne straty gdy padnie lokalny dysk.
Gdy masz projekt na 50 osób, to awarie dysków są częste. Na serwerze robi
się backupy jest porządna (a nie zabawkowa) macierz i jeden serwer
statystycznie psuje się o dwa rzędy wielkości rzadziej niż któryś z
kilkudziesięciu komputerów deweloperskich.
Commity robi się tak samo, co każdą spójną zmianę. Ba często nawet spójność
zmiany jest iluzoryczna, bo w typowym większym systemie lokalnie to sobie
można unit testy zrobić albo nawet i to nie pójdzie (bo lokalnie to masz
Peceta, a system jest na zupełnie co innego).
>>> Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich
>>> calkowicie prywatnych klonow repozytorium, ktorych nikt nigdy nie musi
>>> ogladac i na ktorych mozesz eksperymentowac ile dusza zapragnie bez
>>> zadnego wstydu.
>>
>> Z punktu widzenia firmy (a o tym właśnie pisze) to wstyd możesz sobie
>> schować do kieszeni przed wejściem do budynku i wyjąć z powrotem przy
>> wyjściu. Przypomnę, że piszę o projektach nie-opensource.
>>
>> Nie rozumiem poza tym jak można się wstydzić własnego kodu. Chyba będę
>> musiał zaprzestać organizowania code reviews, bo może ktoś się wstydzi
>> poddawać pod komentarze swój własny kod.
>
> Jesli nikt nie wstydzi sie wlasnego kodu (lub nie powinien sie wstydzic),
> to nie widze sensu organizowania przefgladow kodu
Czy Ty kiedykolwiek programowałeś zawodowo, w zespole, a nie tylko
studencko/hobbystycznie + jakiś maleńki projekcik dla dorobienia?
> -- bo to chyba wlasnie
> jest ich celem, zeby sklonic ludzi do pisania ladniejszego kodu.
Ich nadrzędnym celem jest wczesna eliminacja błędów. Drugim celem jest
utrzymywalność kodu (czyli żeby był ładny, w znaczeniu czytelny).
> Wstyd
> jest tutaj czynnikiem motywacyjnym. Mozesz sobie pisac jak to nie obchodzi
> Cie co sobie o Twoim kodzie mysla inni i ze nie ma sie czego wstydzic --
> na pewno wszyscy sobie pomyslimy jaki wspanialy macho jestes. Ale wachanie
> jest zawsze, nawet jesli ukrywane pod maska bezczelnosci.
I co z tego? Celem jest kod z możliwie małą liczbą pułapek dla późniejszych
developerów i małą liczbą heisenbugów. Na jedno i drugie przeglądy kodu
działają znakomicie.
>> Przecież wiadomo, że nikt nie tworzy od razu pięknego kodu. Jeśli
>> piszesz tracer bullet to go wrzucasz do VCS z komentarzem, że to tracer
>> bullet (w prywatnej gałęzi). Jak zadziała to jeśli jesteś dobrym
>> programistą to go przepisujesz już poprawnie, jeżeli słabym to nigdy go
>> poprawnie nie napiszesz. Będziesz go wtedy ukrywał na zawsze w prywatnym
>> repozytorium?
>
> Jak nigdy nie zadziala, to po pewnym czasie prywatne repo skasuje albo
> przeniose do archiwum i tyle. Osobiscie nie wierze w przepisywanie kodu
> od zera -- probowalem tego kilka razy (pare razy nie mialem wyboru, bo
> w gre wchodzila zmiana jezyka) i nigdy nie bylo to latwa. W sumie, patrzac
> wstecz, to chyba nawet nigdy do konca nie bylo to przepisanie. Sam piszesz
> ze nikt od razu nie napisze dobrego kodu -- zatem piszesz kiepski
> i stopniowo ulepszasz. A jak juz jest wystarczajaco dobry zeby twoi
> wspolpracownicy sobie nie wydrapali oczu, to laczysz z repozytorium
> "glownym" i tyle.
A jak w między czasie sprzątaczka zaczepi odkurzaczem o komputer i dysk
padnie to masz pisanie od początku... W przemyśle na takie zabawy nie ma
miejsca.
>>> Rozproszone repozytoria maja
>>> za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na
>>> synchronizacje dwoch repozytoriow -- najczesciej Twojego lokalnego i
>>> centralnego,
>>> firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy
>>> maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego
>>> commita).
>>
>> A jak to się różni od złączenia dwóch gałęzi w SVNie?
>
> Roznica w zasadzie jest tylko taka, ze robisz to kilkanascie razy dziennie
> jako czesc normalnej pracy, a nie od swieta i z bolem tak wielkim, ze
> wygodniej jest dana rzecz napisac od nowa.
Bo taka rzecz w normalnej organizacji pracy jest potrzebna od święta. To, że
systemy rozproszone przyczynaiją się do robienia tego często jest w tej
sytuacji ich poważną wadą a nie zaletą.
>>> Wydaje mi sie, ze komentarz o "pryszczerskich projektach" to cos w
>>> rodzaju hasla "sikajac z wiaterm idziesz na latwizne" :)
>>
>> Przeczytaj jeszcze raz wątek, bo to nie moje słowa.
>
> Ale przeciez ja nie twierdze ze sa Twoje. Nie prowadze tej dyskusji
> wylacznie z Twoja osoba, nawet Cie nie znam -- staram sie przyczynic
> do pokazania roznic miedzy tradycyjnym i rozproszonym systemem wersji
> oraz pokazac zalety tego drugiego. Nie ma w tym nic osobistego.
>
> Chcialem zaznaczyc, ze osobiscie nie mam nic do uzytkownikow SVN-a,
> i cieszy mnie, ze rasowi wyjadacze potrafia uzyc tego poteznego
> narzedzia do skonstruowania sobie czegos na ksztalt wspolczesnych
> rozproszonych systemow zarzadzania wersjami -- uzywajac prywatnych
> galezi i podobnych mechanizmow. Osobiscie jednak latwiej mi jest
> se nauczyc samych tylko podstwa systemu ktory juz ma to wbudowane.
Najwygodniej jest nie musieć stosować rzeczy do niczego w pracy
niepotrzebnych. Dlatego branche robi się rzadko bo ich celem jest
rzeczywisty branch (np. wersja działąjąca u klienta "na produkcji") a nie
prywatne zabawy koderów (które są w takiej sytuacji szkodliwe)
pzdr
Każdy, w którym mogą brać udział szerokie rzesze pryszczersów, jest projektem
pryszczesrkim. Jak będzie system antyrakietowy, do którego kod będzie mógł
modyfikować nastoletni "spec" z Zadupiesville, to też bedzie to pryszczerski
projekt ;-P
> Rozproszone mają po prostu sens dla projektów developowanych "rozproszenie"
> co nie ma nic do pryszczerstwa.
Oczywiście, że mają. Są to projekty Open Source albo Free Software.
> Ale tam gdzie chodzi się do pracy i
> commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a
> straty są istotne (nadużywanie branchów i wynikające z tego zdarzające się
> od czasu do czasu błędy merdżowania, utrata istotnych danych bo pudełko pod
> biurkiem zdechło, itp).
Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może
być nawet i po przeciwnej stronie globu.
bart
--
This signature is intentionally left blank.
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
To zależy jakie zmiany są robione i ile jest branchy. U mnie pobieranie
całego projektu przez ocean po CVS trwa zdecydowanie dłużej niż godzinę.
Jednoplikowe poprawki to rzeczywiście żaden problem.
No dobra, ale tak często pobierasz projekt+wszystkie branche?
--
Rzadko, ale czasami to się robi.
Po ssh, gdzie ssh ma kompresję ustawioną ma max?
I co znaczy "pobieranie całego"? Przecież checkout się robi konkretnej
wersji a nie wszystkich branchy.
bart
--
"PLEASE DO *NOT* EDIT or poldek will hate you." - packages.dir (PLD)
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Ale ten jeden snapshot to setki megabajtów.
Ale to nie jest argument za zdecentralizowanymi VCS, bo pobranie całego
projektu z oficjalnego repo będzie działało tak samo długo w każdym VCS.
Pozdrawiam,
Wojciech Malinowski
Setki megabajtów *źródeł*??
bart
--
"Szukam potomków na serwerze..." (c) SLRN
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
A ile zajmą wszystkie snapshoty wszystkich developerów w VCS-ie
rozproszonym? Przecież też się trzeba od czasu do czasu zsynchronizować
z resztą, nie?
--
<:> Roger, MoonWolf Out <:>|So fu*king what
(::) (::)|
(:)JID:moonwolfATjabberpl.org(:)| http://karakkhaz.prv.pl
Ha, to już wiem skąd się bierze te 80% ruchu w Internecie generowanego
przez P2P ;-)
bart
--
"Przeciez nie ma internetu bez przegladarki" - (c)Dariusz Kaminski
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Taka twoja definicja. Z definicjami się nie dyskutuje. Choć mnie by bardziej
interesowały kryteria wg których kod jest włączany do projektu.
Bo tak to i Windows jest "pryszczerski", bo wzięli gotowe
fragmenty "pryszczerskiego" BSD (choćby w obsłudze sieci). Jeśli kod przed
wpuszczeniem jest odpowiednio weryfikowany to niech sobie pochodzi od
kogokolwiek. BTW. w wielu projektach OS wpuszcza się spoza zespołu tylko
maleńkie fragmenty -- głównie poprawki bugów. Celem otwarcia źródeł jest
darmowy zewnętrzny przegląd kodu + darmowe testy + darmowe poprawki.
>> Rozproszone mają po prostu sens dla projektów developowanych
>> "rozproszenie" co nie ma nic do pryszczerstwa.
>
> Oczywiście, że mają. Są to projekty Open Source albo Free Software.
Też nie koniecznie. Rzadko bo rzadko, ale nie muszą być otwarte.
>
>> Ale tam gdzie chodzi się do pracy i
>> commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a
>> straty są istotne (nadużywanie branchów i wynikające z tego zdarzające
>> się od czasu do czasu błędy merdżowania, utrata istotnych danych bo
>> pudełko pod biurkiem zdechło, itp).
>
> Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może
> być nawet i po przeciwnej stronie globu.
Problem wtedy taki, że minimalnie wolniej działa. Choć w praktyce to ma małe
znaczenie, bo w przeciwieństwie do różnych wypisywanych w tym wątku
opwiastek, to commity, zwłaszcza częste, dotyczą małej liczby danych, więc
idą szybko. Kłopot jest tylko z trzymaniem w repozytorium binariów typu
dokumentacja w Wordzie czy PDFach, obrazki itp.
pzdr
Przyszczerski to jest Free/OpenBSD. BSD (jak można domyśleć się z nazwy)
należy do Uniwersytetu Kalifornijskiego w Berkeley.
>>> Rozproszone mają po prostu sens dla projektów developowanych
>>> "rozproszenie" co nie ma nic do pryszczerstwa.
>>
>> Oczywiście, że mają. Są to projekty Open Source albo Free Software.
>
> Też nie koniecznie. Rzadko bo rzadko, ale nie muszą być otwarte.
Oh? Możesz podać jakiś przykład?
>>> Ale tam gdzie chodzi się do pracy i
>>> commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a
>>> straty są istotne (nadużywanie branchów i wynikające z tego zdarzające
>>> się od czasu do czasu błędy merdżowania, utrata istotnych danych bo
>>> pudełko pod biurkiem zdechło, itp).
>>
>> Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może
>> być nawet i po przeciwnej stronie globu.
>
> Problem wtedy taki, że minimalnie wolniej działa. Choć w praktyce to ma małe
> znaczenie, bo w przeciwieństwie do różnych wypisywanych w tym wątku
> opwiastek, to commity, zwłaszcza częste, dotyczą małej liczby danych, więc
> idą szybko. Kłopot jest tylko z trzymaniem w repozytorium binariów typu
> dokumentacja w Wordzie czy PDFach, obrazki itp.
SVN używa xdelta, dosyć dobrze działa na binarkach.
bart
--
"Security issues are not discussed in this memo, but then again, no
other issues of any importance are discussed in this memo either." [RFC1438]
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Michał
> Owszem, i tak bywa.
Co ma setki megabajtów źródeł? Całe KDE? Ale KDE jest podzielone na
dziesiątki projektów. Windows Vista? ZTCP, jądro Visty ma poniżej
100 tys. linii.
A jeśli do tego, żeby pracować nad jakiś fragmentem, trzeba ściągnąć
setki megabajtów źródeł, to najwyraźniej coś jest nie tak.
bart
--
Set phasers on kill, fire at will.
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
> A jeśli do tego, żeby pracować nad jakiś fragmentem, trzeba ściągnąć
> setki megabajtów źródeł, to najwyraźniej coś jest nie tak.
A to chyba całkiem normalne że zawsze coś jest nie tak.
--
Adam "Prawda jest prosta - gdyby było inaczej
każdy głupiec mógłby ją zrozumieć".
> A to chyba całkiem normalne że zawsze coś jest nie tak.
ROTFL :)
AK
I udostępniany jest na licencji znanej jak BSD. Bardzo pryszczerskiej.
A Java należy do Sun Microsystems. A przed chwilą stwierdziłęś, że jest
pryszczerska (bo otworzono źródła).
>>>> Rozproszone mają po prostu sens dla projektów developowanych
>>>> "rozproszenie" co nie ma nic do pryszczerstwa.
>>>
>>> Oczywiście, że mają. Są to projekty Open Source albo Free Software.
>>
>> Też nie koniecznie. Rzadko bo rzadko, ale nie muszą być otwarte.
>
> Oh? Możesz podać jakiś przykład?
Różne projekty akademickie. Skoro BSD należycu do UK w Berkeley jest OK, to
i inne należące do różnych uczelni też muszą być OK (nie pryszczerskie).
>>>> Ale tam gdzie chodzi się do pracy i
>>>> commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego,
>>>> a straty są istotne (nadużywanie branchów i wynikające z tego
>>>> zdarzające się od czasu do czasu błędy merdżowania, utrata istotnych
>>>> danych bo pudełko pod biurkiem zdechło, itp).
>>>
>>> Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może
>>> być nawet i po przeciwnej stronie globu.
>>
>> Problem wtedy taki, że minimalnie wolniej działa. Choć w praktyce to ma
>> małe znaczenie, bo w przeciwieństwie do różnych wypisywanych w tym wątku
>> opwiastek, to commity, zwłaszcza częste, dotyczą małej liczby danych,
>> więc idą szybko. Kłopot jest tylko z trzymaniem w repozytorium binariów
>> typu dokumentacja w Wordzie czy PDFach, obrazki itp.
>
> SVN używa xdelta, dosyć dobrze działa na binarkach.
Pod warunkiem, że kolejne binraki mało się różnią. A wystarczy że coś jest
kompresowane i różnice eksplodują.
Sad but true :)
Bynajmniej. Na takiej licencji, to dopiero jak wycieli kod należący do AT&T.
>>>>> Rozproszone mają po prostu sens dla projektów developowanych
>>>>> "rozproszenie" co nie ma nic do pryszczerstwa.
>>>>
>>>> Oczywiście, że mają. Są to projekty Open Source albo Free Software.
>>>
>>> Też nie koniecznie. Rzadko bo rzadko, ale nie muszą być otwarte.
>>
>> Oh? Możesz podać jakiś przykład?
>
> Różne projekty akademickie. Skoro BSD należycu do UK w Berkeley jest OK, to
> i inne należące do różnych uczelni też muszą być OK (nie pryszczerskie).
Nie ma to jak konkret...
bart
--
"You understand, captain, this mission does not exist, nor will it ever exist."
http://candajon.azorragarse.info/ http://azorragarse.candajon.info/
Np. projekt z przetwarzania języka naturalnego porowadzony przez IPI PAN i
ileś tam instytucji zagranicznych... Nazwy nie pamiętam
Tylko co to wnosi?
Michał
>> > 50% tych funkcji, a tu masz odpowiedz dlaczego(pod nia jest dalszy
>> > ciag posta):
>> >
>> >>>> l = [dict, list, map, str, float]
>> >>>> dir(l)
>>
>> Co wy chcecie? len(dir((dict,list,map,str,float))) to w sumie tylko 27
>> metod. Pikuś.
>
> Co ty gadasz wykonales przeciez dir na tupli a nie na tych wszystkich
> klasach:
>
>>>> dir((dict,list,map,str,float))
> ['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
> '__eq__', '__ge__', '__getattribute__', '__getitem__',
> '__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__',
> '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__',
> '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__',
> '__setattr__', '__str__']
I to ma być ten natłok metod? Ech, ta dzisiejsza młodzież...
--
Jarosław Zabiełło
http://blog.zabiello.com
>> Co ty gadasz wykonales przeciez dir na tupli a nie na tych wszystkich
>> klasach:
>>
>>>>> dir((dict,list,map,str,float))
>> ['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
>> '__eq__', '__ge__', '__getattribute__', '__getitem__',
>> '__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__',
>> '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__',
>> '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__',
>> '__setattr__', '__str__']
>
> I to ma być ten natłok metod? Ech, ta dzisiejsza młodzież...
Tym razem mlodziez ma conieco racji :)
PS: Sorry ze zepsulem zabawe :)
AK