nbw: Redefine the undefined

Ludzie potrafią przewijać strony w dół… ommm… Ludzie potrafią przewijać strony w dół… ommm.. Ludzie naprawdę potrafią przewijać strony w dół… ommm…

1. Planowanie zaczynasz mniej więcej na rok przed terminem wdrożenia. Jesteś typowym klientem: nic nie wiesz, nie wiesz gdzie szukać, kogo pytać, czego oczekiwać. Prawdopodobnie wybierzesz konsultanta, przez co będziesz pluł sobie w brodę przez resztę życia. A przynajmniej okresu przygotowawczego. I okresu spłaty zadłużenia.
2. Konsultant zaproponuje ci wdrożeniowców, którzy – jeszcze o tym nie wiesz – zjedzą cię razem z kopytami. A potem wystawią rachunek na usługi, o których nikt cię nie poinformował.
3. Jeśli projekt będzie trwał rok, przez 11 miesięcy nic znaczącego się nie wydarzy. Nie licząc oczywiście podpisania umowy, wpłacenia zaliczek oraz pierwszych przymiarek. Jeśli masz mniej czasu na wdrożenie, proporcje będą zachowane choć z racji krótszego czasu wdrożenia, może ci się wydawać, że wszyscy ci pomagają.
4. Konsultant będzie cię nagabywał o przygotowanie i trzymanie się planu projektu. Tak, masz rację, w rzeczywistości nie ma żadnego planu a wszystko co jest spisane to to, co zaproponowałeś na samym początku.
5. Przez większość czasu będziesz płacił za rzeczy, których nie widzisz; różnica z projektem internetowym polega na tym, że w sporej mierze są to rzeczy, których faktycznie nie potrzebujesz.
6. Na etapie oferty, konsultant przedstawi ci listę rzeczy/pomysłów, które nie są już trendi, nie wyglądają dobrze oraz są średnio 4 razy droższe w ofercie niż kosztują w rzeczywistości.
7. Na etapie oferty zostaną ci również przedstawione wodotryski, z których wiadomo od razu, że nikt nie skorzysta. Możesz być niemal pewien, że będzie to oś oferty.
8. Nikt nawet nie ośmieli się zapytać, czy masz może jakiś pomysł przewodni, czy może chciałbyś, by jakiś element z twojego/waszego życia był jakoś wyróżniony…
9. …a jeśli takowy sami zaproponujecie, na drugim spotkaniu zostanie sprzedany jako błyskotliwe odkrycie konsultanta
10. Przez 10 miesięcy będziesz uspokajany, że projekt idzie zgodnie z planem, że wszystko jest pod kontrolą…
11. …oczywiście, tak nie jest. O czym dowiesz się na dwa tygodnie przed, kiedy nagle wszystko stanie na głowie
12. I tak jak w projektach internetowych, prace nie posuną się do przodu jeśli przynajmniej raz dziennie sam się z czymś nie przypomnisz.
13. Prawdopodobnie nikt z konsultantów/podwykonawców nie uczyni nawet najmniejszego kroku by ci coś podpowiedzieć bądź pomóc. Jeśli już, będzie to kosztowało horrendalnie dużo a i tak nie dostaniesz tego, co byś chciał.
14. Aż w końcu, tego wyjątkowego dnia i tak okaże się, że z większością rzeczy nie zdążyliście.

W przeciwieństwie do projektów internetowych – z perspektywy czasu, to i tak nie ma znaczenia. Bo zabawa na pewno będzie przednia.

Ostatnio nie włączałem czytnika RSS ponieważ nie miałem na to czasu; teraz nie włączam, bo boję się trafić na kolejną informację z gatunku “Nowy konkurent Windows!!!!11oneoneone”.

Rozumiem myślenie życzeniowe ale z tego, co napisano na blogu Google wynika, że Google Chrome OS nie jest systemem operacyjnym, który ma na celu zagrozić pozycji Windows. Przynajmniej nie globalnie.

Czym Google Chrome OS jest/może być?

Jak możemy wyczytać, system od Google jest zbudowany z myślą o przeglądarce Chrome i przeznaczony przede wszystkim do netbooków. Ma działać na procesorach z serii x86 oraz ARM co oznacza niemal nieograniczony dostęp do netbooków, notebooków i całej masy sprzętu, który ma – mniej lub bardziej – ograniczone zasoby. Google twierdzi, że również celują w silne desktopy ale to mnie jakoś nie przekonuje.

