Entries Tagged 'Ogólne' ↓

Biznes i kod w jednym mieszkali domu

Jakiś czas temu pisałem o relacji tzw. „biz guy” versus „tech guy” w tekście Mam pomysł, potrzebuję tylko programisty. Ostatnio trafiłem na dość dobry tekst, który pokrótce podsumowuje to, co starałem się przekazać. Jako że nie ma sensu wszystkiego przepisywać, to podam tylko to, co uważam za esencję. Jest to też niejako skondensowana myśl przewodnia mojego wyżej wspomnianego tekstu. No i na dodatek świetne zobrazowanie graficzne tejże teorii. Jestem zagorzałym zwolennikiem przejrzystego przedstawiania treści w formie graficznej.

„(…) the product entrepreneurs have an increasingly marginal role as a startup evolves and becomes more successful. In fact, I’d argue that they are in a rude awakening – they either need to evolve into business entrepreneurs (as Gates and Jobs did, for example – both shrewd business guys) or hire people to play that role (a la Eric Schmidt at Google). Building an asset is the first (and most important) challenge. But finding the customer for that asset and maximizing the revenue/profit is also a challenge (and one that many builders are ill-suited to handle).” 

Dobre podsumowanie tego, co również uważam za prawdziwe. W artykule jest trochę więcej na ten temat i rozwinięcie powyższego akapitu. Polecam zapoznanie się z całością.

Na początku trzeba zbudować produkt i tylko to się liczy. „Tech guy” i jego wartość są zbliżone do maksimum. Kiedy jednak produkt jest już gotowy i działa, to na początku oczywiście trzeba robić jakieś poprawki i wprowadzać funkcje, które są naprawdę potrzebne i przydatne dla użytkowników. Poprawki jednak z biegiem czasu powinny (przynajmniej w teorii) się zmniejszać, a funkcji też nie ma sensu dodawać w nieskończoność. Przykład: czy ktoś, tak jak ja, tęskni za WinAmpem sprzed ładnych kilku lat, kiedy to był on małym i prostym programikiem idealnie spełniającym jedną funkcję: odtwarzanie muzyki? Teraz to ledwo dający się używać kombajn do wszystkiego i jeszcze trochę. Sens? Brak…

Na początku, kiedy produkt nie jest dostępny publicznie i dopiero jest budowany, wartość „biznesowego partnera” ogranicza się do generowania pomysłów na funkcje, a nie do generowania kodu, czyli samego mięsa produktu. Oczywiście w bardzo dużym uproszczeniu. Z biegiem czasu jednak, kiedy programista już tylko wprowadza poprawki i dodaje nowe funkcje, to wtedy zaczyna się prawdziwa praca partnera od biznesu. I to w przeważającej części od niego będzie zależało czy produkt (który równie dobrze może być rewolucyjny) odniesie jakikolwiek sukces. Czy dotrze tam, gdzie jest potrzebny. Czy przekona tych, których trzeba przekonać, żeby dali szansę temu produktowi.

Idealnie oczywiście kiedy jedna osoba (lub kilka) skupia w sobie cechy jak z jednego partnera, tak i z drugiego. Jednak daleko nie zawsze tak się dzieje.

Tak na marginesie, to jest artykuł napisany przez autora RescueTime, czyli najważniejszego konkurenta dla polskiego TimeCamp. I moim zdaniem chłopaki z RescueTime niestety wygrywają bezapelacyjnie. 
Kilka miesięcy temu (zdaje się na jakimś *campie) we Wrocławiu dyskutowałem o tym publicznie z autorem serwisu, ale od tamtego czasu nie widzę żadnych zmian. Chyba że pracuje nad backendem (oby tak było) i dlatego efektów nie widać gołym okiem. Z niedawnej dyskusji z autorem serwisu wynika, że skupiają się bardziej na niszy monitorowania pracowników, niż na modnym ostatnio i dość nasyconym już rynku personal productivity (nie znajduję naturalnie brzmiącego polskiego odpowiednika). Ukierunkowanie się na monitoring i odejście od programu stricte dla użytkownika publicznego jest moim zdaniem dobrym posunięciem. Chłopaki jednak nie mają polskiej wersji – od początku stawiają tylko na angielską. Polskiej nie ma nawet w najbliższych planach. Co najwyżej dalszych. Czy to słuszne posunięcie? Niekoniecznie.

Nie mając sensownego zaplecza sprzedażowego, dość trudno jest od razu uderzać z ofertą międzynarodową. Na dodatek skierowaną do firm, do których się jednak dociera inaczej, niż do użytkowników prywatnych.

