develway.pl naszym partnerem

W ostatnich dniach nawiązaliśmy współpracę z develway.pl - wykopopodobnym serwisem dla pasjonatów IT. Kibicujemy im mocno, ponieważ uważamy, że tego typu serwis w Polsce może być przydatny, jeśli tylko uda się zgromadzić wystarczająco dużą społeczność. Zachęcamy więc do zaglądnięcia na develway i aktywnego udzielania się w tamtejszej społeczności. Od teraz pod każdym postem na devBlogach znajduje się przycisk, który umożliwia szybkie dodawanie danego wpisu do serwisu develway.

Oto co twórcy serwisu develway piszą o sobie:

Develway jest serwisem, w którym znajdziesz aktualne informacje z zakresu szeroko-pojętej branży IT. Skupiamy się tu przede wszystkim na przekazywaniu ciekawych informacji dla programistów, administratorów sieci i wszelkiej maści innych osób, które na co dzień stykają się z nowoczesnymi technologiami.

Dziel się wiedzą i korzystaj z tego, czym dzielą się inni. Poszerzaj swoją wiedzę i buduj prawdziwą społeczność specjalistów z branży IT. Develway.pl to serwis tworzony przez użytkowników. Każda informacja jest dodawana i oceniana właśnie przez nich. Dziel się, odkrywaj i oceniaj informacje, które uznajesz za interesujące! To Ty decydujesz, co jest ważne, a co nie.

Przy okazji chcieliśmy poinformować Was, że jesteśmy w trakcie rozmów z różnymi firmami — potencjalnymi sponsorami — więc może niedługo pojawi się jakiś konkursik z nagrodami :> Aktualną listę firm/serwisów, z którymi współpracujemy, możecie obejrzeć na podstronie Partnerzy. Dodaliśmy również podstronę Projekty, gdzie możecie zapoznać się z naszą "twórczością developerską".

Pozdrawiamy Was gorąco, a serwis develway witamy wśród naszych partnerów!

Zespół devBlogi

Dwa rodzaje programistów

Oryginalny post: The Two Types of Programmers

Autor: Jeff Atwood

W przeciwieństwie do mitu, nie ma czternastu rodzajów programistów. Są tylko dwa, jak przypomniał nam Ben Collins-Sussman.

W świecie tworzenia oprogramowania istnieją dwie "klasy" programistów: nazwę ich 20% i 80%.

Kolesie z grupy 20% to Ci, których możnaby nazwać programistami "alfa" -- liderzy, pionierzy, prekursorzy, typy kolesi, na których punkcie firmy takie jak Google czy Fog Creek mają obsesję. Oni byli jednymi z pierwszych, którzy zainstalowali Linuxa w domu w latach 90; ci ludzie piszą kompilatory LISPa i uczą się Haskella w weekendy "dla zabawy"; aktywnie udzielają się w projektach open source; zawsze są świadomi najnowszych i najfajniejszych trendów w programowaniu i narzędziach.

Kolesie z grupy 80% stanowią większość branży tworzenia oprogramowania. Nie są głupi; są tylko zawodowcami. Chodzili do szkoły, nauczyli się wystarczająco Javy/C#/C++, dostali pracę, która polegała na pisaniu wewnętrznych aplikacji dla banków, rządów, biur podróży, firm prawniczych, itd. Świat zazwyczaj nie zauważa ich oprogramowania. Używają jakichkolwiek narzędzi, które im da Microsoft -- zazwyczaj jest to VS.NET jeśli piszą w C++, albo IDE takie jak Eclipse czy IntelliJ jeśli piszą w Javie. Nigdy nie używali Linuxa i nie są tym zainteresowani. Wielu z nich nie używało nigdy kontroli wersji. A jeśli już, to tylko za pomocą narzędzi Microsoft (jak na przykład SourceSafe) bądź bardziej starożytnych narzędzi, które im się podsunie. Wiedzą wystarczająco dużo, aby wykonywać swoją pracę, pójść do domu i w weekend zapomnieć o komputerze.

Jako iż zawodowo pracuję z zespołami programistów, powala mnie przepaść pomiędzy tymi 20% a resztą świata. Podział między obozami open-source i Microsoft to przy tym płytki rów.

Wstrząsające oświadczenie nr 1: Większość przemysłu oprogramowania składa się z programistów grupy 80%. Tak, większość świata to warsztaty tworzące oprogramowanie na platformę Windows, albo małe firmy zatrudniające własnych programistów. Większość firm posiada trochę gości z 20% i oni zazwyczaj lobbują przeciwko beznadziejnym szefom, aby zmienić zasady, zaktualizować narzędzia bądź zmienić system kontroli wersji na bardziej rozsądny.

Wstrząsające oświadczenie nr 2: Większość maniaków alfa zapomina o wstrząsającym oświadczeniu nr 1. Ludzie, którzy pracują nad oprogramowaniem open-source, biorą udział w pasjonujących debatach o kryptografii na Slashdot bądź ściągają najnowsze wydanie GITa, najprawdopodobniej przestaną zauważać, że te "80%" w ogóle istnieje. Podniecają się tylko najnowszymi dystrybucjami Linuxa, AJAX toolkitem albo rozproszonym systemem SCM i spędzają cały weekend nad tym, a potem piszą o tym na swoim blogu... a potem są wprawieni w zakłopotanie tym, że nie mogą namówić swojego biura na używanie tego.

Być może nie jest to dla mnie tak wstrząsające, ale mimo wszystko jest to doskonałym i ważnym upomnieniem dla każdego.

Często myślę, iż tracimy swój czas na pisanie blogów, które w większości są czytane przez tę samą grupę 20%. Moje doświadczenie podpowiada mi, że istnieje mały, cenny interwencjonizm pomiędzy programistami alfa i resztą. A jeśli jest, to trwa dziesięciolecia. I jeśli naprawdę chcesz zmienić status quo tworzenia oprogramowania, jeśli chcesz, aby zmiany zaszły jeszcze w tym roku, musisz pomóc nam dotrzeć poza naszą małą, odizolowaną grupę programistów alfa i wpłynąć na pozostałe 80% świata. I to jest o wiele, wiele trudniejsze niż propagowanie tego wśród tych 20%. To dlatego właśnie doceniam ludzi takich, jak Scott Mitchell, ponieważ on rozumie wagę dotarcia do tych 80%:

