@rek online

Nie tak dawno bo raptem kilka dni temu a właściwie kilkanaście godzin temu pisałem o najprawdopodobniejszej (wg. Serwisu NikonRumors) specyfikacji następcy rewelacyjnego Nikona D90, mianowicie D95. Serwis NikonRumors opublikował informację, że nowy następca zostanie ogłoszony w połowie września, a najprawdopodobniej około 15-tego. Czyli już za kilkanaście dni dowiemy się jak naprawdę będzie wyglądała nowa lustrzanka dla amatorów i zaawansowanych (acz niezamożnych amatorów). Przy okazji zaprezentowany ma zostać obiektyw Nikkor 200mm f/2.0 z redukcją drgań VRII oraz Nano coating (czyli nowa lepsza nano powłoka, która spowoduje że Wasze zdjęcia będą jeszcze lepsze). Nowe szkło ma kosztowac w okolicy 6000$ (czyli daleko poza moim zasięgiem ). Jak się sprawy rozwiną, zobaczymy. Mam tylko nadzieję ze następca D90-tki będzie w tej samej cenie co oryginał czyli 999$ – może i się nie zapowiada ale przecież marzyć każdy może.

Ostatnio przeglądałem statystyki bloga i jak się okazuje jedną z częściej poszukiwanych informacji jest sposób na zamianę małych liter na duże lub odwrotnie, dużych na małe w programie Microsoft Word. Pisałem o tym ponad dwa lata temu a mimo do wpisu ciągle płynie stały ruch osób w potrzebie. Zatem w ramach przypomnienia poniżej umieszczam zrzut ekranu:

Który pokazuje jak dokonać tej czynności. Można zamienić litery również za pomocą skrótu klawiszowego Shift+F3 (dziękuję Kober). Na koniec oczywiście video, które zostało dodane później jako zobrazowanie całości.

Mamy pomysł, który został odpowiednio przeanalizowany pod względem użyteczności oraz priorytetów. Co dalej? Należy się zastanowić, czy realizujemy go czy nie. Pytanie może wydawać się zupełnie idiotyczne, no bo jak to… mam pomysł i nie realizuję go? Jak podają eksperci, firmy odnoszące największe sukcesy odrzucają większość początkujących projektów. Dlaczego tak się dzieję? No cóż, nie ma się co łudzić, że pewnego dnia wstaniemy i wpadniemy na genialny pomysł, który zrewolucjonizuje podbije świat. Takie pomysły potrzebują czasu aby można je było określić. Czasem kilka innych pomysłów nakieruje nas małymi kroczkami na ten jeden, jedyny słuszny. Zobaczcie co robi Google, jak wieść gminna niesie, programiści są zobligowani do spożytkowania 20% czasu pracy na pracę nad własnymi projektami. Co więcej z tych projektów są rozliczani (czy rzeczywiście coś robili). Co się dzieje z tymi projektami dalej? Przecież to mogą być zupełnie niepotrzebne rzeczy, które nawet nie pasują do polityki firmy. Takie projekty są weryfikowane i w większości odrzucane jednak mały procent z nich wchodzi do „produkcji”, stają się rozwijane i upubliczniane. Tak stało się między innymi z listą zadań w gmail-u. Dlatego namawiam Cię do spisywania swoich pomysłów, analizowania ich i odrzucania tych, które są bez przyszłości. Małymi kroczkami dojdziesz do tego jednego upragnionego Grala. Być może to będzie coś na miarę Skype-a lub Facebook-a a może coś mniejszego ale dającego twórcy – Tobie – satysfakcję.

Wracając do mojego projektu. Odpowiedź na pytanie o realizację zawarłem poniekąd w poprzednim poście. Więc sprawa jest prosta. Realizuję. W tym celu należy przygotować sobie środowisko pracy. Dopiero tutaj proponuję zastanowić się nad technologią.