Na miejscu ekipy z TimeCamp spróbowałbym więc najpierw spenetrować rynek polski, tu się trochę doszlifować i ewentualnie później wypływać na szersze wody. Po pierwsze – łatwiej dotrzeć do grupy docelowej, po drugie – mniejsze będą koszty alternatywne ewentualnych pomyłek. No i zdobyte doświadczenie na pewno nie zaszkodzi.

Podsumowując: zarówno TimeCamp’owi, jak i innym polskim firmom – jak najlepszej mieszanki kodu i biznesu życzę.

Ruby on Rails 2.2 (a nawet 2.2.2)

Ruby on Rails 2.2Jako że Ruby on Rails doczekało się kilka dni temu (a dokładniej 21-go listopada) kolejnej odsłony, wypadałoby opisać co ważniejsze lub co ciekawsze rzeczy, które pojawiły się w tej wersji. Poniżej więc są rzeczy, które zwróciły moją uwagę, posortowane w miarę losowo i zdecydowanie nie jest to kompletna lista poprawek, ale moje spojrzenie na to, co uważam za przydatne (lub mniej przydatne, ale warte odnotowania z różnych względów).

Z luźnych i nie związanych z tematem skojarzeń to niedawno oprogramowanie firmware dla iPhone’a też doczekało się wersji 2.2, a wtyczka Akismet do WordPressa trafiła jeszcze dokładniej – aktualnie jest w wersji 2.2.2. Ciekawy zbieg okoliczności.

* i18n (Internationalization)
Jaki jest polski odpowiednik tego? Internacjonalizacja? Brzmi zdecydowanie zbyt sztucznie. Pozostanę więc przy i18n – prostsze, szybsze i bardziej naturalne.
Tak czy owak, Ruby on Rails trochę urosło, wyedukowało się i w efekcie nauczyło się mówić w wielu językach. W tym oczywiście po polsku. Skończą się wreszcie różne dziwne sztuczki i triki, żeby oduczyć swoje aplikacje od angielskiego i przekabacić na polski. Teraz to jest wbudowane we framework i można się skupić na ważniejszych rzeczach. Bardzo duży plus dla wszystkich piszących aplikacje w innych językach. Ze swego doświadczenia wiem jak duży jest komfort kiedy się pisze aplikację po angielsku (praktycznie nic nie trzeba poprawiać i wszystko jest naturalne) i ile się trzeba napoprawiać i o ile rzeczach pamiętać, kiedy się pisze np. po polsku.
Tuż po wyjściu wersji 2.2 nie było jeszcze polskiej lokalizacji, więc ja i oki postanowiliśmy przetłumaczyć co było do przetłumaczenia i wrzucić to do oficjalnego repozytorium Ruby on Rails. Spóźniliśmy się o jakiś dzień lub dwa, bo ubiegł nas Jacek Becela z trix.pl i dzięki temu Rails już nie ma problemu z dogadaniem się po szczebrzeszyńsku.
Dla zainteresowanych – dużo materiałów na temat i18n jest zebranych na oficjalnej stronie: Rails I18n. Warto się zapoznać.

* Zgodność z Ruby 1.9 i JRuby
Z JRuby nie korzystam i w najbliższym czasie prawdopodobnie jeszcze nie skorzystam, ale warto o tym wspomnieć, bo JRuby nabiera coraz bardziej rumieńców i jest już dostatecznie szybkie i stabilne, żeby działać w trybie produkcyjnym.
Bardziej interesuje mnie zgodność z Ruby 1.9. Co prawda nie przesiądę się jeszcze na 1.9, bo nie jest to jeszcze wersja stabilna, ale dobrze wiedzieć, że jak tylko Ruby 1.9 dojdzie do wersji końcowej, to Ruby on Rails już będzie na to gotowe. A jest na co czekać, bo Ruby 1.9 jest dużo, dużo szybsze od Ruby 1.8.x.

* Dokumentacja
Dużo dobrego dzieje się w działce dokumentacji. Jedna z ważniejszych inicjatyw ostatnich miesięcy to uruchomienie Ruby on Rails Guides. Jest to zbiór niby-tutoriali, niby-opisów, niby-zbiorów-informacji o najważniejszych komponentach Ruby on Rails. Trzeba przyznać, że ich jakość jest lepsza, niż się spodziewałem i zdecydowanie warto do nich zajrzeć.
Oprócz tego moim zdaniem najlepsze źródło dla API, czyli APIdock już ma dokumentację dla Ruby on Rails 2.2, więc można śmiało korzystać i się cieszyć.

* Wsparcie dla ETag i last_modified
Od teraz łatwiej będzie unikać zasobochłonnych zapytań poprzez porównywanie ETag i last_modified oraz wysyłania „304 Not Modified”

