Pytania i odpowiedzi z zakresu administracji IT

W ubiegłym roku uruchomiliśmy dwa miejsca, na których można w bardzo przyjemny sposób wymieniać się wiedzą, pytając i odpowiadając. Były to serwisy:

Idea serwisu z pytaniami i odpowiedziami w formie w jakiej ją Wam dostarczamy jest niesamowicie pomocna, czego dowodem jest chociażby coraz większa aktywność na devPytaniach. W efekcie postanowiliśmy zacząć zbierać informacje zwrotne od użytkowników w celu ciągłego ulepszania systemu wymiany wiedzy.

Dziś chcielibyśmy wykonać kolejny krok i dodać serwis do istniejącej rodziny. Przedstawiamy Wam sysPytania:

syspytania

Jest to miejsce dla administratorów systemów IT - ludzi, którzy zawodowo pracują z komputerami.

sysPytania są niezależne od platformy - tak samo jak devPytania. Tak więc administratorzy systemów UNIX, Mac oraz Windows są bardzo mile widziani - wierzymy, iż z programistami łączy ich coś poza komputerami: kochamy to, co robimy i chcemy uczyć się od siebie nawzajem!

Pamiętajcie, że sugestie są zawsze mile widziane.

Do zobaczenia na sysPytaniach!


Zespół devMedia.pl

Uwagi zawsze mile widziane - rozwój serwisów Grupy devMedia.pl

Co jakiś czas na devPytaniach pojawiają się pytania o sam serwis bądź o działalność Grupy devMedia.pl. Takie pytania, sugestie, czy zgłoszenia błędów otrzymujemy również na nasz e-mail. Dodatkowo, nie tak dawno temu padło pytanie o kod źródłowy serwisu. W odpowiedziach zostało pokrótce wyjaśnione, iż pracujemy nad uruchomieniem własnej wersji platformy, dzięki czemu będziemy mogli dynamiczniej się rozwijać i dostarczać nowe funkcjonalności użytkownikom.

Śledząc statystyki serwisu wiemy, że coraz więcej zadajecie pytań i coraz szybciej otrzymujecie satysfakcjonujące odpowiedzi. Przez ostatnie 137 dni zostało zadanych 506 pytań, z czego tylko znikoma część pozostała bez odpowiedzi. Przyrost liczby zadanych pytań widać na poniższym wykresie (ostatnie 137 dni):

pytania devPytania

Co więcej, serwis notuje 1000 odwiedzin dziennie z czego 60% pochodzi z wyników wyszukiwania Google.

Niejednokrotnie powtarzaliśmy, że "devPytania to serwis budowany i utrzymywany wspólnymi siłami Twoich kolegów programistów". Naszym celem jest to, aby serwis devPytania stawał się coraz przyjemniejszym miejscem do wymiany wiedzy. Aby tego dokonać, uwagi, o których wspominamy na początku, są dla nas niezwykle cenne.

Wobec powyższego postanowiliśmy podjąć pewne działania i na początek:

  1. Uniezależnić się od platformy StackExchange 1.0 - aby uzyskać możliwość rozwoju serwisu.
  2. Utworzyć jedno centralne miejsce zbierania uwag dotyczących działalności Grupy devMedia.pl, a w szczególności funkcjonowania naszych serwisów.

Na początku roku, korzystając z dobrodziejstw OSS, zaczęliśmy przygotowywać nową platformę, na którą docelowo chcemy zmigrować devPytania oraz antylamę. Na dzień dzisiejszy jest ona na tyle przygotowana, że chcielibyśmy ją opublikować i zacząć testy z prawdziwymi użytkownikami.

Efektem naszych postanowień oraz potrzeb jest nowe miejsce, które dzisiaj Wam prezentujemy:

meta devmedia

Jest to serwis, który działa w oparciu o naszą nową platformę oraz przeznaczony jest do meta-dyskusji.

Co to są meta-dyskusje i dlaczego potrzebujemy dla nich osobnego miejsca? Zostało to opisane na podstronie informacyjnej serwisu:

Meta-dyskusja oznacza dyskusję o samej dyskusji a nie na temat w tej dyskusji poruszany. Przykładowo:

  • styl dyskusji,
  • jej uczestnicy,
  • okoliczności w jakich dyskusja ma miejsce,
  • powiązanie tejże dyskusji z innymi dyskusjami na te same bądź inne tematy.

Etymologia prefisku "meta-" sięga czasów dzieła Arystotelesa zatytułowanego "Metafizyka", które powstało po jego innych pracach z dziedziny fizyki. Podstawowe znaczenie tego prefiksu w języku greckim to po prostu "po".

