Przypominamy, że ta wersja Django nie jest do produkcji lecz tylko dla testów!

O zmianach można przeczytać tutaj.

• Imię i Nazwisko
• O mnie/Zainteresowania
• Lokacja
• Data Urodzin
• Płeć

Znalazłem coś – dostałem nawet więcej niż oczekiwałem:

• Imię, Nazwisko
• O mnie
• Strona WWW
• Płeć
• Data urodzenia
• Lokacja (Integracja z Google Maps)
• Avatar
• Zmień Hasło/E-mail/Usuń profil

Jak widać całkiem ciekawa lista – nie wiem czego mógłbym jeszcze potrzebować.

Opiszę pokrótce jak uruchomić demo. Jest to wręcz „masakrycznie” proste.

Pobieramy aplikację – ja wziąłem wersję 0.6 z Downloadu. Wypakowujemy archiwum, przechodzimy do katalogu django-profile. Kopiujemy foldery media, userprofile do katalogu demo.  Teraz musimy zsynchronizować bazę danych, uruchamiamy.

manage.py syncdb

Tworzymy konto administratora, i wtedy już w stu procentach nasze demo działa. Możemy je uruchomić.

manage.py runserver

Uwaga!

Aby aplikacja działała poprawnie potrzebujesz biblioteki Gdata.

Instalacja:

Pobieramy najnowszą wersję. Wypakowujemy archiwum, przechodzimy do katalogu (cd w linii poleceń dla Windowsa) i uruchamiamy instalację.

setup.py install

Potrzebna jest również biblioteka Image (PIL).

Jak tego używać.

Aby zacząć używać tej aplikacji potrzebujemy bibliotek:

1. Python-Openid
2. Python-yadis
3. Python-oAuth

No i to właściwie wszystko. Klucze API można zdobyć stąd:

• Facebook
• Yahoo!
• Google
• Twitter

Klucze wpisz w pliku „localsettings.py” (uprzednio usuwając „.example” z nazwy pliku „localsettings.example.py”). Powinno wyglądać to mniej więcej tak:

TWITTER_CONSUMER_KEY = ‘LCpeKIvSJ9Zxowd3Dad29yQ’
TWITTER_CONSUMER_SECRET = ‘J0yLhHve94QgwJ7oyaRT38fFhezKz40RAh8yxdFAAw4′

FACEBOOK_API_KEY = ‘achdka5f46725f9f7201c79c67ca31a7′
FACEBOOK_API_SECRET = ’00945075d85e95fa310cc3ch82n96e4′

Aby wszystko działało musimy sprecyzować gdzie Django ma szukać naszego pliku koordynującego cały proces. Do pliku settings.py dodajemy:

from django.conf.global_settings import TEMPLATE_CONTEXT_PROCESSORS

TEMPLATE_CONTEXT_PROCESSORS = TEMPLATE_CONTEXT_PROCESSORS + (
    "mysite.blog.context_processors.latest_tweet",
)

TWITTER_USER = "djangoblog"
TWITTER_TIMEOUT = 3600

TWITTER_USER to nazwa użytkownika którego statusy będą pobierane, TWITTER_TIMEOUT to odstęp czasowy.

Teraz powinniśmy dodać definicję latest_tweet w context_processors.py, powinno wyglądać to mniej więcej tak:

from datetime import datetime
from django.conf import settings
from django.core.cache import cache
import twitter

def latest_tweet( request ):
    tweet = cache.get( 'tweet' )

    if tweet:
        return {"tweet": tweet}

    tweet = twitter.Api().GetUserTimeline( settings.TWITTER_USER )[0]
    tweet.date = datetime.strptime( tweet.created_at, "%a %b %d %H:%M:%S +0000 %Y" )
    cache.set( 'tweet', tweet, settings.TWITTER_TIMEOUT )

    return {"tweet": tweet}

Powyższy kod sprawdza cache, jeśli go nie ma pobiera statusy przez API. Następnie datę ostatniego Tweeta zmienia na bardziej ludzki format, zapisuje cache.

Teraz możemy wyświetlić tweeta:

<div id="tweet">
    {% if tweet %}
        <p>Ostatni tweet z dnia {{ tweet.date|naturalday }}: {{ tweet.text }}<p>
    {% endif %}
</div>

• Apache + mod_python
• SCGI + Cherokee
• Apache + mod_fcgid
• Lighttpd nginx/FastCGI

Przydatny jest również dostęp przez Shell.

Istnieje przydatna lista amerykańskich Django-Friendly serwerów którą znajdziemy tutaj. Mała również tutaj.  Istnieje też możliwość skorzystania z dobrodziejstw Google App-Engine, jest nawet mały kurs jak zacząć (przed postawieniem tam swojej strony polecam trochę poczytać).

Jesteśmy w trakcie tworzenia listy polskich dostawców hostingowych umożliwiających hosting aplikacji napisanych w Django, jeżeli znasz jakiś napisz do nas.

Jeżeli masz jakiś pomysł na notkę (np. czegoś potrzebujesz a nie umiesz tego zrobić) napisz do nas a my odpowiemy w formie posta na blogu (o ile tego będziesz chciał).

Jesteśmy na WordPressie więc teraz możemy dosłownie wszystko! Co prawda to nie jest Django ale po co pisać coś co już jest i do tego jest bardzo dobre.

Już niedługo ruszy Forum – pracujemy jeszcze nad skórką i szukamy moderatorów oraz administratora forum. Forum będzie stało na PHPBB3 – spróbujemy.

Mamy również konto na Blipie oraz Fun Club na FaceBook-u zapraszamy do obserwowania nas i do łączania.  Przypominam o kanale RSS oraz możliwości Subskrypcji przez E-Mail.