Dlaczego dopiero tutaj? Dlatego aby nie mieszać pomysłu na software z jego implementacją. Jeśli mamy skrystalizowany pomysł, jeśli będziemy wiedzieli co chcemy uzyskać i jak ma to „coś” pracować, łatwiej będzie nam wybrać technologię (jeśli mamy taki wybór). W moim wypadku technologia wynika bezpośrednio z chęci jej poznania a nie z potrzeby stworzenia komercyjnej aplikacji, która będzie dostępna dla milionów użytkowników. Gdyby ta aplikacja miała być dostępna szeroko to pewnie poszedł bym w kierunku C++ oraz WinAPI, tutaj jednak priorytety są trochę inne.

Środowisko pracy czyli co będziemy potrzebować:

1. Narzędzie programistyczne
2. Narzędzia zwiększające możliwości wybranego narzędzia programistycznego
3. Repozytorium źródeł
4. Automatyczna kompilacja
5. Miejsce przechowywania zadań do wykonania oraz informacji o błędach
6. Miejsce do publikacji wersji
7. ….

Listę pozostawiam otwartą bo być może macie sugestie odnośnie tego co jeszcze może być przydatne.

Jak ta lista wygląda w przypadku DesktopInfo

1. Narzędzie programistyczne

   Visual Studio 2010 Ultimate – bo do takiego mam dostęp w ramach MSDN AA (jeśli macie możliwość skorzystania z tego programu to z całego serca polecam go, dostajecie potężny pakiet oprogramowania za darmo i w pełni legalnie. Większość z nich ma lepsze lub gorsze darmowe alternatywy ale w codziennej pracy w realiach naszego kraju, z wieloma tymi narzędziami się spotkacie więc warto skorzystać z możliwości poznania ich)

2. Narzędzia zwiększające możliwości wybranego narzędzia programistycznego

   No cóż, żadne narzędzie nie jest idealne i chyba do większości z nich powstają dodatki zwiększające produktywność. Aplikacje takie jak ReSharper, Tommatoe czy choćby PowerTools dla VisualStudio pozwalają wycisnąć jeszcze więcej z ulubionego IDE. Ja będę korzystał z PowerTools i kilku innych dodatków do Visual Studio 2010 – więcej o nich w nadchodzących wpisach.

3. Repozytorium źródeł

   Dlaczego w ogóle tego potrzebujemy jeśli pracujemy jako samodzielny programista? Dla bezpieczeństwa i wygody. Wyobraź sobie sytuację, w której jakaś część kodu lepiej działała w poprzedniej wersji niż teraz. Mając dowolne repozytorium źródeł możemy wrócić do konkretnej wersji, możemy porównywać zmiany pomiędzy wersjami i sprawdzać co się zmieniło/zepsuło/naprawiło. W przypadku jeśli chcemy pracować w kilka osób, wówczas takie repozytorium jest wręcz niezbędne. W swoim projekcie będę korzystał CodePlex-a wspomaganego TeamExplorerem – czyli uzyskam namiastkę Team Foundation Server-a

4. Automatyczna kompilacja

   Rzecz bardzo miła i przyjemna. Możliwość skompilowania naszego projektu za pomocą jednego kliknięcia lub jednej komendy. Pracując w zespole rzecz równie nieodzowna co repozytorium źródeł. Nie każdy przecież musi pamiętać jak skompilować aplikację (szczególnie jeśli ma wiele zależności, dodatkowych modułów etc). W moim wypadku chyba nie będę z tego korzystał, ponieważ jeszcze nie wiem jak wykorzystać BuildServer (część Team Foundation Servera) na CodePlex-ie

5. Miejsce przechowywania zadań do wykonania oraz informacji o błędach

   Rzecz chyba najbardziej kluczowa jeśli chodzi o zarządzanie projektem. Pomijając wszelkie metodologie (czy to SCRUM czy PRINCE2 czy klasyczne kaskady i inne „wymysły”) musimy prowadzić listę rzeczy do zrobienia oraz listę błędów. Nie ma się co łudzić, że nawet przy jednoosobowym projekcie zapamiętamy listę ficzerów i błędów do rozwiązania. Zresztą po co o tym pamiętać, nasze mózgu można wykorzystać bardziej efektywnie niż do zapamiętywania informacji.

   Ponieważ DesktopInfo będzie jest hostowany na CodePlex i korzystam z Team Explorera, to mogę przechowywać WorkItemy czyli rzeczy do zrobienia (oznaczone jako ficzer albo jako bug). Czyli wybierając odpowiednie narzędzie załatwiam 2 punkty na liście J