Gorąco zachęcamy do dzielenia się uwagami, propozycjami oraz krytyką na wyżej wymienionym serwisie. Dodatkowo, udzielając się w serwisie meta, pomagacie testować nową platformę, która będzie niedługo silnikiem m.in. dla devPytań.

Pragniemy zaznaczyć, iż meta ma służyć rozwojowi wszystkich serwisów Grupy devMedia.pl, włączając w to projekty takie jak devBlogi i 97rzeczy.

Uwagi są zawsze mile widziane i jeszcze raz: zachęcamy do wzięcia udziału w testowaniu nowej platformy oraz w tworzeniu jej poprzez wymianę myśli, dyskusję oraz krytykę.

Przejdź do mety.


Zespół devMedia.pl

Rozproszona kontrola wersji to jest to, dziecinko

Oryginalny post: Distributed Version Control is here to stay, baby

Autor: Joel Spolsky

Jakiś czas temu Jeff i ja zaprosiliśmy Erica Sinka do podcastu Stack Overflow i narzekaliśmy na kontrolę wersji, zwłaszcza na modne, nowe rozproszone systemy kontroli wersji, takie jak Mercurial i Git.

W tamtym odcinku powiedziałem "Według mnie to, że tworzenie nowych gałęzi i ich łączenie jest łatwiejsze spowoduje, iż twoi współpracownicy będą częściej wykorzystywać te funkcje, co sprawi, że ciężko będzie się w tym wszystkim połapać."

Wiecie, podcast nie jest wcześniej drobiazgowo przygotowywany. Siedzimy sobie w kilka osób i urządzamy pogawędkę. Z tego powodu zazwyczaj nasze wypowiedzi są, używając technicznego sformułowania, błędne. Zazwyczaj błędny jest ogólny wydźwięk albo tylko szczegóły, lub wydźwięk i szczegóły, ale tym razem były po prostu naprawdę błędne. Jak truskawkowa pizza. Albo bajgiel z jalapeño. BŁĘDNE.

Na długo zanim podcast został wyemitowany, mój zespół zaczął używać Mercurial i ta zmiana naprawdę wszystko mi zagmatwała, więc zatrudniłem kogoś żeby wprowadzał dla mnie kod do repozytorium (żartuję). Walczyłem przez jakiś czas próbując zapamiętać kilka kluczowych komend, wyobrażając sobie, że wszystko działa tak jak w Subversion, ale kiedy coś nie działało tak jak w Subversion nie wiedziałem co mam dalej robić i byłem zmuszony biec po Benjamina lub Jacoba żeby mi pomogli.

Wtedy mój zespół obwieścił mi "Wiesz co? Ten Mercurial jest całkiem niezły i chcemy w oparciu o niego napisać produkt pozwalający na rewizję kodu, a co więcej wydaje nam się, że istnieje duży popyt na komercyjne wsparcie i hostowanie go" (sam w sobie Mercurial jest dostępny dla każdego na licencji GPL, ale wiele korporacji chce mieć jakieś wsparcie zanim zaczną czegoś używać).

Pomyślałem sobie, co ja tam wiem? Jak pewnie wiecie, ja nie mam tutaj ostatniego słowa, ponieważ "zarządzanie to funkcja wspierająca", więc zabrali wszystkich stażystów, wszystkich sześcioro i zaczęli tworzyć aplikację opartą na Mercurial.

Postanowiłem dowiedzieć się, o co chodzi z tą całą "rozproszoną kontrolą wersji" zanim ktoś zada mi pytanie o produkt, który podobno moja firma sprzedaje, a ja nie będę wiedział, co odpowiedzieć i ktoś znowu obsmaruje mnie w blogo-"sferze".

Drążyłem, drążyłem i w końcu coś wymyśliłem. Coś czym chcę się z Wami podzielić.

W rozproszonych systemach kontroli wersji, rozproszenie nie jest najistotniejsze.

Istotne jest to, że te systemy działają w kontekście zmian, a nie wersji.

To brzmi bardzo "zen", wiem. Tradycyjne systemy kontroli wersji działają tak: OK, mam wersję 1. To jest wersja 2. A to jest wersja 3.

Rozproszony system działa tak: Nie mam nic. A teraz wprowadzono te zmiany. A teraz ktoś wprowadził te inne zmiany.

To inny Model Programu, więc model użytkownika też się musi zmienić.

W Subversion myślisz sobie "uaktualnij moją wersję, żeby była taka sama jak główna wersja" albo "cofnij się do poprzedniej wersji".

W Mercurial myślisz "daj mi zestaw zmian Jacoba" albo "zapomnijmy o tych zmianach".