Mam też kilka pomysłów w zanadrzu więc już niedługo wielkie zmiany. Zapraszam do komentowania i subskrybowania naszego kanału RSS.

Po kolei.

Mam świadomość, że mogę zostać za to zlinczowany

Nie przeze mnie.

Każdy kto pierwszy raz zainstaluje django, uruchamia panel admina i zaczyna się rewelucja – jakie to łatwe i przyjemne. Django na podstawie modeli baz danych automatycznie generuje dobre panele administracyjne. Lecz dla mnie to za mało. Tworząc aplikacje Web2.0 panel administracyjny musi być ładny przejrzysty i podporządkowany użytkownikom. Czyli ikony, pomoce itp. W django stworzenie takiego panelu jest możliwe – tylko trzeba się dość namęczyć, i trzeba mieć dużo doświadczenia w tej technologii – oznacza to permanentne klepanie takich cudaków.

Prawda, większość tak myśli. Dostajemy od razu bezpieczny panel administracyjny, logowanie, dokumentację. Może nie ma takiego szczegółu jak ikonki – mi osobiście one by przeszkadzały. Wyobraź sobie ile musiałbyś spędzić pisząc panel administracyjny w PHP, logowanie, zarządzanie każdym działem po kolei, użytkownikami, forum, artykułami, newsami, galerią. A to wszystko tylko dla ikonek ? Nonsens.

Aktualne aplikacje muszą być nowoczesne i ładne, w pełni ajaxowe – panele django są na poziomie który był jakieś dwa lata temu. W permanentnie zmieniającym się środowisku - to już przeszłość. Także panel admina nie przekonał mnie.

Możesz sobie upiększa panel admina jak tylko zechcesz, przykładem jest plugin Django-Grappelli
(którego zresztą mam zamiar opisać w następnej notce). Ale szczerze ja nie potrzebuje ładnego panelu admina.

Znając wady i zalety – sqlAlchemy nie wywarł na mnie super wrażenia – to samo osiągam w doctrine/propel. W modelach nie ma zresztą wielkiej trudności – zależności i tyle.

W takim razie jesteśmy na 0. Skoro jest takie same jak doctrine/propel to dlaczego jest gorsze? Może czegoś nie zrozumiałem.

Lecz abym nie wyszedł kogoś kto się nie zna sqlAlchemy pozwala na budowanie relacji pomiędzy tabelami w innych bazach danych – a nie tylko tabelami w tej samej bazie – lecz z takim praktycznym rozwiązaniem się nie spotkałem. No ale jest i to jest ciekawe w tym – na poziomie akademickim oczywiście

Tutaj mały przykład:
Pobieram feedy z RSS’ów, trzymam je w bazie w postaci

Oraz wpisy:

i teraz nie muszę używać dwóch modeli żeby dowiedzieć się z jakiego są feeda dzięki czemu mam mniej kodu, a skrypt jest wydajniejszy.

Tutaj niekwestionowanym liderem jest python, z tego powodu że każdy kod kompresuje to bytecodu i dopiero wykonuje. W php takie coś nie istnieje. Powiedzmy sobie szczerze – tyle aplikacji jest php’owych i nie sądzę aby zwykły użytkownik widział różnicę w prędkości podczas korzystania ze strony/aplikacji napisanej w php czy python. Także ta szybkość pythona nie jest super praktyczna.

Nie zauważa…dlaczego ? A no bo w większości przypadków nie wie czy strona jest napisana w Pythonie czy w PHP, poza tym przeciętny użytkownik na to nie zwraca uwagi. Głównie chodzi tu o obciążenie serwera, Python generuje mniejsze.

Dokumentacja mnie nie przekonała bo końcowy użytkownik i tak nie zobaczy różnicy.

Nie zobaczy ? A co gdy wykorzystasz funkcje źle ? Gdy wyskoczy Ci masa błędów, ciężko będzie tego nie zauważyć.

Nie uważam aby w pythonie można było super więcej zarobić niż w php – wszystko zależy od tego co się tworzy i gdzie . Jeżeli ktoś jest dobry w programowaniu w języku X i ma otwarty umysł – bez problemu poradzi sobie z językiem Y. Ja od zawsze jestem zadowolony ze swoich zarobków – i na ich wysokość – nigdy nie wpłynęła umiejętność programowania w python – to nie argument. Ważniejsze jest „co” a nie „jak”.

Chodzi tutaj raczej o terminy. Aplikacja która będzie pisana w PHP 3 tygodnie w Django napisana zostanie w tydzień ? „Django – Framework webowy dla perfekcjonistów z terminami”.

No tutaj niestety, ale w php prędzej znajdziemy pracę Pomimo zajebistości pythona, rynek php się nie zmniejsza, z prostych powodów – programistą php można być po pół roku, a bycie programistą pythona na tym samym poziomie – zajmie troszkę więcej – także i kasy trzeba więcej zapłacić. Php jest popularniejszy i nie ma co się tutaj kłócić

Tutaj nie będę się kłócił, jak na razie łatwiej jest znaleźć programistę PHP lub zleceniodawce który woli PHP. Nie jest to dziwne, a powód – hosting, nic innego wg. mnie.

Po poznaniu języka python – emocje opadły. Czy to ruby (tego tez poznałem )

Wybacz ale tutaj wychodzi to, że chyba jednak mało poświęcasz na nowe języki. Po programowaniu w Pythonie 1 tydzień nie poznasz jego wszystkich zalet.

python to tylko inny język programowania, w którym tak samo jak w php należy napisać pętle, funkcje, modele, widoki itp.

No niestety, jakby robił to za nas język – programiści nie byliby potrzebni.

To chyba wszystko co bym chciał i mógł powiedzieć nt. Pythona i Django.