Ola Kunysz

Kiedy zaczęłam czytać Async Remote, już na początku uderzyło mnie coś, na co wcześniej nie zwracałam uwagi. Mimo kilkuletnich doświadczeń ze SCRUM'em, nigdy nie zauważyłam niszczącej mocy słowa  sprint . Faktycznie jest tak, że kiedy scrumowy sprint się kończy, to od razu zaczynamy następny. Niektóre zespoły mają nawet demo, retrospektywę i planowanie tego samego dnia. Wrażenie ciągłego pośpiechu może i powoduje ekscytację i poczucie produktywności, ale na dłuższą metę bardzo męczy. Bo, jak po każdym sprincie, należy się długi odpoczynek, czas na regenerację mięśni i przewietrzenie głowy. Inaczej możemy doprowadzić do wypalenia. Jest jeszcze jedna nienaturalna rzecz w sprintach, czyli podział pracy. Zazwyczaj nie zaczynami, ani nie kończymy zadań w tym samym momencie, a do tego jesteśmy zmuszeni. Może to powodować frustracje, a nawet wzajemne obwinianie w przypadku "niedowiezionego" sprintu. Ciekawe jest też podejście autorów książki do składu i obowiązków zespołu. Dopi...

Kiedy pracujesz w zespole, w którym pięć osób przebywa w trzech strefach czasowych, mówi natywnie trzema językami i pisze kod w trzech innych, uświadamiasz sobie co tak naprawdę jest ważne w pracy. No bo nie osiem godzin spędzonych biurko w biurko, na piciu kawy i wspólnych posiłkach w firmowej kantynie. Ważne jest zaufanie. Zaufanie zdobyte pracą, uczciwą komunikacją i przezwyciężonymi problemami. Trochę nam się rozrósł zespół i postanowiliśmy się podzielić po 4-5 osób. Ja trafiłam do grupy, w której tylko jeden kolega, tak jak ja, pracuje we Wrocławiu, ale akurat postanowił wyjechać na workation do Tajlandii. Stało się bez znaczenia, czy pracuję z biura, z domu, czy z kawiarni. Ważne, żeby dostarczać dobry kod i żeby mój element układanki pasował do innych. Nie jest to takie oczywiste, bo komunikacja przy pracy całkowicie zdalnej ma inny wymiar. Dojście do konsensusu, kiedy wszyscy mówimy drugim dla siebie językiem jest co najmniej utrudnione. Mimo, że każdy z nas ma biegły angiels...

Podczas moich kilkudniowych zmagań z postawieniem aplikacji na Heroku były komendy i zaklęcia, których używałam częściej, niż innych. Były też przekleństwa, których używałam równie często, ale to nie czas i miejsce na taki post. Napotkałam też kilka problemów, które wymagały mniej lub więcej googlowania. Na przykład: app[web.1]: Exception in thread "main" com.typesafe.config.ConfigException$Missing: No configuration setting found for key 'youtube' Rozwiązaniem jest dodanie zmiennej środowiskowej. Można to wyklikać w Heroku, ale najprostsze rozwiązanie to: $ heroku config:set youtube.apiKey="xyz" # dla jednej z kilku aplikacji, będzie analogicznie heroku config:set youtube.apiKey="xyz" --remote speech-rank-api Innym problelem, który napotlałam na początku był brak dyno'sów, objawiający się takimi oto błędami: heroku[router]: at=error code=H14 desc="No web processes running" method=GET path="/favicon.ico" host=sp...

