SQLite nie jest nowym projektem, jednak wraz ze wzrostem popularności aplikacji mobilnych zainteresowanie tą bazą także rośnie. Dzieje się tak dlatego, że najbardziej popularne platformy mobilne (Android i IOS) natywnie wspierają ten slinik.

SQLite nie bezpodstawnie ma opinię bardzo łatwej w użytkowaniu, wydajnej bazie danych.

Jeżeli potrzebujecie także do swojego projektu małej wbudowanej bazy danych to SQLite jest godny sprawdzenia. Zaczynamy:

1. Instalacja.

Wszystkie niezbędne pliki znajdziemy na stronie SQLite Download Page

MacOSX:
Nie trzeba nic instalować, SQLite już jest w systemie.

Linux:
Aby zainstalować w systemie Linux możemy skorzystać z linku powyżej aby pobrać odpowiedni plik, ale większość dystrybucji ma SQLite w swoich dystrybucjach gotowe do zaisntalowania. Np.:

/* Debian lub Ubuntu */
sudo apt-get install sqlite3 sqlite3-dev

/* RedHat, CentOS, Fedora */
yum install SQLite3 sqlite3-dev

Windows
Tu nie ma tak prostych metod jak powyższe. W przypadku tej platformy musimy skorzystać z powyższego linku, pobrać tam odpowiednie pliki i umieścić je w obrębie zmiennej PATH (lub też ustawić PATH aby wskazywało na folder z bazą). Niestety nie posiadam Windows nie więc dla bardziej szczegółowych instrukcji proszę udać się na stronę SQLite

2. Tworzymy pierwszą bazę

Gdy mamy zainstalowane pliki binarne SQLite jesteśmy gotowi do utworzenia swojej pierwszej bazy.

Aby utworzyć nową bazę nazwaną test.db wpisujemy w lini komend:

sqlite3 test.db

Aby teraz utworzyć tabelę w naszej bazie wpisujemy:

sqlite> create table firsttable(id integer primary key, value text);

Została utworzona tabla firsttable z dwoma kolumnami. Pierwsza id jako Klucz Główny która ma możliwość autogenerowania wartości, oraz druga kolumna value która przechowuje wartości tekstowe.

Musimy tu pamiętać o dwóch rzeczach:
1. Wszystkie komendy muszą kończyć się znakiem średnika ;
2. komendy systemowe zaczynają się od znaku kropki ., np. .help .quit
3. baza danych NIE zostanie zapisana na dysku dopóki nie utworzymy conajmniej jednej tablicy.

Czas na dodanie trochę danych do naszej tablicy:

sqlite> insert into firsttable(id, value) values(1, 'Stefan');
sqlite> insert into firsttable(id, value) values(2, 'Maria');
sqlite> insert into firsttable(value) values('Franek');
sqlite> insert into firsttable(value) values('Krysia');

Sprawdzamy czy wszystko się zapisało:

sqlite> select* from firsttable;
1|Stefan
2|Maria
3|Franek
4|Krysia

Nie do końca czytelnie, możemy trochę przeformatować wyświetlanie:

sqlite> .mode column

Wyświetli dane w postaci kolumnowej

sqlite> .header on

Pokaże nagłówki tabeli. Pamiętajmy jednak, że w przeciwieństwie do komend sql, komendy systemowe nie mogą kończyć się znakiem średnika ;
Pobieramy dane jeszcze raz:

sqlite> select * from firsttable;
id          value     
----------  ----------
1           Stefan    
2           Maria     
3           Franek    
4           Krysia 

Aby dodać dodatkową kolumnę do naszej tableli:

sqlite> alter table firsttable add column email text not null default '' collate nocase;

Dodaliśmy kolumnę email, która nie może mieć wartości NULL domyślnie pusty string, podczas sortowania wiekość znaków nie ma znaczenia.

Tworzenie widoków jest tak samo proste:

sqlite> create view firstview as select * from firsttable;

Tak samo proste jest tworzenie indeksów:

sqlite> create index first_idx on firsttable(value);

