stary-wpis

Tęczowy kod blogaska

~ Jarosław Stadnicki ~ Leave a comment

Jak obiecałem tak zrobiłem. Zebrałem swoje leniwe dupsko i zrobiłem (skopiowałem) piękne kolorowanie kodu w postach. Kilka kroków jak dokonać tego samego.

1. Korzystam z takiego chytrego rozwiązania: http://code.google.com/p/syntaxhighlighter Należy zaciągnąć paczkę i rozpakować.
2. Znaleźć stronę która umożliwi upload plików i podlinkowanie się do nich. Jak skorzystałem z podpowiedzi i zapodałem sobie pustą stronę na https://sites.google.com/site/sites/
Tam wrzuciłem na root wszystkie pliki z paczki. Pominąłem te z katalogu uncompressed.
3. W blogerze trzeba wyedytować plik z templatem. BLOG -> PROJEKT -> EDIT HTML i teraz zaczyna się prawdziwy ultra mega hard core połączony z grindem i blekiem.

Bierzemy ten kod i wklejamy w template zaraz za head.

A ten kawałek trzeba zapodać zaraz przed zakończeniem się body:

  
  dp.SyntaxHighlighter.ClipboardSwf = 'http://twojadomena/twojdostep/clipboard.swf';   
  dp.SyntaxHighlighter.BloggerMode();  
  dp.SyntaxHighlighter.HighlightAll('code');

Daliście radę? Najs – mega szacun.
Po taki zabiegu napisanie <pre name=”code” class=”cpp”> i wrzucenie kodu do takie części powinno spowodować ładny i kolorowy kodziczek na stroniczce. Z tego co zauważyłem shCore.js musi być jako pierwsze na liście. Nie znam nie wnikam czemu i czy zawsze. Jeżeli będziecie potrzebować inny styl wystarczy je dołączyć do listy.

W tym przykładzie jest tylko cpp.

#include

/* ten komentarz jest dobry :) jezeli usunę całkowicie komentarze, to include  powoduje pojawienie się dodatkowej lini  za '}', jeżeli zostawię jak jest to wszystko jest w porządeczku z kodem */

/* w dodatku jezeli koment jest w lini z inludem to się robi szary, widać nie wszystko działa idealnie, ale i tak lepiej niż czarno-biały tekst */

void main( void )

