Qt4: konwersja projektu qmake do CMake

Podczas tworzenia projekt w Qt z poziomu QtCreatora, do budowania projektu (generowania plików Makefile i tak dalej) QtCreator używa narzędzia qmake. Okazuje się jednak, że to nie wszystko:) QtCreator potrafi także używać CMake! Niestety nie ma póki co gotowego narzędzia, które automatycznie przekonwertuje projekt z qmake na CMake. Możemy jednak zrobić to sami. Jak? O tym jest właśnie ten tutorial.

Na sam początek warto wiedzieć, że sercem CMake jest plik CMakeLists.txt. To w nim definiowane są zasady, jakie biblioteki trzeba znaleźć i dołączyć, które pliki zbudować itd.

W pierwszym kroku trzeba zatem utworzyć plik CMakeLists.txt. Dodajemy go w głównym katalogu projektu. Natomiast folder wyżej (ponad źródłami i plikiem CMakeLists.txt) warto stworzyć dodatkowy folder, w którym będzie budowany nasz program.

Oto wersja pierwsza przykładowego pliku CMakeLists.txt – oferuje automatyczne wyszukiwanie plików ui i moc i generowanie na tej podstawie kodu. Odpowiadają za to zmienne: CMAKE_AUTOMOC i CMAKE_AUTOUIC.

CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON)

PROJECT(V1)

set(QT_SRC ${QT_SRC} "${PROJECT_SOURCE_DIR}")
https://wiki.qt.io/Using_CMake_build_system
FIND_PACKAGE(Qt4 REQUIRED QtGui QtXml)
INCLUDE(${QT_USE_FILE})

QT4_WRAP_UI(UISrcs mainwindow.ui)
QT4_WRAP_CPP(MOCSrcs mainwindow.h)
 
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
INCLUDE_DIRECTORIES(${QT_SRC})
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/src/gui)

add_executable(DemoQt ${PROJECT_SOURCE_DIR}/main.cpp mainwindow)

TARGET_LINK_LIBRARIES(DemoQt Qt4::QtGui Qt4::QtXml) 

Aby wypisać wartości zmiennych, warto użyć polecenia MESSAGE, np.:

MESSAGE("MyProjectLib_src:\t\t${MyProjectLib_src}")

Moje wartości zmiennych są zatem następujące:

MOCSrcs /home/d9k/ProstyProjektQtCmake/qponiższytcreator-build/moc_mainwindow.cxx
MOCSrcs /home/d9k/ProstyProjektQtCmake/qtcreator-build/ui_mainwindow.h
QT_SRC /home/d9k/ProstyProjektQtCmake/zrodla
PROJECT_SOURCE_DIR /home/d9k/ProstyProjektQtCmake/zrodla
QT_USE_FILE /usr/share/cmake-2.8/Modules/UseQt4.cmake
CMAKE_CURRENT_SOURCE_DIR /home/d9k/ProstyProjektQtCmake/zrodla
CMAKE_CURRENT_BINARY_DIR /home/d9k/ProstyProjektQtCmake/qtcreator-build
QT_LIBRARIES /usr/lib/x86_64-linux-gnu/libQtGui.so;/usr/lib/x86_64-linux-gnu/libQtCore.so

Okazuje się jednak, że używanie automatu nie zawsze jest dobre – zwłaszcza, jeśli projekt jest rozbudowany i struktura katalogów jest drzewiasta. Wzorując się na poniższych wpisach w serwisie StackOverflow, udało mi się zmodyfikować poprzednią wersję, aby nie używała automatycznego przypisywania plików ui i moc.

Usuwamy zatem fragment ze zmiennymi CMAKE_AUTOMOC i CMAKE_AUTOUIC, by zastąpić go własnym wskazaniem ścieżek: Czytaj dalej

Zanurkuj w Pythonie – recenzja

Odważyłam się i zanurkowałam w paszczy Pythona 😉 A konkretnie to udało mi się przebrnąć przez „Zanurkuj w Pythonie” Marka Pilgrima. Podręcznik dostępny jest za darmo tu: https://pl.wikibooks.org/wiki/Zanurkuj_w_Pythonie (i to w dodatku po polsku).