3. Kilka przydatnych komend systemowych:

Przede wszystkim .help chyba wiadomo po co ? ;)

Sprawdzenie struktury bazy:

sqlite> .schema

Albo struktury tabeli (lub widoku)

sqlite> .schema firsttable

Lista tablic i widoków:

sqlite> .tables

Lista indeksów:

sqlite> .indices

Export bazy danych do pliku SQL:

sqlite> .output nazwa_pliku.sql
sqlite> .dump
sqlite> .output sdtout

Import danych z pliku SQL:

sqlite> .read nazwa_pliku.sql

Export wyników zapytania do pliku CSV:

sqlite> .mode csv
sqlite> .output nazwa_pliku.csv
sqlite> select * from firsttable;
sqlite> .output stdout

Import danych z pliku CSV (dane rozdzielone przecinkiem) do tablicy:

sqlite> create table secondtable(id integer primary key, value text);
sqlite> .separator ,
sqlite> .import dane_w_pliku.csv secondtable;

Zrzut całej bazy:

/* Formuła: sqlite3 [nazwa_bazy] .dump > [nazwa_pliku] */
sqlite3 test.db .dump > backup.sql

Import całej bazy:

/* Formuła: sqlite3 [baza] < [plik] */
sqlite3 test.db < backup.sql

4. Koniec.

To tylko preludium możliwości tej małej bazy danych, mam nadzieję, że zachęciłem do używania.

O tym, że Vim jest moim ulubieńcem, wie chyba każdy kto tu zagląda. Mam dzisiaj nowy tips na temat jego działania. Edytor ten doskonale układa wcięcia w plikach. Jednak gdy pracujemy trochę dłużej na jednym pliku (np. html) to porządek we wcieciach może zostać nieco zachwiany.

Aby poprawić wcięcia w całym pliku musimy wykonać pewną sekwencję komend – nie ma jednej uniwersalnej komendy. Wpierw musimy przesunąć kursor do pierwszej linii, potem przeformatować tekst aż do ostatniej linijki, na koniec najlepiej by było aby kursor wrócił na ostatnią pozycję edytowania. Powyższa sekwencja wygląda tak: gg=Gg``

Jeżeli często korzystamy z tego to możemy ustawić jako macro i np. wpisać w .vimrc

map gg=Gg`` – Poprawiam plik po wciśnięciu Ctrl-G

W mojej obecnej pracy używam dwóch komputerów. Jednego w domu i drugiego w pracy. Z tego też powodu chciałbym mieć możliwość aby mój prywatny branch był w centralnym repozytorium jednak aby nie bałaganił kodu głównego. Za pomocą Git jest to możliwe i łatwe do wykonania.

Jest nawet kilka sposobów na wykonanie tej operacji,

Opiszę ten z nich, który używam i działa dla mnie wyśmienicie.

Przyjmijmy, że pracujemy już z kodem, lokalne i zdalne repozytoria są ustawione. W pierwszej kolejności tworzymy gałąź w zdalnym repozytorium, nazwijmy ją new_feature

git push origin origin:refs/heads/new_feature

To spowoduje skopiowanie zdalnej gałęzi master do nowoutworzonej new_feature

Sprawdzamy czy kod jest aktualny

git fetch origin

teraz na liście branch’y możemy znaleźć tą zdalną

git branch -r

na liście powinniśmy zobaczyć: origin/new_feature

Kopiowanie zdalnego branch’a do lokalnego repozytorium

git checkout --track -b new_feature origin/new_feature

Powyższa komenda utworzy nową gałąź new_feature która opiera się na zdalnej o tej samej nazwie. Dodatkowo lokalny branch będzie śledził ten zdalny.

Co to znaczy śledził?

To oznacza, że przy wykonywaniu komend bez argumentów push czy pull gałęzie te będą automatycznie się synchronizowały Git wie, że lokalny branch jest połączony ze zdalnym.

Ponownie sprawdzamy czy wszystko jest aktualne

git pull

I to wszystko

Kasowanie zdalnego branch’a