Lubię programowanie i dobrze bawię się przy ASP.NET. Myślę, iż interesujące i fajne jest to, że w zasadzie z niczego, w zaskakująco szybki sposób można stworzyć aplikację webową, pełną informacji, która może być używana przez ludzi z całego świata. Co więcej, chcę rozprzestrzeniać ten entuzjazm wśród ludzi. Chcę powiedzieć tym, którzy nigdy nie programowali, albo tym co używają innych technologii, albo tym co dopiero zaczynają - "Przyjdź tutaj i spróbuj ASP.NET. Patrz, pokażę Ci, co możesz dzięki temu zrobić!" Właśnie dlatego uczę (na czym zarabiam grosze w porównaniu z konsultingiem). To dlatego piszę (na czym da się więcej zarobić niż na nauczaniu, ale nadal nie tak dużo jak na konsultingu). To dlatego udzielam darmowych prelekcji w lokalnych grupach i konferencjach sponsorowanych przez społeczności w południowej Kalifornii. Aby głosić słowo!

Jak dla mnie, mówienie, że tytuły typu Naucz się X w 24 godziny zubożają rzemiosło jest równoznaczne z powiedzeniem, "Nasz klub jest już pełny. Idź sobie." To nie jest, "Powitajmy świeżaków i sprawmy, aby podekscytowali się tą technologią." To raczej, "Świeżaki są spoko, ale muszą najpierw uświadomić sobie jakie to trudne, jak ciężko pracowaliśmy i o ile więcej wiemy niż oni." Takie uczucie ze strony społeczności może wydać się tym ludziom pompatyczne, a powinno być serdeczne.

Chciałbym, żeby to było dla mnie łatwiejsze, ponieważ zgadzam się ze Scottem. Jestem fatalny w tych rzeczach, które opisuje. Myślę, iż prawdziwą miarą nie jest to, jak wielu maniaków alfa jesteś w stanie zaabsorbować. Jest nią to, do jak wielu typowych, przeciętnych programistów dotarłeś, o ile w ogóle. Jeśli naprawdę troszczysz się o sztukę tworzenia oprogramowania, też nam pomożesz budować most pomiędzy tymi 20% a 80%.

Data publikacji oryginału: 25 listopada, 2007

Czy więcej niż jeden monitor zwiększa produktywność?

Oryginalny post: Does More Than One Monitor Improve Productivity?

Autor: Jeff Atwood

Począwszy od mrocznych czasów Windowsa Millenium jestem entuzjastą pracy na wielu monitorach. W ciągu ostatnich czterech lat pisałem już kilka razy o rozmaitych przyjemnościach płynących z pracy na kilku monitorach:

• Liczba monitorów a produktywność
• Wiele paneli LCD
• Dołączając do prestiżowego klubu trzech monitorów
• Paradoks wielkiego wyświetlacza
• Ramiona dla paneli LCD

Posiadam trzy monitory w domu jak i w pracy. Jestem tym, kogo mógłbyś nazwać prawdziwym zwolennikiem. Zawsze szukam argumentów dla kolegów po fachu, którzy żądają drugiego (albo nawet trzeciego) monitora, które im się słusznie należą zgodnie z Kartą Praw Programisty.

Tak więc byłem zaintrygowany, gdy przeczytałem o nowych badaniach nad wieloma monitorami na Uniwersytecie Utah:

Naukowcy z Uniwersytetu Utah przetestowali jak szybko ludzie wykonują zadania typu edycja dokumentu, czy kopiowanie liczb między arkuszami kalkulacyjnymi, używając trzech różnych konfiguracji komputera:

1. jeden 18" monitor
2. jeden 24" monitor
3. dwa 20" monitory

Oto do czego doszli:

• Ludzie używający monitora 24" ukończyli zadania 52% szybciej niż Ci, którzy używali 18" monitora
• Ludzie, którzy używali dwóch 20" monitorów byli o 44% szybsi od tych z 18" monitorem
• Produktywność spadła, gdy ludzie używali 26" ekranów.

Pokopałem trochę tu i ówdzie i znalazłem faktyczne wyniki badań (pdf), albo coś koło do tego, jeśli szukasz więcej szczegółów do zestawienia, które zaprezentowałem powyżej. To nie pierwszy raz, kiedy Uniwersytet Utah przeprowadza badania nad wieloma monitorami. To bardzo podobne do ankiety dotyczącej wielu monitorów, którą przeprowadzili w 2003 roku również pod auspicjami NECa. Zgadzam się z tym, iż śmiesznym jest cytowanie badań producenta wyświetlaczy, który doradza -- niespodzianka -- kupowanie więcej oraz większych monitorów. Ale miej na uwadze, że oni doszukali się zanikającej produktywności podczas pracy z 26" wyświetlaczami. To jest to czego osobiście doświadczyłem i nazwałem paradoksem wielkiego wyświetlacza. Tym spostrzeżeniem na pewno nie zdobędą serc innych producentów wyświetlaczy.

Patrick Dubroy przyjrzał się sceptycznie twierdzeniom o produktywności związanej z wieloma monitorami i znalazł kilka wiarygodnych źródeł informacji. Połączę je razem z moimi znaleziskami, aby stworzyć takie centralne źródło dla danych do badań wspierających ideę, że oczywiście, posiadanie większego wyświetlacza mogłoby uczynić Cię bardziej produktywnym:

• Zalety drugiego wyświetlacza
• Porównanie jednego i dwóch monitorów o standardowych wymiarach z monitorem panoramicznym w nawiązaniu do produktywności (pdf)
• Charakteryzując zyski produktywności związane z bardzo dużymi wyświetlaczami (pdf)
• Benchmark produktywności dla 30" Apple Cinema HD Display (pdf)

Patrick mimo swojego sceptycyzmu -- i pamiętaj, to jest gość, który nie widział różnicy w produktywności między 14" wyświetlaczem laptopa a olbrzymim LCD -- dał się przekonać:

