Distributed wget - projekt semestralny

04 lipca 2009, 14:46:47

Końcówka maja była dość wyczerpująca - zakończenie semestru, a zgodnie z regulaminem elki oznacza zaliczenie wszystkich przedmiotów nieegzaminacyjnych, czyli takich, które zamiast egzaminem, kończą się kolokwium na ostatnim wykładzie :>.

Noce upływały nam (mi oraz Tomkowi, Pawłowi i Łukaszowi) na wesołym kodowaniu w Pythonie oraz spożywaniu napojów energetycznych. Powstał dwget, rozproszony wget. Program jest realizacją zadania drugiego, z nieznacznymi modyfikacjami.

Idea projektu polega na kilku węzłach podrzędych, które ściągają fragmenty pliku, i węźle nadrzędnym, który koordynuje zadania i nawiązuje interakcję z użytkownikiem. Sens takiego sposobu pobierania pliku jest cokolwiek wątpliwy, poprawa szybkości będzie miała miejsce jedynie w dość rzadkim przypadku: węzły podrzędne muszą mieć niezależne łącza do Internetu oraz szybkie łącze wewnętrzne do przesyłania pobranego fragmentu do węzła nadrzędnego.

Był to dla nas pierwszy większy kawałek kodu pisany w Pythonie, więc z pewnością jest bardzo niedoskonały :). W związku z tym, że program korzysta z dość pokaźnej liczby wątków (oddzielny wątek dla każdej komunikacji), architektura jest głównie zdarzeniowa, stąd szerokie wykorzystanie PyDispatchera. Brak doświadczenia w Pythonie zaowocował też niepotrzebną stratą czasu i nerwów na napisanie synchronizowanej kolejki zadań na eventach (robi dokładnie to, co standardowa queue).

Istnieje też interfejs www napisany w Django, ale w obecnej wersji coś się skaszaniło ze ścieżkami w szablonie i nie ma grafik oraz css, może to poprawimy niedługo.

Całość można pobrać z repozytorium na githubie, instrukcja użycia jest na tamtejszym wiki.

Cream - najsłodszy edytor?

27 października 2007, 21:39:40

Większość z was pewnie słyszała o vimie. Każdemu choć raz zdażyło się, że złośliwy klasowy linux-guru zablokował wam terminal wchodząc do vi(ma) i z wyszczerzonymi kłami obserwował jak się pocicie, aby zamknąć ten ^#$%!@%# program. Vim to doskonały (obok emacsa) awatar ducha czarnej *nixowej konsoli. Prawdziwe l33t narzędzie.

Tak jak Ubuntu to linux dla ludzi, tak Cream to gVim dla szarych zjadaczy chleba. Ikonki, działające normalne skróty klawiszowe, a pod spodem, cicho chrapiąc, drzemie cała potęga vima z jego :s/ i innymi cudami. Za darmo, na linuxa, winde, fribsdę. Z autouzupełnianiem słów/kodu pod ctrl-spacja. Kilka trybów pracy, które pozwalają płynnie zmieniać zachowanie programu, od normalnego edytora począwszy, do typowego vimowego. To powinno przekonać wszystkich ortodoksów, że nie należy wywalać creama dlatego, że defaultowo esc nie działa tak jak powinien. Jeszcze wczoraj pracowałem na cream default, dziś po lekturze vimtutora przełączyłem się na cream-lite ;o). Kiedy pierwszy raz użyłem :s/ do zamiany treści, wewnętrznie poczułem, jak jakość pisanego przeze mnie kodu magicznie wzrosła :).

A teraz wypadałoby się przyznać, dlaczego tak naprawdę porzuciłem fantastycznego notepada++ na rzecz edytora, na którego naukę musiałem poświęcić ponad półtorej godziny. To dostarczone wraz z creamem color themes utrzymane w ciemnych, niskokontrastowych tonacjach, które nie męczą oczu w czasie wielogodzinnej pracy nocą. A temat Inkpot wygląda prawie jak kolorystyka TextMate'a którego używają goście od Ruby on Rails do nagrywania swoich screencastów :).

Free Image Hosting at www.ImageShack.us

PATRZąc na 8apps

23 stycznia 2007, 01:59:41

Sukces trzech wrocławskich studentów. Co go łączy z 8apps, pierwszą siecią społeczną dzięki której będzie można pracować, a nie tracić czas?. Właśnie mała liczba developerów. 8apps to efekt pracy dwóch Japończyków z brytyjskim rodowodem.