* Transakcje w migracjach
Koniec z problemami kiedy migracje wywalały się w połowie i mimo iż żadna z migracji po błędzie nie została wykonana, to w bazie została zapisywana nieodpowiednia wersja i albo trzeba było ręcznie zmieniać numer wersji albo kasować wszystko i zaczynać od nowa. Teraz wszystko wygodnie jest pakowane w transakcję i jak coś ma nie działać, to nie zaśmieca to nam bazy częściowymi migracjami i po poprawieniu błędu możemy spokojnie migrować raz jeszcze.

* Łatwiejsza praca z łączonymi tabelami (JOIN)
Teraz do łączonych tabel można dodawać tablicę asocjacyjną (hash) z dodatkowymi warunkami wyszukiwania, co znacznie ułatwi zapytania na skomplikowanie połączonych tabelach.
Prosty przykład dla unaocznienia:

# Znajdź wszystkie książki z twardą okładką
Book.all(:joins => :covers, :conditions => { :covers => { :hard => true }})

Nasuwa mi się od razu tematyczny dowcip. Może i znany, ale niezmiennie dobry:
Zapytanie SQL wchodzi do baru, podchodzi do dwóch tabel i mówi: „Can I join you?”

* find_last_by_<atrybut>
Dopiero niedawno (zdaje się w wersji 2.0 albo 2.1) zostało wprowadzone ‘last’, a już jest find_last_by. Jest to odpowiednik tego kodu:

Model.last(:conditions => {:attribute => value})

# Znajdź ostatnią książkę Gladwella
Book.find_last_by_author['Malcolm Gladwell']

* Układy stron w Action Mailer (layouts)
Kto trochę dłużej pracował z Action Mailerem, ten wie, że generowanie i wysyłanie maili jest delikatnie mówiąc zrobione „trochę naokoło”. Ja przynajmniej zawsze odnosiłem takie wrażenie. Od teraz jest to ułatwione poprzez stosowanie layout’ów. Łatwiej się będzie teraz tym zarządzało, aczkolwiek ciągle uważam, że wysyłanie maili jest niepotrzebnie przekombinowane w Ruby on Rails.

* Pomocne szczególiki
- Dodane metody past?, today? i future? dla klas Date i Time, dla łatwiejszego porównywania czasów i dat
- Time rozpoznaje teraz ułamkowe wartości w konstrukcjach takich jak: 2.3.hours.ago albo 3.6.weeks.since

* Dziwoląg
Stworzono aliasy Array#second do Array#tenth dla Array#[1]Array#[9]
Po co? Nie mam najmniejszego pojęcia. Jak dla mnie to jedynie niepotrzebne zaśmiecanie frameworka. Więcej zachodu niż to jest tego warte.

Dla dalszego zgłębiania szczegółów polecam ten link. Jest tam naprawdę dużo przydatnych rzeczy i szczegółowych opisów.

Podsumowując
Ruby on Rails 2.2 jest – szczególnie dla międzynarodowej części społeczności Ruby on Rails – dużym i ważnym krokiem do przodu. Rails 2.1 był w sieci dość mocno nagłośniony, jednak uważam, że to 2.2 jest większym krokiem do przodu w porównaniu do poprzedniej wersji, niż 2.1 w stosunku do 2.0. Rzeczy wyżej wymienione to tylko część zmian. Dużo więcej się dzieje pod maską, tam gdzie nie jest to tak widoczne, a co jest równie ważne.
W najbliższym czasie mam zamiar napisać prostą aplikację w Rails 2.2.2. Żeby potestować nową wersję i żeby napisać coś użytecznego (tak przynajmniej to postrzegam). Jeśli będą jakieś nietypowe rzeczy, to się nimi podzielę. Jak aplikacja będzie gotowa, to również nie omieszkam o tym wspomnieć.
A teraz zapraszam do kodowania w nowej odsłonie Rails. Miłego klawiaturowego i intelektualnego szaleństwa.

Democamp 2008 Poznań – wrażenia i refleksje

Na Democamp wybrałem się z Wrocławia zachęcony przede wszystkim mocną obsadą panelu komentatorów. Miało to mi zagwarantować „zwrot z inwestycji”, czyli nawet jeśli będą słabsze startupy i ich prezentacje, to przynajmniej ciekawie będzie posłuchać komentatorów. Wcześniej bywałem tylko na wrocławskich spotkaniach, przeważnie spod egidy Grill IT. Wyprawa do Poznania była więc pierwszym moim przedsięwzięciem międzymiastowym.

Sama organizacja była dość dobra. Ciężko jest ogarnąć ponad stuosobową grupę osób (nie wiem ile było dokładnie uczestników, więc tylko szacuję), ale chłopakom z Netguru i Ubik BC to się udało. Odbyło się to niestety czasami kosztem jakości, a mianowicie:

* dobrze, że starano się trzymać ram czasowych, czyli każda prezentacja trwała dokładnie 5 minut.
* gorzej, że prezentujący nie widział nigdzie ile czasu mu zostało i czasami efektem było wyrywanie mikrofonu na 2 zdania przed zakończeniem prezentacji, niejako zawieszając ją w powietrzu.
* a można… byłoby uniknąć tego dając chociażby jakiś timer albo na ekranie albo gdzieś przed oczami prezentującego, żeby wiedział czy minęło dopiero 1,5 minuty i jeszcze może wdawać się w jakieś szczegóły, czy też już ma za sobą ponad 4 minuty i to ostatnia chwila, żeby podać jakieś wnioski i najważniejsze rzeczy o swoim startupie (te najważniejsze powinny być na początku oczywiście, ale nie każdy wybierał najbardziej optymalny sposób prezentowania).

* dobrze, że zgromadziło się różnorodny i adekwatny panel komentatorów, którzy bardzo dobrze wywiązali się ze swego zadania, dając wartościowe komentarze i sugestie.
* gorzej, że nie dano możliwości odniesienia się do komentarzy samym prezentującym, nawet choćby jednym zdaniem.
* a można… dać możliwość polemiki jeśli już nie widowni z prezentującymi, to przynajmniej komentatorów. Zajęłoby to raptem 1-2 minuty więcej na każdym startupie, a dodałoby o wiele więcej kolorytu i na pewno przyniosłoby o wiele więcej korzyści przedstawicielom startupów. Brak tej możliwości zminimalizował ich udział do roli biernego odbiorcy treści – niewiele więcej, niż otrzymanie maila, na dodatek bez możliwości odpowiedzenia na niego.

* dobrze, że zebrano sporą widownię (choć spodziewałem się, że może być więcej osób).
* gorzej, że sprowadzono widownię do stricte biernej roli, nie dając możliwości zadania choćby jednego pytania.
* a można… dać głos ludowi. Tutaj może to być trochę trudniejsze z ogarnięciem logistyczno-czasowym, ale parę pytań do każdej prezentacji tragedii by nie zrobiło. Tutaj można byłoby śmielej stosować przerywanie w pół zdania, jeśli to konieczne.

Odnosząc się do samej zawartości merytorycznej, to po pierwszej połowie czułem spory niedosyt, jednak startupy prezentujące w drugiej połowie to nadrobiły. Bardzo nierówny był sam sposób prezentowania (poczynając od show, poprzez czytanie z kartki, zdarzały się też bardzo dobre prezentacje, a kończąc na całkowitym nieporadzeniu sobie z tematem). Jak jednak słusznie zauważył Michał Brański (jeden z komentatorów), większość startupów to były przedsięwzięcia, gdzie większość pracy została włożona w backend, a nie we frontend, co daje im sporą przewagę konkurencyjną w stosunku do firm, które chciałyby skopiować ich działalność. Dobrze to wróży na przyszłość, bo wcześniej bywało przeważnie odwrotnie – zdecydowana większość pracy była wkładana we frontend, a backend był prostą aplikacją, bez głębszej logiki i skomplikowanych algorytmów.

Dobrym pomysłem były też stoiska startupów. Każdy miał do zagospodarowania stół i było wiele przykładów na wykorzystanie tej sposobności i pokazanie swego startupu dużo bardziej szczegółowo i dogłębnie, niż to miało miejsce podczas prezentacji. Dodatkowo ci, którzy „zainwestowali” w jakiekolwiek materiały promocyjne, mieli większą szansę na bycie zapamiętanym. Obok naoczny tego przykład: zdjęcie materiału promocyjnego jednego ze startupów połączonego z zabijaniem nudy na jednej z tych nudniejszych prezentacji.

Kilka startupów, które z różnych względów zapadły mi w pamięć:

Redlink
Imponujące możliwości produktu i dopracowany zarówno layout, jak również model biznesowy, zaplecze i cała reszta. Bez wątpienia jeden z najbardziej godnych uwagi produktów. Jednakże… ciężko to nazwać startupem. Cytując chociażby ze strony firmy, zakładka „O firmie„:

Platforma Redlink.pl została w całości stworzona przez firmę Vercom. Bazując na własnych doświadczeniach związanych z telefonią VOIP, Web Services oraz aplikacjami webowymi zintegrowaliśmy różne kanały komunikacji elektronicznej tworząc w ten sposób nowatorskie narzędzie marketingu bezpośredniego.
Firma Vercom Sp. z o.o. powstała w roku 2005 w Poznaniu i od początku działalności skoncentrowała się na tworzeniu innowacyjnych rozwiązań IT dla biznesu.