Google targetuje swój system na użytkowników, którzy spędzają bardzo dużo czasu w Sieci i nie lubią czekać na to, aż uruchomi im się system, przeglądarka czy program pocztowy. Z GCOS wszystkie aplikacje uruchamiają się błyskawicznie. A przynajmniej tak błyskawicznie na ile pozwala łącze internetowe. Bo co jest raczej jasne, to Google tworzy system pod swoje aplikacje.

GCOS to w takim razie, potencjalnie, doskonale wpasowany system, realizujący z góry określone zadanie – szybki dostęp do najpopularniejszych usług w Internecie: Google Apps, YouTube. Do tego pewnie Twitter i Facebook. System, który ma minimalne wymagania przez co – powinien – uruchamiać się błyskawicznie i zużywać jak najmniej zasobów komputera. Jako taki, na fali popularności netbooków i szerokiego dostępu do Internetu, może odnieść duży sukces i spokojnie powalczyć z Linuksem czy Windows na polu systemów dla netbooków/handheldów.

Czym Google Chrome OS (raczej) nie jest?

Z powyższego wynika, że Google Chrome OS nie jest systemem mogącym zagrozić Windows czy nawet Linuksowi – w Google na pewno zdają sobie sprawę z tego, że stworzenie “dużego” systemu operacyjnego to karkołomne i kosztowne zadanie. Tworząc system dla Netbooków (i innych urządzeń przenośnych) Google wbija się w małowymagającą niszę, w której może w szybkim tempie stać się numerem jeden. Poza tym, Google musi zdawać sobie sprawę z czysto “pijarowych” zagrożeń – porażka takiej firmy na rynku “tradycyjnych” systemów byłaby dużo głośniejsza niż setnej dystrybucji Linuksa, która ma rzucić wyzwanie Windows.

GCOS nie jest też zbawcą Linuksa – nie spodziewałbym się mnogości aplikacji skoro wszystko jest zbudowane wokoł Google Chrome. Cel jest jasny: stworzyć system, który ma najmniejsze możliwe wymagania, startuje najszybciej jak to tylko możliwe i zapewnia jedną rzecz: dostęp do wszystkich aplikacji internetowych (w domyśle: Google). Dlatego oczekiwanie, że wraz z GCOS do Linuksa uśmiechną się producenci gier czy innej “komercji” jest – co najwyżej – myśleniem życzeniowym.

GCOS także nie przedstawia – w tej chwili – większej wartości dla tradycyjnych użytkowników desktopów. Jak wnoszę, system nie będzie bogaty w aplikacje – te mają być dostępne głównie przez Internet, co dyskwalifikuje go jako system “domowy”. Z drugiej strony, zdaję sobie sprawę, że przeciętnemu użytkownikowi nie trzeba wiele: wystarczy przeglądarka (+ program do torrentów) i player filmów/muzyki.

Przez chwilę zastanawiałem się jeszcze nad tym, czy brak standardowych aplikacji do obsługi chociażby poczty, nie będzie stanowił problemu w sytuacji ograniczonego dostępu do Internetu. Ale nie, jest przecież Google Gears.

Jeśli faktycznie ten system będzie tak wyglądał jak się zapowiada: czapki z głów przed Google; tempo i kierunki rozwoju produktów tej firmy muszą wzbudzać uznanie nawet u takich firm jak Microsoft.

Jak można przeczytać w komunikacie na stronie w3c, organizacja zaprzestaje prac nad XHTML2 by skupić się nad HTML5.

Z mojej perspektywy to krok w dobrą stronę – XHTML2 choć początkowo wydawał się być bardziej poukładany, był wg mnie zbyt mocno oderwany od rzeczywistości. Od tego, że na co dzień HTML służy do budowania stron internetowych – o często bardzo zróżnicowanej treści.

W życiu każdego popularnego serwisu internetowego przychodzi czas, kiedy należy zabrać się za jego optymalizację. Zwykle dokupuje się dodatkowe serwery, wpina memcache, optymalizuje kod serwisu i zapytania do bazy danych. Frontend jest zwykle pomijany, choć w rzeczywistości, optymalizując szablony, można uzyskać całkiem niezłe wyniki relatywnie niskim nakładem sił i środków.

Ponieważ miałem ostatnio kilka serwisów, które trzeba było zoptymalizować, postanowiłem przypomnieć sobie technikę CSS Sprites opisaną przez Dave’a Shea na łamach AListApart. Jeśli ktoś jej nie zna – proponuję się zapoznać. To prosta technika, z korzeniami w świecie gier komputerowych, polegająca na łączeniu wielu plików w graficznych w jeden większy, łatwiejszy w zarządzaniu i zmniejszający ilość zapytań o elementy graficzne.

