Świetny program do robienia screenów pod Windows

Zawsze zachwycały mnie screeny prezentowane w sieci przez użytkowników komputerów Mac. I nie chodzi mi o cukierkowy interfejs OS X, ale o ładnie opisane, zaznaczone, wskazane przejrzystymi strzałeczkami elementy.

Zacząłem szukać oprogramowania pod Windows, nawet płatnego, który pozwoliłoby tworzyć równie schludne obrazy, pozwalając na nanoszenie strzałek czy napisów.

Początkowo, wraz z wydaniem Windows 7, zwrócił moją uwagę program "Narzędzie Wycinanie" dostępny wraz z systemem operacyjnym. Był to pierwszy raz kiedy do robienia zrzutu ekranu nie używało się guzika Print Screen, a wykorzystywanym programem wcale nie był Paint.

Pomimo znacznie podwyższonej wygody korzystania możliwości "Narzędzie wycinanie" nie zachwycały. Kilka miesięcy później trafiłem na Screenpresso. O kupnie programu myślałem już nie raz jednak żadna z dostępny po zapłacie opcji nie jest mi do szczęścia potrzebna i darmowa wersja w stu procentach spełnia moje potrzeby i oczekiwania.

Po zainstalowaniu program podpina się pod klawisz PrintScreen przyciemniając ekran i dając nam możliwość wyboru obszaru, który chcemy umieścić na zrzucie. Już na tym etapie otrzymujemy dwa udogodnienia: małą lupkę w prawym dolnym rogu ekranu, która pozwala nam dzięki powiększeniu precyzyjnie dobrać współrzędne prostokąta oraz szalenie użyteczny detektor kontrolek Windows, który po najechaniu zaznacza jej obszar sugerując nam wykonanie screenshotu tego konkretnego okna, pola, przycisku czy obszaru.

Chwilę później możemy już skopiować zawartość zrzutu [CTRL]+[SHIFT]+[C], plik ze zrzutem [CTRL]+[C], zmienić nazwę pliku [F2] czy usunąć nasze dzieło [DEL]. Najciekawszą opcją jest otworzenie zrzutu w wewnętrznym edytorze [ALT]+[E].

Opcji dostępnych w otworzonym przed chwilą oknie nie powstydzi się nawet użytkownik MacOSX. Program pozwala nam:

• nanosić strzałki
• tekst
• zaznaczać eliptyczne lub prostokątne obszary
• dodawać dymki i ikony
• numerować punkty
• podświetlać lub zamazywać fragmenty obrazu

Wszystkie elementy wyglądają szalenie elegancko i schludnie a efekt końcowy naprawdę cieszy oko.

Jeżeli nie wystarcza nam zaznaczanie obszaru ScreenPresso oferuje wykonanie screenshotu poprzednio użytego regionu, całego ekranu lub wykonanie zrzutu tuż po puszczeniu paska przewijania jednego z okien.

Edit

W myśl dewizy "zarabiam - płacę" zakupiłem wspomniany program w celu odblokowania opcji kręcenia filmików dłuższych niż, dostępnych w wersji darmowej, 15 sekund.

To co mile zaskakuje - nie musimy ujmować na filmie całego ekranu - możemy wyznaczyć obszar, który zostanie ujęty na filmiku. Niestety, to wszystko co oferuje obecnie w tej materii ScreenPresso. Nie znajdziemy tu żadnych zaawansowanych efektów, możliwości podświetlania i zaznaczania, przejść czy podążania za kursorem - mam jednak nadzieję, że to czasowe :)

Po nakręceniu filmiku jest on zapisywany w formacie zrozumiały wyłącznie dla wewnętrznego edytora. Aby udostępnić pozostałym nasze dzieło musimy korzystać z opcji konwersji. Tutaj nie możemy narzekać na brak możliwości: MP4, WebM, OGV, WMV czy witryna HTML5. Podążanie za trendami twórców oprogramowania aż zaskakuje.

Każdemu kto tworzy wiele instrukcji i szuka dobrego programu do ubogacania jej zrzutami serdecznie polecam!

Języki ponad-maszynowe

Odnośnie poprzedniego wpisu, moim zdaniem świat programistyczny powinien zainwestować więcej uwagi w kierunek jaki obrał chociażby PyPy czy Rubinius. Implementacje języków programowania, które są niezależne od maszyny wirtualnej, z której przyjdzie nam korzystać.