Po przejrzeniu badań myślę, iż uczciwe jest stwierdzenie, że niektóre zadania mogą być wykonane znacznie szybciej, jeśli posiada się więcej miejsca na ekranie. Z drugiej strony, myślę, iż programiści nie staną się o połowę bardziej produktywni w ciągu jednego dnia tylko dzięki drugiemu monitorowi. Zadania, które można usprawnić nie są wąskim gardłem produktywności programistów.

Nie jestem pewien czego Patrick tu oczekiwał. Pozwól, iż wyrażę się jasno w tym temacie: więcej znaczy więcej. Więcej użytecznej przestrzeni pulpitu zmniejsza ilość czasu jaką spędza się na zarządzaniu oknami. Zamiast nieprzerwanie przeciągać, zmieniać rozmiar, minimalizować czy maksymalizować okna, możesz wykonywać konkretną pracę. Posiadając większy pulpit możesz spędzać mniej czasu nad bezmyślnym porządkowaniem informacji, a więcej czasu nad operowaniem tymi informacjami. To, jak bardzo będzie to miało znaczenie dla Ciebie, zależy od rodzaju oraz stylu Twojej pracy. Osobiście, byłbym wniebowzięty, gdybym nie musiał już nigdy zmieniać rozmiaru bądź położenia kolejnego cholernego okienka przez resztę mego życia.

Wybierz własną drogę do szczęścia, czy będzie to aktualizacja do jednego 30" wyświetlacza, dwóch 24" panoramicznych wyświetlaczy, czy trzech 20" standardowych wyświetlaczy. Jeśli tylko w wyniku dostajemy więcej przestrzeni pulpitu, jest to czysta wygrana. Popieram wszystkie trzy scenariusze, a co ważniejsze, obecne badania również. Koszt kilku monitorów jest zaniedbywalny w porównaniu do pensji programistów czy informatyków. Nawet jeśli zyskasz marne dwa bądź trzy procent wydajności, to i tak jest to więcej niż zwrócenie kosztów.

Frustrujące jest to, kiedy ludzie twierdzą, że jeden duży monitor powinien być "wystarczający dla każdego". To nie jest gra o sumie stałej. Tam gdzie jest jeden duży monitor, mogłyby być dwa duże monitory, albo trzy.

Czasami, więcej znaczy więcej.

Data publikacji oryginału: 16 marca, 2008

Wątpliwość programistycznej etyki

Oryginalny post: A Question of Programming Ethics

Autor: Jeff Atwood

Z Kodeksu Etycznego ACM:

Jako członek ACM będę

1. Przyczyniał się do dobrobytu społeczności oraz ludzi.
2. Unikał krzywdy innych.
3. Był uczciwym i godnym zaufania.
4. Uznawał prawa własności włączając w to prawa autorskie i patenty.
5. Doceniał własność intelektualną.
6. Respektował prywatność innych.
7. Uznawał poufność.

Ciężko to porównać z przerażającą opowieścią, którą przesłał mi e-mailem Dustin Brooks:

Szukałem sposobu na zrobienie kopii zapasowej swojego konta gmail, którą mógłbym zapisać na dysku lokalnym. Zebrało mi się dosyć sporo ważnych informacji, których raczej nie chciałbym stracić. Podczas moich poszukiwań natrafiłem na G-Archiver, stwierdziłem, że co mi tam, spróbuję.

Nie posiadał tych funckcjonalności, o które mi chodziło, ale ponieważ jestem programistą, użyłem Reflectora, żeby zerknąć na kod źródłowy. To na co natrafiłem było trochę szokujące. John Terry, domniemany twórca, umieścił w kodzie nazwę użytkownika i hasło do swojego konta gmail. Dobra, nie jest to najmądrzejsza rzecz jaką można zrobić, ale co zauważyłem to również to, że za każdym razem, kiedy użytkownik dodawał swoje konto do programu, aby zrobić kopię zapasową, wysyłał on e-mail z nazwą użytkownika i hasłem na swoją osobistą skrzynkę! Zmartwiło mnie to, ponieważ sam przed chwilą podałem swoje dane do logowania.

Otworzyłem przeglądarkę i zalogowałem się na skrzynkę korzystając z jego danych. Wciąż działało.

W momencie wejścia na skrzynkę zastałem 1777 e-maili, które zawierały informacje o kontach każdego, kto kiedykolwiek użył tego oprogramowania, a na samej górze był mój. Postanowiłem, że wywalę każdy e-mail do folderu z usuniętą pocztą, a następnie opróżnię go. Mogło też się tak zdarzyć, że przypadkowo zmieniłem hasło i pytanie bezpieczeństwa na coś czego nie pamiętam, cóż.., mój błąd. Skontaktowałem się też z Google, aby usunęli to konto jako, iż nie znalazłem sposobu, aby zrobić to samemu.

Zazwyczaj ufam ludziom i staram się wierzyć w ich uczciwość, ale w tym wypadku nie jestem w stanie sobie wyobrazić żadnego scenariusza, w którym nie jest to całkowicie podstępne pogwałcenie ludzkiego zaufania. Jedną z największych obaw użytkowników jest podawanie swoich danych uwierzytelniających, i gdy okazuje się, że ten strach wcale nie jest bezpodstawny, dochodzi do pogorszenia relacji między użytkownikami i wszystkimi obecnie pracującymi programistami. Sam kiedyś nieumyślnie wysłałem swoje dane do logowania na ten właśnie blog. Na szczęście dla mnie sokolooki czytelnik, Israel Orange, nie wykorzystał tych informacji dla własnego zysku, ale zamiast tego uprzejmie wytknął mi mój błąd w e-mailu.

Naturalnie, mam nadzieję, że jest więcej programistów takich jak Israel Orange niż John Terry. Etyka ma również znaczenie wśród programistów.

Data publikacji oryginału: 7 marca, 2008

JavaScript - lingua franca Internetu

Oryginalny post: JavaScript: The Lingua Franca of the Web

Autor: Jeff Atwood