6. Miejsce do publikacji wersji

   Tutaj sprawa jest oczywista, wersja skompilowana musi gdzieś być opublikowana. Jeśli to jest publicznie dostępna aplikacja OpenSource to pewnie na jakiejś stronie (DesktopInfo będzie publikowany na stronach CodePlex oraz być może – tu sprawa jest jeszcze otwarta – tuta na blogu), jeśli aplikacja jest tworzona przez firmę i będzie dostarczana jedynie tym którzy zapłacą, wówczas aplikacja musi być tak opublikowana, aby dostęp do niej mieli testerzy.

    

7. …

   W tym punkcie oddaję głos Wam, co jeszcze uważacie, że powinno się znaleźć na liscie?

    

    

Jak już pisałem we wcześniejszym wpisie, Maciek Aniserowicz organizuje konkurs, dzięki któremu można będzie po pierwsze wygrać bardzo ciekawe nagrody a po drugie trochę bardziej „dać się poznać”. Postanowiłem wziąć udział w konkursie z kilku powodów:

1. Rewelacyjny impuls aby powrócić bardziej aktywnie do bloga.
2. W końcu ruszę projekt bardzo powoli i leniwie rósł gdzieś w zakamarkach świadomości.
3. Młodzi programiści, którzy nie pracowali zawodowo często nie wiedzą jak wygląda tworzenie aplikacji więc spróbuję opisać ten projekt krok po kroku wraz z kilkoma pseudo filozoficznymi przemyśleniami. Dzięki temu będziecie mogli poznać kilka narzędzi i metod oraz będziecie wiedzieli na co zwracać uwagę w swoich projektach (jak ten aspekt wyjdzie, jestem bardzo ciekaw). Jeśli to co będę pisał pomoże chociaż jednej osobie, wówczas będę uszczęśliwiony.
4. No i w końcu, zgarnięcie jakiejś ciekawej nagrody

Okej, czas zacząć. Pierwsza rzecz to pomysł. Bardzo często w pracy zawodowej mamy narzucone narzędzia, czy to przez kulturę konkretnej firmy/organizacji, dostępne licencje czy też inne aspekty. W sytuacji idealnej, kiedy mamy możliwość wyboru narzędzi proponuję w fazie pracy nad pomysłem zupełnie zapomnieć o technologii, zapomnieć o narzędziach i skupić się na samym pomyśle. Proponuję zadać sobie następujące pytania:

1. Jaki jest cel projektu? Co ma wykonywać aplikacja?
2. Dlaczego taka aplikacja jest potrzebna? A może nie jest potrzebna?
3. Czy istnieją takie aplikacje na rynku? Jeśli tak to w czym moja będzie lepsza od innych?
4. Jak mam zamiar zarabiać na mojej aplikacji?

Oczywiście można by zadać sobie więcej pytań ale te wydają się na tyle podstawowe a jednocześnie na tyle szerokie, że powinny zainicjować odpowiedni proces myślowy i sprowokować do głębszych przemyśleń.

Jak to wygląda w przypadku mojej aplikacji konkursowej ?