Oto kolejny odcinek serialu: i ty możesz być jak 37signals, naprawdę imponujący:

Tych pięciu panów sprawiło, że zaczynam coraz bardziej wierzyć w swój startup. Potrzebuję tylko jeszcze jednego człowieka ;o)

Jaki framework? Jaki CMS?

16 stycznia 2007, 22:05:35

Mam dość piep*enia się ze pisaniem setek kolejnych formularzy obsługujących wstawianie/edycję/usuwanie rekordów bazy, podczas produkcji webaplikacji. Postanowiłem zacząć używać jakiegoś frameworka, może nawet CMSa. Nauka konkretnej platformy to duża inwestycja czasu, chciałbym by była przemyślna. Żadne porównania, ani marketingowe teksty z domowych stron projektów nie są tak pomocne, jak doświadczenia użytkowników, dlatego pytam was o zdanie.

Jaki framwork? Czynniki istotne dla mnie (od najważniejszego):

  1. Flexible. Dowolność, nieograniczoność. Wszak w swoich projektach nie chcę tylko powielać powszechnych koncepcji, nie chcę, żeby f. mnie do tego zmuszał.
  2. Blisko kodu. Łączy się z powyższym. Mimo wszystko najbardziej komfortowo czuję się w czystym PHP, wiem, że będę mógł zrobić prawie wszystko. Chce, żeby można było łatwo dodawać własne funkcje, żeby zmiana tych bibliotecznych była możliwie prosta, nie wymagała mozolnego prześledzenia setek linii kodu (żeby moduły były dość niezależne), bo mam wrażenie, że to może się często zdarzać.
  3. Dokumentacja. Nie same tutoriale, ale (e-)książka, która w podręcznikowy sposób opisuje całą sprawę. Nie chce szukać helperów do zrobienia każdej rzeczy, z których będę kopiował kod nawet go nie rozumiejąc. Screencast jak zrobić silnik blogowy w 3 sekundy to nie jest podręcznik.
  4. Stroma krzywa uczenia się. Jestem niecierpliwy, chce szybko widzieć jak umiem raptownie developować.
  5. Automatyzacja. Zwłaszcza formularzy. Choć pewnie większość f. umie o wiele więcej.

Moimi kandydatami są w tej chwili Cake i Code Igniter. Ciacho, ze względu na support, community i mam przeczucie, że skrypt bakery bake.php dużo potrafi. Podpalacz, ze względu na prostotę, lekkość, szybkość, łatwość modyfikacji, niezależność modułów.

Drugie pytanie, czy warto uczyć się jakiegoś CMS ? Czy przyspieszy to produkcję aplikacji zakładając znajomość frameworka? Pamiętając, że tu również chodzi o trochę niestandardowe rozwiązania (powiedzmy, że chodzi mi po głowie sieć społeczna, oczywiście z kilkoma ficzersami, których nie ma na gronie ani spinaczu ;o) ). Utrzymując warunki z powyższej listy, waham się między Joomlą i Drupalem. Joomla wydaje mi się silnikiem do portali, Drupal zdradza ogromne możliwości, ale też duże skomplikowanie i konieczność inwestycji sporej ilości czasu zanim stworzę przy jego pomocy stronę, które będzie wyglądała i działała dokładnie tak jak tego chcę, to prawie jak nauka nowego języka.

Ruby on Rails? Nie, PHP on Trax!

30 grudnia 2006, 17:13:53

Wielu webdeveloperów rozpływało się nad możliwościami języka Ruby wyposażonego we framework Rails, niestety szybko zrzedła im mina, gdy okazało się, że mało która z rodzimych firm oferujących hosting wspiera Ruby'ego. Pozostały konta na niezrównanym DreamHoście (z kodem TANIEJ50 płacisz 50$ mniej!) lub stare, dobre PHP, które również okazało się niezłą kolejką, którą można postawić na torach.

PHP on Trax pozwala developować równie raptownie (rapidnie ;o)), co jego odpowiednik dla Ruby'ego. Nawet szablony stron z formularzami do obsługi bazy danych wyglądają podobnie ;-). Tak samo składnia niektórych poleceń (nie pamiętam dokładnie, ale coś w stylu: class post { public has_many = "comments" } ), przypomina nam te używane w screencastach Ruby'ego. Oczywiście, na stronie PHPonTrax też są ładne filmki o robieniu silnika blogowego w czasie parzenia herbaty.