Niedawno przetestowałem to rozwiązanie w kilku serwisach, które aż prosiły się o optymalizację i trafiłem na ciekawe zachowanie. Ale po kolei. Zakładając, że nasz przeciętny Jan Kowalski, czyta artykuł na ALA po raz pierwszy, skorzysta z zapisu zaproponowanego w artykule:

#panel1b a:hover {
    background: transparent url(test-3.jpg)
    0 -200px no-repeat;}
  #panel2b a:hover {
    background: transparent url(test-3.jpg)
    -96px -200px no-repeat;}
  #panel3b a:hover {
    background: transparent url(test-3.jpg)
    -172px -200px no-repeat;}
  #panel4b a:hover {
    background: transparent url(test-3.jpg)
    -283px -200px no-repeat;}

Puryści i fanatycy optymalizacji już w tym momencie powinni (już możecie) złapać się za głowę. Ale to nie nieoptymalny zapis jest problemem; prawdziwy problem rodzi się, kiedy chcemy skorzystać z tego rozwiązania w serwisie, w którym nasz plik z “duszkami” ma ponad 350kb, przeciętny obiekt wycinany z pliku ma wymiary rzędu 250×160px a takich wycinanek mamy na jednej podstronie około dwudziestu.
W przeciwieństwie do demonstracyjnego pliczku (parę kb) załadowanie takiego potworka chwilę zajmuje i – jak się okazuje – wpływa na sposób budowania strony… w Firefoxie.

Chcieliście napisać: no jasne, że w Internet Explorerze? Właśnie nie. Ten – o dziwo – renderuje stronę tak, jak byśmy chcieli: po załadowaniu pliku, pojawiają się wszystkie elementy graficzne. Od razu. Ale nie w Firefoxie; Firefox wycina je po kawałku tak, jak by nic się nie zmieniło.

Ok, co jest źle z tym zapisem? Przede wszystkim: zupełnie zbędnie powtarza się ten sam kawałek kodu tylko po to, by zmienić jedną/dwie wartości. Deklarację tła i jego powtarzanie możemy przenieść w jedno miejsce tak, by później tylko deklarować co chcemy wyciąć z tego pliku. Poprawniejszy zapis, może wyglądać tak:

#panel1b, #panel2b, #panel3b, #panel4b {
background: url(test-3.jpg);
background-repeat: no-repeat;
}
panel1b {
background-position: 0 -200px;
}

…

I to jest rozwiązanie warte kilka sekund renderowania strony. Firefox nie lubi się z powtarzaniem całej deklaracji ładowanego tła – za każdym razem otwiera plik z grafiką, wycina i wkleja potrzebny fragment wydłużając cały proces w swoistą “nieskończoność”. W moim przypadku, zmieniając deklarację udało mi się zejść z 16-20s renderowania strony (wg YSlow) do 6.

Nie chodzi o możliwości, kod czy rozwiązania. Grono kopiuje lepiej bądź gorzej, ale też nie można nie przyznać, że trochę dobrego chłopaki i dziewczyny z tego projektu zrobili.

To, z czym kompletnie sobie nie radz,ą to zarządzanie informacją. To PR. Jest hype a grono milczy. Od razu przypomina mi się ten obrazek:

z xkcd

Jak kilka słów może diametralnie odmienić sens wypowiedzi, dowiedzieć możemy się z tekstu Microsoft: 2400 stron jest niekompatybilnych z najnowszym IE na Gazeta Technologie.

Czytając, uświadmiamy sobie, że nadchodzi apokalipsa a Microsoft znów jest tym złym, który jeszcze śmie mówić, że tysiące stron w Internecie jest niekompatybilna z jego najnowszym produktem, kiedy to sam, przez lata, olewał standardy. Chciałoby się powiedzieć: standard. Chwytliwy tytuł jest, sensacja w treści jest, popularność leci, wierszówka też i wszystko dobrze. Ale wystarczy zajrzeć na stronę ZDNet na którą powołuje się autor artykułu, by zauważyć, że pozwolono sobie na pewne “semantyczne nadużycie”. W oryginale wspomina się bowiem o IE8 w trybie “standards-mode”, który łamie kompatybilność ze starszymi wersjami IE.