Pewne uniwersalna rodzina dialektów, które możemy wybierać do potrzeb danego zagadnienia nie zastanawiając się czy nasza aplikacja będzie działała na Androidzie, Linuksie, czy MacOS X. To jest moim zdaniem przyszłość.

Jeżeli o maszyny wirtualne chodzi - można zaobserwować ciekawe zjawisko. Pewien szczególny rodzaj maszyny wirtualnej, dostępnej wszędzie wytworzył się "przypadkiem". O dziwo jest nią przeglądarka internetowa. Połączony z tym rozwój takich standardów jak HTML5, CSS3 i projektów z nimi powiązanymi, problemy z technologią Flash na platformach mobilnych sprawiły, że dzisiaj przeglądarka internetowa/sieć jest najczęściej wybieraną platformą do tworzenia oprogramowania. Jeżeli już dziś chcemy napisać oprogramowanie, która za 20 lat będzie działało na kaczuszce do kąpieli naszego dziecka - zaimplementujmy to w JavaScript. Dzięki CoffeeScript, SprouteCore, ExpressJS, NodeJS JavaScript przychodzi pod strzechy. Za nią zaś stoją niewyobrażalnie zoptymalizowane maszyny wirtualne, które są od lat tuningowane i wystawiane do prezentowania swoich możliwości na torze zwanym Internet. Tutaj nie ma miejsca na pozorne rozwiązania - współzawodnictwo jest zacięte, a konkurencja nie śpi.

Może się wydać to nietypowe. Każdy język programowania posiada jedną maszynę wirtualną, stworzoną dla niego - JavaScript posiada ich aż kilka. Gdyby nie CoffeeScript - to z jej ohydną składnią i obleśną semantyką ociekającą toną wtfjs byłaby jak rozprzestrzeniające się na ogromną skalę trucizna. Na szczęście ludzie zaczęli ją oswajać i powoli uczą się ją wykorzystywać do tworzenia leków, znaleźli już wiele ciekawych zastosować.

Rodzi się pytanie - czy i jak JavaScript będzie można sprzedać? Język programowania, wykorzystywany do tej pory "dla bajeru", przez domorosłych informatyków, używany do pisania małych fragmentów, wstawek kodu staje się kompletnym rozwiązaniem z armią, przez lata optymalizowanych w wyścigu "zbrojeń" maszyn wirtualnych w drugim szeregu.

Język, w którym nie jest znana mi żadna metoda dająca zaczepienie oprogramowaniu "closed-source", gdzie jedyną metodą "chronienia" kodu jest jedynie jego zaciemnianie. Czyżby polimorfizm znany z pierwszych lat tworzenia wirusów? Zobaczymy.

Java w nowych projektach i racja jej bytu.

Czas języków programowania dawno minął - nastał czas dialektów maszyn wirtualnych.

Od kilku dni w firmie zatrudniani są programiści języka Java. Po rozmowie z zatrudniającymi managerami załamałem się - bo niby dlaczego Java?

Pisząc aplikację dla platformy Android, czy rozwijając Rational Team Concert to czego potrzebujesz to - plik wynikowy, zrozumiały dla JVM, napisany w konkretnej konwencji, używający konkretnych bibliotek a nie Java!

Jakie miejsce powinni zajmować dziś programiści C++ czy Java? Rozwijać dalej istniejące, dobrze napisane, oprogramowanie.

W dzisiejszych czasach możemy mówić o dialektach maszyn wirtualnych. Ślepe wybieranie dialektu języka Java do pisania oprogramowania dla JVM to po prostu zaściankowość i ciemnota.

Wiele innych: Clojure, jRuby, Jython, Noop czy chociażby Scala - mogą w danym zastosowaniu znacznie skrócić czas kodowania, podwyższyć jakość oprogramowania, obniżyć stopę występowania błędów, znacznie zwiększyć jakość kodu. W skrócie: skoro może być szybciej i lepiej to po co trzymać się języka Java? Trawestując Martina Klepmann : "Modern language programming is good 'quality filter' for people."

Oczywiście: nadal istnieje wiele powodów, dla których utkniemy z kolejnym projektem w języku Java. Brak developerów danego języka na rynku to podstawowa przyczyna - choć może być ich więcej. Moim zdaniem należy jednak próbować, podejmować wyzwania i ryzykować bycie innowacyjnym - to się opłaci.

Continous integration i Python?

Czy ktoś widział może kiedyś budowanie projektu pisanego w Pythonie?

