Programowanie: programowanie to przyszłość nauki. Bez tego nie mógłby istnieć współczesny świat. To programiści tworzą obecnie cywilizację. Skoro tak, winni mieć tu swój kącik.
Programowanie: programowanie to przyszłość nauki. Bez tego nie mógłby istnieć współczesny świat. To programiści tworzą obecnie cywilizację. Skoro tak, winni mieć tu swój kącik.
Gdy producenci sprzętu dotarli do granic możliwości przyspieszania pojedynczego układu, zainteresowali się zagadnieniem współbieżności. Technologie dostępne wcześniej głównie w serwerach oraz stacjach roboczych nagle pojawiły się w każdym domu za sprawą procesorów wielordzeniowych. Jednak pisanie programów wielowątkowych jest dużo trudniejsze. Aby ułatwić życie programiście, powstały języki do programowania współbieżnego. Jednym z nich jest Erlang, o którym chciałbym dzisiaj nieco opowiedzieć.
Na forum PHP.pl pojawiło się niedawno pytanie czy informatykowi do czegoś potrzebna jest matematyka, fizyka i w ogóle cała ta "zbędna wiedza" i czy koniecznie jest to potrzebne na studia informatyczne. Pytanie dobrze postawione, trapiące z pewnością wielkie rzesze młodzieży zastanawiające się czy nie zacząć zarabiać w ten sposób na życie. W tym wpisie postaram się dostarczyć dobrze postawioną odpowiedź, patrząc z własnego punktu widzenia.
2 stycznia 2007 roku, po latach oczekiwania ukazała się pierwsza stabilna wersja rewolucyjnego języka programowania D zaprojektowanego jako prawdziwy następca C. Jego twórca, Walter Bright stworzył dzieło niemalże epickie, które od razu podbiło moje serce. W tym wpisie pragnę przyjrzeć się, gdzie D znajduje się po trzech latach obecności.
Wczoraj cojack na swoim blogu napisał notkę zatytułowaną "Inicjalizacja != Inicjacja". Tytuł powinien mówić wszystko, co tam znajdziemy, zaś ja pragnę zaprezentować komentarz z punktu widzenia osoby, która mimo bycia zwyzywaną tam od umysłowo upośledzonych i dzieci neo, dalej woli zmienne inicjować. Mój grudniowy limit na ilość emocji we wpisach został już prawie wyczerpany, jak to zauważyli czytelnicy, dlatego będzie spokojnie i rzeczowo.
Każdy internetowy framework, aby nie został wyśmiany, musi koniecznie implementować wzorzec projektowy MVC. Twórcy każdego frameworka starają się przede wszystkim pokazać, że "ich MVC" jest lepszy, spychając wszystkie pozostałe aspekty na dalszy plan. Jednak czy wiesz, czym tak naprawdę jest MVC? Czy jesteś pewien, że spotykając taki wzorzec na ulicy, będziesz potrafił go rozpoznać, czy też może pomylisz go z kimś innym? Sprawdź i przekonaj się.
Sprzęt sprawdzony? Światła? Mikrofony działają? W porządku, jest perkusja, basy gotowe... ej, debilu! Gdzie po kablach łazisz? Chcesz, by nam MIDI wywaliło w środku koncertu?! Skaranie boskie z tymi nowymi pomocnikami... na czym to, aaa tak. Basy są, gitara jest, kołki do stukania w zęby (odjechane pomysły ma ten producent), zatem jedziemy. Trzy, dwa, jeden... tumdurrumdumtumdurrumdum... This is a story of UML, the language that did not want to be used.
W trzeciej części serii poświęconej systemom transakcji rozproszonych zajmiemy się samym protokołem oraz przejrzymy ostateczną implementację, którą zastosowałem, bowiem pomysł zaproponowany w ostatnim wpisie został znacznie rozszerzony, czyniąc kod bardziej idiotoodpornym poprzez zwyczajne zablokowanie szeregu niedozwolonych kombinacji funkcji.
W ubiegłym tygodniu omówiliśmy sobie, czym są transakcje rozproszone, do czego mogą być wykorzystywane oraz zaznajomiliśmy się z koncepcją ich działania. Ponieważ prace posunęły się naprzód, czas omówić krótko budowę systemu do realizowania internetowych połączeń transakcyjnych oraz przyjrzeć się projektowi API.
Powoli dobiega końca drugi rok moich studiów informatycznych, tymczasem na blogu raczej nie pojawiały się dotąd wpisy i artykuły związane z różnymi interesującymi tematami przerabianymi w ich trakcie. Tymczasem kilka dni temu oddałem ostatnie z dziesięciu semestralnych zadań z przedmiotu systemy operacyjne i do szczęśliwego zakończenia pozostał mi projekt - Symulacja mechanizmów transakcji rozproszonych i protokołów niepodzielnego zatwierdzania transakcji przy użyciu mechanizmów systemowych. W ramach eksperymentu postanowiłem spróbować udokumentować proces projektowania i implementacji serią wpisów w Dziennikach i właśnie czytacie odcinek pierwszy.
W bazach danych serwisów internetowych (i nie tylko) hasła użytkowników nie są trzymane w postaci jawnej. Przed ich zapisaniem przepuszcza się je przez funkcję haszującą (zwaną też funkcją mieszającą), która podany ciąg odwzorowuje jednoznacznie na pewien klucz o stałej długości (kilkaset bitów). Haszowanie jest procesem jednokierunkowym, w trakcie którego część informacji jest bezpowrotnie gubiona. Na forach dyskusyjnych stale pojawiają się propozycje nowych programistów, żeby hasło haszować podwójnie: H(H(hasło)), co ma zwiększyć bezpieczeństwo. O tym właśnie chciałbym dziś napisać.
