Posts Tagged django
Hosting idealny (php, postgreSQL, django, shell)?
Wydaje mi się, że znalazłem dla siebie hosting idealny. Serio, to chyba najlepszy polski hosting za rozsądną cenę. Jakiś czas temu szukałem takiego, który dałby mi przynajmniej dostęp przez ssh do plików.
Wiele jest takich, które dają sftp, ale to trochę mało. Po wielu godzinach poszukiwań znalazłem.
Otóż, Panie i Panowie! Najlepszym hostingiem w Polsce jest …
tutududu…
moim zdaniem oczywiście
VIPServ.org
(zaczynając od pakietu VIP2008). Wymienię listę wspaniałych rzeczy, które oferuje za cenę 9,99zł/miesiąc, oprócz podstaw takich jak php, mysql
- dostęp do konta przez SSH (z uwagi na zdarzające się programowanie w plenerze korzystając z publicznych hotspotów – dobrze choć zaszyfrować hasło
)
- zainstalowany SVN i zintegrowany z nim bugtracker TRAC
- możliwość opłacania konta nawet na jeden dzień! (nie wiążesz się na cały rok)
- baza danych postgreSQL i sqlite3
- DJANGO!!!
And last but not least
- wspaniała obsługa techniczna!
Jak ta obsługa techniczna wygląda? Otóż w momencie kiedy przeglądałem ich ofertę nie było mowy o pythonie czy django. Dlatego wysłałem zapytanie i po równie krótkiej co przyjemnej wymianie maili – django zostało doinstalowane
. Po niewielkiej współpracy z adminem udało się przezwyciężyć problem ze współpracą django z sqlite i wszystko śmiga
Pewnie jest jeszcze kilka szczegółów, które trzeba będzie dopracować. Ale powiedzcie mi:
CZY WASZ HOSTING TO POTRAFI?
Podsumowując: VIPServ.org daje Ci dużą elastyczność przy niewygórowanych opłatach.
Będę teraz prywatnie używał go przez jakiś czas. Jeśli okaże się równie niezawodny co elastyczny – będę go z przyjemnością polecał klientom. Wam już teraz polecam do przetestowania (5dniowy okres próbny + możliwość zapłacenia za na przykład miesiąc).
Od dzisiaj do prywatnych projektów będę używał tylko tego
Czego brakuje frameworkowi cakePHP?
Jakiś czas temu zetknąłem się z frameworkiem Django dla języka Python. Oprócz samego języka, który jest zdecydowanie bardziej nowoczesny w Django szczególnie urzekła mnie jedna rzecz.
Chodzi o sposób definiowania struktury dla bazy danych. Otóż w Django odbywa się to tylko w jednym miejscu – w plikach modeli.
Dlaczego jest to takie fajne? Posłużę się antyprzykładem z cakePHP.
Wyobraź sobie, że masz projekt i zarządzasz jego wersjami za pomocą popularnego SVN, czy CVS. Najczęściej pracujesz na lokalu i we wczesnych fazach projektu to dodasz pole w bazie danych w jakimś miejscu, do zmienisz indeks. Robisz commit kodu, który na nowej strukturze działa dobrze, ale struktura bazy danych nie podlega wersjonowaniu.
Zatem albo musisz zrobić eksport struktury do pliku który jest wersjonowany, albo (jak często odbywa się to w moich projektach) – robisz zmiany na pewnej głównej i ogólno dostępnej bazie (co by reszta mogła sobie ściągnąć nową wersję).
Pierwsze rozwiązanie sprawia, że przybywa Ci pracy. Wiem, że to nie dużo, ale zawsze jedna dodatkowa rzecz o której musisz pamiętać. A w przypadku gdy commit zrobiłeś po tygodniu pracy, bo wcześniej cały system się sypał – możesz zapomnieć o takich szczegółach jak dodanie pola na początku.
W przypadku jest jeszcze gorzej. Oprócz problemów opisanych powyżej dochodzi niebezpieczeństwo usunięcia całej bazy, brak możliwości powrotu z bazą do wcześniejszej wersji.
Z kolei w django możesz zapomnieć o phpMyAdminie i innych. Całą strukturę bazy danych masz zdefiniowaną w modelu i jednym poleceniem synchronizujesz jej wersję w silniku bazy z definicją w modelu.
Oczywiście do podejścia trzeba się przyzwyczaić. W cake’u trzymając się konwencji wszystkie modele mogą wyglądać tak:
class TabelaWFormieLiczbyPojedynczej extends AppModel {};
W django – to co nie istnieje w modelu – nie istnieje w bazie.
Ciekaw tylko jestem jak to się sprawdza przy nietypowych sytuacjach, które nieraz wymagają nieco karkołomnych konstrukcji w projekcie bazy danych i specyficznych zapytań sql. Moja znajomość samego Django jest na ten moment za mała, żeby odpowiedzieć na to pytanie.