Może nie jestem czegoś świadom, albo myślę zbyt szablonowo ale: continous-integration jest dobrze zdefiniowane dla projektów, które trzeba kompilować. Wiadomo. Developer nie kompiluje kodu sam. System CI sam sprawdza za niego czy kod pozytywnie przechodzi etap kompilacji i wysyła powiadomienia.

Ale jak odnieść się do tego w świetle Pythona. No dobra, wyciągamy kod źródłowy z repozytorium - i co? Przecież go nie skompiluję. Wszystko, na stać moją wyobraźnię na dzień dzisiejszy, to hmm... scan pylint, pychecker, pep8, odpalanie metody .compile() na każdym module? Jeżeli już zdecydujemy się na skany: to jak zachować się w przypadku jakiś komunikatów. Kod nie musi być źle napisany, zresztą zakładamy, że przeszedł review, ale wtedy co? Sfailować build tylko dlatego, że kod Pythona programisty nie odpowiada pylint. To niczego nie udowadnia.

Piszę ten post w związku z sytuacją jaka miała miejsce kilka dni temu. Rozumiem, żeby w trakcie budowania projektu Pythonowego odpalać testy w ramach. W moim przypadku nie mam nawet czasu aby je pisać więc nie ma co odpalać. Przyjmuję argument, że to co wychodzi na produkcję powinno być numerowane. To bardzo pomocne i użyteczne. Jednak w Python 2 wszystko co sobie wyobrażam to otagowywanie kolejnych wersji w repozytorium. Podmienianie egga, który wywala serwer Apache ponieważ przestają mu się zgadzać sumy kontrolne - to jakaś porażka. To nie wiem co innego mógłbym robić? Dodawać komentarz z numerem buildu w jakimś umówionym pliku? Dodam jeszcze, że to aplikacja internetowa pisana w Django.

Jeżeli ktoś jest w temacie to jestem bardzo zainteresowany wymianą doświadczeń w tym temacie.

Webdevelopment i unit testy

Kilka tygodni temu zacząłem developować webowy frontend dla projektu gitolite o nazwie glboard. Gitolite to warstwa abstrakcji pozwalająca na kontrolę dostępu do repozytoriów systemu git podczas dostępu do serwera przez ssh.

Glboard od samego początku pisany był z myślą o testach, dlatego wraz z kodem publikowane były unit testy do udowadniania poprawności metod, klasy, która stanowi trzon funkcjonalności.

Podczas oglądania prelekcji "State of Pylons/Turbo Gears2/repoze.bfg", moją uwagę przykuły zarzuty postawione unit testom w web-developmencie.

W tym okresie spędziłem sporo czasu, w glboard, na poprawianiu unit testów. Jeżeli padłem ofiarą zbyt wczesnego testowania - to jaki sens ma Test Driven Development?

Podczas zmieniania głównej klasy, obsługującej operacje na repozytorium gita, uzyskałem pewien ciekawy efekt - witryna działała i mogłem dzięki niej wykonać wszystkie operacje - natomiast testy failowały. Wszystkie. Powód był prosty: klasa przyjmowała teraz nowy argument w metodzie __init__.

Wspomniana prelekcja uświadomiła mi jedną rzecz. Jeżeli nie wystawiasz czegoś na zewnątrz, nie wystawiasz API lub biblioteki, nie będziesz zobligowany do zachowywania wstecznej kompatybilności z jakimś stworzonym przez siebie interfejsem, które kiedyś udostępniłeś, tylko dlatego, że używają go klienci - nie używaj unit testów. Pisanie unit testów do elementów, które zostają w twoim projekcie i nie wychodzą w żaden sposób na zewnątrz - to strzelanie sobie w stopę.

Moim zdaniem pisząc aplikację we frameworku webowym to co powinno się testować - to działanie przez przeglądarce. Testy funkcjonalne wydają się wystarczające. Może są troszkę bardziej kosztowne niż unit testy, ale w gruncie rzeczy, dobrze napisane, testują dokładnie to co powinny. Nie skupiają się na API konkretnej klasy, funkcji, metody, ale na tym czy witryna działa - nie ważne jest jak.

Odnosząc się do narzekań na Selenium i długiego czasu trwania testów w nim napisanych: myślę, że możemy spodziewać się rewolucji w świecie testów web-aplikacji dzięki PhantomJS. Nie znam jego wydajności, ale funkcjonalność jest w tej dziedzinie bardzo obiecująca i daje znacznie więcej możliwości niż zwykłe funkcyjne testy. Równocześnie nie używa całego niepotrzebne osprzętu jakie ładuje przeglądarka.