Konkurowanie głęboko osadzonej w biznesie i działającej od kilku lat firmy ze startupami, które działają od kilku miesięcy czy nawet tygodni jest moim zdaniem trochę mijające się z celem. Stąd też mimo najlepszego produktu nie oddałem swojego głosu na Redlink.

Flux
Najbardziej dopracowany wizualnie produkt. Konkurencja na rynku światowym jest jednak bardzo duża w tej dziedzinie, a naprawdę innowacyjnych rzeczy niezbyt wiele.
Moim zdaniem jednym z rozwiązań mogłoby być postawienie na sprzedaż produktu dla firm (na początek polskich) i na podkreślaniu funkcji sprzyjających współpracy, współdzieleniu zadań i lepszej kontroli nad całym przepływem informacji. Po pierwsze – do firm jest łatwiej to sprzedać, a po drugie – w tej właśnie działce (przepływ informacji w firmie) są najbardziej innowacyjne funkcje produktu (przynajmniej takie mam wrażenie po obejrzeniu prezentacji i przedstawieniu funkcji).
Sposób i przebieg prezentacji o wiele lepszy, niż poprzednio (zdaje się na którymś z Barcampów), więc chłopaki idą w tej dziedzinie do przodu.
Strona główna wygląda jednak jakby ktoś ją stworzył we Front Page’u 1997. W 3 minuty. Z przerwą na herbatę. Wiadomo, że nie na stronie głównej powinno się skupiać swoje wysiłki, ale jak na razie jest to jedyna dostępna strona dla potencjalnych przyszłych użytkowników i dla tak dopracowanego produktu taka wizytówka jest prawie jak obelga. Wierzę, że bardzo szybko to się zmieni.

e-podroznik.pl
Bardzo przydatny produkt, widać sporą pracę w backendzie, jest zapał twórców, jest duża przewaga nad możliwymi przyszłymi konkurentami (umowa z firmą dostarczającą rozkłady), więc składając to wszystko do kupy powinna wyjść bardzo przyjemna mieszanka. Z prezentacji nt. planów na przyszłość wynika, że wszystko jest na dobrej drodze, pozostaje więc tylko życzyć powodzenia. I poprawienia wyglądu serwisu.
No i jak to zauważyli zgodnie komentatorzy – przejęciami konkurencji lepiej chwalić się po fakcie, a nie przed nim. Po co dawać stronie przejmowanej dodatkowe argumenty podczas negocjacji? Szczególnie że nawet chyba została podana suma, jaką mają zamiar przeznaczyć na przejęcia.

Opiekun Inwestora
Serwis, który całkowicie zmarnował szansę zaprezentowania się w dobrym świetle. Z prezentacji nie wynikło praktycznie nic, w przeważającej części z powodu tego, że kiedy miało dojść do wyłuszczania najważniejszych rzeczy, czas się skończył i mikrofon został zabrany.
Rozmawiałem później z przedstawicielem serwisu przy stoisku i się okazuje, że stoi za tym przemyślany produkt, w który włożono sporo pracy i który jest na dodatek efektywny w tym, co robi. A robi to, co jest na dzień dzisiejszy (w czasach bessy) niemodne: podpowiada w jakie fundusze inwestycyjne inwestować. Temat dość szeroki, więc nie będę go rozwijał.
Może brakuje im kogoś, kto potrafiłby dobrze sprzedać pomysł? Może zrobiliby to, gdyby mieli więcej czasu? Może publiczność nie była „targetem” takiego serwisu? Każda z opcji jest możliwa. Uważam jednak, że jest to jeden z najbardziej niedocenionych startupów, które się zaprezentowały.

Szuku
Usługa, która ciągle czeka (na poziomie światowym również) na dobrą implementację. Jeśli ta okaże się dobra, a przynajmniej dostatecznie dobra, to powinna bez problemu odnieść sukces. To, co widziałem, wyglądało obiecująco. Wytrwałości i powodzenia więc w finalizacji tego, co zaczęliście. Tylko ta domena jakaś nie najbardziej fortunna…

EcooSystem
To z kolei moim zdaniem najbardziej przeszacowany pomysł wśród wszystkich zaprezentowanych. Wygrał na podstawie samej prezentacji (choć trzeba przyznać, że dość dobrze zrobionej) i luźnych pomysłów o współpracy. Szeroki zakres pomysłów może budzić pewne obawy czy to będzieć działać zgodnie z zamysłem twórców. Do dzisiaj nie było możliwości, żeby się o tym przekonać, bo strona główna była tylko screenshotem, ale teraz serwis otworzył już swoje podwoje i można zacząć weryfikować czy to, co chcieli stworzyć pomysłodawcy, udało im się osiągnąć. Idea szczytna, ale trudna, więc oby jak najwięcej ze swojej wizji udało im się spełnić.

