//DEVGURU

Jak donosi Grzegorz Wolański, 16 grudnia o godzinie 18:00 w Warszawie odbędzie się czwarte spotkanie programistów z cyklu TechAula poświęcone systemom kontroli wersji (VCS).

Zygmunt Krynicki (Samsung Electronis Polska) zaprezentuje Baazar, Alexey Shabalovskiy (Embiq) opowie o Mercurialu, a Paweł Kołodziej będzie przekonywał do darcsa.

Szczegóły na www.aulapolska.pl.

Rozpoczynamy cykl krótkich postów z linkami do ciekawych zasobów, na które natrafiamy podczas pracy nad naszymi projektami. Oto pierwsza partia linków:

• Jeden z członków teamu Google Gears Dion Almaer pisze o przyszłości Gearsów, wygląda na to, że dostęp do aplikacji offline to nie wszystko co Google ma w zanadrzu…
• Filip wrzucił video o pisaniu łatwego w “utrzymaniu” Javascriptu.
• Na blogu twórców ukazała się informacja o nowej wersji shoulda – 2.0. Używamy w netguru.
• Scrumy to ciekawe podejście do tworzenia znanych ze Scruma “tablic” z wymaganiami projektu.
• Adam podzielił się linkiem do prezentacji o zaawansowanym Javascripcie – wiedzieliście, że takie czary można robić w tym niedocenianym języku?
• Netmaniac podpowiada jak dodać parametry do tasków Rake’a.
• Na blogu Ajaxian ciekawy sposób zastąpienia Javascriptowego alert() czymś bardziej “dojrzałym”

Znalazłeś ciekawy link? Dodaj go do flakera z tagiem #devguru. Przejrzymy i być może w przyszłym tygodniu umieścimy w przeglądzie.

Nikt nie rodzi się ze znajomością języków programowania i frameworków ( :-P ).

Również nie wszyscy w netguru zaczynali pracę znając Ruby on Rails. Większość z nas nauczyła/uczy się tego frameworka dopiero w firmie. Jako, że problemy i pytania na które napotyka początkujący RoRowiec są często takie same, postanowiliśmy stworzyć jedno miejsce gdzie każdy początkujący znajdzie niektóre z odpowiedzi…

Tak właśnie powstało “Getting started with RoR“.

Pomyśleliśmy, że może komuś też taka wiedza się przyda, więc udostępniamy :-) SMACZNEGO

Jak pewnie gdzieś już pisałem od dawna korzystamy podczas developmentu z SVN oraz z Capistrano. Niedawno nasi zachodni sąsiedzi z firmy peritor stworzyli narzędzie webistrano, które po wprowadzeniu drobnych poprawek (prawa dostępu i style) wdrożyliśmy u siebie.

Dlaczego warto skorzystać z webistrano?

1. Prosta instalacja i względnie prosta konfiguracja.
2. Bezpieczeństwo (nie ma konieczności dawania dostępu do shella)
3. Prosta obsługa – deployment polega na kliknięciu w przycisk deploy.
4. Łatwe cofanie problematycznych deployów (deploy:rollback)
5. Przejrzysta historia deployów wraz z informacją kto go wykonał (wiadomo na kogo zwalić winę jak coś nie działa :P)
6. Obsługa Ruby on Rails (mongrel, passenger) jak i PHP
7. Automatyczne nadawanie praw odpowiednim katalogo.
8. Wiele innych możliwości (jeśli umiesz pisać skrypty do rake’a)

PS: Jak ktoś ma propozycję na polski odpowiednik słowa deploy/deployment to proszę o komentarz :-)

Jak to mówią – lepiej późno niż później…

Poniżej prezentacja jaką miałem przyjemność wygłosić podczas RuPy 2008:

W ramach netguru friday talks moja krótka prezentacja o tym jak wykorzystywać maksymalnie efektywnie pracę swoją i innych oraz jak i dlaczego korzystać ze sprawdzonych wzorców projektowych.

Enjoy.

| View | Upload your own

Kolejna historyjka z życia wzięta…

Klient przesyła feedback do projektu w pliku doc/txt czy po prostu w mailu. Załóżmy, że jest w miarę porządny i każda linijka odpowiada jednemu problemowi. I teraz co ma zrobić PM? Przepisywać kolejne tickety do firmowego Traca?