Jeśli podchodzisz do Mercurial z nastawieniem na Subversion, wszystko będzie prawie działać, ale kiedy nie będzie, wszystko Ci się pomiesza, będziesz niezadowolony i go znienawidzisz.

Kiedy uwolnisz swój umysł, ponownie wyobrazisz sobie kontrolę wersji i pojmiesz zen różnicy między zarządzaniem wersjami, a zarządzaniem zmianami zostaniesz oświecony i z radością zdasz sobie sprawę, że właśnie w ten sposób powinna działać kontrola wersji.

Wiem, że to dziwne... od 1972 wszyscy myśleli, że operują na wersjach, a teraz zaskakująco okazuje się, że myślenie przede wszystkim o zmianach samych w sobie rozwiązało bardzo istotny problem: łączenia gałęzi kodu.

Oto najważniejszy wniosek, a właściwie, najważniejsza rzecz, której dowiedzieliśmy się o produktywności deweloperów w ciągu ostatniej dekady. Jest to tak istotne, że zasługuje na to, aby być ostatnią opinią jaką napiszę, więc jeśli zapamiętasz tylko jedną rzecz to zapamiętaj to:

Kiedy zarządzasz zmianami zamiast wersjami, łączenie gałęzi działa lepiej, a przez to możesz rozgałęziać kod kiedy tylko wymagają tego twoje cele organizacyjne, ponieważ ponowne ich łączenie to kaszka z mleczkiem.

Nie potrafię powiedzieć ilu użytkowników Subversion opowiada taką historię: "Spróbowaliśmy stworzyć nową gałąź i to działało dobrze. Kiedy przyszedł czas żeby połączyć ją z powrotem to był absolutny koszmar i musieliśmy praktycznie każdą zmianę wprowadzać ręcznie przysięgając sobie, że nigdy więcej, a nawet wypracowaliśmy specjalny sposób pisania z instrukcjami if zamiast gałęzi."

Czasami są nawet dumni ze swojej inwencji korzystania z pojedynczej głównej gałęzi. Tak jakby było zaletą to, że muszą obchodzić sposób działania ich systemu kontroli, który nie potrafi zrobić co do niego należy.

Z rozproszonym systemem kontroli, łączenie jest łatwe i działa jak należy. Więc naprawdę możesz mieć gałąź stabilną i rozwojową albo tworzyć długożyjące gałęzie dla swojego zespołu kontroli jakości, który wykonuje testy przed wdrożeniem, albo krótkożyjące gałęzie po to, żeby wypróbowywać pomysły i zobaczyć jak będą się sprawować.

To zbyt ważne, żeby to pominąć. Być może jest to największy postęp jaki dokonał się w dziedzinie tworzenia oprogramowania w ciągu tych 10 lat przez które pisałem tutaj artykuły.

Innymi słowy, prędzej wrócę do C++, niż zrezygnuję z Mercurial.

Jeśli używasz Subversion, proszę przestań. Po prostu przestań. Subversion = pijawki. Mercurial i Git = antybiotyki. Mamy teraz odpowiednią technologię.

Z powodu tego, że ludzie nurkują w Mercurial bez pełnego zrozumienia modelu na jakim pracuje program przez co mogą odnieść wrażenie, że jest zepsuty albo złośliwy, napisałem tutorial o Mercurial HgInit.

Dzisiaj, kiedy ktoś pyta mnie o tamten podcast o rozproszonych systemach kontroli wersji, mówię, że był to drobiazgowo planowany podstęp wobec mojego długoletniego przyjaciela i konkurenta Erica Sinka, który buduje nierozproszony system kontroli wersji. Tak jak wtedy kiedy zaczął sprzedawać oprogramowanie do śledzenia błędów i ukaraliśmy go wysyłając mu wypasiony plecak Fog Creek z lipnym oficjalnym listem, z którego wynikało, że idzie nam tak dobrze, że ten drogi plecak był standardowym gwiazdkowym prezentem, który wysyłamy każdemu klientowi korzystającemu z FogBugz.

Chyba kończy mi się czas. To wielki zaszczyt, że czytaliście moje wypracowania przez ostatnie 10 lat. Nie mógłbym prosić o lepszych czytelników. Niezależnie od tego, czy należysz do setek ludzi, którzy poświęcają swój czas, aby tłumaczyć artykuły na ponad 40 języków, czy 22.894 osób, którzy napisali do mnie emaila, czy 50.838 osób zapisanych do newslettera lub 2.262.348 osób, które rocznie odwiedzają stronę i czytają część z 1067 artykułów jakie napisałem, serdecznie dziękuję Ci za uwagę.

Data publikacji oryginału: marzec 17, 2010

Related Posts with Thumbnails