Wniosek z Democamp jest taki, że coraz lepiej się dzieje wśród startupów i choć nie widać żadnych rewolucji na skalę chociażby europejską, to jednak coraz więcej pracy jest wkładane w startupy, co tworzy większą barierę wejścia dla potencjalnej konkurencji. Mniej już jest serwisów bazujących na czystej kopii pomysłu, którą ktokolwiek inny z kolei może skopiować w ciągu kilku tygodni. Oby ten trend został podtrzymany.

Inne relacje z Democamp:
http://netto.blox.pl/2008/11/democamp-state-of-mind.html
http://netto.blox.pl/2008/11/democamp-hall-of-fame.htm
http://antyweb.pl/democamp-o-startupach-i-generlanie-jak-bylo
http://www.internetstandard.pl/news/175789/Redlink.i.Ecoosystem.docenione.na.Democamp.html
http://blog.ecoosystem.com/democamp-wrazenia/

Ruby on Rails: szlachetny kamień na szynach czy duchowny w pociągu?

Ruby vs RabbiPewnego słonecznego dnia szedł sobie stary i mądry rabin przez pola i łąki. Rozmyślał nad Torą, nad niebezpiecznie rozluźniającymi się obyczajami w swojej gminie (młodzi już nie kłaniają się starszym tak nisko jak drzewiej bywało) i nad nadmiernie wzrastającym autorytetem rabina z sąsiedniej gminy za rzeką. Będąc dotychczas najbardziej szanowaną osobistością w całej okolicy między rzeką a tą miejscowością, dokąd czasem się zapuszczał dokonać bardziej nietypowych zakupów, niż chleb czy mięsiwo (np. kałamarze czy płótno), oczywistością było, że rosnący u boku autorytet jest co najmniej powodem do niespokojnego snu w nocy i podczas siesty. Idąc więc przez łąkę i bezwiednie muskając dłonią czubki wyższych traw, podświadomie poszukiwał „znaku”, który by go wewnętrznie umocnił w przekonaniu, że jego pozycja jest niezagrożona i że nieoczekiwane drgawki nie będą go wyrywały z błogiego stanu siesty.
Tak niepostrzeżenie doszedł aż do nasypu, który biegł wzdłuż rzeki. W swym zamyśleniu i trosce zabrnął dalej, niż zwykle. Wspiął się więc po nasypie (a trzeba zaznaczyć, że nie był to nasyp zwykły, lecz kolejowy) i wzdłuż tego nasypu podążył powoli z powrotem w kierunku swej siedziby.
Aż tu raptem z zadumy wyrwał go nieoczekiwany czerwony blask, strzelający wprost spod nóg. Ku jego bezgranicznemu zdumieniu był to… dorodnej wielkości rubin leżący wprost na torach kolejowych.
- Cóż za wspaniały rubin! – wykrzyknął rabin, podniósł go z torów i już ze spokojnym umysłem i uśmiechem na twarzy dziarsko potruchtał w kierunku unoszącego się dymu, zwiastującego rychły obiad.

A jaki jest morał tej historii?
Otóż apeluję szczerze, żebyśmy nie zamieniali ról w tej historii i nie pozwalali rubinowi znaleźć rabina na torach, tylko pozostawili to w takiej wersji jak powyżej, nawet nie zważając na fakt, że nie jest to najwybitniejsza przypowieść tego roku.

Jak bowiem brzmiałoby kluczowe zdanie przypowieści w języku angielskim?
- What a nice ruby! – exclaimed rabbi, took it off the rails and merrily trotted home. (tłum. wolne)

Ze szczegółami:
[hwuht] [a] [nahys] [roo-bee]! – [ik-skleymd] [rab-ee]
Źródło: Dictionary.com Unabridged (v 1.1)

[roo-bee] (pol. rubi) – Rubin
[rab-ee] (pol. rabi) – Rabin

Jeśli więc jesteśmy w tej branży, programujemy w tym języku, inwestujemy w projekty związane z tą technologią czy wręcz posiadamy firmy, które się zajmują programowaniem m.in. w tym języku, to ja bardzo proszę… nie mieszajmy w to religii i duchownych :)

Mam pomysł, potrzebuję tylko programisty

Czy tego szukam? Czytałem ostatnio sporo branżowych blogów, przeglądałem odpowiednie fora, trafiłem na kilka artykułów w Newsweeku / Time / Polityce / Fortune, przejrzałem polskie poletko Web 2.0 i wpadłem na świetny pomysł!
Teraz potrzebuję tylko programisty, który mi to szybciutko skleci i będę kolejnym złotym dzieckiem polskiego Internetu. Na szczęście w Polsce takowych jest jeszcze bardzo mało, więc tym bardziej mam spore szanse.

