Mmm, to już było, to na mej psychice bardzo się odbiło, jak to śpiewał Liroy scyzoryk z Galicji. No ale co zrobić kiedy zmiany muszą nastąpić? :)
Ze względu na zbliżający się dużymi krokami limit dokumentów które za darmo mogę przechowywać w darmowych hostingu RavenDB (który aktualnie już nie istnieje, albo istnieje, ale w zmienionej formie i dopiero po zalogwaniu się), postanowiłem coś zmienić. Dokładniej to postanowiłem, że gdzieś za darmo dalej będę miał hosting RavenDB, ale tego się nie ustało mi zrobić niestety.
Także właśnie z tego powodu, stwierdzam, że popełniłem błąd stawiając bloga na RavenDB. Nie zależnie od tego jak fajną bazą jest Raven, hostowanie go samemu graniczy prawie z cudem. Próbowałem wszystkiego na co wpadłem:
- Embedded Mode – nie miałem jak tam wgrać istniejących danych
- Azure self hosting – taa, te bloby i nie bloby. Poległem, a może mi cierpliwości nie starczyło. Ale ogólnie, Azure to super sprawa, ale to kwestia tego jak i co trzeba było zrobić by można było mieć tam własny server RavenDB. Teraz jest… ale jest właśnie przez RavenDB HQ, z którego uciekam
- Płacenie za hosting – szczerze, po 2-3 ticketach by mi w końcu poprawne faktury wystawili zrezygnowałem. Oni fakturą nazywają napisanie na stronie: Invoice, RavenDB hosting: $15 – i to all. Szczerze to chyba był w ogóle błąd, że poszedłem na płatny, wydałem łącznie $180 w ciągu roku aż się wkurzyłem i przeszedłem na darmowy hosting do 1000 dokumentów (aktualny stan 992, z czego po przeczyszczeniu zostało 942 czy jakoś tak) i/lub 20mb (aktualnie 19mb)
Na pewno RavenDB ma swoje zastosowanie, ale dla mnie do bloga to była czysta porażka i przyznaje to teraz z wielkim bólem. Nie licząc, że aktualizacja paczek RavenDB parokrotnie rozwaliła mi całego bloga, gdyż były problemy z referencjami. Na przykład RavenDB wymagał biblioteki X w wersji Z, ale przy okazji biblioteki Y, która wymagała tej samej biblioteki X ale już w wersji Z+1. Ogólnie mały chaos.
Nie licząc tych problemów z RavenDB to uważam, że sama w sobie baza jest super i jest super wydajna, widać to było po moim starym blogu – działał imo bardzo szybko i sprawnie. Więc tutaj duuuże brawa dla Ayende.
Kolejną rzeczą która mnie drażniła to brak łatwego tworzenia nowych stron. Chciałem kilka rzeczy dodatkowo dodać a to wymagało otwarcia VS (i możliwe, że walki z nugetem), a to mnie już trochę odstraszało, na tyle, że nie napisałem nawet generycznej akcji która by mi renderowała dowolną stronę.
To co jednak uważam, że w moim blogu było zajebiste to CSS z którego jestem NIEZMIERNIE dumny bo sam go napisałem zarywając noce :) Aż szkoda mi się z nim rozstawać :)
Kilka dni temu zacząłem więc wszystko przenosić na Jekyll i Github pages. Dlaczego Jekyll? Bo szczerze jest zajebisty :) Bardzo podoba mi się idea generowania stron statycznych na podstawie danych po stronie serwera. Do tego prostota w tworzeniu szablonów i masa fajnych pluginów. A co najważniejsze, wiem, że mam bugi w artach, teraz by była prosta możliwość zrobienia mi pull request z poprawką :) ha! Jakie to by było zajebiste :)
Ale ok, by z migrować, musiałem iść pośrednio przez WordPress, jako, że naprawdę nie chciałoby mi się pisać exporterów do wielu formatów dla mojego bloga, a Wordrpess ma to już załatwione. Do tego Jekyll ma importera do WordPressa. Wszystko wydawało się takie piękne. Postawiłem WordPress na Azure w 5 minut, postawiłem Jekyll na macu (win oficjalnie nie jest wspierany) i do dzieła. Nie zupełnie.
By zainstalować Jekyll na macu… trzeba było się trochę na męczyć. W końcu naprawdę nie wiem jak to mi się udało. Zastosowałem jeden trick z StackOverflow który powiedział by zainstalować command toolsy od XCode. I to zadziałało. Mając Jekyll pora na instalację importera, done, a następnie na importera do WordPressa.
Oczywiście w komentarzu do pluginu znajduje się informacja, że na macu to może być kłopot, no ale co w tym trudnego. Ściągnąłem MySql, zacząłem go instalować do póki instalator nie krzyknął błędem, i że bym się skontaktował z producentem (WTF?). Na szczęście jakiś dobry człowiek napisał exporter z WordPressa do Jekyll który jakoś zadziałał.
Szczęśliwy mając już posty wyeksportowane następnego dnia zacząłem tworzyć UI. Mac został w domu, więc przerzedłem przez kroki instalowania Jekyll na windows (ten sposób działa). Ładnie wszystko sobie poukładałem, byłem już tak w połowie robienia UI kiedy stwierdziłem, że sprawdzę jak to działa na github pages bo lokalnie dobrze wygląda, a chciałem się spytać o opinie innych.
No i zaczęły się problemy. Po pierwsze jeden z pluginów (moim zdaniem najważniejszy) nie jest wspierany – chodzi o tagi. Ok, to jakoś przebolałem, bo wiem, że jest workaround. Ale za nic w świecie strona nie chciała i dalej nie chce mi się kompilować na github. Czytam by odpalić build z parametrem safe, to tak robię i to dalej mi śmiga na Windowsach.
Przychodzę do domu, wykonuje builda na macu a tutaj jakimiś błędami UTF-8 mi krzyczy. Sprawdzam, bug naprawiony w wersji 2.0.3 jekyll, moja wersja zainstalowana: 2.4, wersja githuba? 2.4 Acha…
W tym momencie dałem sobie spokój z Jekyll. Może kiedyś do niego wrócę, ale nie mam sił na łamanie sobie łepetyny problemami, które istnieją ale w zależności od platformy i co najlepsze, wersji ruby.
Zdecydowałem się więc na WordPress jako, że miałem go już postawionego ze wszystkimi postami, kwestia więc tylko jego konfiguracji i… theme. Z tymi themami to jakoś maksymalna porażka. Ok, rozumiem, są one tworzone dla prostych ludzi, ale serio, to DA SIĘ LEPIEJ ZROBIĆ. Niezależnie przez ile theme przeszedłem, skończyłem na jednym który kupiłem kilka miesięcy temu, a następnie spędziłem noc łatając bugi w nim – na mobile menu nie działało, by działało trzeba było ustawić primary menu (opcję), to spowodowało, że menu nie renderowało się na górze a na dole postu itp. itd. Ogólnie, mówię szczerze, masakra. A jak popatrzę na kod LESS to do głowy mi przychodzi tylko jedna myśl: po co ktoś stosuje LESS jak nie wykorzystuje żadnych zmiennych i mixminow i za każdym razem tak pisze wszystko od początku. Chyba po to by być trendi.
To co teraz widzicie to jest ostro zmodyfikowana wersja kupionego theme, ma ona swoje wady i bugi, jeżeli coś znajdziecie dajcie znać w komentarzu, postaram się pomniejsze rzeczy naprawić, jednak plan jest taki, że uciekam z tego theme jak najszybciej się da – jak tylko znajdę osobę chętną do zrobienia mi custom theme zgodnie z moimi wytycznymi (tak zapłacę za to, ale musi być zgodnie z wytycznymi).
No, ale dzięki tej migracji, zyskałem pewną swobodę. Jestem na platformie z której mogę wszystko wyeksportować do innych platform, mogę także zacząć rozszerzać blog o nowe strony o których już od dawna myślałem.
Więc pierwszy krok ku lepszemu jutra zrobiony :)
PS.: Próbowałem także ghost, świetnie działał, ale ma jeszcze mała drogę do przejścia by być przydatny dla mnie. Ale ogólnie, gdyby nie to, że brakowało mi dwóch/trzech funkcji które są w trakcie tworzenia to jak nie Jekyll to Ghost by był. Niestety, wylądowałem na WordPress ;)
PS2.: tak wiem, że można statyczne strony wrzucać na gihub pages i nie korzystać z generatora githubowego. Ale to w tym momencie trochę dla mnie mijało się z celem. Choć może jak nie znajdę nikogo chętnego do pomocy z theme na wordpress to tak właśnie zrobię i wykorzystam grunt build control (plugin do grunta) czy coś podobnego z gulpa i kod będzie szedł na github, a statyczna strona poprzez FTP na mój serwer. Zobaczymy.
PS3.: jak zwykle, miał być post krótki, informacyjny o zmianach a wyszedł rant :/ muszę nad tym popracować :)
Ładnie :) Przydałoby się jeszcze zadbać o stare URLe. Google ma poindeksowane artykuły pod starymi adresami i niektóre się nie zgadzają. Np. Google zna:
http://blog.gutek.pl/2013/09/30/will-code-objective-c-for-free-czyli-przygarni-gutka-do-projektu
a teraz jest:
http://blog.gutek.pl/2013/09/27/will-code-objective-c-for-free-czyli-przygarni-gutka-do-projektu/
albo dawne:
http://blog.gutek.pl/2014/06/16/co-to-jest-grunt-js-czesc-1
to teraz:
http://blog.gutek.pl/2014/06/15/co-to-jest-grunt-js-czesc-1/
Szkoda odnośników, które gdzieś w sieci mogą prowadzić do tych tekstów i szkoda wartości, jaką sobie strona wyrobiła w Google.
tego się obawiałem – postaram się coś z tym zrobić. Dzieki za info
nie mam zbytnio pomysla jak to naprawic inaczej niz recznie. Tak czy siak, wezme wszystkie linki z poprzednich postow (permalinks) i odpytam wordpress i zobaczymy ile tych bledow bedzie. To chyba jedyny “prosty” sposob jaki mi przychodzi do glowy oprocz czekania na google webmaster tools
A czemu nie zostałeś przy starym blogu, zmieniając bazę? Za dużo roboty?
@Artur
Tak, bardzo silnie polegalem na RavenDB. Zmiana tego, wymagala by przepisania 70/80% aplikacji plus przemyslania kilku rzeczy ekstra, ktore RavenDB daje Ci z miejsca jak caching.
Ale kto wie, kod nie znkinal, backup calosci jest do tego MovingScrewdriver blog engine jest na github wiec, moze kiedys ;)
Czyli przećwiczyłeś kilka opcji, żeby na końcu wybrać szambo pod tytułem WordPress? A teraz szukasz jelenia, który za Ciebie w tym szambie zanurkuje i na końcu wypluje działający szablonik.
Hmm… Chyba Procent się ostatnio chwalił, że robi pluginy do wordpressa w 5 minut. Październik się skończył, to może wyprawi skórkę dla Ciebie za flaszeczkę wódeczki. ;)
Przepraszam za głupi, sarkastyczny komentarz powyżej.
W ogóle cała historia jest strasznie smutna, wręcz wkurzająca! Musiałeś wpakować mnóstwo pracy na marne. Wychodzi na to, że RavenDB jest właściwie bezużyteczny, skoro tak ciężko jest go samodzielnie postawić. Aż trudno w to uwierzyć! Może jednak za szybko się poddałeś?
@Rafał
haha luz :) masz racje, szukam “jelenia” który za mnie wykona ciezka prace na ktora nie mam czasu ani ochoty. Polbiedy, ta sama osoba zostanie poproszona o przygotowanie takze szablonu graficznego uwaga (to chyba nawet gorsze niz wordpress) w pure css – tak naprwade to w sass albo w less, ale biedak bedzie sie musial 7 poty wypocic by to jakos wygladalo :( wspolczuje mu, ale co zrobic – ja za to zaplace :)
I tak, sadze ze wordpress mi nie pasi i jak uda mi sie w koncu wykabinowac dlaczego jekyll nie chce sie kompilowac pod mac to zrobie pewnie kolejna migracje. Dlaczego chce by sie kompilowalo pod maciem? bo w domu juz nie mam systemu operacyjnego windows. a posiadac bloga po to by moc jedynie publikowac posty bedac w pracy to troche slabe.
Co do RavenDB – nie, jest to go latwo “postawic” ale wymaga to osobnego serwera, a ow takiego nie posiadam. w Azure za to nie ma normalnego dostepu do plikow wiec trzeba pisac wrappery. Do tego i tak musisz postawic osobna isntacje Web Role – tutaj jest obawa, ze postawienie czegos takiego zeżre wszystkie “zasoby finansowe” jakie mam dostepne per month. A co za tym idzie bedzie to kolejna oplata ktorej chcialbym uniknac.
Postawienie zas Embedded RavendB na web hostingu normalnym wiaze sie z kilkoma problemami. Na przyklad uzytkownik na web hostingu musi miec uprawnienie do reading extended properties na dysku na ktorym jest hostowana strona (nie kazdy taka opcje daje – webio na przyklad daje). Ale by moc sie dostac do bazy by na przyklad przeprowadzic import export danych potrzebny jest dostep bezposredni, ktory to wymaga by na serwerze hostingowym dalo sie otworzyc odpowiednie porty. Zreszta nawet popelnil maly projekt ktory sprawdza czy to jest mozliwe: https://github.com/Gutek/embedded-raven-test (mozna sie bawic ustawieniami portow).
Hmm… Może w Azure trzeba to jako VM stawiać?
jako VM to za droga sprawa jak na cos co ma byc darmowego. chodzi o ograniczenie placenia za strony :) ale tak, na vm by sie udalo.
Comments are closed.