Mike Shaver, członek-założyciel Mozilla Organization wyraża mocne przekonania na temat przyczyn popularności Internetu:

Jeśli wybierasz platformę powiązaną z konkretnymi narzędziami, jeśli porzucasz swobodną współpracę przez Zobacz Źródło, mashupy robione na zasadzie copy-and-paste i możliwość zapakowania jQuery tam gdzie wcześniej siedział Prototype, wtedy tracisz to, co spowodowało rozrost i rozproszoną ewolucję sieci. Tracisz to, co spowodowało, że sieć jest tak niesamowita, i że sieć wygrywa.

Zgodna z duchem open source, wirusowa natura menu Zobacz Źródło z pewnością jest kluczową składową sukcesu Internetu. Ale to tylko część historii. Dojrzewanie implementacji JavaScriptu w nowoczesnych przeglądarkach jest fundamentem dla teraźniejszości i przyszłości Internetu:

Jednym ze składników Web 2.0 jest z pewnością Ajax, a który cały czas trudno mi pisać bez cudzysłowia. W zasadzie „Ajax” znaczy tyle, co „JavaScript wreszcie działa”. Oznacza to z kolei, że aplikacje webowe mogą być tworzone tak, aby działały podobnie do desktopowych.

Tak jak wielu innych programistów, na początku odrzuciłem JavaScript jako język-zabawkę. Nawet Douglas „mój pseudonim to JavaScript” Crockford miał takie błędne mniemanie:

Kiedy wprowadzony został JavaScript zlekceważyłem go, jako nie wart mojej uwagi. Znacznie później przyjrzałem się bliżej i odkryłem, że ukryty w przeglądarce był wspaniałym językiem programowania. Moje wcześniejsze podejście opierało się na pierwszych charakterystykach JavaScriptu dostarczanych przez Suna i Netscape'a. Chcąc uniknąć traktowania JavaScriptu jako konkurenta dla Javy, wypowiadano na jego temat wiele mylących zdań. Pokutuje to do dzisiaj w postaci źle napisanych książek na temat JavaScriptu dla opornych i amatorów.

Bez względu na Twoje pierwsze opinie o języku, JavaScript przeszedł długą drogę od kiepskiego dla niego roku 1995. Obecnie mamy bardzo mocne procesory po stronie klienta. Na tyle mocne, że nawet interpretowany, dynamicznie typowany język, taki jak JavaScript, może być wiarygodnym środowiskiem deweloperskim. Język standaryzowany jest od początku 1999 roku jako ECMA-262 edycja 3 (aktualna edycja oznaczona jest numerem 5 -- przyp. tłum.), więc racjonalnym jest oczekiwać kompatybilności między przeglądarkami.

Coraz więcej i więcej stron internetowych wykorzystuje JavaScript do pokonywania granic wynikających z ograniczeń przeglądarek. Pomysł, aby przeglądać Internet z wyłączoną obsługą JavaScriptu został praktycznie porzucony. Wraz z sukcesem tak wielu startupów opartych na niczym innym, tylko właśnie na JavaScripcie, HTMLu i wybranym języku serwerowym, mógłbyś pomyśleć, że JavaScript zyska zasłużony szacunek. Ale cały czas możesz usłyszeć utyskiwania na JavaScript, nawet dzisiaj. Scott Koon znalazł sposób, żeby to dobrze ująć:

JavaScript wygrał z powodu braku innych kandydatów. Ludzie chcieli tworzyć lepsze aplikacje webowe. Programowanie z użyciem Flasha było kiepskie. JavaScript był już w każdej przeglądarce. Jeśli jesteś ostatnim mężczyzną na Ziemi, nie ma znaczenia jak mało jesteś atrakcyjny, kiedy pojawia się kobieta, aby ponownie zaludnić planetę.

Niektórzy programiści zrobią prawie wszystko, żeby tylko uniknąć konieczności stawiania stopy w brudny świat niedoskonałego JavaScriptu. Dostawcy bardzo chętnie oferują alternatywy:

• Microsoft Silverlight 1.1
• Adobe Flex
• Sun's JavaFX
• Adobe Flash

Ale wbrew wszystkim pretendentom do tronu, JavaScript w najbliższym czasie nigdzie się nie wybiera. JavaScript jest najbardziej powszechnym środowiskiem uruchomieniowym na świecie. Już nadszedł ten czas, kiedy nauczyliśmy się akceptować JavaScript, a nie ślepo z nim walczyć. Nie oznacza to, że nie powinniśmy badać alternatyw -- ale najlepszym sposobem na przekroczenie ograniczeń JavaScriptu jest wtopienie się w te ograniczenia. Dzięki temu przynajmniej dowiesz się o co walczysz, i co rzeczywiście niosą za sobą alternatywy.

Czy JavaScript jest czasami denerwujący? Jasne. Czy utrudnia i tak trudną do uzyskania kompatybilność między przeglądarkami? Absolutnie. Czy debugowanie w przeglądarce jest bolesne? Jesteś tego pewien, aczkolwiek FireBug pomaga. Bo to jest tak: JavaScript jest tak samo przełomowy jak wkurzający.

Składnia podobna do tej znanej z C -- w tym nawiasy klamrowe i budowa pętli for -- powodują, że JavaScript wygląda na typowy język proceduralny. To jest mylące, ponieważ JavaScript posiada więcej wspólnego z językami funkcyjnymi takimi jak Lisp lub Scheme niż z C lub Javą. Ma tablice zamiast list i obiekty mogące działać jako listy właściwości (tablice asocjacyjne). Funkcje są obiektami typu first class (czyli mogą być przekazywane jako parametry, zwracane w podfunkcjach albo przypisywane zmiennym –- przyp. tłum.). JavaScript ma domknięcia (ang. closures). Możesz posługiwać się rachunkiem lambda bez konieczności balansowania tych wszystkich nawiasów.

JavaScript to lingua franca Internetu. Zignoruj tę wiadomość na własną odpowiedzialność.

Jeśli chcesz od początku zapoznać się z JavaScriptem, wtedy cały czas najlepszym materiałem w sieci jest strona Douglasa Crockforda. Mogę również zarekomendować serie filmów Douglasa Crockforda na Yahoo, które są przykładem świetnego i nowoczesnego myślenia na temat JavaScriptu.