Taki mniej więcej tok zdarzeń i rozumowania jest aż nazbyt częsty. Zarówno w Polsce, jak i w innych krajach, ale na innych się skupiać nie będę, więc będę pisał o rodzimym rynku.

Jest niestety bardzo dużo przypadków jak powyżej i odpowiednich ogłoszeń "szukam programisty". Przy czym dalszy tok rozumowania wygląda następująco:
- Zrób mi proszę prosty serwis (a i tak dobrze, jeśli pada słowo "proszę")
- taki coś w stylu Allegro / Nasza-Klasa / Web 2.0 / Flickr (w zależności na jaki genialny pomysł się wpadło)
- to przecież powinno być proste
- trochę PHP, trochę MySQL, oczywiście AJAX i powinno być gotowe (ilość i stopień wyszukania akronimów odpowiedni do stopnia oczytania branżowych blogów i znajomości aktualnych topowych buzzwordów)
- jako że to jest proste, to jestem nawet skłonny zapłacić 1000-2000 PLN (co też jest wspaniałomyślne, bo równie często prosi się znajomego programistę o sklecenie podobnego serwisu po znajomości)
- dodaj jeszcze do tego serwisu funkcje X, Y i Z i po sprawie (przy czym te właśnie funkcje, nawet jeśli są całkowicie pozbawione sensu z punktu widzenia przeznaczenia serwisu, powinny z niego zrobić co najmniej drugiego eBay’a, jak nie lepiej)

Kwestie, o których się nawet nie myślało
- godne wynagrodzenie za wykonanie pomysłu (to 1-2K nie jest godne?!)
- podział zysków z programistą / developerem
- udziały w przedsięwzięciu dla programisty / developera
- no i oczywiście najważniejsze – zasadność tworzenia takiego serwisu

Kwestie, o których w wielu wypadkach się nawet nie słyszało
- User Interface
- Pageflow
- Struktura bazy danych
- Bezpieczeństwo (serwisu, serwera, danych użytkowników)
- Skalowalność

Powyższe kwestie nie zostały wyssane z palca – widziałem zbyt wiele ogłoszeń typu "1-2K PLN za serwis o funkcjonalności Allegro", przy czym zawarte jest w tym wszystko od zarejestrowania domenu do uruchomienia serwisu. Zbyt wiele, żeby uznać to za jednostkowe przypadki.

Jeśli już nawet zasadne byłyby przypadki, kiedy tzw. "biz guy" szuka "tech guy" do zrobienia roboty, to rozumowanie powinno się zaczynać od końca:
- Jaka jest zasadność tworzenia takiego serwisu? (pytanie to powinno być zadane wielokrotnie i pod wieloma kątami, dopiero później można przechodzić do pytań kolejnych)
- jak będzie wyglądał / kto stworzy UI
- jaka będzie struktura serwisu (pageflow)
- jaki będzie podział ról między biz / tech guy
- jaki będzie podział zysków / udziałów między nimi
- jak znaleźć dobrego programistę / developera, który na dodatek będzie chciał pracować z kimś, kto ze strony technicznej nic nie wniesie do przedsięwzięcia (równie dobrze może to być na pierwszym miejscu, jeśli chodzi o wpływ, jaki ma to na powodzenie projektu)
- dopiero później cała reszta

Ciekawe dlaczego nie ma pytań ze strony programistów potrzebuję tylko człowieka do generowania pomysłów, a z resztą sobie poradzę, prawda?

Zawsze źle oceniamy to, czego nie rozumiemy. A to, co rozumiemy, możemy zrobić sami.
Dlatego też powinno być tak, że to developerzy powinni poszukiwać ludzi, którzy się zajmą "stroną biznesową" serwisu, który już stworzyli, a nie odwrotnie. Dlaczego tak nie jest? W dużej mierze przedstawiłem to tutaj: Dlaczego powstaje mało serwisów mimo ciągle zmniejszającej się bariery wejścia?

Moim zdaniem jeśli już, to właśnie w odwrotną stronę powinno to działać, czyli do gotowego serwisu powinna być poszukiwana osoba, która się zajmie żmudną pracą wprowadzania go na szerokie wody. zakładając oczywiście, że osoba, która go stworzyła, chce się zajmować tylko techniczną stroną i dlatego takiej osoby poszukuje. Tudzież z braku czasu na obie role naraz. Jednak takiego ogłoszenia, nawet jednego, jeszcze w Polsce nie widziałem…