Wszystko co w tej chwili mi pozostaje to usunąć unit testy z glboard i napisać functional testy :)

Co w językach programowania i web developmencie piszczy

Od czasów, kiedy skończyłem studia bardzo interesowałem się rozwojem języka C++. Na początku bibliotkę Boost, w której ląduje co ciekawsze pomysły, które mają w przyszłości zagościć w języku a potem wersją C++0x. Dzisiaj spojrzałem na wsparcie dla składni C++0x w gcc-4.6 i powiem szczerze, że nie mogę się doczekać kiedy Ubuntu i Debian zostaną skompilowane na tym właśnie kompilatorze. Na razie nie jest dostępny na żadnej dystrybucji - niestety brak go również w paczkach Ubuntu 11.04, ale użycie tego kompilatora będzie szalenie ekscytujące.

Lista wszystkich zaimplementowanych nowinek jest dostępna tutaj: http://gcc.gnu.org/gcc-4.6/cxx0x_status.html

Mnie cieszą dwie: składnia dla for znana z python - gdzie iteruje się po elementach, nie po indeksach oraz lambdy - czyli funkcje nienazwane, które można przekazywać jako parametry.

W sumie powiem szczerze, że mam szaloną chęć napisać coś w C++ :) na przykład stronkę - jest framework Web Toolkit więc czemu by nie spróbować :] Jak się patrzy na listę możliwości to pojawia się UTF-8 i 16, HTML 5 native, async I/O, VML, SVG, PDF, PNG/GIF, SSL, TLS właściwie wszystko czego dusza zapragnie, a czym nie chwalą się żadnej inne frameworki należące do języków skryptowych, które borykają się z różnymi problemami w tej dziedzinie (ostatnio szczególnie frameworki Pythonowe). Można deployować przez FastCGI, postawić na dedykowanym serwerze dostarczonym z frameworkiem albo podpiąć do IIS. Brzmi super :)

C++ staje się naprawdę fajnym językiem, może mniej fajnym niż Go (z frameworkiem web.go) :) ale naprawdę wartym uwagi. Pozostaje czekać tylko czym będzie język Noop i cieszyć się z tego co przyniosą najbliższe lata :)

Jeżeli zaś ktoś chciałby popróbować development na wirtualnej maszynie to przychodzą mi na myśl wyłącznie Lift z języka Scala i z troszkę innej beczki :) ExpressJS dla języka Node.JS.

Jako ciekawostkę dodam, że jeżeli ktoś chce się nauczyć, w jakimś subiektywnym aspekcie języka "idealnego" to istnieje świetny kurs do języka Haskell pod tytułem "Learn You a Haskell for Geate Good!" . Web Development też jest wtedy możliwy - dzięki frameworkowi Snap.

O zapomniałbym. Ostatnio (no już trochę czasu minęło) Zed Shaw stworzył (ten gość chyba się po prostu nudzi) Tir - framework do web developmentu w języku skryptowym Lua. Co więcej wszystko w ramach projektu Mongrel2, który jest jeszcze bardziej imponującą kontynuacją znanego developerom Ruby On Rails serwera Mongrel - tym razem, w drugiej wersji wspiera chyba każdy język programowania.

Przy okazji - dla tych, którzy siedzą wciąż w świecie Python i Ruby. Jeżeli szukacie jakiegoś hiper wydajnego frameworka to nie tylko najnowszym i najnowocześniejszym w architekturze, ale również ewidentnie najszybszym jest Pyramid - jeżeli wierzyć wynikom z artykułu "The great web technology shootout – Round 4: Pyramid vs Django vs TG vs Rails 2 & 3" - bije na głowę dosłownie wszystko. Jednak jest to framework stricte w filozofii i podejściu wykorzystywanym w Pylons - i jego sukcesorem. Co miłe jest to "najszybciej wydany" framework w dziejach macro-frameworków jakie w życiu widziałem bo development zaczął się w Grudniu 2010 a pod koniec Stycznia 2011 wyszła stabilna wersja 1.0 - chociaż to troszkę naciągane bo projekt nie startował od zera ale był adaptacją już wcześniej wydanego Repoze BFG.

Zdradzę jeszcze, że dowiedziałem się iż na PyCon 2011 US, który odbywa się w Marcu odbywają się sprinty, które mają na celu portowanie Pyramid na Python 3 tak więc możemy mieć pierwszy framework działający na Py 3k :) Czy to nie ekscytujące?