Jak wiemy, Microsoft chce nadgonić stracony czas i IE8 ma zawierać całą masę poprawek w sposobie renderowania stron zgodnych ze standardami, by w końcu przestać być utożsamianym z najbardziej problematyczną przeglądarką na rynku. Poprawienie setek błędów, które przez lata zostały uznane za standardowe zachowanie oznacza, że większość (jeśli nie wszystkie) haki na IE w IE8 przestaną działać co z kolei oznacza, że jeśli strona została źle zaprojektowana – prawdopodobnie rozpadnie się w mniej lub bardziej efektowny sposób.

Dlatego została opublikowana lista stron “niekompatybilnych”, którą można pobrać i zainstalować w IE. Jeśli zdecydujemy się na instalację i wejdziemy na “problematyczną stronę” – IE8 wyrenderuje ją w sposób zgodny z IE7.

Chcąc liczyć się na rynku przeglądarek, Microsoft musiał zdecydować się na lepszą obsługę standardów, nawet kosztem zerwania kompatybilności ze starszymi wydaniami IE.
Lista kompatybilności to dobry kompromis a dodatkowo także autorzy stron mogą powiedzieć – na przykład, za pomocą dyskusyjnego tagu X-UA-Compatibile – IE8, że nie mają czasu by odgruzowywać kod i usuwać haki, więc niech będzie tak miły i grzecznie pokaże stronę jak IE7.

Do całej sprawy odniesiono się także na oficjalnym blogu IE, podając “po prostu fakty” w notce: Just The Facts: Recap of Compatibility View, z której dowiemy się więcej na temat problemu, z perspektywy tych, którzy IE8 tworzą.

• Microsoft’s IE 8 incompatibility list: 2,400 major sites (and counting)
• Just The Facts: Recap of Compatibility View
• Microsoft: 2400 stron jest niekompatybilnych z najnowszym IE

Dobry beta tester to prawdziwy skarb i wie o tym każda firma czy zespół, który po długich poszukiwaniach taką osobę znalazł. Niestety, zwykle ta pozycja jest nieobsadzona albo obsadzona niewłaściwymi ludźmi, którzy sieją zamęt. Dość powszechny jest pogląd, że betatesterzy to zbytek luksusu – ich pracę mogą wykonywać członkowie zespołu rozwojowego danej aplikacji.

Jaki więc powinien być dobry beta tester?

Powinien być członkiem zespołu deweloperskiego

Niekoniecznie. Właściwie, w większości przypadków, lepiej kiedy nie bierze udziału w rozwoju aplikacji. Choć wydaje się, że powinno być inaczej, to autorzy aplikacji są zwykle najgorszymi beta testerami. Oni po prostu znają ją na wskroś i przeglądając aplikację, poruszają się po ściśle określonych ścieżkach – generują nadzwyczaj mało przypadkowych kliknięć. Jako autorzy, doskonale wiedzą gdzie należy kliknąć by osiągnąć właściwy wynik.

Powinien być techniczny

Niekoniecznie. Pogląd ten bierze się z tego, że osoba techniczna szybciej i jaśniej wytłumaczy problem niż nietechniczna. I owszem, często to prawda. Równie często osoba techniczna stosuje skróty myślowe bądź pomija błędy, które w jej ocenie są “oczywiste i na pewno koledzy już nad nimi pracują”. Użytkownicy Waszej aplikacji nie muszą (zwykle: nie są) techniczni.

Powinien być ciekawski

Oglądaliście Dexter’s Laboratory? Pamiętacie sceny z DeeDee, głupiutką siostrą Dextera, która niszczyła piękny sen Dextera tekstem “Oohh, what does this button do?”. Mniejsza o to, dlaczego przycisk autodestrukcji był zawsze niechroniony i ściagający wzrok – Wasze aplikacje są lepsze, ale również nie pozbawione takich przycisków. Wy wiecie czego nie klikać a wasz idealny betatester właśnie to kliknie. I o to tu chodzi.

Powinien mieć dużo czasu wolnego

Koniecznie. Nie macie czasu? Zapomnijcie o beta testowaniu czegokolwiek. Powszechny błąd to myślenie, że “mogę się przeklikać przez tą aplikację w 15 minut”. “Przeklikać się” przez aplikację może każdy z nas, z różnymi efektami – nie o to tu chodzi. “Przeklikanie” to dopiero początek – trzeba jeszcze przekazać tę informację do zespołu i zrobić to w zrozumiały sposób. Tu zwykle okazuje się, że ochoczy beta bester “z tłumu” nie ma na to czasu albo mu się nie chce: “przecież to widać”.