• The JavaScript Programming Language
• Advanced JavaScript
• An Inconvenient API: The Theory of the DOM

Do kompletu możesz ściągnąć slajdy tych prezentacji ze świetnego Yahoo User Interface Blog.

Na horyzoncie pojawia się kilka ciekawych alternatyw dla JavaScriptu. Niektóre odniosą sukces, inne nie. Ale w całym tym natłoku narzędzi i nowych możliwości nie zapominaj, że JavaScript pozostaje świetnym wyborem dla tworzenia bogatych aplikacji internetowych -– i ponieważ JavaScript to lingua franca sieci, jego sukces jest gwarantowany.

Data publikacji oryginału: maj 21 2007

Doskonały grafik-pasjonat poszukiwany/poszukiwana

W związku z ciągłym rozwojem serwisów devBlogi oraz (nowego) devPytania, stwierdziliśmy, iż czas na zmiany. Głównie graficzne. Wobec czego chcielibyśmy ogłosić, iż poszukujemy osoby zajmującej się tworzeniem grafiki na potrzeby sieci Web. Jako iż nasze serwisy są tworzone przez pasjonatów dla pasjonatów chcielibyśmy, aby ta osoba lubiła to co robi.

Do obowiązków takiej osoby należałoby:

• zżycie się z istniejącym zespołem
• praca nad wyglądem serwisu devBlogi
• praca nad wyglądem serwisu devPytania
• praca nad wyglądem serwisu metaFoto
• praca nad wyglądem serwisu ?????? - nie zdradzimy jeszcze nazwy, ale w przygotowaniu jest kolejny serwis skierowany do programistów
• praca nad wygladem serwisu ?????? - tu kolejny serwis w przygotowaniu, tym razem ogólnie dla użytkowników komputerów

Masz takie zdolności? A może masz znajomego, który mógłby być zainteresowany? Wszystkie osoby prosimy o kontakt na adres: kontakt@devBlogi.pl. Jesteśmy otwarci na różne propozycje.

Cel nasz jest prosty: skupić w jednym miejscu dojrzałych, wymagających i profesjonalnie podchodzących do swojej pracy programistów.

Zespół devBlogi

Czy certyfikaty mają znaczenie?

Oryginalny post: Do Certifications Matter?

Autor: Jeff Atwood

Wymień jakąkolwiek ważną technologię oprogramowania, a znajdziesz odpowiednią ścieżkę certyfikacyjną. Odpłatną oczywiście.

To dezorientujący i zastraszający szereg akronimów: MCSD, SCJD, RHCE, ACSA. A firma oferująca daną certyfikację jest najczęściej tą samą firmą, co firma sprzedająca dany produkt. Nie ma tu konfliktu interesów.

Ale czy te certyfikaty w rzeczywistości sprawdzają się? Czy są uzasadnionymi referencjami? Czy ludzie posiadający te certyfikaty radzą sobie lepiej niż Ci, którzy ich nie mają? Wyobraź sobie siebie jako przyszłego pracodawcę, prowadzącego rozmowę kwalifikacyjną z kandydatem, który pokazuje Ci następującą rzecz:

Moja reakcja jest zawsze taka sama. Bardzo fajnie, ale pokaż mi nad czym pracowałeś do tej pory.

Twoje referencje powinny być sumą projektów, nad którymi pracowałeś, a zwłaszcza tym jak wiele nauczyłeś się ze swoich porażek. Z pewnością Twoje faktyczne doświadczenie, Twoje portfolio, liczy się o wiele bardziej niż to, czy zdałeś wybrany test jakiś czas temu.

Mam mieszane uczucia co do certyfikacji.

Pracowałem z tak zwanymi "web" developerami, którzy nie rozumieli jak działają HTTP POST i HTTP GET. Tacy programiści wywołują u mnie pragnienie certyfikacji na pewnym poziomie. Nawet jeśli nie byliby kompetentni to, jeśli posiadaliby certyfikaty, dałoby im to przynajmniej pojęcie o podstawowych zagadnieniach, które umożliwiałyby im pracę. Tak czy inaczej to tylko teoria. Na najniższym poziomie wydaje się być rozsądnym wymaganie certyfikatu w konkretnej technologii przed dopuszczeniem do pracy. Z tego samego powodu większość firm nie zatrudni nikogo kto nie ma, powiedzmy, ukończonej szkoły średniej, bądź uczelni wyższej.

Z drugiej strony, pracowałem ze starszymi programistami, którzy mieli całą masę certyfikatów, a nadal nie mieli pojęcia o tym, co robią.

Dyskusja dotycząca certyfikacji szaleje od lat. Ten list od Toma DeMarco do edytora z 1998 roku pokazuje jak sporny może być temat certyfikacji.

Mimo iż przesłaniem certyfikacji jest zawsze dobro ogółu, prawdziwy cel jest inny: przejęcie władzy. Certyfikaty to nie jest coś co tworzymy dla korzyści społeczeństwa, ale dla korzyści instytucji certyfikujących. Wielką rzeczą jest decydować, które istnienie ludzkie powinno być dopuszczone do pracy, a które nie. Ci którzy chcą być częścią tej wielkiej rzeczy, tworzą rdzeń obozu zwolenników certyfikacji.

Cała ta dyskusja jest poniekąd nieuczciwa. Pojęcie "certyfikacji", przykładowo, przywołuje obraz młodocianych ludzi ustawionych w kolejce po odbiór obowiązków biurowych, kiedy ich rodzice, siedzący na widowni, wycierają łzy dumy, a chór delikatnie nuci złożone melodie. Ale prawdziwym problem nie są tu certyfikacje; prawdziwym problemem są de-certyfikacje. Niektórzy ludzie zostaną przekreśleni nie dlatego, że są bezużyteczni według potrzeb rynku, ale dlatego, że nie stają na głowie dla instytucji certyfikujących. Pozostaliby niezauważeni - przynajmniej zdaniem Nancy Mead - Ci, którzy nie posiadają określonych stopni. Przykro nam Panie Gates, w nowym, lepszym świecie, nie pozwolonoby panu pisać oprogramowania. Można wyczuć frustracje instytucji certyfikujących w chwili, gdy firmy takie jak Yahoo zatrudniają dzieciaków zaraz po szkole, które nie wiedzą nawet, co to jest Data Division, na miłość boską! Coś musi zostać z tym zrobione!

