Powoli zbliżam się do skończenia kodu więc pora zacząć coś na ten temat pisać. Na pewno posty te będą stanowiły mała motywację by jednak się zebrać i dokończyć te parę linijek kodu.

A więc dlaczego własny engine?

Krótka odpowiedź? Bo tak, dłuższa? Bo tak i już :)

A tak szczerze, na rynku dostępnych jest masa rozwiązań, które są już dojrzałe, mają set pluginów i są banalnie proste do postawienia, skonfigurowania i odpalenia. Czemu więc zdecydowałem się przejść na „własny” engine?

Sprawa rozbija się o .NET Blog Engine z którego korzystałem do tej pory. Jest on… no właśnie jaki jest to ludzie widzą. Nie powiem, że kod silnika jest zwalony czy co, bo jak się poczyta trochę kodu to wygląda on sensownie, ma ręce i nogi ale niestety jest overengineered (nie wspominając o innych blogach które stosowały DDD i zarządzanie 3 encjami przerodziło się w 10/20K linii kodu).

Na przykład wprowadzenie skórki, którą używam wymagało ode mnie parunastu zmian w różnych miejscach. Zmiany te wyszły mi swojego czasu jak wyszły – przykładem może być tag title w head, czy meta description. Szczerze mówiąc nie wiem na jakiej zasadzie on jest tam ustawiany i dlaczego jest tak. Czytając kod nie powinno się tak stać a to oznacza, że coś się dzieje gdzieś w kodzie i ja o tym nie wiem. Więc K lecą na silnik, choć możliwe, że to była moja wina.

Swojego czasu nawet chciałem to zaktualizować do najnowszej wersji, no i przejechałem się na tych swoich zmianach, nie pamiętałem co, gdzie i jak, a po zmianie na nowszy silnik, kod po prostu nie działał. Więc sprawę olałem.

Sprawdzałem kilka alternatyw, nawet postawiłem swojego czasu WP, ale z niewiadomych przyczyn, na moim serwerze (mój stary provider) czas ładowania strony WP potrafił przekroczyć 1 minutę (coś było nie tak z połączeniem do bazy).

dasBlog, subText, Orchid, Blogger, nBlog, nBlog z RavenDB, FunnelWeb, movableTypes i wiele, wiele innych – jakoś do mnie po prostu nie przemawiały.

Stwierdziłem, że nie chcę być uzależniony od silnika, którego nie rozumiem – może i nawet on działać zajebiście, ale ja chcę go rozumieć.

Dodatkowo, co chwilę do głowy wpadają mi coraz to kolejne pomysły – co mógłbym dodać, zrobić itp. Wykorzystując silnik osób trzecich jestem trochę ograniczony – PHP nie znam i nie chcę go poznać, .NET Blog Engine mimo iż udostępnia rozszerzenia to jednak rzeczy które chciałbym móc wprowadzić wymagają koordynacji pomiędzy kilkoma corowymi elementami silnika (po wstępnej analizie zobaczyłem, że musiałbym zmienić 3 corowe moduły by przetestować jedną funkcjonalność) itp. itd.

To były główne powody dla których zdecydowałem się na własny silnik (własny jak własny, ale o tym kiedy indziej).

Pomniejsze powody to nauka – tak, dobrze czytacie. Chciałem się czegoś nowego nauczyć a nie miałem pomysłu co z daną rzeczą zrobić więc blog okazał się najlepszym miejscem do tego. To co chciałem przetestować i sprawdzić jak działa to:

  • NoSQL – mam dość SQLowo podobnych baz
  • LESS
  • CoffeScript
  • WebSockets
  • Różnego rodzaju metadane strony

Do tego wiedziałem, że tak czy siak bloga wypada zmienić. Stąd też moja decyzja o napisaniu własnego silnika, który będzie dostępny jako OOS, ale nie będzie on silnikiem typowo blogowym (i za pewne pięknym). Zrobiłem kilka założeń które miały na celu ograniczenie funkcjonalności bloga, jak:

  • Tylko jeden użytkownik
  • Brak zarządzania stronami (content managment)
  • Brak zarządzania sekcjami/aside
  • themes

Jak chcę nową stronę dodać do bloga to mogę to zrobić normalnie – z palca. W ciągu ostatnich 5 lat nie dodałem żadnej strony więc raczej nie spodziewam się by to było jakimkolwiek problemem. Jeżeli jednak zacznie to być problemem to bez wysiłku dopiszę taką funkcjonalność.

Co do zarządzania sekcjami to znów, sekcje przeważnie pobierają jakieś dane skądś, zaś statyczne są po to by napisać je raz i przez N czasu nie zmieniać. Więc po co to implementować? Chcę sekcję, to sobie ją dodam.

Wielu użytkowników? Po jakiego grzyba :) piszę tylko ja. Komu mam dawać jeszcze prawa dostępu?

Mając do dyspozycji silnik nad którym panuje, jestem wstanie samemu zaimplementować funkcjonalność która mnie interesuje. Do tego jak coś nie działa to K będę mógł sypać jedynie na siebie – co jest już dużym plusem :)

Więc mój blog będzie moim poletkiem doświadczalnym – funkcjonalność będę dodawał z czasem lub nie będę w ogóle.

Plusem dodatkowym posiadania własnej implementacji jest to, że jak chce się UI zmienić to ma się dowolność – wiem, wiem, WP ma masę themes itp., ale szczerze? Żaden w pełni mi nie pasował. A płacić komuś za coś co i tak samemu będę przerabiał mi się po prostu nie chce :)

To chyba tyle na teraz, następnym razem będzie o dev stack a potem o trudnościach i K które mogły spowodować iż jednak walnę to wszystko i przejdę na WP :)

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

10 KOMENTARZE

  5. Popieram, niestety w moim przypadku wygladalo to tak ze chyba juz ze 3 razy zaczynalem pisac wlasny silnik, za kazdym razem z nowym, ze swiezym pomyslem. Do tej pory nie skonczylem zadnego :), a na google docsach zalega juz kilka postow ktore chcialem opublikowac.

  8. @gorczas

    najprostsze na jakie moglem wpasc – siedzisz sobie na blogu, dodajesz komentarz i dostajesz info zanim klikniesz wyslij ze nowy komentarz sie pojawil, albo dodajesz komentarz i Ci sie odswieza info o aktualnych komentarzach i liczbie komentarzy na stronie. albo przegladasz strone i dostajesz info, ze nowy post sie pojawil itp itd. nie chodzi mi tutaj o komunikacje klient->server a server->klient. Oczywiscie wszystko to za pomoca jakiegos long polling dalo by sie zalatwaic

Comments are closed.