Gdy branch, którego wykorzystywaliśmy przestanie nam być potrzebny, możemy go usunąć:

git push origin :heads/new_feature

A co w przypadku gdy mamy skonfigurowany zdalny branch, ale ten lokalny go nie śledzi?

Możemy to zrobić ręcznie

git config branch.new_feature.remote new_feature
git config branch.new_feature.merge refs/heads/new_feature

git push

Może komuś się przyda

Gdy do tworzenia aplikacji używamy dowolnego frameworka zgodnego z wzorcem MVC, treść takich stron powinna być przechowywana w bazie a pobierana przez kontroler.

Innym rozwiązaniem jest napisanie oddzielnej metody dla każdej strony i treść umieszczać w odpowiednim widoku. Pracując z Play Framework można to zrobić o wiele prościej.

Przypuśćmy, że mamy aplikację która ma stronę „Regulamin” jako semistatyczna.

Treść regulaminu umieszczamy w pliku app/views/Pages/regulamin.html.

W routes wpisujemy:

GET     /pages/{pageName}                 Pages.show

Tworzymy kontroler Pages ze zdefiniowaną metodą show:

public class Pages extends Controller

    public static void show(String pageName){

        String filePath = String.format("app/views/Pages/%s.html", pageName);

        notFoundIfNull(Play.getVirtualFile(filePath));

        renderTemplate(filePath);

    }
}

Jak to działa? Nie wiem czy trzeba tłumaczyć, ale w kilku zdaniach: Gdy w przeglądarce wpiszemy adres /pages/costam zostaniemy przekierowani do metody show kontrolera Pages gdzie costam zostanie użyte jako parametr metody.

Kontroler wtedy szuka pliku costam.html w folderze app/views/Pages i gdy znajduje – wyświetla go, w przeciwnym razie wyrzuca błąd 404 Not Found.

where (:conditions)
having (:conditions)
select
group
order
limit
offset
joins
includes (:include)
lock
readonly
from

Natomiast zniknęły takie metody jak :

find(:all, :limit => 1)
find(:all)
find(:first)
first(:conditions => {:name => "Jaś"})
all(:joins => :products)

Metody, które najczęściej służyły do wyszukwiania w bazie rekordów nie zostały przeterminowane i dalej są dostępne w Rails 3

find(1)
find(1,2,3)

Nasuwa się pytanie, której metody powinniśmy używać? find czy where, przecież ten sam efekt uzyskamy gdy użyjemy:

Item.find(283746)

jak i:

Item.where(:id => 283746).first

Pomiędzy tymi dwoma formułkami jest jedna subtelna różnica, w przypadku gdy szukamy rekordu, którego nie ma w bazie, użycie where zwróci nam nil. Użycie find natomiast rzuci błąd ActiveRecord::RecordNotFound i przerwie wykonywanie dalszego kodu. Jeżeli tego błędu nie wyłapiemy to pojawi się nam wspaniały stacktrace na ekranie.

Miejmy to na uwadze.

Przyznam szczerze, czekałem z niecierpliwością na to wydanie. Pierwsza edycja miała bardzo dobre recenzje więc mogłem się domyślić czego się spodziewać. Czekałem także z tej przyczyny, że książka ta jest jedną z nielicznych typu Reference Book. Większość pozycji omawiających Rails 3 czy rails 2 to książki tutorialowe, gdzie wykonujemy poszczególne zadania przez całą książkę a na koniec otrzymujemy gotową aplikację. W tej książce jest inaczej.

