Pierwszym problemem na jaki natrafiłem w trakcie rozpoczynania prac nad blogiem to był problem hostingu – gdzie mogę go postawić i na czym i czy mi się to opłaca.

Od niego tak naprawdę uzależniłem wszystko inne. Ogólnie mam kilka domen ale wszystkie są hostowane na hostingach windowsowych – tak naprawdę per web app a nie per serwer. Czyli ja mam dostęp do IIS a nie do serwera. Czyli pewne rzeczy są czasami nie do przeskoczenia.

Mimo ogromnej chrapki na Node.JS i napisanie całego bloga w Node, stwierdziłem, że to mi się aktualnie nie opłaca, node wykorzystam gdzie indziej. Ze względu na ograniczenia i niechęć testowania pewnych obejść, decyzja padła dość szybko. Musi to być .NET i tyle.

Konstrukcja serwerów także spowodowała ograniczenie w doborze baz danych, pewnych rzeczy jednak nie da się przeskoczyć i jedynie RavenDB z Document DB umożliwia opcję embedded DB – to znaczy, że nie potrzebuje osobnego serwera by mieć bazę, baza jest zawarta w apkę, robię dep i mam all w jednym miejscu.

Mając tak narzucone środowisko pozostała jedynie decyzja: Nancy, Fubu czy MS MVC.

Z Fubu szybko zrezygnowałem – niezależnie jak fajne to może być, dla mnie StructureMap jest nie czytelne kompletnie, ot i tyle.

Nad Nancy się sporo zastanawiałem. Jest fajne, lekkie i kurna zajebiście się z nią pisze. Jednak tutaj wszedł kolejny constraint.

Ostatnio zaznaczałem własny engine kursywą lub brałem cudzysłowy. Dlaczego? Dlatego, że nie miałem zamiaru pisać od początku wszystkiego. Chciałem móc wziąć pewne części z jednego systemu, wkleić do drugiego, poprawić/dodać soją funkcjonalność i w ten sposób szybko zbudować sobie własny base. Nie chciałem marnować czasu na coś co już zostało wynalezione – w tym model danych.

I tu skoro już wiedziałem, że mam wykorzystać RavenDB, pojawił się Racoon Blog. Który cała strukturę ma już gotową – jest on wydajny, dobrze z optymalizowany oraz ma kilka ciekawych rozwiązań zaimplementowanych.

Zrobiłem mały search (naprawdę mały) i nie znalazłem nic w tej postaci dla Nancy. Więc to olałem i wykorzystałem MVC 4.

Czy żałuje, że nie wybrałem Nancy? Nie, dlatego iż chcę mieć bloga który będzie dawał mi możliwości jego rozszerzania i nie będzie on ograniczony przez jeszcze nie dostępną funkcjonalność. Dla Nancy znalazłem inne zastosowanie i jest ona z kolejkowana po Node.

Aktualnie więc, dla wersji 1.0 mój stack wygląda tak:

  • ASP.NET MVC 4 – w minimalnym stopniu
  • Autofac
  • xUnit
  • FakeItEasy
  • nLog
  • LESS – do css’ów, wraz z Web Essentials
  • Parsley.js – do walidacji formularzy (domyślnie od dwóch lat wywalam MVC validate plugin bo za dużo z nim problemów przy bardziej złożonych formularzach)
  • jQuery – wstępnie, ale zamierzam się tego pozbyć jeżeli będzie taka możliwość
  • BCrypt.NET – dlaczego? Warto przeczytać
  • BlogML – przerobiony na własne potrzeby by uwzględnić rzeczy nie zawarte w std. BlogML takie jak tagi czy też Trackbacks – plus pewne poprawki do blog engine .NET by pewne rzeczy jednak uwzględnić w eksporcie
  • RavenDB
  • Markdown Sharp – do komentarzy, możliwe że zmienię na MarkdownDeep
  • Akismet.NET – do walidacji komentarzy pod względem spamu
  • AutoMapper – miałem duże opory przednim, jak zwykle, ale tutaj się sprawdził – mapowanie modelu RavenDB do ViewModels itp.
  • XML-RPC.NET – bardzo przydatne przy zarówno MetaWeblog API jak i przy pingbacks

To co olałem to CoffeScript – dlaczego? Dlatego, że jednak nie lubię jak ktoś ingeruje w kod JS który piszę :)

