Może drogus nam coś więcej opowie ?
Wyręcze trochę Piotrka, bo nie dadzą mu ludzie spokoju ;). Też przyłożyłem do tego projektu ręce 
Piotrek dużo ze mną projektował, bo wbrew pozorom system jest dość skomplikowany, ale sam tworzył głównie te części, do których używamy sproutcore’a. Część dostępna dla użytkowników jest bardzo prosta i to tylko mniejszy kawałek aplikacji. Pod spodem jest dużo ciekawiej. Na początku, jeszcze w fazie projektowania, myśleliśmy, że podstawowa funkcjonalność będzie bardzo prosta w implementacji, ale szybko okazało się, jak bardzo złożone mogą być przypadki użycia, jeśli chodzi o obsługę takiego systemu przez restaurację.
Krzyżyk na drogę, jeśli ktoś chce napisać coś takiego bez porozumienia z kilkoma różnymi restauracjami, które mają dobrze ogarnięty proces (my mieliśmy to szczęście pracować z kilkoma fajnymi restauracjami, a najbardziej pomocni okazali się managerzy Blue Cactusa).
Na sieci jest wywiad, w którym można znaleźć wypowiedzi na temat kilku istotnych kwestii:
http://blog.kurasinski.com/2011/07/stoliczku-pl-kuchenna-rewolucja-w-polskim-internecie/
Nie wiem co więcej możnaby powiedzieć ;). Jeśli padną jakieś konkretne pytania, to spróbuję na nie odpowiedzieć (również konkretnie :).
Wchodźcie, rezerwujcie. Na razie niestety jest mały wybór, ale “dział handlowy” naprawdę mocno pracuje nad tym, żeby jak najwięcej dobrych restauracji do nas trafiło :>
Tak z ciekawości: Jaka wersja rails, haml vs erb, formtastic vs simple_form, sql vs nosql vs …, test unit vs rspec vs cucumber vs bbq, wielkość zespołu sprzedażowego vs wielkość zespołu developerskiego (z uwzględnieniem grafików na kontraktach itp). Planujecie zdobywać miasto po mieście czy od razu szukacie w całej polsce potencjalnych klientów.
Ja bym chętnie się zapisał na powiadomienie kiedy pojawią się restauracje w danym mieście. Zapisałem się na powiadomienie o starcie serwisu, wszedłem, zobaczyłem że nie ma Wrocławia i nic mnie już tam nie trzyma. Gdyby była opcja, bym mógł zapisać się na powiadomienie o miejscach we Wrocku to znów by mi to w odpowiednim momencie (kiedy tam dotrzecie) przypomniało o serwisie. No ale zdaję sobię sprawę, że to bardzo niszowe potrzeby geeka i pewnie lepiej się skupić na innych rzeczach.
No i coś na co nigdy nie ma czasu bo są bardziej priorytetowe zadania: http://stoliczku.pl/is_this_rails_app => poprawcie stronę błędu w appce 
To po kolei
- Rails - to jest najlepsza część - jechaliśmy na 3.1 od samego początku. Mieliśmy nadzieję, że przed wypuszczeniem, wyjdzie coś stabilnego :> Było parę fakapów po drodze, ale dało radę. Piotrek ma commit access do railsów, więc stwierdziliśmy, że jak coś będzie nie tak, to się poprawi
- haml - były długie dyskusje, ale Piotrek dał mi wolną rękę (on rzadko tego dotyka, a ja lubię hamla
- simple_form - ja nigdy nie używałem formtastica, ale z perspektywy czasu chyba wybralibyśmy formtastica. Simple form jest fajne, dopóki nie natrafi się na kilka edge caseów o których się nie pomyślało.
- Testy mamy w rspec + steak. Cucumber to z mojego punktu widzenia porażka, jeśli testy nie mają znaczenia biznesowego. Niektórzy piszą scenariusze z klientami i na tej podstawie robią kod. Nie chcę flejma robić, ale dla mnie pisanie po angielsku nie jest w tym wypadku łatwiejsze od pisania w kodzie, skoro i tak w każdym bardziej skomplikowanym kroku muszę pisać kod Taka moja subiektywna opinia
- Używamy sproutcore’a w panelu restauracji, jedziemy na najnowszej wersji (release jakoś teraz jest na dniach). O tym więcej Piotrek może napisać :).
Jeżeli chodzi o podział handel vs kod, to jest to mniej więcej wyważone Piotrek pisał w wywiadzie o planach - chcemy przyciagnąć jak najwięcej restauracji, niekoniecznie z Warszawy. Zaczęliśmy tu z oczywistych technicznych przyczyn. Mamy to szczęście pracować z Olą Lazar, dzięki czemu ja sobie nie zaprzątam głowy marketingiem - skupiam się na pisaniu ;).
Co do braku restauracji w innych miastach - z każdą restauracją musimy najpierw porozmawiać, bo dajemy im system do obsługi rezerwacji. Dlatego nie możemy tak jak niektóre serwisy, wrzucić tysięcy restauracji i wszędzie podkreślać, jak dużo ich mamy, a po drugiej stronie kabla posadzić kogoś, kto będzie to obsługiwał. Tylko jeśli restauracja wpisuje wszystko do systemu, to mamy pewność, że możemy dodać restauracje bez potwierdzenia.
Naszym największym problemem może być właśnie brak świadomości, co tak naprawdę dajemy użytkownikom (tak sobie gdybam trochę, bo może za parę tygodni okaże się, że z tym nie ma problemu ;). Jak to mówią, hejters gona hejt. Po artykule na Antywebie, było trochę komentarzy, że “hola hola, ale takie serwisy to już są i to mają dużo więcej restauracji, to żadna nowość”. Tylko, że jak na razie na wszystkich serwisach, które osobiście sprawdzałem, model jest taki, że oni i tak muszę pośredniczyć w samym procesie rezerwacji. Ani to skalowalne, ani to wygodne.
Marketingowo niektórzy starają się to przykryć, pisząc, że “z reguły potwierdzenie jest od razu”, co jest zazwyczaj bzdurą, bo sami mamy kontakt z wieloma restauracjami wpisanymi w te serwisy, a które albo o nich nie słyszały, albo mówią, że tak - ktoś do nich dzwoni albo faks wysyła. Mamy nadzieję, że damy radę zrobić w Polsce coś, co na zachodzie jest już całkowicie normalne (open table, the fork, la forchette itd.).
Życze powodzenia całemu zespołowi i dajcie kiedyś szanse bbq ( https://github.com/drugpl/bbq ). Mega wygodnie się w tym pisze testy akceptacyjne, w których bierze udział więcej użytkowników np. jeden coś robi a drugi to akceptuje, a 3 może to obejrzeć.
Mógłbyś zarzucić screenem panelu admina i powiedzieć co wam daje i do czego wykorzystujecie sproutcore ?
Zgaduję że do praktycznie całego interfejsu dla restauracji – podgląd rozmieszczenia stolików i rezerwacji, doklikiwanie rezerwacji które się pojawiły innymi niż przez stoliczku.pl kanałami.
Może nie do całego interfejsu, bo mało znaczące części są w railsach (edycja profilu restauracji, konta pracowników, ustawienia wszelakie), ale właśnie do floorplanu, wpisywania rezerwacji itp. Sproutcore to prawdziwe MVC, więc tam sprawdza się bardzo dobrze. Aktualizowanie całej gamy rzeczy, które się zmieniają przy różnych akcjach, napisane od zera stworzyłoby pewnie mocno poplątany spaghetti code
Myślę, że w przyszłości zarzucimy wieloma screenami, ale teraz niestety to nasza tajemnica. Nie chcemy podkładać gotowych pomysłów konkurencji, przynajmniej na tym etapie ;).
Prośba, jakiej konkurencji?
(tzn. pewnie jakaś się pojawi, ale wygląda na to że na razie jesteście lata świetlne przed resztą)
[quote=Tomash]Prośba, jakiej konkurencji?
(tzn. pewnie jakaś się pojawi, ale wygląda na to że na razie jesteście lata świetlne przed resztą)[/quote]
Wiesz, konkurencja jest, chwalą się, że mają książkę rezerwacji online, ja zgaduję, że właśnie ją pośpiesznie piszą, albo mają jakiś bardziej zaawansowany scaffold. Nawet twórca nazwał nas w komentarzu pod którymś z postów “naśladowcami”, tak jakbyśmy napisali stoliczku w 2 tyg po tym jak oni wyszli :D.
polecam REWORK chlopaki
Czytaliśmy
Ja się zgadzam z Jasonem i Davidem
A ja nie do końca. Ogólnie zgadzam się z większością rzeczy z reworka, ale wszystko zależy od sytuacji. Wiele rzeczy robimy w podobnej do 37signals filozofii, np. nie chcemy finansowania, ucięliśmy prawie wszystkie feature’y jakie się dało, żeby szybko wypuścić, nie dbaliśmy o to co mówią ludzie dookoła (np. “no… już kilka osób próbowało coś takiego zrobić i jak na razie nie wyszło”), nie planowaliśmy zbyt dużo rzeczy z wyprzedzeniem itd.
W tym konkretnym przypadku sytuacja wygląda tak, że mniej więcej w podobnym czasie powstało kilka serwisów tego typu (nagle obrodziło w rezerwacje online ) i głupio byłoby dawać im jak na tacy to nad czym pracowaliśmy kilka miesięcy wspólnie z kilkoma restauracjami, które pomagały nam merytorycznie. Może jest to trochę “paranoiczne” zachowanie, ale uwierz mi - na sieci nie ma dostępnych prawie żadnych screenów z tego jak działają serwisy zza wielkiej wody, a uzyskanie wiedzy o tym jak działa restauracja od środka wcale nie jest takie proste. Uczyć zamierzamy, ale nie konkurencję tylko naszych klientów (myślę, że bardziej o to chodziło w pierwszym cytacie)
@phocke, no, Piotrek przykładowo walnął prezentację o Sproutcore na ostatnim(?) djangopiwo
edit: G-sas 5s.
Dokładnie, o brak dzielenia się wiedzą, to akurat Piotrka nie można posądzić
Phcoke - nie wiem jak to sobie wyobrażasz - wychodzi konkurencja równo z Twoim serwisem i wiesz, że na pewno ostro developują, a Ty im dajesz to, co robiłeś we współpracy z ludźmi od usability i z restauracjami? :> Nie sądzę :>
Jest różnica między dzieleniem się wiedzą, a lekkomyślnym postępowaniem :>
Brak walidacji daty mi się rzucił.
Na stronie głównej wpisałem jako datę: 201/2011
Chyba da radę szybko naprawić.