Rails 3 Way opisuje dokładnie framework Rails 3. W kolejnych rozdziałach poznajemy poszczególne jego elementy. Na początku autor opisuje Bundler i zasadę uruchamiania aplikacji. Znajdujemy tu opis poszczególnych elementów startowych – application.rb, pliki konfiguracji środowisk, initializery itp. Poznajemy routing i zasady działania kontrolerów wraz ze sposobem działania filtrów. Dokładnie opisane modele – przeczytamy jak działa relacja Modelu z bazą danych, cykl życia modelu i callbacki. Można przeczytać o migracjach i konfiguracji kilku baz danych. Opisane są także Observery i walidatory. Nauczymy się także tworzyć własny walidator dla modeli. Następnie znajdziemy opisy Mailerów i poznamy jak konfigurować połączenie naszej aplikacji z kontem pocztowym. Nauczymy się jak wysyłać i odbierać maile. Ajax i zarządzanie sesją także znalazły tutaj swoje miejsce. Opisane także są widoki i layouty, jak z nich korzystać, jakie są relacje pomiędzy widokiem i kontolerem. Znajdziemy tu także opis Helperów. Fajnie jest opisany sposób na Cacheowanie aplikacji i jak ją rozszerzać za pomocą pluginów.

Co więcej, autor także postarał się opisać elementy, które nie są bezpośrednio związane z railsami, ale tworzenie webaplikacji bez nich się nie obejdzie. Przykładem jest tu autoryzacja – sam framework nie posiada narzędzi autoryzujących sam w sobie. Musimy skorzystać z oddzielnych gemów. Autor opisuje w książce dwa najpopularniejsze: Authlogic i Devise.

Oprócz gemów do autoryzacji autor pokusił się także o opisanie gemów do wykonywania zadań w tle i gemów do uploadu plików. Jeden rozdział został także poświęcony RSpec jako alternatywy dla TestUnit.

Na końcu jest opis API, przynajmniej jego najważniejszych elementów.

Zawartość książki opisuje zatem każdy z elementów powstawania aplikacji. Znalazłem tutaj nawet kilka rzeczy, o których nie miałem pojęcia.

Szczerzę polecam tą książkę każdemu, zarówno początkującym programistom jak i bardziej zaawansowanym. Przeczytanie tej książki pozwoli nam na zrozumienie „jak to właściewie działa”. Fajnie jest ją mieć pod ręką. Jak będziemy chcieli kiedyś przypomnieć sobie dany element wystarczy po nią sięgnąć.

Miłej lektury.

Dzisiejszym artykułem rozpocznę nową, krótką serię mającą na celu przedstawienie naważniejszych moim zdaniem pluginów do edytora Vim.

Pierwszym z nich jest surround Plugin ten skupia się na jednej funkcjonalności: otaczanie (surrounding). Pisząc kod niejednokrotnie otaczamy (fatalnie to brzmi :) ) swój kod. Otaczamy wyrazy cudzysłowami, nawiasami, klamrami albo tagami. Surround dba o wszystkie te aspekty. Możemy bardzo łatwo nimi manipulować.

Surround działa przeważnie w trybie komend chociaż w trybie wizualnym też dodaje kilka funkcjonalności. Jego podstawową zaletą jest bardzo zwięzła składnia, posiada tylko kilka komend, których odpowiednia kombinacja wykonuje tą magiczną robotę

• s – podstawowa komenda: oznacza sorround
• c – modyfikator surrounda oznaczający zmianę
• y – modyfikator surrounda oznaczający wprowadzanie
• d – modyfikator surrounda oznaczający usuwanie
• t – oznacza tag używany w plikach html/xml

to wszystko do tego dochodzi znajomość selektorów i czasem użycie trybu wizualnego: v

• v – tryb wizualny
• p – selektor paragrafu
• w – selektor słowa

Przykłady

Kursor generalnie może być w obrębie otaczanego fragmentu więc nie trzeba się restrykcyjnie trzymać zgodnie z naszym przykładem (W przykładach kursor oznaczamy |). Pierwsze komendy postaram się łopatologicznie rozłożyć na części pierwsze.

Zacznijmy od początku – mamy proste zdanie Surround jest super i chcemy pierwszy wyraz (Surround) otoczyć cudzysłowem. Skoro chcemy dodać to używamy y potem s jako klucz i selektor (iw) na koniec czym czym chcemy otoczyć („)

Surr|ound is super
ysiw"
"Surround" is super

yh, Chyba miał być pojedyńczy cudzysłów…. musimy to zmienić. c Zmiana, s – klucz, selektor już nie potrzebny (bo plugin sam odnajdzie oataczającą parę znaków) i co chcemy zmienić („) na co (‘)

