Архив недели @freiksenet
Понедельник
В Финляндии неожиданно началось лето, а тут начался @freiksenet. Привет уютному чату!
Меня зовут Михаил Новиков, в интернете я везде freiksenet. Я разработчик, в основном на JS. Живу в Финляндии уже 12 лет, переехал из СПб.
Я работаю в своём стартапе, https.//reindex.io. Мы делаем BaaS для реакта на основе GraphQL. Пишем на node + hapi + rethinkdb.
Планы на неделю - поговорить о GraphQL и Relay, про жизнь и IT в Финляндии, пофлеймить про то что я не люблю - например Angular, gulp/grunt
Я мог бы поговорить про реакт, но после @dan_abramov, @andreypopp и @deepsweet мне сложно что-то добавить. Реакт крутой, юзайте его :)
"Just say no" to babel?stage=0 in production.На выходных в английском твиттере было аж два срача - сначала про babel и использование stage 0 преобразований mobile.twitter.com/ryanflorence/s….
@codinghorror @jeffkibuule @tomdale safari is still the king of real-world perf.
Второй про то достаточно ли V8 оптимизирует "реальный код", а не только микробенчмарки. mobile.twitter.com/wycats/status/…
Про babel - мы юзаем и на клиенте и на сервере, stage 1. async/await это невероятно удобно при работе с базами данных.
aahhh so much better pic.twitter.com/bA4SdwmOoB
Милый трюк с console.log и function bind в бабеле. twitter.com/freiksenet/sta…
Расскажу про GraphQL и почему он нам так нравится. Меня можно назвать не модным уже именем full-stack developer или модным product developer
Я пишу фронтенд, часто я так же писал и бакенд. Как минимум я правил бакенд или пинал бакендеров, чтобы они его правили.
Очень частая история - сделал REST API, все чистенько и по спеку. Начал писать фронтенд - нужны еще эти связанные данные или это поле.
Начинаешь править бакенд, эндпоинты становятся намного менее чистыми и с кучей странных параметров. Или просто толстыми и возвращают все.
Еще веселее ситуация, когда бакенд команда отделена от команды которая делает приложения. Каждый запрос на новую фичу вызывает недовольство
В итоге хачишь workaround-ы на фронтенде и все глючит и тормозит.
Фейсбук (и например Netflix) решили что хватит это терпеть и придумали, соответственно GraphQL и Falcor.
GraphQL позволяет на сервере описать все данные, которые доступны и их связи. Клиентское приложение может одним запросом взять что ему надо.
Поменялись требования или компонент? Просто добавь или удали поле в запросе.
А бакендеры написали один ендпоинт и просто добавляют туда фичи, когда они становятся доступны.
Несколько ссылок - introduction от FB.
facebook.github.io/react/blog/201…
Программный пост от нас.
reindex.io/blog/how-faceb…
Референс имплементация
github.com/graphql/graphq…
Вот только что запостил гайд, как писать простой сервер на надо юзая reference implementation.
reindex.io/blog/building-…
Я понял что я неправильно отвечал на вопросы. Woe on me! Можете почитать все в tweets and replies. Теперь буду старатся правильно.
Это было в ответах, но вынесу сюда. Мы начали стартап почти сразу после первого talk-а на конференции про GraphQL.
Ловили GraphQL запросы из мобильных приложений FB, читали блог посты, сделали свою имплементацию до выхода спека.
Что вы делали крутое не-веб в своей карьере? Я работал в zenrobotics.com, писал код для роботов сортирующих мусор на clojure.
Если что - сортирующих мусор физически, IRL. Я не про garbage collection :D
Так что надо будет просто написать такой Mutation который правильно изменяет несколько обьектов.
Вообще GraphQL не отвечает на эти вопросы напрямую. Главная идея что ты написал свои типы данных и связал их с базой данной @snejink
Потом клиент уже просто этим пользуется, тебе не надо ничего менять.
Но при этом то как ты решишь у себя внутри проблему с permissions - это не то что GraphQL решает, это решает твой бакенд.
В этом прелесть GraphQL - он не навязывает как тебе все сделать, только как это показывать клиенту и как клиент это будет запрашивать.
Надеюсь нормально обьяснил, запутанно получилось.
Важно понять про GraphQL, что это не SQL. Это намного ближе к WSDL, чем к SQL, такой WSDL для хипстеров)
Это не общий язык для запросов данных. Скорее язык для описания удобных для использования RPC серверов.
Ну и язык для использования этих RPC серверов, да.
Они немного раскрыли тему в личных разговорах, плюс мы читали де-минифицированный код, но деталей про интересные вещи не очень много.
Итак Relay - клиентская библиотека от ФБ, должна очень круто работать с реактом и graphql.
Еще не вышла :( Базовая идея - компоненты сами описывают свои требования кусками GraphQL запросов, Relay их умеет собирать и запрашивать.
Relay обещает делать кеш, pagination (судя по всему больная проблема в ФБ), и оптимистичные модификации на клиенте.
Если про первые две вещи все в целом ясно, то про клиентские мутации известно только то, что у них будет клиентский id :)
Кеш будет сделан через уникальный id для каждого обьетка возвращаемого relay-compatible сервером. id похоже будет содержать в себе тип.
Pagination - для страничных вещей, для каждого обьекта возвращается курсор - непрозрачный id, который можно дальше передавь для листания.
Вероятно в курсоре будет хранится тип и текущая сортировка (или/и фильтр).
Самый подробный набор примеров про Relay
facebook.github.io/react/blog/201…
Про relay и мутации - раз у нас есть уникальный кеш, мы можем даже при мутациях которые меняют несколько обьектов обновить наше состояние.
Достаточно денормализовать данные полученные с сервера и обновить наше представление по id для каждого отдельного элемента из этих данных.
Что пока не понятно - это как именно происходит оптимистичное обновление до этого.
Спасибо @deepsweet, забыл совсем про эту презентацию. Немного больше всего известно про мутации, чем я сказал сначала)
tl/dr - Relay заменит flux, GraphQL заменит REST и всем нам будет нирвана и полный React. :)
Ну вот в Relay будет какой-то процессинг, хотя бы денормализация для кеширования. @deepsweet
Бесстыжая реклама - reindex.io будет поддерживать relay как только relay выйдет :)
Возможно. Может в Relay будет возможность хранить такое состояние. @vslinko. В любом случае клиентское состояние это намного проще.
Прелесть GraphQL что можно смотреть куда тебе удобно, это implementation detail @MaximSukharev
Может им показалось что так удобнее писать. JSON не самый удобный формат для программирования. @MaximSukharev
Улучшаем мир, one company at a time. @Barlog_M
Несмотря на твиттер, день прошёл продуктивно. Ребейзнул и починил бранч с аутентификацией на версию с graphql-js. А что вы сегодня сделали?
Но это зависит от того что за база данных, я бы например mongoose выбросил и написал типы заново, а из sql базы генерил.
В любом случае надо генерить побочные типы, типа InputObjectType или Connection. @roman01la
Вторник
Доброе утро уютный чатик! Сегодня у нас день срачей :) По просьбе @vladimore я расскажу почему я не люблю Angular.
Начну издалека, люблю истории. Вот реакт многие засирают за jsx, типа html в коде, фу. И это при том что jsx это трансформ в js.
А в ангулар магический код в виде html атрибутов, который запускается чуть ли не eval, который не отдебажить и который не js, но это ок %)
Да, я про filter и иже с ними.
Реакт очень активно заставляет программиста делить все на компоненты. refы намерено имеют минимальный функционал, чтобы даже не пытались.
В ангулар туториалы предлагают писать толстые контроллеры, а интерфейс написания директив (компонентов) как будто намеренно ужасен.
Заметьте я ещё ни разу не сказал 'ангулар тормозит'. Все чисто с точки зрения программиста.
Дальше - у ангулара свои модули, своя система DI, свои тесты, свое все. Какая-то фабрика велосипедов.
DI это отдельная история, мне иногда кажется что оно в ангуларе, чтобы пугать людей и заставлять думать что раз так сложно то видимо круто.
Но я отдам ангулару должное, формочки в нем делать быстро и просто. В реакте до сих пор нет хорошей и простой либы для форм. :(
Но SPA в современном мире это не только формы и это ограничивает использование ангулара.
Прекрасный коммент про N+1 и GraphQL. reddit.com/r/reactjs/comm…
Ну я заметил что я слишком часто начинаю ответы с ну. :)
Мирно закончили срач про ангулар, но не волнуйтесь, у меня ещё несколько срачей запланировано на сегодня :)
То есть кто-нибудь с миллионами пользователей. Я знаю что ангулар очень популярен в кровавом энтерпрайзе.
Самый простой троллинг ангулара - спросить почему гугл сами до сих пор его не юзают :P С реактом к ФБ такого нет, они едят свой dogfood.
Для тех кто в танке - Elisa это местный большой телеоператор. Кстати я там отдельно взятый проект таки перевел на реакт.
Естественно если был выбран ангулар когда-то и на нем тысячи кода, то надо пилить на нем. Перепись всего заново и с нуля редко оправдана.
Я просто предлагаю взглянуть на альтернативы когда будете начинать новый проект.
Новая тема для срача - coding style. Какое самое срачеобразующее правило в вашем coding style? У нас, например, обязательные trailing comma.
Заодно скиньте ваш .eslintrc/.jscsrc/.jshintrc etc. Вот наш. gist.github.com/freiksenet/464…
Trailing comma, кстати, чтобы диффы были красивые. :)
Лучший аргумент за ; это правило в standard style - 'never start a line with ( or ['. Правило, чтобы исправить что ты натворил в предыдущем.
Самый sensible 'общий' стиль который я видел это airbnb. Почти все по делу. github.com/airbnb/javascr…
Помню делал консалтинг в стартапе, где был кофескрипт и 4 пробела индент.
Мой ко-фаундер даже на
e ругается переодически :) А вообще, читабельные названия переменных - наше всё.Кстати мы очень любим code review. Мне кажется это очень помогает, чтобы код катился в легаси медленнее.
RE: code review i.imgur.com/eBBAUct.jpg
Сейчас уже поздно, это было у одного из клиентов.
Нашествие любителя Ember в ответах. Все что он говорит про Эмбер я могу сказать про Реакт.
Надо брать что лучше знаешь или что больше понравилось после туториала. Ember хороший фреймворк. React для меня лучше.
Экономия на длинне переменных - головная боль для читателя в будущем. Пишешь один раз, читаешь 100.
С префиксом component они все одинаково начинаются, удобно группировать.
Среда
Доброе утро! Сегодня у нас эмигрансткий день. Как я говорил, я в Финляндии 12 лет из 28, живу здесь всю учебу и карьеру.
Язык я знаю плохо. В IT тут не надо язык знать если ты нормальный программист, но базу знать полезно чтобы заполнять формы и читать ценники.
В Финляндии хорошо если ты любишь единение с природой и когда мало людей. Хельсинки пытается быть хоть немного городом, но фейлит.
Тут безопастно, отличное образование, хорошая медицина, очень хорошее все для размножения. Но бывает скучно, концерты сюда не приедут.
Стартапы сюда доходят медленно, разнобразие всего тут намного меньше чем в Мск или в Питере. Например доставка еды только щас развивается.
В принципе IT развито, есть достатчно хорошее стартап комьюнити, проходят конференции, есть местные инвесторы и не-местные знают про нас.
Налоги тут высокие, но если смотреть на все Европу, то достаточно средние для развитых стран. В Дании, например, выше. В Чехии сильно ниже.
Интересный факт, который вымораживает русских - зп тут называется до налогов, тк налоги это твое дело и твой рабодатель про них не знает.
Так что ждите получить 3к евро чистыми после названной зп в 5к.
Русские в IT и науке тут бывают (иногда) нормальные, остальные эмигранты больше любят Путина, чем самый ватный ватник в России.
Я кончил, можете задавать вопросы.
Про дискриминацию, заранее отвечу - нет, тут не отминают детей просто так, как в целом, так и у русских.
В YC точно не возьмут :D @beshkenadze
Это евро-двушка. В спальных районах можно найти за 700€. В остальном - алкоголь очень дорогой. Остальное по-моему окей. @smashercosmo
Вообще, думаю одному можно достойно жить на 2000 чистыми (~3300 до налогов), вдвоем на 3000 (~4500). @smashercosmo
Закончим с политотой, перейдем к пятиминутке ненависти. Ненавижу когда просят чтото установить глобально (типа npm install -g).
Это отличная дорога в ад из-за несовместимых версий тулзов в проектах. Есть ./node_modules/.bin и npm scripts. Только локальная установка!
Кстати npm scripts еще может заменить ненужный gulp/grunt. gulp/gruntfile это всегда каша. webpack для сборки, npm scripts для запуска.
Это кстати еще до выхода babel конфиг. Старые добрые времена.
Еще пример scripts с большим количеством вещей:
gist.github.com/freiksenet/773…
Всё большое можно перенести в отдельные скрипты, либо баш либо просто js. Гарантирую что будет чище чем писaть это gulp-ом.
Четверг
Доброе утро! Сегодня мы поговорим про Webpack и почему это наш выбор для сборки фронтенда.
Начну опять издалека. У фронтенд ассетов есть некая дихтомия, javascript уже давно собирается каким-то способом, а все остальное нет.
И к js модулям все привыкли, тут миллионы решений, от того же webpack-а до require.js до browserify. Все модули на любой вкус.
С css-ом или например картинками или шрифтами все поступали более грубо. Возможно был список файлов и гулп или грунт делали над ним магию.
Очень просто было забыть что-то добавить. Оч!ень просто было налажать с путями на другие файлы из css. Очень тяжко было добалять либы с css.
webpack решает эту проблему убирая это различие между js-м с модулями и другими ассетами. CSS это такая же зависимость проекта как и js.
Шрифты, картинки, все что угодно - это зависимости и их можно require так же как javascript. Нет больше независимого списка файлов.
Дальше больше - url внутри css-a это такой же require. Можно не думать о том что ты перепутаешь путь в сервере.
В собранном css-е будет ссылка на (возможно захешированный) файл с картинкой или шрифтом. Просто отдавай весь build folder и будет счастье.
Темплейты - такие же зависимости. Просто requirе и пользуйся. Никаких магических путей в твоем коде, никаких кривых поделок типа icanhaz.
Кстати такая модель с зависимостями отлично ложится на реакт. Один компонент, один css/less файл.
Oстальные плюшки webpack-а, типа hot reload, code splitting - вишенка на торте. Главное - возможность все выражать через зависимости.
Иногда мне кажется что аудитория jsunderhood на 90% состоит из бывших сотрудников яндекса и соответственно бывших БЭМ разработчиков.
Яндекс это как Нокия у вас? Если не работал на прямую, то как минимум заляпался через консалтинг?
У нас до развала Нокии половина IT индустрии на нее работало. Очень рад что она сдохла, народ хоть делать что-то начал свое.
ИМХО сейчас в стилях сейчас важнее сделать все модульно и чтобы поддерживать просто было. А с этим программисты обычно лучше справляются.
JSON все-таки убогий формат, жаль что мы так широко его используем.
Как-бы ты не сериализовал, рано или поздно нужна будет схема, даже для сериализации. Почему бы не начать с формата в котором она есть?
Появился у тебя datetime в json, сразу у тебя кастамный код на клиенте и на сервере чтобы правильно его (де)сериализовать.
В JSON многих подкупает что типа сериализации without any effort. Вообще это неправда, любая сериализация требует обработки твоих данных.
Если ты просто делаешь JSON.stringify на свои объекты, ты не сериализируешь, а блюешь своими данными наружу.
Это особенно заметная проблема в js или например в питоне, в Java или Haskell (де)сериализация обычно domain-specific.
Как научится хорошо делать code review? Мне повезло с коллегами, на всех прошлых работах с code review были такие, кто это делал круто.
Наверно надо быть садистом с OCD, чтобы это делать правильно. Но это реально работает. Переодически очень бесит, но код реально лучше.
У меня вот редко получается так тщательно делать code review, больно добрый может.
Тут много кто ответил про JSON. Я не говорю что нет решений, я говорю что надо делать решение. Схема, кастамная десереиализация.
Просто json не решает этой задачи. Надо писать свою сериатлизацию на основе json, json просто так это не решит.
Пятница
С такими историями в русском IT, я не удивлен что местные порывы боротся с неявным сексизмом вызывают удивление. Явный бы побороть %)
Да какое побороть - признать что есть проблема, хотя бы.
В пятницу я таки порвал пуканы. Даже наезды на Яндекс и БЭМ не вызвали такой реакции. Надо к вечеру еще за геев выступить, для закрепления.
Вообще про зп, большая проблема что они сильно зависят от того как хорошо человек выбивает себе зарплату на интервью.
Поэтому я за четкие формулы по которым высчитывают эти зарплаты и за то чтобы все зарплаты в фирме были публичными.
Статья про формулы для зп
open.bufferapp.com/introducing-op…
Buffer вообще дальше идут, у них все публично даже наружу, не только внутри компании.
Может казатся что я борюсь за права программиста, но at the end начальству выгодно чтобы люди были счастливы и не уходили из компании.
В долгой перспективе наябывать своих сотрудников вредно для компании. Прозрачность - один из способов не наябывать сотрудников.
Причем я не говорю что начальство хочет наебать программистов. Начальство может просто не понимать, что оно делает чтото плохое.
Я был в двух VC-backed стартапах, в обоих начальство вызывало своими действиями много фрустрации у сотрудников. Всё с лучшими побуждениями.
Кстати про stock options, по-моему многие переоценивают их и соглашаются на слишком большое понижение зп.
At the end, это лотерея и тебе просто дается возможность в будущем купить лотерейный билет. Даже не сам билет, просто возможность, Карл!
А при покупке этого билета за тобой еще и налоговая придет, кстати.
Мне теперь немного стыдно, что я разжег такой срач про сексизм. Это важная тема и я рад что поднял ее, но троллить стоило меньше.
Поговорим про менеджеров. Я нахожу модель которая (была?) в Гитхабе и есть в Valve очень привлекательной, то есть когда менеджеров нет.
Гитхаб - zachholman.com/posts/how-gith…
Идея в том что если вы набрали себе команду талантливых, амбициозных и мотивированных людей, то ставить над ними менеджера контрпродуктивно.
Даже цель им можно не ставить - они талантливые, амбиционзные и мотивированные, они придумают что надо сделать чтобы компании стало лучше.
Кто-то говорит что программисты аутисты для которых нужен переводчик, чтобы они поняли что клиентам надо.
По-моему проблема именно в том, что программисты не могут нормально общатся с клиентов или кастомером из-за менеджера.
Особенно хорошо такая модель работает в компаниях которые делают продукты, а не в консалтинге, конечно. Поэтому гитхаб и валв так хороши.
Мы уходим от темы, зря я сюда конслатинг добавил. Компании с продуктами намного интереснее, тк они продают продукт а не продаются клиенту.
Конслатинг, оговорка по фройду. @jsunderhood
Опять же оба стартапа развалились из-за того что до тех команды не то доносили что надо кастомерам. @__fro @VasyaRomashova
ZR еще может и достигнет, HDm продан бездушной корпорации ) @Sigiller @__fro @VasyaRomashova
Большая дискуссия про ТЗ в ответах. Ни разу не видел ТЗ который бы не устаревал дольше чем за неделю разработки.
У всего должен быть target audience. @VasyaRomashova @__fro
Тред (@freiksenet)
Еще я очень не люблю митинги. 99% митингов имеют слишком много участников, лог в них ведется лажово и говорит в них один человек.
А не работают при них все участники. Надо старатся быть асинхронным и не думать что твоя проблема такая сложная что ее не решить имейлом.
Зато в больших корпорация митинги позволяют бесполезному народу чувствовать себя полезным. Весь день занят на митингах, значит нужен.
Несмотря на всю дикую активность в твиттере, неделя выдалась очень продуктивной. Надо наверно начать тоже активно вести :)
Надеюсь вам я тоже поднял продуктивность, а не убил её :)
Суббота
Суббота, поговорим про опен сорс. Делает ли ваша компания опен сорс? Какое отношение начальства? Кидайте ссылки на oss вашей фирмы.
Друг работал в компании где полагалось во внерабочее время контрибьютить в их опен сорс проекты.
Бывало ли такое что опен сорсили что нибудь из клиентского проекта при консалтинге? Как к этому относились клиенты?
Тут как минимум одна компания доплачивает за работу над опен сорсом в свободное время. futurice.com/blog/futurice-…
Кстати до @dan_abramov мое представление о русскоязычном js комьюнити основывалось на редком чтении хабры и я долго думал что он из США.
Тк я думал что в русском комьюнити из ценного только серьёзные бородатые дядьки которые пилят БЭМ.
Потом @dan_abramov провел @jsunderhood, потом @andreypopp, потом @deepsweet и все стало казаться намного менее грустным.
Так что спасибо @jsunderhood за развеянье мифов о js в России.
Поговорим о плюшках которые вам даёт работодатель помимо зарплаты и акций/опций. Есть ли у вас крутые плюшки, а какие вы бы хотели?
В Финляндии с этом есть некие проблемы, налоговая старается считать это доходом, все компании делают только то что налоговая ещё позволяет.
В это входит обычно оплата телефона и домашнего интернета, медицинская страховка (без стоматологии). Бесплатные обеды уже нельзя.
Правда покупать еду в офис можно, но так мало кто делает. Кстати про еду/колу/пиво в офисе, вы за или против?
Не является ли кейтеринг в офис тайным заговором чтобы все подольше сидели в офисе?
Люди тут говорят что у них чай кофе и печенья не оплачиваются компанией.
Воскресенье
Наш последний день вместе и похоже я таки догоню @listochkin по общему количеству твиттов. Сегодня я хочу поговорить про удаленную работу.
Я очень за со всех точек зрения. Работодатель получает более мотивированных сотрудников и recruitment pool размером с мир, вместо города.
Работник получает возможность работать там где ему нравится, больше времени проводить с семьей и не парится по поводу похода в офис.
При этом это все требует правильной огранизации работы. Я видел как communication ломался, когда команды были не рядом.
Я видел как удаленные люди чувствовали себя не частью команды. Как до них менее быстро доносилась информация.
Как вы решаете эти проблемы с удаленными людьми? Что за инструменты можно использовать для этого?
Основатель basecamp написали хорошую книгу про удаленку. 37signals.com/remote/
Про communication - в принципе я видел как он не работал даже когда команд(а/ы) были рядом, так что дело скорее в людях а не расстоянии.
Вот вы основатель компании. Как развивать в компании ту культуру которую вы хотите? Например, культура удаленной работы.
Кстати опять мы упираемся в прозрачность. ИМХО в прозрачной компании, где вся информация шерится легче сделать удаленку. @yuritkachenko
Я наверно больно задрачиваюсь на прозрачность, но мне кажется многие проблемы уходят если использовать ее по полной.
Плохие компании не доверяют своим сотрудникам и думают что сотрудники это шпионы, которые все выдадут врагу. @jsunderhood
Это все время afterthought. По-моему это должно быть одно из первых о чем ты думаешь, когда основываешь компанию. @deepsweet
Я видел как стартапы лажали и хочу не повторить их ошибок. Отстутствие прозрачности оба раза было главной лажей. @svenyurgensson @deepsweet
Тред (@freiksenet)
Раз уж мы начали про agile - идеи в Канбане мне нравятся больше чем идеи в Скраме. По-моему короткие итерации это стрессовово и тяжело.
К тому же они заставляют держать скоуп маленьким, что не всегда возможно. @jsunderhood
Ограничением же паралеллизма канбан добивается таких хороших вещей, как более быстрые ревью/тесты, быстрый деплой и тд. @jsunderhood
Тк свой ревью/деплой не получишь пока не поможешь соседу. @jsunderhood
Тред (@freiksenet)
Вот и подошла к концу наша с вами неделя. Сделаю небольшой рекап.
В понедельник мы обсуждали GraphQL и как он заменит REST api. Мы также обсудили попутные технологии типа Relay и React.
Во вторник я рассказал про мою нелюбовь к ангулару, в среду мы говорили про Финляндию и Webpack.
В четверг про grunt, gulp, npm scripts. В пятницу у нас был разговор про сексизм и про ведение бизнеса.
В субботу мы поговорили про бонусы в компании и менеджмент и наконец сегодня про удаленную работу и немного agile.
С вами был @freiksenet. Спасибо за то что с вами было интересно спорить.