Co w ostatnich tygodniach.

Dawno nie pisałem na blogu. Gdy jeszcze dzieliłem czas na studia i pracę starczało mi czasu na wszystko. Obecnie obcowaniem z komputerem staram się ograniczać do siedzenia przed nim w pracy, a wieczory i weekendy spędzać w inny sposób.

Ćwiczę Angielski. Umiałem go świetnie przed maturą, jednak studia inżynierskie skutecznie uwsteczniły mnie w tej materii. Jakiś już czas temu, bo w zeszłym roku, mój manager widząc braki, zorganizował spotkania z lektorką dzięki czemu wtorki i czwartki zaczynam lektoratem z języka angielskiego :) co skutecznie poprawia mi humor na pozostałą część tygodnia.

Co do języków programowania - wciąż używam Pytona, ze względu na jego znajomość zostałem zatrudniony i przez ostatnie 1,5 roku zostawiłem po sobie na tyle skryptów i aplikacji zapisanych w tym dialekcie, że ciężko codziennie się z nim nie stykać. Jednak moje marzenia i pasje kierują się w stronę Node.JS oraz wciąż zagadkowego dla mnie języka Scala.

Node.JS chciałem rozpocząć od przebrnięcia przez fantastyczny podręcznik do JavaScript "Eloquent JavaScript". Niestety, silnie funkcyjne podejście autora do sprawy skutecznie utrudnia mi przyswojenie lektury, a problemy zaczęły się już w rozdziale 4.

Co do Scala jest lepiej. Wiele zawdzięczam prelekcji Mikołaja Sochackiego Aplikacje webowe w Scala i Lift wygłoszonej na Zimowisku TLUGu. Sama prezentacja, jak i późniejsza wymiana doświadczeń w prywatnej rozmowie z prelegentem, pozwoliły mi dojść do wniosku, że trzeba przestać przejmować się, że "czegoś" nie rozumiem i opanować Scalę na miarę swoich możliwości - z czasem poznając ją może po prostu lepiej.

Tak też narodził się pomysł na prostego bloga, z przykładowymi aplikacjami w języku Scala, które skupiałyby się na konkretach i w prosty sposób pozwoliły na zapoznanie się z językiem. Co z tego wyjdzie - zobaczymy. Obecnie robię rozeznanie w silnikach, na których warto byłoby taki "blog" postawić. Z dotychczasowych poszukiwań wszystko wskazuje na Joggera - chyba, że znajdą się jakieś fundusze na zakup i utrzymanie domeny - wtedy będzie to Wordpress. Przy okazji trafiłem na Polski Portal Scala, na którym już w tej chwili można zapoznać się z niemałym zbiorem przykładów kodu w tym języku.

Jednak pierwszeństwo przed projektem Scalowym ma stworzenie Planety Pythona, którego podjąłem się niedawno w ramach mojej działalności w Polish Python Coders Group - wszak na koszulkę jakoś trzeba sobie zasłużyć :). Twarzą w twarz poznałem większość ekipy dopiero na PyCon.pl 2010 i co tu dużo gadać - są genialni. Kocham tych chłopaków za kawał dobrej roboty jaki odwalają, szczególnie na IRCu i Forum - uważam, że mamy fantastyczną scenę Pythonową w Polsce jakiej można tylko pozazdrościć i każdy kto chce zacząć przygodę z tym językiem nie mógłby sobie wymarzyć lepszej społeczności niż obecna.

Wracając do Zimowiska Linuksowego TLUG - było naprawdę fajnie. Dzięki zakwaterowaniu w Puckim HOMie czułem się jak na wczasach, do tego urok małego miasteczka jakim jest Puck - genialnie. Prelekcje były zróżnicowane, poziom wielu z nich naprawdę wysoki i profesjonalny. Szczególnie dało się to odczuć w prezentacjach Piotra Macuk, Tomasza Torcz (wiem, że gdzieś prowadzi bloga, ale nie mam adresu), Roberta Jaroszuk, Grzegorza Borowiak oraz Dariusza Puchalak. Subiektywnie jednak bardziej interesują mnie technologie webowe i ten charakter konferencji, która moim zdaniem była zaadresowana głównie do administratorów systemu Unix, nie przypadł mi specjalnie do gustu.

Co do spędzania czasu po pracy zagospodarowuję go w znacznej mierze treningami Aikido w Shoshin Dojo. I grubsza tyle z nowinek - wracam chorować :]