{

std::cout

Inspiracja vel motywacja

~ Jarosław Stadnicki ~ 2 Comments

“Jak mi się nie chce” – powiedziałem do bliżej nie określonej osoby, siedząc samotnie w mieszkaniu. I tak strzelił prawie miesiąc. W końcu zmuszając się do zrobienia czegokolwiek pomyślałem “zaciągnąłeś demoscenę to oglądaj” tak też zrobiłem i podziałało cuda. Wierzcie lub nie, ale jestem strasznym zazdrośnikiem. Strasznie zazdroszczę ludziom tego, że coś robią, że mogą się pochwalić, a inni mogą to podziwiać. Tak więc wiedziony zazdrością i żądzą chwały i milionów (fanów, dolarów, wywiadów, etc) ponownie zabrałem się do pracy. Jak się okazało praca też mnie motywuje, może nie sama praca, a raczej postęp w pracy i jej efekty. Na razie i tak nie wiele widać, ale mi to wystarczy. Może dodam jeszcze, że mała żółta karteczka pomaga mi skupić się na tym co mam robić:

  • pracować
  • uczyć się
  • ćwiczyć
  • czytać
  • pisać
  • tutaj nazwa super tajnego projektu, mającego przynieść mi wyżej wymienioną chwałę i bogactwo

Spisane tak po prostu, nie sortowane. Pisałem na żywo, tak jak każdy wpis na blogasku. Niby takie proste, a nie mogłem się zając żadną z tych czynności przez prawie miesiąc.
Cytując małego r, “nie poddaje się” i walczę dalej.

Co was inspiruje do dalszego działania moi nieistniejący czytelnicy?

z gorącymi przeprosinami za wpis
js

Jakość czy też jak woli empik “Jakaść”

~ Jarosław Stadnicki ~ Leave a comment

Siedzę na tej zsyłce, patrze i napatrzyć się nie mogę – jak można pewne proste rzeczy tak spierdolić. Proste sprawy jak odczytanie ramki z sieci, prosty switch w środku i jak to może nie zadziałać? Ano może się okazuje – jak się chce to koledzy z B. centrum chujozy potrafią. Jak? A to proste! Nikt tutaj nie robi review kodu, a jeżeli zrobi się i to tak mają to głębiej my. Może dlatego że używają operatora “?” – z tym, nic strasznego, każdy na studiach musiał poznać zasadę działa tego dziada. Ale tutejsi przechodzą samych siebie, przykład: “a?b:c?d:e?f:g?h:i;” są tutaj takie kwiatki. Kod poprawny, a potem jak chcesz to zrozumieć to gorzej. Rozumiem goto, nawet polubiłem bo czasem ratuje dupsko, ale czy taki kod jest w porządku:

success:
  return S_OK;
fail:
  assert( FALSE );
  return E_FAIL:

Do tego dochodzi magiczny sposób formatowani kodu, który czytelny staje się nie wiem kiedy. Jeszcze nigdy nie widziałem tak złego formatowania. Bardzo często zdarza mi się uznać wywołanie funkcji za definicje jakiejś struktury (sic!).

Być może jest jeszcze jeden problem, a nawet dwa. Obiecuję dzisiaj więcej nie kaleczyć języka polskiego.
Raz – podczas pracy siedzią na facebook czy na czatach i zamiast być skupionym na robocie, wchodzić w zone, zen, nirwane, czy co tam klikają to, nie lubię tamtego i umawiają się na randki.
Dwa – brak odpowiedzialności. Jak się coś zjebie, to wszyscy bekną. Jak muszkieterzy 😉 Nie ważne czy robisz czy klikasz, masz pensję, a robotę jak nie ty, to ktoś inny odwali. Jak się zjebie, to trudno, przecież to nie ja pisałem.

Panowie wystarczy chcieć pisać dobrze, a z czasem się wszystko ułoży.
Tym oto mądrym zdaniem kończę kolejny żałosny wpis.

porady jak lepiej, najlepiej, wunder

~ Jarosław Stadnicki ~ 1 Comment

dzone – nie wiem czy znacie (pewnie tak), to taki agregator hiciorów z neta. Mam rssy od nich ze stronki i często można tam (zresztą nie tylko u nich), znaleźć wpis o tym co zrobić by być lepszym programistą, menagierem, testerem. Jak lepiej robić to i tamto lepiej czy w ogóle super. Praktycznie zawsze jest przy tym jakaś cyferka 8 sposobów, 3 drogi, 13 uproszczeń, bla bla bla. Już prawie się uodporniłem na takie wpisy, choć czasem się skuszę i kliknę i jak zwykle jestem zawiedziony – czemu? Bo zawsze jest to samo! Rób review, debuguj, skup się, testuj, … Którego nie klikniesz to na pewno takie punkty tam będą. Moje proste pytanie po co się z tym ciągle powtarzać?

Tak chciałem się tym podzielić z moim słitaśnym blogaskiem. Następny razem takiego linka nie kliknę 😉 (mam nadzieje).

Chcesz się pożalić, albo mnie wyśmiać – napisz
js

release, debug, #ifdef

~ Jarosław Stadnicki ~ Leave a comment

Czytam i czytam kod, staram się go zrozumieć. Czasem każą mi coś poprawić albo napisać testy. Ale jak widzę, że kod dla release, debug, czy np. QAC zachowuje się inaczej to lekki nerw mnie łapie. Pomijam różnice w dodatkowym kodzie z “logprint” czy “assert” – ok, to nie zmienia logiki aplikacji (chyba że jest app jest time-driven [sic!]). Ale! Jak można prześledzić zachowanie aplikacji, kiedy w jednej wersji zachowuje się inaczej niż w drugiej? Ja tego nie potrafię zrozumieć.
I jeszcze jedna dziwna rzecz, która do tej pory do mnie nie dotarła. Ktoś u klienta powiedział “mają być asserty“. No więc są:

if( warunek == ok )
{
    // do stuff 
}
else
{
    // assert( false );
}

I bardzo proszę mądrość internetową, która może tutaj kiedyś zawita o wytłumaczenie mi takiego kodu. Dodam że to w embedded, więc liczę na jakiś głębszy ukryty sens.

siara jak zwykle ale trzeba
uściski!
js

//łupdejt
Poprawka do formatowania kodu