W pełni się zgadzam. Moje wybory byłyby troszkę inne, ale Kamilowi widać przeszkadza co innego. Mnie najbardziej wkurza rozmiar języka, zdecydowanie jest za duży i za dużo ma ‘kruczków’ nikomu do niczego nie potrzebnych.
Dlatego tak ciepło myślimy o mRuby.
http://brakemanscanner.org/ - czyli “Static analysis security scanner for Ruby on Rails” - moje odkrycie z dnia dzisiejszego 
Writing Fast Ruby by Erik Michaels-Ober
In established engineering disciplines a 12% improvement, easily
obtained, is never considered marginal and I believe the same viewpoint
should prevail in software engineering.
– Donald Knuth
Niestety, nie ma jeszcze nagrania z talku, ale same slajdy też są ciekawe.
1 Like
Przy czym fajne bylo to, ze podczas prezentacji podkreslil fragment easily obtained
Pomijając już jak sceptycznie nastawiony do takich mikro optymizacji, to warto zwrócić uwagę przy slajdzie 23 na subtelne różnice w zachowaniu merge i merge! jeśli przesyłamy identyczny Hash. Nietrywialne bugi z tego wychodzą potem.
Żem popełnił notkę: “Splitting monolithic Rails applications” https://www.amberbit.com/blog/2014/9/19/splitting-monolithic-rails-applications/
2 Likes
Najnowsza notka: “10 skills that will make you a better Rubyist” https://www.amberbit.com/blog/2014/9/29/10-skills-that-will-make-you-better-ruby-developer/
Zakładasz a priori, że jak ktoś robi w Ruby, to musi pisać internetowe startupy. Może tak jest u Was, ale jeśli trzymać się ogólnych zastosowań, to wyrzuciłbym punkty 7, 9 i 10.
Poza tym, punkt 4 zamieniłbym z “typing” na “know your editor”. Szybkie klepanie tekstu nie pomaga nawet w połowie tak bardzo jak umiejętność płynnej obsługi swojego edytora.
No tak, artykuł pisany jest s kontekście naszej firmy i chyba to wyraźnie jest napisane. Jeśli jesteś programistą Ruby to z dużym prawdopodobieństwem zdarza Ci się tworzyć aplikacje internetowe, chcesz czy nie - tak jest.
Jeśli chodzi o punkt 4, to się tylko częśćiowo zgodzę. Rozmawiasz również na czatach, piszesz maile, komentarze w systemie śledzienia ticketów. Jeśli nie umieszp pisać to marnujesz swój czas i czas osoby która stara się z Tobą skomunikować.
Zmień tytuł na “10 skills that will make you a better Ruby web developer” i się nie czepiam. Zwłaszcza, że w pierwszej wersji i tak mieliście podobny 
Co do pisania, to dobra uwaga z komunikacją, nie wziąłem tego pod uwagę. Jednakże uważam, że jakość komunikacji (czaty, mejle, komentarze) zależy głównie od ułożenia wiadomości w głowie, a nie od problemów z pisaniem. Nie kładbym osobiście większego nacisku na umiejętność klepania po klawiaturze.
Ah, mieliśmy, było za długie. “Web Rubyist?” też słabo.
Prędkość pisania nie ma znaczenia przy pisaniu kodu, to fakt. Bo jak ile linii napiszesz dziennie, 100, 150? To nawet jednym palcem by się dało wystukać. Ale właśnie komunikacja czy - edytor/shell, to inna sprawa. Pair programming z osobą która pisze na klawiaturze 2 palcami i wstukuje komendy z prędkością żółwia jest mocno denerwująca, niestety 
Jak ktoś chce użyć dekoratorów z Drapera na current_user z Devise, to ma problem Nie uda się uruchomić current_user.jakis_dekorator bo nie widzi tej funkcji.
Trzeba zrobić tak:
Katrina Owen – Overkill
Jeśli znacie exercism.io, to autorka dała świetną prezentację, która cała krąży wokół potencjalnych rozwiązań jednego z pierwszych zadań na tej platformie. Polecam wszystkim, niezależnie od stopnia wtajemniczenia.
Ciekawe kiedy ten wątek znajdą koledzy pamiętający jak ustawiając replikację postgresa niechcący spuściłem bazę produkcyjną sporego serwisu ogłoszeniowego.
Zrobiłem to nie rake’iem tylko sesją psql (tl;dr zamiast dropnąć bazę slave do rozpoczęcia czystej replikacji dropnąłem bazę master, głupie zakładki w terminalu), więc ten trik niestety by mnie nie uratował. Ale generalnie zacny, podoba mi się.
1 Like
1 Like
Step Outside Of Your Beloved Tools: Kuba o przerzucaniu się z Vima na Emacsa i dlaczego warto próbować nowych narzędzi (w sam raz na początek roku).