edd's blog

django, brak modelu w panelu administracyjnym.

2011-08-20T12:36:00.000-07:00

W celu nauczenia się django, pobrałem kilka ebooków z sieci i zacząłem naukę. Szybko się podirytowałem, bo pomimo, że robiłem wszystko jak trzeba, to model nie pojawiał się w panelu administracyjnym. Dopiero po konsulatacji ircowej na #django, dowiedziałem się, że najnowszych wersjach frameworka model rejestruje się inaczej aniżeli w starszych wersjach. Tak więc ZAMIAST :


# TAK NIE RÓB
class SomeModel(model.Models):
.... some code
    class Admin:
        pass

# TAK JEST OK :
W katalogu aplikacji (tam gdzie views, models, __init__, tests) tworzymy plik admin.py i tam rejestrujemy model.

from MOJA_APPKA.models import MY_MODEL
from django.contrib import admin
admin.site.register(MY_MODEL)

To bardzo mylące i frustrujące, a wszystkiemu winne nieaktualne (z 2008 roku SIC!) książki. Dlatego, rekomenduję oficjalną dokumentacja Django, może nie razi czytelnością ale za to jest aktualna jak diabli :)

link : https://docs.djangoproject.com/en/1.3/
do pobrania w pdf : http://media.readthedocs.org/pdf/django/1.3.X/django.pdf

django flatpages, No FlatPage matches the given query.

2011-08-15T06:45:00.000-07:00

Baaardzo irytujący problem który pojawia się podczas początków z django. Mianowicie, kiedy już dodamy flatpages do aplikacji:


INSTALLED_APPS = (

    # inne appy django

    'django.contrib.flatpages'

)

i dodamy Url'a który będzie tym zarządzał :


 (r'',include('django.contrib.flatpages.urls'))

Miej na uwadzę że podczas przeszukawania url.py django szuka pierwszego dopasowania, więc taki kwiatek jak ten na górze jest tylko w celach testowych i powinien być dodany na końcu tupli.

Kiedy, wszystko już powinno działać, dostawałem wciąż ten sam błąd :
No FlatPage matches the given query.

Problem rozwiązywałem pare godzin rozbebeszając django aż doszedłem to konkretnego rozwiązania. Mianowicie : w

settings.py jest pole :

SITE_ID = 2

Niczym okomentowane ale raczej samosiętłumaczące (sorki za nowomowę). Problem polega na tym, że podczas edytowania ustawień id w bazie danych może się zmienić (create after delete).


blog=# SELECT * from django_site;

 id |     domain     |   name    

----+----------------+-----------

  2 | 127.0.0.1:8000 | localhost

Trzeba uważać, żeby nie utracić tej spójności, wtedy wszystko będzie działać :)

ipython

2011-07-17T06:40:00.000-07:00

Kolejny post rozgrzewkowy z serii Cool-Tools. Często potrzeba nam konsoli pythonowej, żeby na szybko sprawdzić jakąś koncepcję - szybkie 10-20 linijek które naświetlą nam nasz problem. Domyślna konsola pythona nie jest zła, ale zawsze znajdzie się coś leszego. iPython jest odpowiedzią. Jego główną zaletą jest łatwy dostęp do dokumentacji i kolorowanie składni. Dodatkowo mamy numeracje wierszy, generalnie zalet jest wiele i to bardzo drobnych ale sumarycznie tworzą one super narzędzie <;

iTerm.

2011-07-16T18:22:00.001-07:00

Główną zaletą Mac Os jest połączenie zalet systemu Unixowego oraz Windows, swobodnie można korzystać z mediów, nie trzeba dbać o sterowniki, wszystko wygląda w porządku i działa w miare sprawnie. Jednocześnie mamy pełną kontrolę nad systemem poprzez powłokę bash, czy sh. Zasadniczo, jako, że korzystam z Linuxów już wiele lat, szybciej poruszam się poprzez basha niż findera i skróty klawiszowe, był jednak jeden problem.

Domyślna konsola w mac os jest dość słaba. Taby nazywają się albo bash albo ssh, nie można splitować okien, nie można sterować przezroczystością... ogólnie słabo. Tutaj z pomocą przychodzi iTerm a raczej iTerm2. Świetna aplikacja, która daje absolutnie wszystko co potrzebujemy. Bardzo polecam.

Migracja.

2011-07-09T12:53:00.000-07:00

Moje ostatnie wojaże na serwerze skończyły się omyłkowym usunięciem bloga (tak, rm -rf :<). Zamiast stawiać od zera WP postanowiłem przenieść się tutaj z racji tego, że blogger dba o brak spamu i ma fajne synchro z adsense oraz analytics.

No ale do rzeczy. Kto mnie zna, to wie, że dużo pisałem swojego czasu w php. Wydawało mi się, że ten język jest dobry do rozpoczęcia przygody z kodowaniem webowym. Nie miałem racji (: Php to wyjątkowo paskudny język i jedyny co przemawia za nim to prostota napisania HellU Łorda. Potem jest już tylko gorzej. Dlaczego? Problemem jest niemal wszystko. Ciężkie frameworki, nieskalowalne aplikacje, składnia ze średniowiecza, wydajność... Powodem dla którego takie serwisy jak nasza-klasa.pl czy allegro.pl używają php jest to, że nie opłaca się przepisywać całej aplikacji na nowy język, poza tym naprawde duże aplikacje są rozproszone na wiele usług i podejrzewam, że php służy tylko do frontendów i niczego więcej <:

Przekonano mnie natomiast do pythona. Na początku jak każdy kręciłem nosem na składnie, że wcięcia są obligatoryjne, że średników nie ma... i takie tam inne kretynizmy. Po 2 tygodniach, zrozumiałem czystość i przejrzystość tego języka. Jest po prostu cudowny i bardzo wydajny. Jego pełna obiektowość daje niesamowite możliwości i zapewnia super plastyczność kodu. Jest to chyba najszybszy w pełni obiektowy język. Dodatkowo posiada ficzery takie jak generatory czy dekoratory, które za pomocą kilku linijek załatwiają problemy które w javie (nie wspominając o php) były codziennością. Ponieważ chce usystematyzować swoją wiedzę o pythonie, będe tutaj wrzucał kody z komentarzami które będę uważał za najbardziej pythonicowe - znaczy się zgodne z filozofią pythona <:

Ale to nie koniec zmian, MySQL być może jest dobrą bazą danych, ale według moich mistrzów Zen nie sprawdza się w dużych projektach wymagających wysokiej dostępności. Pulling dostępy dla Postgre oraz rozbudowane możliwości funkcyjne pozwalają przerzucić niemal całą logikę aplikacji do bazy danych, co daje możliwość trybu Ultra-Turbo który zawstydza nawet samego Pana GóręCukrową. Tak więc programowanie baz danych czas zacząć! Przedemną długie wakacje dedykowane właśnie tym dwóm zagadnieniom. Keep it REAL!