Powinien… dobrze pisać

To absolutna podstawa. 37signals w Getting Real; stwierdzają “Zatrudnij dobrze piszących (Hire good writers)” i mają rację.

Dobry beta tester pisze bardzo dużo i bardzo dobrze. Raport od dobrego betatestera jest zwięzły, rzeczowy i zawiera między innymi:

• informacje o środowisku w jakim testował,
• informacje o napotkanych problemach,
• ścieżkę “krok po kroku” co zostało kliknięte, jakiego efektu się spodziewał, jaki efekt otrzymał

Pracując jeszcze przy grach komputerowych, spotkałem się z poglądem osoby, która rekrutowała betatesterów, że wybiera tylko tych, którzy potrafią się dobrze komunikować. Mogą nie mieć doświadczenia, mogą być kompletnymi laikami w sprawach którymi przyjdzie im się bawić ale nie mają najmniejszego problemu w przekazywaniu informacji. Pamiętaj, że błąd w aplikacji, nad którą zespół pracował wiele dni jest już wystarczająco stresującą sytuacją – oszczędź im kolejnych stresów związanych z próbą zrozumienia twojego zgłoszenia.

Może być twoim przełożonym

Lepiej nie. W zespołach w których nie chce się zatrudniać testerów, rolę tę przejmują przełożeni. I zwykle, jest to początek końca. Nikt nie lubi błędów a już w szczególności nie lubią ich ludzie, którzy muszą się ładnie uśmiechać do klientów/zarządu. Jeśli więc przytrafi się wam błąd, możecie być pewni, że jego znaczenie zostanie wyolbrzymione a wasze umiejętności podważone. Drugim słabym punktem jest brak czasu. Feedback przyjdzie skrótowy, enigmatyczny i z poślizgiem. Albo z informacją, że błędy są “widoczne na pierwszy rzut oka”.

Podsumowując

Błędy zdarzają się wszędzie – nie widziałem jeszcze aplikacji, która byłaby ich pozbawiona. Przyczyn tego stanu rzeczy są setki: brak czasu, brak narzędzi, brak doświadczenia, złe założenia, zmiany koncepcji w trakcie trwania prac nad kodem i tak dalej. Serio, błędy były, są i będą. Możesz jednak uniknąć części problemów, zatrudniając dobrych beta testerów. Jeśli nie stać cię na nich – możesz nimi uczynić swoich użytkowników. Z oczywistych względów, zadziała to tylko w przypadku określonego typu aplikacji.

A jeśli chcesz zostać beta testerem albo chcesz wiedzieć więcej, jak najlepiej zgłaszać błędy, poczytaj – stary już – tekst: jak efektywnie zgłaszać błędy.

• Jak efektywnie zgłaszać błędy
• Uservoice.com – aplikacja do zgłaszania feedbacku, do osadzenia na stronie.

Od dnia kiedy rozpoczęliśmy tłumaczenie Getting Real od 37signals minęły już dwa lata (właściwie to nieco ponad). Choć przez długi czas wydawało się inaczej, to jednak uda się je skończyć…

Tłumaczenie z przygodami – tak mógłbym w skrócie je określić.

Na początku tłumaczyłem GR sam, później pomagał mi Kuba Filipowski, z którym mieliśmy nadzieję wpiąć tłumaczenia w traduko.info. Niestety, na drodze realizacji tego pomysłu stanęły problemy licencyjne – padło więc na Wiki.

Mediawiki to nienajlepsza platforma do tłumaczenia książek – wszystko ponad standardową edycję i składnię jest dość zawiłe. Poza tym, to armata na komara. Jednak sam wybór wiki był dobry – umożliwiło to wprowadzenie większej liczby ludzi do projektu tłumaczenia i kontrolę nad tym, co w tłumaczeniu się dzieje.

Bardzo dobrym pomysłem było przygotowanie słowniczka trudnych pojęć i próba narzucenia sobie wzajemnie pewnego standardu tłumaczenia. A było o czym dyskutować: czy zwracać się bezpośrednio do czytelnika, czy stosować formy grzecznościowe, czy zmieniać nazwy serwisów na te, które lepiej przemawiają do naszego czytelnika (ot, choćby Facebook > Nasza-klasa). Język angielski jest elastyczniejszy jeśli chodzi o pisanie o technologii. To, co mnie osobiście rozbrajało w niektórych esejach to pseudo-metaforyczne tłumaczenia problemów, które po angielsku są oczywiste i brzmią doskonale. Po przetłumaczeniu na polski – już nie bardzo, niestety. Wypadało zgodzić się z Wolterem: “Tłumaczenia są jak kobiety – piękne nie są wierne; wierne nie są piękne” i zachowując sens i kontekst, stworzyć dany fragment od początku.

