Wiem, że ma 18 lat i to jest pewnie przyczyna, co nie znaczy, że nie będę nazywał rzeczy po imieniu :>
A ja się nie wypowiem w sprawie samego problemu z mass assignment (bo już pewnie znacie moje zdanie na ten temat), ale ten koleś mógł narobić więcej syfu gdyby chciał. W skali złowrogości raptem 2/10 - trochę go poniosło ale można to wytłumaczyć młodym wiekiem.
PS. Wiem że komentarze na reddicie to nie argument, a często wręcz kontrargument, ale sporo z nich zaskakująco obiektywnych. Oraz nie wiem jak Wy, ale ja bardzo cenię opinię outsiderów, z odległości mają często mniej zniekształconą perspektywę:
Potwierdzam.
W Railsach od początku brakowało polityki secure-by-default i to się mści. Pamiętam jak 5-6 lat temu była walka postulujących domyślne eskejpowanie w szablonach, którą przegrali z DHH. Na szczęście kilka lat później rozsądek wygrał i mamy dziś domyślne eskejpowanie. Z mass assignment też tak będzie, wcześniej czy później.
Trochę się offtop zrobił i jak ktoś będzie szukał info o terminie na drugiej stronie wątku (nie wiem jak inni, ja zazwyczaj patrzę na koniec, bo a nuż jakaś zmiana) to nie znajdzie terminu i miejsca, więc może przypomnę:
Marcowy Wrug 20 marca o 18:30 w BRAMie przy metrze politechnika
event na fejsie: http://www.facebook.com/events/247061535381920/
Zaktualizowałem stronę, żeby wszystko było zgodnie z koranem.
http://wrug.eu/2012/03/08/2012-03-spotkanie-marcowe/
pojawi się też gość specjalny z lightning-talkiem o pewnej inicjatywie w kwietniu. ale sza, to niespodzianka!
(zaraz dodam tego teasera na stronę)
ciekawe kogo z berlina przywieziesz…
Załączam prezentację o izolacji transakcji w Railsach.
PS publika dopisała, prezki o debuggowaniu i deface bardzo praktyczne, fajny WRUG wyszedł.
Tak.
+1
[quote=qertoip]Załączam prezentację o izolacji transakcji w Railsach.
PS publika dopisała, prezki o debuggowaniu i deface bardzo praktyczne, fajny WRUG wyszedł.[/quote]
Dzięki za fajne prezentacje, kudos!
delayed_job (2.1.4, nie wiem jak nowszy) nie stosuje żadnych blokad ani transakcji. Kto pierwszy, ten lepszy.
Dziwne, to by znaczyło, że kilka workerów mogło by zacząć ogarniać ten sam job. Chyba, że jest to inaczej zabezpieczone…
Dzięki wszystkim za dobre spotkanie!
[quote=filiptepper][quote=qertoip]Załączam prezentację o izolacji transakcji w Railsach.
PS publika dopisała, prezki o debuggowaniu i deface bardzo praktyczne, fajny WRUG wyszedł.[/quote]
Dzięki za fajne prezentacje, kudos!
delayed_job (2.1.4, nie wiem jak nowszy) nie stosuje żadnych blokad ani transakcji. Kto pierwszy, ten lepszy.[/quote]
Źle spojrzaleś 
Dzięki wielkie dla Clay, drogusa, Kuby, quertoipa i Tomasha za prezentacje!
Publika tak dopisała, że na następny raz zaczynam załatwiać jakąś większą salę (ale after w Śródmiejskiej był zacny).
Tak. Dzięki wielkie wszystkim, to był rewelacyjny WRUG, chcę więcej takich
Żałuję że spóźniłem się na większość prezentacji Piotrka, dzięki za slajdy!
Jaram się obiema inicjatywami pitchowanymi na tym WRUGu, jeszcze dziś strzelę o nich osobne notki na naszej stronie.
Oraz zdecydowanie potrzebujemy większej sali. Oraz blisko centrum (ew. metra) – sala w Connectmedice jest super (FWIH), ale służew i dojazd tramwajem to średnia atrakcja.
Dziwne, to by znaczyło, że kilka workerów mogło by zacząć ogarniać ten sam job. Chyba, że jest to inaczej zabezpieczone…[/quote]
Navvy ma dokładnie tę wadę (z racji braku blokad więcej niż jeden worker może wziąć to samo zlecenie), a że to jest zasadniczo codebase DJ z dołożonym agnostycyzmem bazodanowym, to bym się nie zdziwił że DJ ma ten sam problem 
Dziwne, to by znaczyło, że kilka workerów mogło by zacząć ogarniać ten sam job. Chyba, że jest to inaczej zabezpieczone…[/quote]
delayed_job rozwiązuje ten problem w inny sprytny sposób.
Wykorzystuje fakt że, pojedyńcze zapytania (tu: UPDATE) zawsze wykonują się atomowo i transakcyjnie.
delayed_job w jednym zapytaniu odszukuje joby i jednocześnie oznacza je jako “wzięte”: kod.
Dzięki temu nie musi jawnie używać transakcji, bo w relacyjnych bazach danych z włączonym auto-commitem każde zapytanie i tak wykonuje się w ACID-owej transakcji.
Wciąż jednak trzeba się upewnić czy w danym RDBMS-ie auto-commit oznacza transakcję ACID z pełnym I, to znaczy w pełni wyizolowaną. Nie mam co do tego pewności. Wydaje mi się, że poziom izolacji powinien być podniesiony nawet jeśli to tylko jedne zapytanie. W kodzie delayed_job tego brakuje.
No to widzę, że mnie fajny event ominął :<
tomash, drogus - będziecie gdzieś publikować slajdy?
Oraz zdecydowanie potrzebujemy większej sali. Oraz blisko centrum (ew. metra) – sala w Connectmedice jest super (FWIH), ale służew i dojazd tramwajem to średnia atrakcja.[/quote]
Dziś wieczorem wybadam perspektywy na PW, powinno się udać.
khalas (organizator PyWawów, które przebyły drogę BRAMA → większa sala na PW przed nami) sugerował, żeby połączyć siły i rozejrzeć się za jakimś pubem w ~centrum, który mógłby co drugi tydzień hostować PyWaw, a co drugi WRUG-a – z rozmów z DRUG-owcami wynika, że pub to dobre rozwiązanie (tylko pytanie, czy znajdziemy wystarczająco duży lokal).