Dla wersji 1.1 jest już przygotowany osoby stack, który może spowodować pewne zmiany w istniejącym, ale o tym będę pisał kiedy indziej.

Co do wszystkich głosów „Show me the code” – z chęcia :) ale nie teraz. Kod tak czy siak będzie dostępny bo tak wymaga licencja RavenDB. Aktualnie nie jest on dostępny gdyż wciąż nad nim prace trwają i wygląda on jak pole bitwy. Moja zasada jest prosta: napisz by działało, potem zrób tak by było to fajne.

Więc punkt jeden jest skończony, teraz robię to tak by to było fajne – i poprawne ;) czyli cały działający prototyp przerabiam na kod, który jest odpowiednio przetestowany co także powoduje, że cała arch się zmienia.

Ale już mam nadzieję niebawem, będę wstanie wszystko wam pokazać, muszę tylko wygospodarować około 5-10h czasu w nadchodzących dniach. No i musi mi się zachcieć :)

Jeżeli macie jakieś pytania dlaczego coś wybrałem a dlaczego nie, dajcie znać w komentarzach a postaram się udzielić bardziej dokładnej odpowiedzi.

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

7 KOMENTARZE

  1. Nieźle, nieźle, miło będzie po(d)patrzeć. :)

    A tak na serio to ten stack całkiem przyzwoity jest, bo sam bardzo podobny używam obecnie w dwóch dużych projektach (łącznie z RavenDB). :)

    Zamierzałem użyć jeszcze ServiceStack'a, ale w końcu olałem i wybrałem MVC4 Web Api oraz ASP.NET Web API Client Libraries (API będę konsumował z aplikacji desktopowej).

  3. @Procent

    wiesz czemu hosting? bo naprawde mi sie nie chce na pewnych rzeczach spedzac czas :) od stworzenia sol do pierwszego dep aplikacji – 2min. Nie musze tez sie meczyc z zadnymi przekierowaniami itp. wiec i konfiguracja bedzie szybszka. i tak, to dosc szybko zmienia moje nastawienie do brania na siebie kolejnej technologii ;)

    co do bcrypt – dzieki, wyczailem :) i odrazu wprowadzilem w zycie. co do alg, jasne, ale kurcze :) to jest tylko haslo do bloga :) i tylko dla jedneog uzytkownika :) ale ok, pewnie to zmienie dla jaj by sie pobawic :) haha

    co do TypeScript… mam do tego pewne zdanie. TypeScript nic mi nie daje – ok, da type check, ale po co mi to? swojego czasu dlugo sie nad tym zastanawialem. w ostatnich kilku aplikacjach mialem pare razy problem z typami i to tylko wtedy kiedy odczytywalem wartosci z pola tekstowego – czyli czegos co juz TS mi nie sprawdzi. Narazie po prostu nie widze zastosowania TS w projektach. Jak MSowi uda sie przewalczyc i wprowadzic do ECMAScript 6 elementy klass, dziedziczenia itp to bardzo szybko bedzie mozna przejsc na TS, jezeli zas nie wprowadzi to bedzie to tylko i wylacznie jezyk ktory powstal i mial ulatwic pisanie ludziom kodu JS – jak na przyklad sprawdzanie typow czy tez generowanie kodu extends dla klas. Dodatkowo by dobrze pisac w TS i tak musisz znac i rozumiec JS. a jak juz znasz i rozumiesz JS :) to zaczynasz sie zastanawiac po co masz korzystac z TS? Jedynym jego plusem jest support toolingu aktualnie. oczywiscie :) moim zdaniem :) ktore sie nie pokrywa pewnie ze zdaniami wielu ludzi w sieci :)

  4. Szkoda że bez CofeeScript albo TypeScript – marudzenie na ingerencje w JavaScript jest raczej kiepskie, bo na dobrą sprawę trzeba olać kompletnie tykanie JavaScript – tylko readonly ;->

  5. @niliphilus

    dlatego tez z nich nie korzystam ;) nie lubie readonly ;)

    do tego… na 25 linijek JS aktualnie naprawde nie potrzeba czegos wiecej ;)

  7. tak, jest warunek do spelnienia – kod musi byc open source.

    mail od ayende:

    If your project is OSS and is publicly available, yes.
    If that isn't the case, you need to purchase a license.

Comments are closed.