Niezłym pomysłem było także dostosowanie się do zagadnień, które zostały zawarte w książce – np.: mając już relatywnie ponad połowę tłumaczenia, postanowiliśmy zacząć wrzucać gotowe fragmenty na stronę Getting Real. I może by to pomogło, gdyby nie pewne ale.

Pierwszym problemem był czas wolny. Właściwie każdy z nas, miał pewien limit czasu wolnego, który mógł przeznaczyć na tłumaczenie.
Drugim problemem była technologia, co jak się okazało, było naszym głównym problemem. Te dwa problemy nałożyły się w momencie, kiedy wiki z tłumaczeniem, trzymane na Dreamhost – padło. Odzyskiwanie danych zajęło długie… miesiące, w czasie których wszyscy się rozeszli, pozmieniali prace, pozakładali rodziny, stali się mikrocelebrytami. Ogólnie: żyli długo i szczęśliwie.

To, co udało się odzyskać z backupów, ustawiłem u siebie i – spędzając wolne wieczory i noce – uporządkowałem, podzieliłem na kategorie i dotłumaczyłem stracone fragmenty oraz te, które nie doczekały się tłumaczenia w ogóle.

W momencie kiedy piszę te słowa, stan tłumaczenia Getting Real to ponad 70 przetłumaczonych esejów, 60 oznaczonych jako wymagające korekty i 2 nieprzetłumaczone/przetłumaczone w połowie. Faktycznie wymagających korekty jest połowa, może nawet mniej – wrzucone są do jednego worka bo i tak trzeba przeczytać je raz jeszcze.

Teraz trzeba wszystkie eseje przejrzeć raz jeszcze, uspójnić, ewentualnie poprawić interpunkcję czy stylistykę. Może świeże spojrzenie umożliwi też znalezienie lepszych tłumaczeń fragmentów już przetłumaczonych.

Jeśli więc czujesz się na siłach by pomóc doprowadzić to nieszczęsne tłumaczenie do szczęśliwego końca – przyda się Twoja pomoc.

W szczególności mile widziane są osoby, które kiedyś już tłumaczyły z nami GR, a na które nie mam już namiarów.

Jeśli chodzi o projekty wykluwające się w kraju nad Wisłą, to wciąż jest mizernie (choć coraz ładniej). Jeśli zaś chodzi o liczbę konferencji o nich traktujących – tu mamy się czym wykazać. Możemy wręcz aspirować do ścisłej światowej czołówki.

Skacząc z imprezy na imprezę, każdy członek ekipy danego startupu, może poczuć się jak prawdziwy entrepreneur: laptop na kolanach, krótkie rozmowy telefoniczne rozpoczynające się “szybko, bo właśnie jadę pociągiem do [tu wstaw miasto kolejnego *campu]” – w skrócie: czuje się ten profesjonalizm i zapracowanie.

Raczej nie wypada pytać o to, kto będzie prezentował się na kolejnej imprezie. Może się okazać że to XY, który będzie mówił o ABC, o którym mówił dwa dni temu na innej imprezie i z którym możemy się skonsultować, bo właśnie siedzi dwa przedziały dalej. A w ogóle to nasz znajomy z liceum.

Oczywiście, nie chodzi o to, że imprezy nie są fajne. Niektórzy ludzie mają dar inspirowania innych i prezentacji na temat ich startupu czy idei można słuchać w nieskończoność. Zastanawiam się tylko, czy nie przekraczamy pewnej masy krytycznej, po przekroczeniu której, czeka nas tylko wtórność.

A że mogę się mylić, to wkrótce pewnie zatrudnię kogoś, kto objedzie wszystkie ciekawsze imprezy i zda relację. Może przy okazji powstanie jakiś projekt, który przeanalizuje kalendarz róznorakich *campów, auli itp konferencji i na podstawie aktualnego nastroju zasugeruje gdzie warto się pojawić, pozwoli zarezerwować bilet i magicznie wykona wszystkie blokujące zadania w pracy, albo za kliknięciem przycisku zrealizuje kolejny fajny startup, o którym będzie można coś ciekawego powiedzieć…