Idealnym rozwiązaniem jednak jest współpraca dwóch takich osób od samego początku. Nie szukanie kogoś tylko do zrobienia czegoś, a wspólne i ukierunkowane działania od etapu generowania pomysłu, poprzez projektowanie interfejsu, poszukiwania potencjalnych źródeł przychodów, do wyprowadzania projektu na szerokie wody. Jako że jest to jednak sytuacja idealna i wymagająca całkowitego poświęcenia dwóch osób, co w Polsce jeszcze jest rzadko spotykane, poświęciłem temu zagadnieniu powyższy post.

Był sobie chłopiec…

Sabon - Start …a przynajmniej chłopiec z punktu widzenia iluzorycznej i enigmatycznej „blogosfery”. Chłopcem był, bo w owej blogosferze nie uczestniczył, czyli że bloga swego nie posiadał.
I nie z chęci stania się „mężczyzną”, ani też z naśladownictwa, jednak od dzisiaj powstaje nowy twór blogosferowy (nigdy nie lubiłem tego słowa, więc będę ograniczał jego uzywanie do minimum). Z potrzeby ustruktyruzowania swoich przemyśleń, skrystalizowania przemyśleń i chęci skonfrontowania ich z szerszym gronem.

Na tym blogu mam zamiar umieszczać treści w przeważającej mierze z trzech dziedzin:

Dlaczego akurat te tematy?
Po kolei:

  • Freelancing, bo jestem freelancerem. Świeżo upieczonym (parę miesięcy) jeśli chodzi o „full time”, ale dość długo już działającym, jeśli chodzi o „part time”.
  • Startupy, bo oprócz bycia freelancerem pracuję też nad swoim(i) projektem(ami), co w przyszłości może się przerodzić w nowy startup (wizja optymalna) bądź nie dożyć do tego etapu (wizja katastrofalna).
  • Ruby on Rails, bo w tym właśnie się specjalizuję i w tym robię swoje projekty.

Nie będę poruszać zaś tematów, na których się nie znam bądź też z którymi nie miałem bezpośredniej styczności na tyle, by wyrobić sobie o nich zdanie.
Nie mam też zamiaru tylko i wyłącznie tłumaczyć na polski tego, co się pojawia w sieci po angielsku. Mieszkam w Polsce (Wrocław), tutaj pracuję, więc będę się na tym właśnie skupiał. Trendy światowe są dla mnie interesujące na tyle, na ile dotykają i wpływają na polskie realia. Często te wpływy są pośrednie i oddziaływujące w bardzo inny sposób, niż na swoim macierzystym rynku anglojęzycznym.

Jeśli zaś chodzi o blogi i język angielski, to nasuwa się od razu skojarzenie związane i z jednym i z drugim: „content is king”. Król jednak nagi chodzić nie powinien. To nic, że nader często tak właśnie paraduje, ale jednak nie powinien. Żeby go trochę oblec w szaty, poniżej zapowiedź pierwszych dziesięciu artykułów, jakie się pojawią na tym blogu. Jak już wszystkie 10 będzie online, to może nie będzie to jeszcze król, a zaledwie zaściankowy szlachcic czy pośledni książę i może nie będzie miał przepysznych szat, ale przynajmniej nie powinien mieć czego się wstydzić i będzie mógł wyjść do ludzi bez świecenia oczami.
A oto i artykuły, wraz z kategoriami, do których będą przypisane:

  1. Przyszłość startupów internetowych w Polsce (startupy)
  2. Znaczenie lokalizacji geograficznej startupów (startupy)
  3. Znaczenie zasięgu rynku docelowego startupu (lokalny / globalny) (startupy)
  4. Porównanie IDE / edytorów dla Ruby on Rails (Ruby on Rails)
  5. Analiza SWOT dla Rails w Polsce i na świecie (Ruby on Rails)
  6. Ataki SQL injection Iniekcja SQL w aplikacjach Rails (Ruby on Rails)
  7. Możliwość wypromowania się będąc freelancerem (freelance)
  8. Nabycie i utrzymanie potrzebnych umiejętności (freelance)
  9. Powody, dla których zostałem freelancerem (freelance)
  10. Dlaczego powstaje stosunkowo mało serwisów mimo ciągle zmniejszającej się bariery wejścia (freelance / startup / Ruby on Rails)

Artykuły te będą się ukazywać niekoniecznie w takiej kolejności jak powyżej, ale na pewno każdy z tych tematów zostanie poruszony.
Żeby nie przegapić tego, który Cię interesuje, najlepiej od razu subskrybuj RSS i wtedy na pewno nic Cię nie ominie.

/ AD 2007 / Sabon (Radek Sienkiewicz) /