Sync everything!

Przepraszam, za tytuł pisany po angielsku, ale nie potrafiłem inaczej ująć tego o czym chciałbym napisać poniżej.
Nie wiem, czy też macie takie wrażenie, ale ostatnio zacząłem się już gubić z kontami na różnych portalach. Dopóki każde konto było oddzielne jedyny problem jaki miałem to ‚jakie to było hasło?’. Prawdziwy burdel zaczął się wraz ze skonfigurowaniem konta na Windows Phone 7, chociaż teraz już wiem, że to zaczęło się dużo wcześniej.

Błąd nr 1. Zakładając Live id, użyj innego maila. Ja założyłem Live id podając swojego maila w domenie studentpartner.pl, teraz na dodatek ten mail został zlikwidowany a ja nadal loguje się na live id podając nieistniejącego maila.

Błąd nr 2. Logowanie do facebooka za pomocą gmaila. Może to nie jest do końca mój błąd, bo rejestrując się na fb trzeba było podać swojego maila, no ale teraz dorzucili pocztę @facebook.com i po co?

Błąd nr 3. Synchronizacja wszystkiego z live id.
Żeby mieć facebooka w telefonie z wp7 trzeba połączyć go z live id. Dodatkowo potajemnie wszystkie moje kontakty z telefonu zostały skopiowane do kontaktów w live id. Kiedy doszedłem wreszcie do ładu i połączyłem wszystkie kontakty z telefonu, z tymi z facebooka i z live id (co zajęło mi trochę czasu) byłem z siebie nawet dumny. Ale gdzieś w głębi miałem przeczucie, że przez to wszystko mogą być tylko problemy.

Błąd nr 4. Synchronizacja twitter’a z live id. 
Do twitter’a w telefonie korzystam z oddzielnej apki, chciałem jednak widzieć nowe tweety w aplikacji Kontakty na Windows 8, dlatego też musiałem zsynchronizować live id z twitterem.


Kiedy następnym razem kiedy zobaczysz coś takiego zerknij w notatnik czy się nie zapętlisz.

 

Dodatkowo ostatnio znalazłem opcję „Post your Tweets on Facebook„, ale chyba z niej nie skorzystam, to już by było przegięcie.

Teraz kiedy chciałbym zmienić live id jestem udupiony. Nawet nie wiem co jeszcze jest z czym połączone, nie wspominając że chcąc zmienić live id musiałbym sformatować telefon… thanks Microsoft!

 

Na koniec tabelka jakie usługi można ze sobą połączyć, tak aby stracić orientacje z jakiego konta została wysłana wiadomość.

Możliwe połączenia:

LiveId – inny mail
facebook – logowanie przez gmail
facebook – synchronizacja z LiveId
twitter – synchronizacja z LiveId
twitter –  wysyłanie tweetów na facebooka
youtube – synchronizacja z facebookiem
youtube – synchronizacja z twitterem
liveid – google account !? 

Leap – przyszłość puka do drzwi

Ok, chyba każdy zna scenę z „Raportu mniejszości”, gdzie Tom Cruise za pomocą specjalnych rękawiczek steruje komputerem. Wtedy (w 2002 roku) było to coś nie do ogarnięcia. Nie sądziłem, że taka technologia pojawi się tak szybko. Najpierw dostaliśmy Kinecta, który już był wielkim przełomem jeśli chodzi o Natural user interface, dzisiaj przeglądając blog Marka Rendle, poznałem Leap. To co potrafi ta mała kostka można zobaczyć na filmiku poniżej.

Aż przychodzi na myśl tylko jedno. Windows 8 jest do tego stworzony. Ciężko by było używać zwyczajnych aplikacji za pomocą tego narzędzia, ale aplikacje metro? Może jednak do czegoś się przyda ten Windows 8 na desktopie 😉

Więcej o projekcie Leap

O programowaniu słów kilka

Z okazji przeprowadzania właśnie refactoringu jednego z projektów postanowiłem napisać kilka rzeczy, które gdy widzę sprawiają, że odechciewa mi się zmiany czegokolwiek.

1. Im mniej komentarzy tym lepiej.

Tak, wyznaję zasadę, która ma tyle samo zwolenników co przeciwników. Nie mniej jednak komentarz w kodzie występuje przeważnie tam, gdzie coś nie działa tak jak chciał programista i w ten sposób chce przestrzec inne osoby przed problemem, który on napotkał. Pomijam tu komentarze opisujące klasy i metody, jeśli są one wymagane do przyszłej dokumentacji, to jak najbardziej powinny być pisane, ale za pomocą ctrl + m + ctrl + o, można je bardzo prosto schować i nie są one nikomu potrzebne. Jednak jeśli kod jest dobrze napisany, czyta się go jak dobrą książkę. Jeśli czegoś szukamy patrzymy jak nazywa się funkcja i co po kolei robi. Te dwie rzeczy powinny nam starczyć, żeby zorientować się czy to czego szukamy jest gdzieś tutaj, czy może w innej części kodu.
Pozostają jeszcze przyzwyczajenia z kodu C++, czyli komentarze-szlaczki wyglądające mniej więcej tak:

///////////////////////////////////////////////////////////////////////////////////////////////////////
public void Refresh_Click(object sender, EventArgs e){
}
///////////////////////////////////////////////////////////////////////////////////////////////////////

Wiem, bo sam takie pisałem kiedy zaczynałem swoją przygodę. Jest to fajne, jeśli piszemy w notatniku i nie możemy zwinąć funkcji. Kiedy jednak mamy tak wspaniałe narzędzie jak visual studio nie musimy się bawić w oddzielanie poszczególnych funkcji, bo w tym momencie szlaczki są ważniejsze od tego co się dzieje w klasie.

2. Dziel klasy na foldery

Tak się dzieje, że kiedy zaniedbamy na samym początku podział klas na foldery, to później bardzo ciężko jest to zrobić. Im większy staje się projekt tym gorzej się połapać w tym gdzie może znajdować się dana klasa. O ile sami siedzimy w tym od początku, to programista, który dostanie nasz kod może mieć spore problemy z odnalezieniem właściwego pliku. Bardzo podoba mi się sposób w jaki programuje się w Javie, czyli podział kodu na paczki. Tam tworzymy paczki i dzielimy kod na oddzielne regiony. W C# moim zdaniem zrobione jest to trochę gorzej. Programista widząc foldery myśli, że w folderach jak to w folderach, powinien umieszczać obrazki, ikony i inne zasoby. Nie martwi się o podział klas na foldery. Tak podział daje porządek w solucji i projektach, chociaż i tak uważam że podział na paczki w Javie jest dużo fajniejszy.

3. Nie komentuj, wyrzuć

Zasada ta wydaje się szczególnie uzasadniona, kiedy korzystamy z systemu zarządzania wersjami. Często sam się łapie na tym, że komentuje kod, bo może kiedyś będę musiał do tego wrócić. Po zmianie jednak zapominamy o tych wszystkich zakomentowanych rzeczach i zostają one w projekcie. Sam widząc taki blok, jeśli nie jest on mój długo waham się czy go wywalić, czy zostawić. Przeważnie jednak wywalam. Jeśli ktoś chce wrócić do starej wersji, może przejrzeć starszego commita, a na 90% jeśli już ten blok zakomentował i zcommitował to nie wróci do starej wersji.

4. Nie bój się dodawać klas.

Zauważyłem, że wiele osób ma problemy z dodawaniem nowej klasy. Na początku oczywiście tworzymy klasy bo są nam potrzebne, ale wraz z tym jak projekt się rozrasta coraz mniej klas jest dodawanych. Wolimy dodawać nową metodę i nowe argumenty niż stworzyć nową klasę. Dochodzi czasami nawet do takich paradoksów, ze skoro mamy obiekt który przechowuje jakieś dane to w tym samym obiekcie przechowywaliśmy listę tych obiektów?! Wydaje mi się jednak, że w programowaniu obiektowym dodanie nowej funkcjonalności powinno oznaczać dodanie nowej klasy, a nie dodanie nowej metody. Tak się robiło pisząc programy strukturalne, pora się przenieść na obiekty…

5. Używaj regionów

Jedna z tych rzeczy, które sprawiają, że pisanie w C# staje się dużo wygodniejsze niż w Javie to właśnie regiony.
Tak wygląda klasa, która w rzeczywistości ma 400 lini:

6. Interfejs to fajna sprawa

Może trochę za często nawiązuje do Javy, wiem, że niektórzy ludzie nawet nie chcą słyszeć, że istnieje coś takiego, ale moim zdaniem Java ma też kilka bardzo dużych zalet i każdy programista .NET powinien poznać chociaż powierzchownie tą technologie. Jedna z rzeczy, nad którymi się często zastanawiam, to czemu w C# nie piszę interfejsów, albo jeśli piszę to wygodniej mi jest jeśli bym ich nie pisał. Nie umiem tego wytłumaczyć, wiem, że to czy używamy interfejsów, to sprawa architektury systemu. Więc technologię odsuwamy na bok, niemniej jednak pisząc w Javie miałem taki wewnętrzny przymus pisania interfejsów, natomiast pisząc w C# olewam to i piszę oddzielne klasy. Zauważyłem, że interfejsów używa niewielka ilość osób piszących w C#, natomiast znaczna większość osób piszących w Javie. Nie mam pojęcia czemu, ale interfejsy to bardzo fajna sprawa i warto ułożyć architekturę aplikacji, tak żeby jednak ich używała, ułatwi to bardzo rozszerzanie funkcjonalności.

7. Nie kopiuj, zrób funkcję

Ktoś, kiedyś, chyba na studiach powiedział mi, że jeśli programista pisze drugi raz ten sam kawałek kodu powinien się zastanowić, czy nie stworzyć nowej funkcji, a jeśli pisze go trzeci raz to już na pewno powinien ją stworzyć. Wprawdzie dziwi mnie to, że ktoś woli pisać 4 razy te same 10 linijek niż skrócić to do jednej funkcji i wywoływać ją w różnych miejscach, przecież informatycy to leniwi ludzie. Powinno nam zależeć an tym, żeby pisać jak najmniej…

Wpis ten poświęcam Panu z żółtą stroną internetową 🙂