"Surr|ound" is super
sc"'
'Surround' is super

a właściwie po co on wogóle, usuwamy cudzysłowy

'Surro|und' is super
ds'
Surround is super

i wracamy do stanu początkowego. Właściwie to cała wiedza, którą musimy znać. Kwestia tylko doboru selektora i znakdu otaczającego. Możemy wybrać dowolny: ", ', (,[, { , <p>

Dla łatwego zapamiętania

• dst – delete selected tag
• cst – change selected tag

Nieparzyste

Nieparzyste znaki to takie, które są inne na początku i na końcu, dobrym przykładem są tagi HTML/XML. Otaczając tekst tagiem zostaje on automatycznie zamknięty na końcu.

Surround
ysiw<b>
<b>Surround</b>
cst<p>
<p>Surround</p>
cst<p class="highlight">
<p class="highlight">Surround</p>

Innym przykładem są znaki nawiasów, klamer itp. Generalną zasadą jest to, że możemy użyć znaku otwierającego lub zamykającego. Różnica jest taka, że w przypadku użycia znaku zamykającego zostanie dodana dodatkowa spacja.

Surround
ysiw(
( Surround )

lub

Surround
ysiw)
(Surround)

Tryb wizualny

Surround dodaje trochę funkcjonalności także w trybie wizualnym Możemy w tym trybie zaznaczyć fragment tekstu, wcisnąć s i dodać czym chcemy otaczać.

Surround jest super
Vs<p>
<p>Surround jest super</p>

Ostanią czynnością, którą warto wspomnieć jest zaznaczanie za pomocą surround. Otóż w trybie wizualnym możemy zaznaczyć tekst zgodnie z symbolami otaczającymi. Dodatkowo mamy wybór czy zaznaczamy tekst wewnątrz tych znaków czy też razem z nimi. Gdy chcemy zaznaczyć tekst wewnątrz używamy i (inner) natomiast na zewnątrz – a (around)

symbol | oznacza pozycję kursora

<p> Najlepszym pluginem do Vim jest <b>Suror|und</b> (Tim Pope)</p>
vitcSurround
<p> Najlepszym pluginem do Vim jest <b>Surround</b> (Tim Pope)</p>

v – wejście w tryb wizualnym i – wybór aby zaznaczało wewnątrz t – wybieramy w obrębie tagu c – zaznaczenie zmieniamy na Surround

<p> Najlepszym pluginem do Vim jest <b>Surround</b> (Tim |Pope)</p>
va(d
<p> Najlepszym pluginem do Vim jest <b>Surround</b> </p>

Zakończenie

Warto używać surround, bardzo warto nawet nie wiecie jak szybko idzie się do tego pluginu przyzwyczaić. Polecam korzystać.

#!/bin/bash

rvm use ruby-1.9.2-p180@moj_gemset
rvm info | grep gemset

wynik:
# Using (...snip...)/gems/ruby-1.9.2-p180@moj_gemset
# gemset:   ""

Czyli pokazuje, że przełączyło na odpowiedni gemset jednak następna komenda już jest wykonywana poza nim.

Mieliście coś takiego?

Otóż przyczyną takiego zachowania jest to, że RVM może działać w dwóch trybach: binarnie lub skryptowo.

Tryb binarny wykorzystany w skryptach nie potrafi zmienić zmiennych powłoki a skryptowy tak, z tego powodu występują takie problemy.

Jeżeli zatem chcemy użyć RVM w naszym skrypcie powinniśmy dopisać gdzieś na początku coś takiego:

if [[ -s "/usr/local/rvm/scripts/rvm" ]] ; then
  source "/usr/local/rvm/scripts/rvm"
fi

# mam zainstalowane RVM globalnie w /usr/local/rvm
# jeżeli używamy normalnie to skryptu trzeba szukać w ~/.rvm/scripts/rvm

Od dzisiaj miną problemy z RVM wykorzystywanym w skryptach :)