DeMarco kontynuuje skromnie sugerując, iż rynek jest całkowicie dobrym sposobem selekcji:

Jestem za tym, aby pozwolić staruszkom typu Citicorp, Aetna czy Microsoft, samym sobie ustalać sposób na zatrudnianie ludzi. Mówię Wam, że mamy już doskonale działający system selekcji; nazywa się - rynek. Jedni ludzie są zatrudniani jako programiści a inni nie. Ten system jest o wiele bardziej kompetentny i etyczny, niż jakakolwiek powołana elita mogłaby być.

Osobiście, zgadzam się z DeMarco. Nie wierzę w certyfikacje. Kolekcja certyfikatów nie zastąpi porządnego portfolio; powinieneś spędzać czas na tworzeniu jakichś rzeczy, a nie na nauce testów wielokrotnego wyboru. Ale to też nie znaczy, że są one bezużyteczne. Nie uważam, iż certyfikacje wadzą, ale tylko wtedy, kiedy jesteś w stanie razem z nimi zademonstrować efekty swojej pracy.

Data publikacji oryginału: 17 stycznia, 2007

Czy walidacja HTML ma znaczenie?

Oryginalny post: HTML Validation: Does It Matter?

Autor: Jeff Atwood

Sieć jest, ujmijmy to litościwie, raczej wyrozumiałym miejscem. Możesz karmić przeglądarki internetowe prawie każdym rodzajem kodu HTML czy JavaScript, a one dzielnie postarają się zrobić z tym coś sensownego i wyrenderować to w najlepszy możliwy sposób. Dla porównania, większość języków programowania jest niemal srodze bezlitosna. Jeśli choć jeden znak nie jest na swoim miejscu, Twój program prawdopodobnie się nie skompiluje, a tym bardziej nie uruchomi. W rezultacie, środowisko HTML + JavaScript jest raczej unikalną -- a często frustrującą -- platformą do tworzenia oprogramowania.

Ale tak nie musi być. Istnieją mechanizmy dające możliwość walidowania Twojego kodu HTML poprzez oficjalny Walidator W3C. Zabawa z walidatorem podkreśla tylko, jak głeboko polityka standardowej wyrozumiałości przenikneła do sieci. Dennis Forbes przepuścił ostatnio parę stron internetowych przez walidator, łącznie z tą, z przewidywalnie złym rezultatem:

FAIL - http://www.reddit.com - 36 błędów jako XHTML 1.0 Transitional. EDIT: Ponownie sprawdziłem Reddit i teraz jest PASS
FAIL - http://www.slashdot.org - 167 błędów jako HTML 4.01 Strict
FAIL - http://www.digg.com - 32 błędów jako XHTML 1.0 Transitional
FAIL - http://www.cnn.com - 40 błędów jako HTML 4.01 Transitional (wywnioskowane, iż nie było wyspecifikowanego doctype)
FAIL - http://www.microsoft.com - 193 błędów jako XHTML 1.0 Transitional
FAIL - http://www.google.com - 58 błędów jako HTML 4.01 Transitional
FAIL - http://www.flickr.com - 34 błędów jako HTML 4.01 Transitional
FAIL - http://ca.yahoo.com - 276 błędów jako HTML 4.01 Strict
FAIL - http://www.sourceforge.net - 65 błędów jako XHTML 1.0 Transitional
FAIL - http://www.joelonsoftware.com - 33 błędów jako XHTML 1.0 Strict
FAIL - http://www.stackoverflow.com - 58 błędów jako HTML 4.01 Strict
FAIL - http://www.dzone.com - 165 błędów jako XHTML 1.0 Transitional
FAIL - http://www.codinghorror.com/blog/ - 51 błędów jako HTML 4.01 Transitional
PASS - http://www.w3c.org - bez błędów jako XHTML 1.0 Strict
PASS - http://www.linux.com - bez błędów jako XHTML 1.0 Strict
PASS - http://www.wordpress.com - bez błędów jako XHTML 1.0 Transitional

W skrócie, żyjemy w zdeformowanym świecie. Tak bardzo, że zaczynasz wątpić w to, czy walidatory w ogóle mają rację bytu. Kiedy widzisz takie logo na stronie, co ono dla Ciebie znaczy? Jak bardzo wpłynie na Twoje odczucia związane z daną stroną? Z punktu widzenia programisty? Z punktu widzenia użytkownika?

Właśnie zrobiliśmy ćwiczenie polegające na zwalidowaniu kodu HTML strony Stack Overflow. Prawie od razu odrzuciłem pomysł walidowania jako XHTML, ponieważ jak najbardziej zgadzam się z Jamesem Bennettem

Prostym i słodkim powodem jest po prostu to: XHTML nie oferuje korzyści nie do odparcia -- jak dla mnie -- w porównaniu do HTMLa , ale nawet jeśli, to oferowałby również większą złożoność i niepewność, co według mnie nie byłoby atrakcyjne.

Całe to walidowanie HTMLa jest wątpliwe, ale walidowanie jako XHTML jest masochizmem pełną parą. Rekomendowane tylko tym, którzy lubią ból. Albo programistom. Nigdy ich nie rozróżniam.

Mimo wszystko zwalidowaliśmy stronę jako bardziej rozsądny HTML 4.01 strict, ale nawet teraz nie jestem pewien, czy warto było na to poświęcać czas. Wiele zasad walidacji wydaje się być dowolnymi i bez znaczenia. A co gorsza, niektóre z nich są najnormalniej szkodliwe. Na przykład poniższe nie jest dozwolone w HTML strict:

<a href="http://www.example.com/" target="_blank">foo</a>