Książka jest bardzo przekrojowa – obejmuje szerokie spektrum tematów: instalacja, sprint (dosłownie) przez składnię języka, operacje na plikach i strumieniach, parsowanie XML i HTML, obsługa usług sieciowych SOAP i HTTP, testy jednostkowe. Potem przychodzi czas na wyrażenia lambda, funkcje dynamiczne i optymalizację kodu.

Każdy rozdział jest zbudowany wg podobnego schematu: przedstawienie kompletnego kodu programu, a następnie tłumaczenie linijka po linijce. Co więcej, autor udostępnia na swojej stronie kody źródłowe, więc lekturę można uzupełnić własnymi doświadczeniami.

Gdy zabierałam się za lekturę, o Pythonie nie wiedziałam praktycznie nic (mając jednocześnie doświadczenia z Javy, Ruby czy innych języków) i nawet będąc już w połowie lektury nadal wydawało mi się, że ten stan rzeczy nie uległ zmianie 😉 Początkowo irytowało mnie , że książka jedynie ogólnie nakreśla podstawy, nie opisuje wszystkich możliwych funkcji, tylko skupia się na kilku, użytych w programie. Tymczasem autor w każdym rozdziale pisze, aby wiedzę uzupełnić u źródła, tj. przeczytać odpowiedni fragment dokumentacji Pythona. Fajnie, ale wymaga to czytania podręcznika na komputerze, a nie na Kindlu… Na szczęście druga część książki poszła już z górki, możliwe że dlatego, że „opatrzyłam się” już ze składnią. Bardzo podobały mi się rozdziały o testach (bycie QA zobowiązuje 😉 ). Ciekawy był rozdział o optymalizacji, brakowało mi jednak lepszego podsumowania, jakiejś tabelki, które podejścia są zasobożerne, a które nie.

Dodatkowo zrobiłam eksperyment, próbując odpowiedzieć na pytanie, czy da się czytać książki techniczne (zawierające kody źródłowe) na Kindlu? Cóż, dać się da, ale czytało się dużo gorzej niż z laptopa – percepcja jest zupełnie inna na dużym ekranie – treść przyswaja się szybciej, rzut oka starczy by cofnąć się do kodu omawianego parę akapitów niżej, można też ogarnąć całość, zorientować się, ile jeszcze zostało do końca itd. Na Kindlu niestety nie ma takiej możliwości, trzeba się to cofnąć parę stronic wstecz, to wrócić do miejsca czytania, by za chwilę znowu musieć się cofać 😉 Dodatkowo „Zanurkuj…” co chwilę odwołuje się do dokumentacji albo innych miejsc w sieci, kody warto też przetestować na swoim komputerze, zatem jak się okazuje, średnio nadaje się do kanapowego trybu czytania.

Podsumowując, wydaje mi się, że nie jest to książka dla absolutnie „zielonych” w Pythonie, a na pewno nie dla osób, które nigdy nie miały do czynienia z programowaniem. Jeśli jednak ktoś już wcześniej programował i zna mniej więcej podstawy Pythona – jak najbardziej polecam.

Jak zacząć z testowaniem – artykuł od Girls Who Test

Ilekroć zabieram się za wpis opisujący jak zacząć karierę jako tester, natrafiam w sieci na artykuł, który już temat opisuje! Jeszcze nie tak dawno w sieci mało można było znaleźć materiałów na ten temat, a teraz – proszę. Nic tylko czytać! 🙂

Tym razem w oko wpadła mi broszurka przygotowana przez Aleksandrę Kornecką z Girls Who Test.

Dokument do przeczytania tutaj: https://docs.google.com/document/d/1e9IVt5x_W8FW24R-7BaQh3xf3jShHfJGzMEjm0E1sWg, a w nim:

  • co to jest oprogramowanie i co oznacza termin „testowanie oprogramowania”
  • kompetencje miękkie u testera
  • obowiązki testera
  • ścieżki rozwoju
  • skąd czerpać wiedzę
  • i inne.