Nie wierzyłem… do dzisiaj. Podczas pracy z ostatnim projektem kod został rozdzielony na dwie części aby móc opracować anglojęzyczną wersję. Po kilkudniowej przerwie miałem podjąć się tego zadania i znalazłem wyodrębniony kod we wszystkomówiącej nazwie gałęzi „Polish” :)

Na szczęście git umożliwia zmianę nazwy gałęzi bez niepotrzebnej kompromitacji i tłumaczenia przed szefem ;)

git branch -m obecna_nazwa nowa_nazwa

Co jednak ze zdalnym repozytorium?

To już nie jest sparawa aż tak prosta. Nie idzie zmienić nazwy zdalnego repozytorium jedną komendą. Najprostrzym sposobem jest usunięcie gałęzi pod złą nazwą i opublikowanie pod nową nazwą.

git push origin :stara_nazwa
git push origin nowa_nazwa

Czasami jednak dochodzi do sytuacji gdzie chcemy zmienić nazwę gałęzi master. Na przykład zmienić nazwę na master-old. Zarówno zdalnie jak i lokalnie. Co wtedy?

# zmiana nazwy lokalnie
git branch -m master master-old
# usunięcie zdalnej gałęzi master
git push remote :master
# stworzenie master-old na zdalnym repozytorium
git push remote master-old
# stworzenie nowego lokalnego master
git checkout -b master galaz_z_ktorej_tworzymy_mater
# tworzymy master w zdalnym repozytorium
git push remote master

Wiele tekstów wyświetlanych zarówno w widokach jak i w wysyłanych wiadomościach email są ‘hardcoded’ – czyli na sztywno umieszczone w miejscach, które utrudniają ich edycję.

Kilka dni temu na światło dzienne wyszła nowa wersja tego gema oznaczona numerem 1.2, która po części naprawiła powyższe problemy. Jednocześnie jednak stworzyła kilka kolejnych.

Udało mi się uzupełnić stare tłumaczenia o nowe i umieściłem całość w tym miejscu.

Nowy problem

Domyślnie w Devise, gdy rejestrujemy się w systemie, to automatycznie zostajemy do niego zalogowani. Chyba, że w opcjach mamy ustawiony obowiązek aktywacji konta poprzez email. W takiej sytuacji nowa wersja wyświetla nam komunikat: „Rejestracja zakończyła się pomyślnie. Nie zostałeś jednak zalogowany ponieważ konto jest %{reason}.”

No właśnie czym jest ten reason?

Reason jak łatwo się domyśleć jest powodem dlaczego nie zostaliśmy zalogowani automatycznie. Domyślnie, gdy nie aktywujemy konta to reason jest równe „unconfirmed”.

Niestety komunikat o treści: „Rejestracja zakończyła się pomyślnie. Nie zostałeś jednak zalogowany ponieważ konto jest unconfirmed.” nie brzmi zbyt dobrze. Próbowałem kilku sposobów umieszczenia tłumaczenia w pliku polonizacyjnym, zawsze w innym miejscu jednak ciągle kończyło się to fiaskiem.

Jak zatem uzyskać ładne tłumaczenie? Znalazłem winowajcę w module Confirmable. Otóż jest tam metoda inactive_message, która jest wywoływana gdy musi umieścić coś w treści podanej wyżej wiadomości jako reason.

    def inactive_message
       !confirmed? ? :unconfirmed : super
    end

Zwracany symbol jest zamieniany na string i umieszczany w treści wiadomości.

Jeżeli zatem chcemy cieszyć się ładnym, w pełni polskim komunikatem to musimy albo skorzystać z monkey patching tej metody, albo zmienić komunikat wiadomości w pliku polonizującym tak aby nie używał %{reason}.

Ja skorzystałem z pierwszego sposobu i gdzieś w initializatorach umieściłem kawałek kodu:

module Devise
  module Models
    module Confirmable

      def inactive_message
        !confirmed? ? "niekatywne" : super
      end

    end
  end
end

Działać – działa. Jednak czy monkey patching jest odpowiednim sposobem na coś tak prostego?