1. Jaki jest cel projektu? Co ma wykonywać aplikacja?

    

   Chcę stworzyć aplikację „Framework” do hostowania gadgetów. Chcę aby aplikacja mogła wczytywać dodatkowe gadżety poza tymi, które dostępne będą domyślnie. Chcę aby nowe gadżety mogły być dodawane w trakcie pracy i prawdopodobnie najważniejsza rzecz (dla mnie osobiście), chcę poznać bardziej Windows Presentation Foundation (WPF). Ostatni powód jest jednym z najważniejszych z prostego powodu, można przeczytać 200 książek, całego MSDN-a i 10 000 blogów na temat ……………. (tu wstaw dowolne literki – u mnie tj WPF) a i tak, ciągle będziemy mieli wrażenie, że wiemy mało. Nic nie powoduje szybszego przyrostu wiedzy niż wykorzystanie jej w konkretnym projekcie. Oczywiście podstawy teoretyczne są potrzebne, potrzebujemy sięgać do książek i dokumentacji, ale dopóki nie wykorzystamy tej wiedzy w rzeczywistym projekcie, ta wiedza będzie tylko i wyłącznie teoretyczna. Zresztą jeśli ten temat Cię interesuje to przeczytaj wpis Programowanie przez eksplorację Maćka.

    

2. Dlaczego taka aplikacja jest potrzebna? A może nie jest potrzebna?

    

   Tutaj odpowiedź jest banalna – nie jest potrzebna. Są gotowe platformy takie jak Yahoo Gadgets (wcześniej Konfabulator) jest Rainmeter i w końcu wbudowany mechanizm gadżetów w Windows-a 7. Tak więc sama potrzeba rozwiązania problemu jest dawno zaspokojona, co więcej ilość dostępnych gadżetów na poszczególne platformy jest tak szeroka, że bez pomocy z zewnątrz, nie będę wstanie zapewnić nawet 1/10 tego co istniejące platformy oferują już dzisiaj. Rozwijana aplikacja jest na moje potrzeby – poznanie WPF-a a przy okazji będzie pozwalała na rozpoznanie wielu zewnętrznych API (ale o tym później)

    

3. Czy istnieją takie aplikacje na rynku? Jeśli tak to w czym moja będzie lepsza od innych?

   Na to pytanie odpowiedziałem już wcześniej. Tak, istnieją takie aplikacje i tak, mają szersze możliwości. Jednak moim nadrzędnym celem jest poznanie WPF-a.

4. Jak mam zamiar zarabiać na mojej aplikacji?

   Tutaj sprawa jest prosta. Aplikacja z uwagi na swoje przeznaczenie nie będzie sprzedawana a jeśli tak się zdarzy, że aplikacja znajdzie szersze zainteresowanie, wówczas przewiduję możliwość złożenia dobrowolnych datków. Nie widzę tutaj miejsca na inny model biznesowy – bo i po co.

    

Okej, sprawy ogólne załatwione, w tym momencie, chciałbym abyś się czytelniku zastanowił nad swoim projektem, który będziesz rozwijał. Zadaj sobie 4 podstawowe pytania (może niekoniecznie dokładnie takie same, jednak poświęć minimum 5-10 minut na przemyślenie powodów tworzenia aplikacji).

W następnym odcinku zajmiemy się kolejnym krokiem, czyli przygotowaniem środowiska.

Nie dalej jak 8 godzin temu pisałem o nowym aparacie, który ma zastąpić rewelacyjnego D90. Jak pisze serwis Nikon Rumors aparat te będzie posiadał wzmacniane – magnezowe bóstwa. Przewidywany sensie to 16mpx – czyli bez zmian w stosunku do wcześniejszych plotek. Oczywiście możliwość kręcenia filmów w 1080 oraz 6 klatek na sekundę w przypadku zdjęć seryjnych. (dla porównania obecny d90 wykonuje 4.5 a bardziej zaawansowany D300s 7 klatek) czyli bardzo przyzwoicie.

Kolejna ciekawostka to aż 39 punktów autofocusa. Robi się coraz bardziej ciekawie. Pozostaje tylko jedno ale… Niezmieniona cena o której pisałem że na taka liczę, prawdopodobnie będzie wyższa. Wprawdzie tylko o 200$ w porownaniu do ceny D90 w momencie premiery ale dla wielu osób 1200$ może stanowić już problem. Szczególne przy obecnym kursie dolara.

Teraz pozostaje jedynie czekać na oficjalne wiadomości