Jeśli chodzi natomiast o same Girls Who Test, polecam śledzić ich stronę: http://www.girlswhotest.pl/events/, większość wydarzeń organizują w Warszawie lub Poznaniu. Dziewczyny, trzymam kciuki! 🙂

Kernel: Don’t panic

W ubiegłym miesiącu, dla zabicia czasu w sobotni, deszczowy dzień, wybrałam się na studencką konferencję organizowaną przez Koło Naukowe Kernel, o uroczej nazwie Kernel: DON’T PANIC! Impreza odbywała się 13 maja ’17, w dużej auli Wydziału Fizyki i Informatyki Stosowanej AGH, którą oczywiście darzę dużym sentymentem:D

Organizacja na piątkę. Szatnia, ciasteczka, gorąca kawa, a nawet upominki dla uczestników: smyczki i elegancka torba z nadrukiem loga koła, a w środku pisadło i butelka wody (może na kaca, w końcu Juwenalia:D), słowem profeska i szacunek dla organizatorów za ogarnięcie tematu (a dla sponsorów za sypnięcie groszem:))

Przechodząc jednak do merytoryki muszę powiedzieć, że wykłady trzymały poziom. Na scenie udało się zgromadzić naprawdę ciekawych prelegentów.

Na początek Piotr Konieczny którego przedstawiać myślę nie trzeba (niebezpiecznik.pl) opowiedział o kulisach ataków socjotechnicznych, jakie w ramach audytów bezpieczeństwa przeprowadzają w firmach. Okazuje się, że czasem nawet świadomość i wiedza pracowników nie wystarcza, by uchronić organizację przed przemyślanym atakiem socjotechnicznym. Bardzo często działamy automatycznie, nawykowo, a na domiar złego w grupie myślenie i odpowiedzialność ulega rozproszeniu, skutkiem czego niestety, najsłabszym ogniwem zabezpieczeń bywa człowiek. Naprawdę warto było wstać przed ósmą (w sobotę!) i pomknąć przez deszczowy Kraków, by dotrzeć na ten wykład!

Wykład pt. „Metodologia tworzenia oprogramowania przez IBM spełniającego wymogi cyber-bezpieczeństwa” niestety ciut mnie rozczarował, więc przejdę od razu do kolejnego punktu, czyli wystąpienia naczelnika krakowskiego wydziału policji do walki z Cyberprzestępczością. Czytaj dalej

Catch-all czyli złap wszystkie maile, nawet wysłane pod nieprawidłowy adres

Niestety ludzie czasem mylą się – popełniają literówki w imieniu albo przekręcają nazwisko. Wisniewski@onedaymail.com czy Wisniowski@onedaymail.com? Jak skonfigurować serwer pocztowy, żeby pobierał także wiadomości wysłane na niepoprawny adres?

Jeśli mamy skrzynkę pocztową u usługodawcy typu Gmail, Poczta O2 itp. niestety nie mamy możliwości manewru. Oczywiście mozna by założyć drugą skrzynkę z przekręconym nazwiskiem i ustawić przekierowanie, nie zawsze jednak jest to możliwe. Na szczęście skrzynkę pocztową można założyć na własnym serwerze – najczęściej kupując konto hostingowe (najlepiej z własną domeną) mamy możliwość założenia również poczty w tej domenie.

Konfiguracja sprowadza się do włączenia usługi catch-all. W zależności od panelu administracyjnego konfiguracja może wyglądać nieco inaczej. Pokażę na przykładzie Direct Admin.

  1. Zakładam skrzynkę, która będzie używana do zbierania wszystkich maili. Warto ustawić jej ograniczenie zajmowanej powierzchni (quota) ponieważ na takiej skrzynce może gromadzić się sporo spamu!
  2. Włączam catch-all, przekierowując wszystkie zabłąkane maile na stworzoną przed chwilą skrzynkę.
  3. Gotowe 🙂 Można przetestować wysyłając maila na adres cokolwiek@twojadomena.xx, blablabla@twojadomena.xx itd. 🙂