Tak jest, target, całkowicie bezpieczny atrybut dla odnośników, które chcesz, aby się otwierały w osobnej zakładce bądź oknie przeglądarki, jest z jakiegoś powodu zabroniony w HTML 4.01 strict. Jest na to oficjalnie wspierane obejście, ale jest zaimplementowane jedynie przez Operę, więc w efekcie.. nie ma obejścia.

Aby dostosować się do walidatora HTML 4.01 strict, musisz pousuwać atrybuty target i w zamian wstawić JavaScript, który robi dokładnie to samo. Tak więc, natychmiast zacząłem się zastanawiać: Czy ktokolwiek waliduje nasz JavaScript? A co z CSS? Czy ktokolwiek waliduje nasze manipulacje na DOM'ie, które JavaScript uskutecznia na kodzie HTML? Kto waliduje walidator? Dlaczego nie mogę przestać myśleć o zebrach?

Czy naprawdę ma znaczenie to, czy wyrenderujemy coś w ten sposób..

<td width="80"> <br/>

.. czy w ten?

<td style="width:80px"> <br>

Znaczy się, kto wymyśla te zasady? I z jakiego powodu?

Nie mogłem się powstrzymać od uczucia, iż walidowanie jako HTML 4.01 sctrict, przynajmniej w naszym przypadku, było jednym wielkim ćwiczeniem na znajdowanie nic nieznaczących różnic, przerywanym denerwującymi zmianami, które byliśmy zmuszeni zrobić bez praktycznego zysku. (Co więcej, jeśli posiadasz masę zawartości wygenerowanej przez użytkowników, tak jak my, od razu możesz wyrzucić przez okno swoje marzenia o 100% zgodności.)

Po tym wszystkim, walidacja ma swoje uroki. Było parę rzeczy w naszym kodzie HTML, które proces walidacji uwydatnił, a które były wyraźnie źle - osamotniony tag tutaj, parę niekonsekwencji podczas aplikowania tagów tam. Mark Pilgrim przedstawia argumenty za walidacją:

Nie twierdzę, że Twoja strona raz zwalidowana, będzie się się bezbłędnie wyświetlać w każdej przeglądarce; może tak nie być. Nie twierdzę również, że nie ma utalentowanych twórców, którzy piszą strony w starym stylu, ze źle sformatowanym kodem HTML, które wyświetlają się bezbłędnie w każdej przeglądarce; z pewnością tacy są. Ale walidator to automatyczne narzędzie, które potrafi wyłapać małe, ale ważne błędy, które są trudne do ręcznego wytropienia. Jeśli w większości tworzysz walidujący się kod, możesz skorzystać z tej automatyzacji do wyłapywania sporadycznych błędów. Ale jeśli Twój kod nie przypomina nawet poprawnego, będziesz działał na oślep, jeśli coś pójdzie źle. Walidator wypluje dziesiątki, jak nie setki, błędów na Twojej stronie i znalezienie jednego, który w rzeczywistości powoduje Twój problem, będzie jak szukanie igły w stogu siana.

Jest w tym trochę prawdy. Przyswajanie zasad walidatora, nawet jak się z nimi nie zgadzasz, uczy Cię definicji "poprawności". Osadza Twój kod w rzeczywistości. To jest jak przepuszczenie swojego kodu przez bardzo restrykcyjny program walidujący typu lint bądź ustawienie opcji kompilatora na najbardziej rygorystyczny poziom. Wiedza na temat zasad i ograniczeń pomaga Ci zdefiniować to, co robisz i daje Ci uzasadnione argumenty na zgodzenie się z tym bądź nie. Możesz dokonać świadomego wyboru zamiast takiego w stylu "po prostu tak robię i to działa".

Po naszych przejściach związanych z walidacją HTML, oto moja rada:

1. Waliduj swój kod HTML. Wiedz co to znaczy mieć walidujący się kod HTML. Zrozum narzędzia. Więcej informacji to zawsze lepiej niż mniej informacji. Po co błądzić po omacku?
2. Nikogo nie obchodzi to, czy Twój kod HTML jest poprawny. Oprócz Ciebie. Jeśli tego chcesz. Nie pomyśl sobie, że wyprodukowanie idealnie walidującego się kodu HTML jest ważniejsze od uruchomienia swojej strony, dostarczania funkcjonalności, które cieszą użytkowników albo od skończenia swojej pracy.

Ale pytanie pozostaje: czy walidacja HTML faktycznie ma znaczenie? Tak. Nie. Może. To zależy. Powiem Wam to samo, co mi powiedział mój ojciec: to jest moja rada, a zrobisz z tym co chcesz.

Data publikacji oryginału: 5 marca, 2009

Dlaczego programiści nie potrafią.. programować?

Oryginalny post: Why Can't Programmers.. Program?

Autor: Jeff Atwood

Popadłem w zdumienie, gdy przeczytałem następującą obserwację Reginalda Braithwaite'a:

Tak jak i ja, autor ma problemy z faktem, iż 199 na 200 aplikantów do każdej programistycznej pracy nie potrafi w ogóle pisać kodu. Powtarzam: nie potrafią pisać żadnego kodu.

Autor, do którego się odnosi, to Imran, który najwyraźniej odrzuca wielu programistów, którzy nie potrafią napisać żadnego programu:

Po stosownym okresie prób i błędów odkryłem, iż ludzie, którzy borykają się z programowaniem, nie mają problemów z wielkimi problemami, czy trochę mniejszymi (jak na przykład zaimplementowanie listy). Z trudem radzą sobie z najmniejszymi problemami.

Podjąłem się zdania, aby opracować pytania, które potrafiłyby zidentyfikować ten rodzaj programisty i otrzymałem pewną klasę pytań, które nazywam "Pytaniami FizzBuzz" po grze, w którą dzieci w Wielkiej Brytanii często grają (albo grały) w szkołach. Przykładem pytania FizzBuzz jest:

Napisz program, który wypisuje liczby od 1 do 100. Ale dla wielokrotności trójki wyświetl "Fizz" zamiast liczby oraz dla wielokrotności piątki wyświetl "Buzz". Dla liczb będących wielokrotnościami trójki oraz piątki wyświetl "FizzBuzz".