Trochę się nagimnastykowałam, próbując różnych rozwiązań, żeby uruchomić równocześnie Gradle i NodeJS na tej samej platformie. Niestety w darmowej wersji Heroku jest to niewykonalne. Każdy z tych wątków musi być uruchomiony na dyno typu web , żeby posiadał adres inny, niż localhost. Postanowiłam stworzyć dwie aplikacje na Heroku, speech-rank i speech-rank-api . Składnia jest dość toporna, bo przy tworzeniu wielu aplikacji dla tego samego repo trzeba  $ heroku create --remote speech-rank-api speech-rank-api pierwsze speech-rank-api odwołuje się do nazwy roboczej, której będziemy używać w konsoli, drugie do nazwy aplikacji na Heroku.  Zmieniłam też sposób uruchamiania aplikacji na Express , żeby łatwiej było ładować statyczny kontent i mój index.js wygląda następująco: var express = require('express') const path = require('path'); var app = express() app.set('port', (process.env.PORT || 80)) app.use(express.static(path.join('.', 'build...

Słowa na dziś: dyno i buildpack . Walka z Heroku trwa, deployowanie aplikacji w kilku technologiach jest dość skomplikowane, albo wielkanocne babki uruchomiły już bombę insulinową... Zaczęłam trochę od końca, bo najpierw ustawiłam buildpacki  $ heroku buildpacks:set heroku/nodejs $ heroku buildpacks:add --index 1 heroku/gradle Później zorientowałam się, że potrzebuję coś, co nazywa się Procfile  (nie mylić z   procfile , Procfile.txt , albo Procfile.conf ). Tam należy określić, jakie komendy mają być wywołane, żeby stworzyć dynos . Dyno to linuxowy kontener, który wywołuje pojedynczą komendę, taka zakładka terminala.  Ja określiłam najpierw buildpacki. Pięknie wykonywał mi się build, najpierw gradle, później node na podstawie skryptów z package.json "scripts": { "local-web-server": "ws -d build/web", "gulp": "gulp", "build": "gulp", "start": "npm install", "postin...

Postanowiłam dodać logowanie do SpeechRank za pomocą Twittera. Do tego potrzebna jest implementacja OAuth, która wymaga własnego kawałka miejsca w internecie. Można tego dokonać z poziomu localhost'a, ale skoro już rzucam się na głęboką wodę i jest to dla mnie czas nauki, postanowiłam, że miejscem dla mojej aplikacji będzie Heroku . Kiedyś postawiłam tam projekt w Railsach, ale jeszcze nigdy nie budowałam tam gradlowo-nodowej aplikacji.  Heroku jest platformą, która pozwala na budowanie i deploy'owanie aplikacji w chmurze. Można ją skonfigurować, żeby współpracowała z Travisem, o którym pisałam niedawno . Heroku trzeba zainstalować, na przykład za pomocą brew , a potem stworzyć projekt, ja wpisałam w ścieżce do mojej aplikacji $ heroku create speech-rank $ git push heroku master Zauważ, że wskazujesz, jaki branch ma być deployowany. Czyż to nie cudowne, że mogę to modyfikować i wrzucać feature branch'e, żeby je tam przetestować? Zwłaszcza, kiedy testowanie wymaga ki...

Odkąd rozwijam aplikację SpeechRank  do oglądania wystąpień z konferencji, inaczej patrzę na prelekcje. Akurat trwa  Scalar , podczas którego nagrywani prelegenci  uczą i  bawią  publiczność monadami, makrami, typeclass'ami i innymi czeluściami języka. Tyle, że wszystkie te elementy (jak kiedyś wspominał Michał Płachta ) wchodzą w skład złożoności przypadkowej. Natomiast złożoności właściwej, mającej związek z problemami natury biznesowej w wystąpieniach jest jak na lekarstwo. Historie z bitew i wojen wygranych na produkcji po krwawych starciach z kompilatorem, bibliotekami, lambdami, aktorami i Future' ami są raczej w mniejszości.  Myślałam przez chwilę, że może ta społeczność gardzi kodem produkcyjnym, uznając za punk honoru pull requesty do Akki . Albo, że to przez fakt związania Scalara z jedną technologią. Ale jak sięgam do wspomnień z innych konferencji, to wszędzie jest podobnie. Co ciekawe, najchętniej oglądamy wystąpienia z praktycznymi wsk...