W panelu Direct Admin wygląda to tak:

I konfiguracja przekierowania:

Jeżeli nie chcemy logować się na tak stworzoną pocztę „serwerową”, można ustawić także, aby wszystkie maile były przekierowane do używanej przez nas na co dzień skrzynki (np. Gmail).

 

SkładQA 2017 – jak było?

Jakiś czas temu, bo 20 marca 2017, udało mi się zajrzeć na tegoroczną edycję testerskiej konferencji SkładQA. O samej SkładQA pisałam przy okazji omawiania wiosennych wydarzeń w IT.

Zespół KraQA nie zawiódł i tym razem. Profesjonalne prowadzenie konferencji, świetnie wybrana lokalizacja (obszerna hala Starej Zajezdni, która pomieści naprawdę sporo osób), dobre zaplecze techniczne (nagłośnienie itd.), ciekawi prelegenci i przekrój  różnorodnych tematów. Organizatorzy to profesjonaliści i to widać.

Merytorycznie mogę odnieść się jedynie do trzech ostatnich prezentacji:

  • Marcin Żołna & Karol Pękała – How to become a cybersecurity hero. Z początku myślałam, że ta prezentacja skierowana jest raczej do początkujących. Ale na szczęście nie tylko. Wyniosłam z niej coś dla siebie – wymienione zostało narzędzie OWASP, któremu z pewnością przyjrzę się bliżej.
  • Wiktor Żołnowski – Pragmatyczny QA. Na którejś edycji Quality Excites miałam możliwość wysłuchania prelekcji Wiktora, kiedy jeszcze zajmował się wdrożeniami Agile. Tym razem zaprezentował model CYNEFIN. Nawet nie wiedziałam, że tak nazywa się ten diagram (o którym pisałam zresztą we wpisie Dla kogo Scrum?, lecz w formie dużo bardziej uproszczonej). Warto zatem chodzić na konferencje, zawsze można się czegoś ciekawego dowiedzieć:)
  • Michał Sajdak – Hackowanie aplikacji webowych na żywo – wybrane przypadki. Ta prezentacja totalnie mnie zachwyciła. Prawdziwy show. Niektóre „sztuczki” pobieżnie znałam z artykułów na Sekuraku czy Niebezpieczniku, ale zobaczenie jak to wygląda na żywo – naprawdę robi wrażenie.

Podsumowując, było to naprawdę dobrze spędzone, INSPIRUJĄCE popołudnie. Chcę więcej i polecam wszystkim:)

Dla kogo Scrum?

Niedawno podawałam garść ciekawych informacji na temat Scruma.

Często słyszy się, że ta metodologia pracy nie jest dla każdego zespołu. Pewnie tak. Na jednym ze szkoleń widziałam ciekawy wykres „obszarów złożoności pracy”:

complexity

  1. Simple – dziedzina dobrze znana – tu sprawdzają się tzw. najlepsze praktyki, zalecenia z poradników itd.
  2. Complicated – dziedzina znana, ale trudna. Sprawdzają się dobre praktyki, ogólne „zalecenia”.
  3. Complex – dziedzina bardzo złożona, nie można powiedzieć, czy dane działania odniosą sukces czy nie. Metodą pracy są głównie eksperymenty – właśnie tutaj najlepiej działa Scrum!
  4. Chaos.

I dodatkowo wykres uczenia się w zależności od złożoności problematyki:

complexity2

  1. Simple – continuous improvement. Wystarczy po prostu działać, powtarzać – uczenie się jest proste, bez większych problemów.
  2. Complicated – continuous improvement – powiedziałabym: wzloty i upadki.
  3. Complex – continuous adaptive – błądzenie jak we mgle 😉 Jeden eksperyment zbliży nas do rozwiązania, inny oddali. Pamiętajmy, że adaptacja leży w głównych założeniach Scruma 🙂

Jak odpakować plik tar.gz