Większość dobrych programistów powinno być w stanie napisać taki program na papierze w przeciągu kilku minut. Chcesz poznać coś strasznego? Większość absolwentów informatyki nie potrafi. Widziałem również samozwańczych starszych programistów, którym napisanie rozwiązania zajęło więcej niż 10-15 minut.

Dan Kegel miał podobne doświadczenia podczas zatrudniania programistów bez stażu:

Zadziwiająco spora część aplikantów, nawet tych z tytułem magistra oraz doktora w dziedzinie informatyki, oblewała podczas rozmów kwalifikacyjnych, kiedy została poproszona o rozwiązanie prostych programistycznych zadań. Na przykład, osobiście przesłuchiwałem absolwentów, którzy nie dali sobie rady z zadaniami typu "Napisać pętlę, która liczy od 1 do 10" albo "Jaka jest następna liczba po F w systemie szesnastkowym?" Mniej trywialnie, przesłuchiwałem wielu kandydatów, którzy nie potrafili użyć rekurencji do rozwiązania prawdziwego problemu. To są podstawowe umiejętności; ktokolwiek komu ich brakuje, prawdopodobnie nie programował zbyt dużo.

Wypowiadając się w imieniu inżynierów oprogramowania, którzy muszą przesłuchiwać przyszłych pracowników, mogę śmiało powiedzieć, iż jesteśmy zmęczeni rozmowami z kandydatami, którzy nie mają programistycznej siły przebicia. Jeśli potrafisz z powodzeniem napisać pętlę za pomocą dowolnego języka programowania wymienionego w Twoim CV, która iteruje od 1 do 10 bądź potrafisz wykonywać proste operacje arytmetyczne bez pomocy kalkulatora, albo użyć rekurencji do rozwiązania prawdziwego problemu, to jesteś już na czele grupy.

Tak jak Reginald, Dan oraz Imran zaczynam się niepokoić. Jestem bardziej niż chętny, aby dawać więcej luzu świeżo upieczonym programistom na początku ich kariery. Każdy musi gdzieś zacząć. Ale jestem zaniepokojony i przerażony faktem, iż tak zwany programista mógłby starać się o pracę bez umiejętności napisania najprostszych programów. To policzek w twarz kogokolwiek kto zarabia programowaniem na życie.

Rozległy podział na tych, którzy potrafią programować i tych, którzy nie potrafią jest dobrze znany. Założyłem, iż ktokolwiek aplikujący o pracę jako programista ma już za sobą tę różnicę. Najwyraźniej nie jest to rozsądne założenie. Najwyraźniej badanie w stylu FizzBuzz jest wymagane, aby nie marnować czasu przesłuchujących na rozmowy z programistami, którzy nie potrafia programować.

Abyś nie pomyślał, że test FizzBuzz jest za prosty -- a jest absolutnie i celowo prosty -- osoba komentująca wpis Imrana odnotowuje jej skuteczność:

Nie cierpię osób przesłuchujących, którzy lekceważą [FizzBuzz] test z powodu, iż jest za łatwy - z mojego doświadczenia zdumiewającym jest, jak wielu kandydatów nie jest w stanie poradzić sobie z najprostszymi programistycznimi zadaniami.

Może rozpoczynanie rozmowy kwalifikacyjnej z programistą bez uprzedniego patrzenia na jego kod nie jest mądre. W Vertigo wymagamy kawałka kodu jeszcze przed etapem rozmowy odbywającej się przez telefon. A etap rozmowy odbywający się na miejscu, zawiera małe programistyczne ćwiczenia. Nic trudnego, bądź tego świadom, tylko podstawowe ćwiczenie na zbudowanie małej aplikacji krok po kroku w około godzinę. Mimo iż były tylko jeden czy dwa wybuchy gniewu, w większości ta strategia była dla nas dobra. Pozwala nam skupić się na inżynierii oprogramowania podczas rozmowy, bez uciekania się do nudnych, zagadkowych pytań.

To wstyd, iż musicie przeprowadzać tak wiele badań wstępnych, aby mieć luksus prowadzenia rozmów kwalifikacyjnych z programistami, którzy rzeczywiście potrafią programować. Byłoby to śmieszne, gdyby nie to, że jest cholernie załamujące. Nie jestem fanem certyfikacji, ale zastanawiam się, czy Steve McConnell miał coś w zanadrzu mówiąc o tworzeniu prawdziwej profesji inżynierii oprogramowania.

Data publikacji oryginału: 26 lutego, 2007

Z Nowym Rokiem nowym krokiem - devPytania.pl

Prawdopodobnie wielu z Was zna bądź słyszało już o społeczności StackOverflow, której wspólnymi siłami, w bardzo krótkim czasie, udało się stworzyć jedną z najciekawszych i najprzydatniejszych stron typu Q&A (pytania i odpowiedzi). Dzięki uprzejmości twórców tego serwisu, mamy przyjemność zaprezentować Wam jego polską wersję — devPytania.

Ogólną ideę przyświecającą temu przedsięwzięciu najlepiej chyba przedstawił Jeff Atwood (jeden z tworców SO):

StackOverflow najłatwiej chyba zdefiniować jako przeciwieństwo serwisu Experts Exchange (czyli bez wywołującego mdłości brudu moralnego i prawie-legalnych optymalizacji dla wyszukiwarek internetowych) w połączeniu z Wikipedią i serwisem Reddit. Jest serwisem tworzonym przez programistów dla programistów z końcowym zamiarem kolektywnego zwiększania dobrej programistycznej wiedzy z całego świata. Niezależnie od tego, w jakim języku programujesz bądź jakiego systemu operacyjnego używasz — naszym celem jest lepsze programowanie.

Jeśli chcecie dowiedzieć się więcej na temat naszej nowej inicjatywy, zaglądnijcie do działu O serwisie.

Gorąco zachęcamy do dołączenia do społeczności devPytania — być może wspólnie uda nam się, podobnie jak na SO, stworzyć równie użyteczną skarbnicę wiedzy programistycznej w naszym jakże pięknym, ojczystym języku :]

Do zobaczenia na devPytania.pl!