Nie wiem jak Wy, ale jak ja mam zrobić tą samą czynność więcej niż 5 razy to wolę wymyślić sposób, aby zrobił to za mnie ktoś inny (najlepiej komputer).

Oto jak to może wyglądać:

Jeśli masz dostęp do bazy (czyli hostujesz traca u siebie) skorzystasz z TracImport. Gorzej jeśli kupiłeś pakiet SVN+Trac na zewnętrznym hoście i nie masz danych mySQL.

Druga możliwość jaka się pojawia to wywołanie przez skrypt bezpośrednio przez POST formularza “New Ticket”. Dwa problemy: logowanie i “__FORM_TOKEN” – zabezpieczenie Traca przed CSRF. Niestety prosty skrypt z curl nie załatwi sprawy.

Na szczęście jest Ruby i Mechanize… Czyli krótka piłka:

1. Logujemy się
2. Pobieramy formularz New Ticket
3. Wpisujemy dane
4. Submitujemy
5. Wróć do 2 jeśli pozostały tickety do dodania

Skrypt do pobrania na pastie.

W razie pytań piszcie w komentarzach…

A taki szybki link – dość wstepna wersja, ale jest dużo ważnych “punktów”:

http://www.masukomi.org/writings/best_practices/best_practices.html

No dobrze, czyli obejrzałeś kilka screencastów, przerobiłeś parę tutoriali i postanowiłeś zrobić swoją własną aplikację Ruby on Rails?

Lokalnie wszystko działa, mongrel serwuje (wolno, bo wolno) strony, baza przetwarza rekordy, testy przechodzą w 100%.

Skończyłeś aplikację i pojawia się problem: Na jakim serwerze ją umieścić i jak go skonfigurować?

Zaczynasz od Dreamhosta… po tygodniu walki z killowanymi procesami odpuszczasz.

Wszyscy mówią: “serwer dedykowany”… i niestety mają rację. Jeśli Twoja aplikacja kierowana jest na rynek US – polecam SliceHost, a jeśli startujesz na Polskę/Europę – Hetzner.

OK, to teraz tylko jeden problem: Jak z czystej instalacji Ubuntu zrobić serwer Railsowy?

Z całej tej przygody jest to wbrew pozorom najłatwiejsze…

Deprec pozwala w 10 minut ustawić czyściutką instalację Ubuntu. Oto jak:

1. Upewniamy się, że nasza aplikacja jest dostępna w repozytorium SVN (jakże mogłoby być inaczej)
2. Upewniamy się, że w config/database.yml dane serwera dla production to localhost/root/[bez_hasła]
3. Logujemy się na serwer i tworzymy usera (np. deploy) nadajemy mu prawa sudo (dodajemy jego login w /etc/sudoers)
4. Logujemy się na serwer jako wcześniej stworzony user (deploy) i robimy testowego checkouta z repozytorium podając usera i hasło (aby zostało zapamiętane) – jak zacznie ściągać można anulować Ctrl-C i usunąć tymczasowy katalog
5. Ściągamy na domowym komputerze gem deprec (gem install -y deprec)
6. W katalogu głównym naszej aplikacji uruchamiamy ‘deprec –apply-to .’ (z kropką)
7. Edytujemy plik config/deploy.rb dodając odpowiednie wartości dla domain (adres/IP serwera), application (nazwa aplikacji – dowolna) i repository (ścieżka do repozytorium SVN)
8. No i po tych krótkich przygotowania już tylko sam lukier – uruchamiamy na domowym komputerze w katalogu głównym aplikacji po kolei:
   cap install_rails_stack – instaluje wszystko – od apache do gemów
   cap setup – ustawia naszą aplikację
   cap deploy_with_migrations – wrzuca aplikację na serwer i migruje bazę
   cap restart_apache – wiadomo…
9. Przy odrobinie szczęścia i szybkim serwerze po 5 minutach aplikacja jest już LIVE!

Jeden z ostatnich argumentów przeciwników RoR pada… instalacja i deployment serwisów w Ralisach przy użyciu deprec i capistrano to kaszka z mleczkiem ;-)

Męczysz się nad poprawieniem wydajności i wyglądu swojego kodu?

Wyślij go na http://refactormycode.com i pozwól sobie pomóc…