Aby odpakować plik tar.gz, można spróbować komendy tar -zxvf, gdzie:

  • z – (zip), zdekompresuj
  • x – (extract), wypakuj na dysk
  • v – (verbose), bardziej szczegółowe logowanie
  • f – (file), odczytaj archiwum z pliku podanego w parametrze

Mój plik był jednak bardziej złośliwy:

d9k@Nihilia:~/folder$ tar -zxvf export.tar.gz
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Jak widać w przykładzie wyżej, pomimo że plik wygląda jak spakowane archiwum tar+gzip, wcale tak nie jest – komunikaty mówią, że plik nie jest w formacie gzip. Nie jest więc spakowany. Wystarczy zatem użyć samego tar -xvf:

d9k@Nihilia:~/folder$ tar -xvf export.tar.gz

Tym razem się udało i na dysku mamy odpakowane pliki.

Instalacja ROOT

ROOT jest biblioteką do analizy danych, statystyk, wizualizacji danych. Używany jest najczęściej w jednostkach naukowych (CERN, uczelnie itd.). Świetny opis instalacji tego frameworka znalazłam tu:
https://yannisflou.wordpress.com/2012/06/05/root-data-analysis-framework-on-ubuntu-12-04/.

Poniżej przedstawiam opis instalacji pod systemem Ubuntu 12.04, w języku polskim – dla absolutnych początkujących, nie znających systemu Linux.

  1. Download
    Ściągnęłam wersję ROOT 5.34/36 wybierając typ: „Source” na podstronie wersji: https://root.cern.ch/content/release-53436. (Po instalacji przedstawia się jako:
    v5-34-36@v5-34-36, Apr 05 2016, 10:25:45 on linuxx8664gcc)
  2. Rozpakowanie
    d9k@Nihilia:~$ cd rootSOURCE
    d9k@Nihilia:~/rootSOURCE$ gunzip root_v5.34.36.source.tar.gz
    d9k@Nihilia:~/rootSOURCE$ tar xvf root_v5.34.36.source.tar
    
  3. Miejsce docelowe instalacji
    ROOT-a installować będziemy w folderze /opt/ROOT/. Folder „opt” był używany niegdyś do instalowania oprogramowania niezwiązanego z systemem (coś jak windowsowe „Program files”). Obecnie zaleca się używać ścieżki /usr/local, w mojej instrukcji użyję jednak „starodawnych” rozwiązań :)Stworzenie folderu:

    d9k@Nihilia:~/rootSOURCE$ sudo mkdir /opt/ROOT/
    

    Stworzenie tymczasowej zmiennej globalnej (w następnych krokach „utrwalimy” ją, aby była dostępna także po zamknięciu tej sesji terminala):

    d9k@Nihilia:~/rootSOURCE$ export ROOTSYS=/opt/ROOT
    

    Możemy sprawdzić, czy się utworzyła:

    d9k@Nihilia:~/rootSOURCE$ echo $ROOTSYS
    /opt/ROOT
    

    Ok.

  4. Configure
    Configure to pierwszy krok instalacji. W skrócie Configure jest to skrypt, który na bazie podanych mu opcji (i zmiennych, uwarunkowań i zależności istniejących w systemie) tworzy plik Makefile, który z kolei zostanie użyty w kolejnych krokach.Można wyświetlić sobie helpa polecenia Configure – najlepiej zrzucając go do pliku, bo opcji konfiguracji ROOT-a jest ogólnie bardzo dużo. Instalować będziemy w opcjach domyślnych, wskazując jedynie miejsce instalacji.

    d9k@Nihilia:~/rootSOURCE$ cd root
    d9k@Nihilia:~/rootSOURCE/root$ ./configure --help > ../configure_help.txt
    

    I wywołanie samego polecenia – ze wskazaniem mu ścieżki, gdzie ROOT ma zostać zainstalowany:

    d9k@Nihilia:~/rootSOURCE/root$ ./configure --prefix=/opt/ROOT
    
  5. Make
    Wykonanie tego kroku trwało dość długo. Podczas tego etapu źródła są budowane za pomocą pliku Makefile, zawierającego instrukcje budowania.

    d9k@Nihilia:~/rootSOURCE/root$ make
    
  6. Make install
    Wreszcie ostatni krok. Na tym etapie skompilowany program jest kopiowany do miejsca docelowego (podanego w parametrze „prefix” na etapie konfiguracji).

    d9k@Nihilia:~/rootSOURCE/root$ sudo make install
    [sudo] password for d9k:
    ============================================================
    === ROOT BUILD SUCCESSFUL. ===
    === Run 'make install' now. ===
    ============================================================
    Installing binaries in /opt/ROOT/bin
    Installing libraries in /opt/ROOT/lib/root
    Installing headers in /opt/ROOT/include/root
    Installing /home/d9k/rootSOURCE/root/main/src/rmain.cxx in /opt/ROOT/include/root
    Installing cint/cint/include cint/cint/lib and cint/cint/stl in /opt/ROOT/lib/root/cint
    Installing icons in /opt/ROOT/share/root/icons
    Installing fonts in /opt/ROOT/share/root/fonts
    Installing misc docs in /opt/ROOT/share/doc/root
    Installing tutorials in /opt/ROOT/share/doc/root/tutorials
    Installing tests in /opt/ROOT/share/doc/root/test
    Installing macros in /opt/ROOT/share/root/macros
    Installing man(1) pages in /opt/ROOT/share/man/man1
    Installing config files in /etc/root
    Installing Autoconf macro in /opt/ROOT/share/aclocal
    Installing Emacs Lisp library in /opt/ROOT/share/emacs/site-lisp
    Installing GDML conversion scripts in /opt/ROOT/lib/root
    d9k@Nihilia:~/rootSOURCE/root$
    

    Udało się.

  7. Source
    Krok wymagany przez program ROOT – uruchomienie skryptu „thisroot.sh„, ustawiającego ścieżki używane przez program ROOT, takie jak $ROOTSYS, $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, $PATH, $LIBPATH i wiele innych. Jego treść można oczywiście podejrzeć dowolnym edytorem:

    d9k@Nihilia:~$ cat /opt/ROOT/bin/thisroot.sh
    

    Ok, czas na wykonanie tego skryptu:

    d9k@Nihilia:~$ source /opt/ROOT/bin/thisroot.sh
    
  8. Uruchomienie
    Nareszcie możemy uruchomić program ROOT:

    d9k@Nihilia:~$ root
    *******************************************
    * *
    * W E L C O M E to R O O T *
    * *
    * Version 5.34/36 5 April 2016 *
    * *
    * You are welcome to visit our Web site *
    * http://root.cern.ch *
    * *
    *******************************************ROOT 5.34/36 (v5-34-36@v5-34-36, Apr 05 2016, 10:25:45 on linuxx8664gcc)CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
    Type ? for help. Commands must be C++ statements.
    Enclose multiple statements between { }.
    root [0]
    
  9. Utrwalenie zmiennych
    Po wyłączeniu terminala, ustawiona w poprzednich punktach zmienna ROOTSYS zniknie. Można ją utrwalić.Jak czytamy w helpie Ubuntu:
    „A suitable file for environment variable settings that affect the system is /etc/environment.
    An alternative is to create a file for the purpose in the /etc/profile.d directory.”Modyfikujemy zatem plik:

     d9k@Nihilia:~$ sudo gedit /etc/environment
    

    Dodając na koniec:

    ROOTSYS="/opt/ROOT"
    

    Aby nie trzeba było za każdym włączeniem terminala uruchamiać na nowo skryptu thisroot, można ustawić, aby skrypt był uruchamiany przy starcie systemu:

    d9k@Nihilia:~$ sudo gedit .bashrc
    

    Na końcu dodając linijkę:

    source /opt/ROOT/bin/thisroot.sh
    
  10. Gotowe 🙂

Jeśli chcesz natomiast przeczytać, jak zainstalować moduł LHAPDF, pisałam o tym tutaj.