jsunderhood
/ raxpost

Коллективный твиттер-аккаунт для фронтенд-разработчиков с новым автором каждую неделю
Уже 10 543 человека в теме.

raxpost

4 июля 2016, Frankfurt on the Main, Germany

# Понедельник 31 твит

Утречко! На этой неделе с вами @raxpost - человек фулстек из Франкфурта

8:32
@jsunderhood @cssunderhood @abroadunderhood @sexsecrethood @iamspacegray парни, репостните , если не жалко :)

Привет, камрады. Это коллективный твиттер для гейм-дизайнеров в модном нынче формате андерхудов – новый автор каждую неделю.

8:33

Будем много говорить о типах, ноде и фулстеке. Думали не будет реакта? Хренушки, от него никуда не деться

8:35

Давайте начнем с небольшого опроса, а чуть позже я расскажу что сам думаю по теме. Нужны ли в js типы?

8:48
@jsunderhood я не могу определиться. С одной стороны типизация добро-меньше ошибок. С другой стороны-уже поздно :)

Есть опциональная, будем считать, что она относится к ответу Да

@jsunderhood я не могу определиться. С одной стороны типизация добро-меньше ошибок. С другой стороны-уже поздно :)

9:51

Думаю все поняли, но на всякий случай суть сабжа: js типы очень слабые, но есть возможность вводить типизацию посредствам доп инструментов

12:59

Вот лишь некоторые из них: TypeScript, Flow, Elm, PureScript, Dart

12:59

Самому мне очень симпатичен Haskell, но еще не доводилось его использовать на продакшене. В вебе он непопулярен

13:05

И во многом именно благодаря сильнейшей типизации. Когда хаскелист пишет программу, ему нужны 100% гарантии бизнес требований

13:07

В реальном же мире, пока вы допишете ваши базые типы, к вам 10 раз прибежит проджект и скажет, давай по новой, миша, все ху%$я

13:09

Поэтому типизация несет оверхед на этапе прототипа, а бизнес от веба ждет всего очень быстро

13:11

При это она сильно помогает при рефакторинге, все ошибки отлавливаются почти сразу

13:12

Более того, вы экономите на тестах, потому что чем строже типизация, тем ближе вы приближаетесь к описанию всех возможных кейсов уже в коде

13:16

Я к сожалению совсем не знаком с Elm и PureScript, если кому-то есть что сказать про них в плане нашего топика, пишите

13:17

Однако на хайпе, столь для нас родном, сейчас TypeScript и Flow. По этому поводу второй опрос

13:21
@jsunderhood опциональная типизация в php вроде бы. А есть в нашем треде люди с успешным опытом ее использования?
13:27
@jsunderhood бизнес код поддерживать команде и новеньким, текущие инструменты мне кажется сильно повышают порог вхождения
13:27
@jsunderhood В реальном мире, одно слово перед параметром функции экономит дофига времени во всем процессе разработки.
13:46
@dcromster @jsunderhood Про меньше ошибок — абсолютный миф. Не влияет. А вот удобочитаемость, по-моему, страдает. medium.com/javascript-sce…

Эта статья всех бомбанула пару месяцев назад. Не сказал бы что она что-то доказывает, но - попытка разобраться

@dcromster @jsunderhood Про меньше ошибок — абсолютный миф. Не влияет. А вот удобочитаемость, по-моему, страдает. medium.com/javascript-sce…

13:53
@jsunderhood более того, последний год Babel просто имплементирует фичи, которые уже есть в TypeScript.

Соглашусь, с TS вы получаете все новые ES фичи бонусом. Тогда как в 6 бабеле в это время выпиливают декораторы

@jsunderhood более того, последний год Babel просто имплементирует фичи, которые уже есть в TypeScript.

13:59
@jsunderhood на самом деле не все так просто.Например, модули в typescript вели себя совершенно иначе и до сих пор отличаются от es6-modules
14:10
@jsunderhood 30% не знают, что TypeScript покрывает весь функционал Flow + избавляет от необходимости использовать Babel.

Не был бы так категоричен, например буквально недавно TS добавил descriminated unions, которые уже были в Flow

@jsunderhood 30% не знают, что TypeScript покрывает весь функционал Flow + избавляет от необходимости использовать Babel.

14:11

А есть кто за Flow? Давайте сравним, что там есть, чего нету в TS. А пока посмотрим маленькую презу djcordhose.github.io/flow-vs-typesc…

14:15

Например @vkurchatkin собирает коллецию сниппетов, где Flow ведет себя лучше чем TS github.com/vkurchatkin/ty…

15:15
@jsunderhood изначально flow и ts созданы для разного. ts для того, чтобы писать все на ts, а flow - чтобы проверять существующий код
15:33
@jsunderhood @vkurchatkin ts next же
15:33

И у меня есть вопросы к обоим сторонам: например есть ли во Flow параметрические типы данных?

16:02

И как с помощью TS проверять типы, описанные в JSDoc. Говорят так можно

16:03

Напомню, что JSDoc имеет тэг usejsdoc.org/tags-typedef.h… который поддерживает композитные типы и юнионы

16:05
Why do I prefer jsdoc3 instead of TypeScript/Flow? Types is meta information, like Contract in DbC. We should separate it from program code.

И например @DenisIzmaylov считает, что это лучше, чем типы в коде

Why do I prefer jsdoc3 instead of TypeScript/Flow? Types is meta information, like Contract in DbC. We should separate it from program code.

16:08
@jsunderhood есть, и, в отличии от ts, поддерживается ковариантность и контрвариантность
16:19

# Вторник 28 твитов

@jsunderhood github.com/Microsoft/Type…

Да, но почему-то он не проверяет типизацию. Съедает
/**
* @type {number}
*/
var var1;
console.log(var1.length);

@jsunderhood github.com/Microsoft/Type…

6:43
@vkurchatkin @bardadymchik @jsunderhood с доками у флоу плохо

@lbljeffmo @rpominov @flowtype personally I don't understand how to define contravariance in generics.

6:44
@jsunderhood а расскажешь про typelint?

Сейчас как раз плавно к этому перейдем :)

@jsunderhood а расскажешь про typelint?

9:02

Продолжим о типизации. По моему опыту большинство проблем возникают при обращении к несуществующему свойству объекта. Пресловутый undefined

9:04

Потому что сложно держать в голове все структуры и интерфейсы приложения. Где-то вы обязательно промахнетесь

9:05

Поэтому я например вижу мало смысла использовать транспайлеры лишь в сборке. Разработчик должен видеть ошибку, пока он в контексте

9:06

Поэтому меня огорчило, что у WebStorm'a до сих пор нет полноценной поддержки Flow. C TS у них все отлично

9:07

Так вот, если большинство проблем в объектах, давайте посмотрим откуда они приходят: модели из API, локальный стейт приложения

9:19

Если вы пишете апи и не используете что-то типо Swagger, API Blueprint итд, то для вас уготован отдельный котелок в аду

9:23

Возьмем локальный стейт и самое популярное решение - Redux. У него есть структура, описанная редюсерами и initialState'ами

9:24

Возьмем пока чуть менее популярное решение - Relay, у него вообще типизированные схемы данных для GQL

9:25

Как мы видим в хороших приложениях большие данные всегда описаны, а в очень хороших еще и типизированы. Почему бы не использовать это?

9:26

Так родилась идея github.com/yarax/typelint -- сделать линтер, который знает о данных приложения и помогает писать код безопасно

9:27

Пока он поддерживает только JSON Schema как формат описание данных (используется в Swagger), но я планирую добавить поддержку Redux и GQL

9:29

Кстати JSON Schema по-моему недооцена. Эот хорошо описанный универсальный формат для JSON. Почему все постоянно изобретают что-то свое?

9:30

JSON Schema поддерживает algebraic data types за счет енумов, allOf и anyOf. И если не нужна хитрая динамика, этого зачастую достаточно

9:32

Например уж mongoose и thinky точно могли бы его использовать. Было бы универсальнее + толчок к развитию единого стандарта

9:46

Говоря об API, в Haskell есть фреймворк Servant, который описывает все ваше апи в типах. АПИ в ТИПАХ Карл. Вот это высота

9:59

Но зато такое апи нельзя будет использовать в typelint :)

10:01

Ладно, больше не буду про хаскель, а то все разбегутся

10:02
@jsunderhood @twenty синтаксис ещё не утверждён — правильно делают, что выпиливают. Всегда можно плагин поставить, если очень нужно.

Полгода собачку утверждают? А в это время полвеба юзает декораторы в TS, вторая половина через легаси бабель плагин

@jsunderhood @twenty синтаксис ещё не утверждён — правильно делают, что выпиливают. Всегда можно плагин поставить, если очень нужно.

12:38
@vkurchatkin @jsunderhood Спрос на эту фичу есть, значит рано или поздно примут. Только вот поведение может отличаться от нынешнего

Именно. Только смысл было ее убирать полностью, если все равно продолжают пользовать с таким функционалом какой есть

@vkurchatkin @jsunderhood Спрос на эту фичу есть, значит рано или поздно примут. Только вот поведение может отличаться от нынешнего

13:12

Завершая тему типов, кто еще не знает есть телеграм чатик по TS telegram.me/typescriptru Может кто-то знает/создаст по Flow?

14:16

И небольшая шпаргалка по типам в TS, Flow, JSON Schema и Haskell, круто если кому-то есть что исправить/дообавить github.com/yarax/typescri…

14:17
Давайте начнем с небольшого опроса, а чуть позже я расскажу что сам думаю по теме. Нужны ли в js типы?

Голосование нужна ли в js типизация: 57% Да, 43% Нет. Подтверждает ощущение, что "хорошо бы, но дорого"

Давайте начнем с небольшого опроса, а чуть позже я расскажу что сам думаю по теме. Нужны ли в js типы?

14:21

Выход - опциональная и без дополнительного писания типов, юзайте typelint :D

14:22

Голосование TS/Flow: TS: 58%, Flow: 42%

14:23
@jsunderhood было бы неплохо, но вроде бы в русскоязычном мире Flow мало используют

По ходу да, кроме тебя про Flow все молчат)

@jsunderhood было бы неплохо, но вроде бы в русскоязычном мире Flow мало используют

14:57

# Среда 55 твитов

@jsunderhood Многи ли в js архитектурных подходов\решений для приложений? Как происходит выбор для нового проекта? Где подобное почитать?

MVC умирает вместе с ОО подходом, компоненты могут решить почти любую задачу и дают больше гибкости

@jsunderhood Многи ли в js архитектурных подходов\решений для приложений? Как происходит выбор для нового проекта? Где подобное почитать?

9:07

В продолжении вчерашней темы про API, немного о REST. REST - говно

9:08

Но от него никуда не деться, потому что он по сути есть HTTP. А HTTP это наше все. И низкий уровень REST'a увеличивает прозрачность

9:10

Но чаще всего, если решение прозрачное, оно не богато возможностями.

9:11

Ограничения REST думаю всем известны: недостаточность ресурсной модели, ограниченность GET запросов, неуклюжий PUT

9:13

А если вы захотите поменять транспорт например на сокеты, то вообще будете переписывать слой работы с данными

9:14

На этом фоне даже JSON-RPC выглядит более привлекательным. Но если вы на реакте, то для вас открыт целый преферанс-бордель: Relay

9:35

Если безусловно талантливая команда фб что-то придумает с неудобными мутациями, конкурентов в асинхронном хендлинге данных у Relay не будет

9:37
@jsunderhood Relay/GraphQL не всем подходит, он сложный, имхо

Кстати да, почему он считается сложным?

@jsunderhood Relay/GraphQL не всем подходит, он сложный, имхо

9:38
@jsunderhood Мне кажется, что сама идея 👍, но конкретная реализация для многих проектов — оверхед. Для больших да, там все это пригодится.
9:41
@jsunderhood можно пример про больше гибкости?

В OOP-MVC переиспользование - наследование, компонентная структура ближе к FP, когда чистая ф-я может юзаться везде

@jsunderhood можно пример про больше гибкости?

9:53

Сама природа UI - компоненты, мне кажется это естественно

9:53
@roman01la @jsunderhood самый простой путь – сделать прослойку для агрегации REST-запросов.

Вот я сейчас точно так же буду пытаться мигрировать систему на GQL. REST при этом должен остаться

@roman01la @jsunderhood самый простой путь – сделать прослойку для агрегации REST-запросов.

9:55
@jsunderhood наследование - механизм subtyping-а, ad-hoc полиморфизма.ООП-инкапсуляция и мессаджинг,то-есть компоненты в чистом виде

Совершенно верно,но так сложилось у всех в головах,что ООП-это наследование. Инкапсуляция и полиморфизм универсальны

@jsunderhood наследование - механизм subtyping-а, ad-hoc полиморфизма.ООП-инкапсуляция и мессаджинг,то-есть компоненты в чистом виде

10:01
@jsunderhood effectful компоненты /= чистые функции, и не композятся в общем случае.Кроме того, ф-ции слишком низкоуровневые

  • Мы говорим про переиспользование 2. В чем проблемa объединения в модули?

    • 10:03
    @jsunderhood чистое фп и всякие редуксы не решают проблем инкапсуляции стейта, то-есть не решают вообще ничего.MVС как раз и есть компоненты

    Инкапсуляция стейта (если она действительно нужна) решается как и инкапсульция скоупа функций - локальным стейтом

    @jsunderhood чистое фп и всякие редуксы не решают проблем инкапсуляции стейта, то-есть не решают вообще ничего.MVС как раз и есть компоненты

    10:04
    @jsunderhood и еще: MVC /= OOP

    В MVC без OOP не остается вообще никакой системы, кроме ненужного разделения логики от представления

    @jsunderhood и еще: MVC /= OOP

    10:07
    @jsunderhood переиспользование стейтфул компонентов /= пересипользованию чистых ф-й. Модули не помогут инкапсулировать стейт.

    Вопрос: зачем инкапсулировать стейт, который мешает переиспользованию? Ради инкапсулирования?

    @jsunderhood переиспользование стейтфул компонентов /= пересипользованию чистых ф-й. Модули не помогут инкапсулировать стейт.

    10:13
    @jsunderhood попробуй сделать такое в языке з правильной системой типов и типизированными effect-ами - сильно удивишься)

    В strong type FP данные пайпом проходят через ф-ии. В реакте это усложняется необходимостью дублировать пропсы

    @jsunderhood попробуй сделать такое в языке з правильной системой типов и типизированными effect-ами - сильно удивишься)

    10:24

    Есть контекст, но он все еще не стабилен

    10:25
    @jsunderhood инкапсуляция - необходимое,но недостаточное условие переиспользования,и самой вожможности существования больших, сложных систем

    Я с тобой согласен, что в реакте есть проблемы со стейтом. Но есть серебряная пуля?

    @jsunderhood инкапсуляция - необходимое,но недостаточное условие переиспользования,и самой вожможности существования больших, сложных систем

    10:34
    @maxmaxmaxmax @roman01la @jsunderhood хочется узнать о таком опыте подробнее. На сколько это было накладно по производительности?
    11:09
    @roman01la @jsunderhood jsonapi же.

    Я с ним мало знаком, но по-моему он работает поверх реста, нет?

    @roman01la @jsunderhood jsonapi же.

    11:28
    @mr_mig_by @roman01la @jsunderhood да, это то что назвают BFF
    11:30
    @mr_mig_by @roman01la @jsunderhood думаю, имеются ввиду два последних слайда с slideshare.net/MaxKlymyshyn/p…
    11:30
    @jsunderhood расскажи про проблему стейта плиз

    То, что глобальный не дает инкапсуляции, а локальный мешает переиспользованию

    @jsunderhood расскажи про проблему стейта плиз

    11:36
    @jsunderhood а зачем инкапсуляция?

    Например для связи компонентов со стейтом, она чаще всего прослеживается. Но как я говорил выше глобал - это решение

    @jsunderhood а зачем инкапсуляция?

    11:43
    @jsunderhood лучше почитать jsonapi.org/format/ Скажу, что там лучше работать с релейшенами, выводить одним запросом детей(с фильтрами)…

    Формат это формат. Но в основе рест - все те же GET, PATCH

    @jsunderhood лучше почитать jsonapi.org/format/ Скажу, что там лучше работать с релейшенами, выводить одним запросом детей(с фильтрами)…

    11:44
    @jsunderhood я ничо не понял. Как инкапсуляция связывает состояние с компонентом?

    Вам с @8gene надо дебаты устроить :) Один говорит везде инкапсуляция, второй инкапсуляция не нужна

    @jsunderhood я ничо не понял. Как инкапсуляция связывает состояние с компонентом?

    11:47

    Возвращаясь в API, кто-то пробовал Falcor?

    12:01

    В нашем случае GraphQL позволит разгрузить клиент от кэширования, асинхронных экшенов и более точно и гибко запрашивать данные

    12:03

    Но меня смущает существование 2 стейтов (Редукс и Релей) одновременно. Есть механизмы поддержания консистентности, но все равно стремно

    12:05
    @jsunderhood А какой у вас продукт?

    Огромная админка управления рекламными компаниями. Много форм, поэтому без локального стейта не обойтись

    @jsunderhood А какой у вас продукт?

    12:08
    @jsunderhood мы в редаксе держим только состояние UI: табы, комбобоксы и т.д.

    Да, в идеале хотелось бы так же

    @jsunderhood мы в редаксе держим только состояние UI: табы, комбобоксы и т.д.

    12:09
    @jsunderhood У нас много такого кода и мы не храним такие данные в редаксе. Обычно родительский компонент собирает эти данные и отправляет.

    Да, я тоже считаю, что форма должна быть в стейте компонента, но у нас это легаси redux-form

    @jsunderhood У нас много такого кода и мы не храним такие данные в редаксе. Обычно родительский компонент собирает эти данные и отправляет.

    12:21
    @jsunderhood про ваше решение для форм. форм может быть много и интересно как вы описываете формы и шарите общий код между
    @roman01la

    Когда-то мне нравилась идея построения форм на основе моделей, но в реальном мире это не работает

    @jsunderhood про ваше решение для форм. форм может быть много и интересно как вы описываете формы и шарите общий код между
    @roman01la

    12:51

    Форма рисуется вручную и к полям биндится специльный пропс field, содержащий value, onChange итд. В hoc field связывается с redux

    12:52

    Возможно когда-нибудь @nosovsh выложит это в опен сорс :)

    12:54

    Кстати также мы юзаем довольно удобное решение для работы с редакс-стейтом github.com/nosovsh/reduce… тоже от @nosovsh меньше мороки с экшенами

    12:56
    @jsunderhood а можно подробностей про то как Редукс и Релей живут вместе?

    Они в общем друг другу не мешают. Главное держать данные консистентными. У редакса стор через dispatch, relay - hoc

    @jsunderhood а можно подробностей про то как Редукс и Релей живут вместе?

    13:08

    Кстати поигрался с github.com/gyzerok/adrena… и понял, что без Relay чистый GraphQL - сомнительное удовольствие

    13:10
    @jsunderhood у нас была одна итерация декларативно описывать формы на сервере, но отказались из-за необходимости свой язык поддерживать

    Мне раньше нравилась эта идея, но в реальности UI должен быть очень гибким

    @jsunderhood у нас была одна итерация декларативно описывать формы на сервере, но отказались из-за необходимости свой язык поддерживать

    13:22
    @roman01la @jsunderhood @apollostack там нет метеора, там есть appolo-client, он интегрируется с реактом или редаксом, можно пользоваться
    13:51
    @jsunderhood @8gene я считаю, что состояние нужно выносить вовне. Это должна быть отдельная ось композиции компонента

    Это интересная тема. Но как например обеспечить неизменение куска стейта другим компонентом?

    @jsunderhood @8gene я считаю, что состояние нужно выносить вовне. Это должна быть отдельная ось композиции компонента

    14:59
    @mr_mig_by @8gene если есть данные, которые нужны ему и только ему, их логично скрывать в компоненте
    15:02
    @mr_mig_by @8gene Каждый компонент жестко связан с редаксом, это противоречит weak coupling. Но я не утверждаю, что это приносит проблемы
    15:02
    @jsunderhood @8gene к примеру, Symbol в качестве имени компонента в глобальном состоянии.
    Но вопрос - зачем обеспечивать неизменность?

    Например пришел новый человек в команду, не разобрался и записал не в свой кусок стейта, все сломалось

    @jsunderhood @8gene к примеру, Symbol в качестве имени компонента в глобальном состоянии.
    Но вопрос - зачем обеспечивать неизменность?

    15:06
    @mr_mig_by @jsunderhood композятся интерфейсы - поведения, view. Стейт не имеет интерфейса, он просто есть.А стейт с интерфейсом-это инкапс.

    Да, но при этом я не вижу решения как разрулить strong coupled data между компонентами, кроме глобального

    @mr_mig_by @jsunderhood композятся интерфейсы - поведения, view. Стейт не имеет интерфейса, он просто есть.А стейт с интерфейсом-это инкапс.

    15:13

    Пока что мне видится оптимальным - там где возможно использовать локальный стейт - юзать локальный, где нет - глобальный

    15:14
    @jsunderhood каждому новому человеку нужно предоставить отдельное рабочее место, ветку стейта и редьюсер!
    15:17
    @jsunderhood @mr_mig_by @8gene как предсказать, что эти данные не понадобятся кому-то ещё в будущем?

    Никак, только рефакторить

    @jsunderhood @mr_mig_by @8gene как предсказать, что эти данные не понадобятся кому-то ещё в будущем?

    15:18
    @jsunderhood @mr_mig_by @8gene и по этому мне больше нравится идея Лёхи: данные - отдельная ось

    Но если не рефакторить, стейт превращается в огромную помойку

    @jsunderhood @mr_mig_by @8gene и по этому мне больше нравится идея Лёхи: данные - отдельная ось

    15:22
    @jsunderhood @nosovsh connectSlicedState('pages.blogs.data.activePost') - это не очень хорошее решение. компоненты привязаны к форме стейта.

    А вот это второй вопрос что есть связь компонента и глобального стейта? Соответствующий ключик редюсера?

    @jsunderhood @nosovsh connectSlicedState('pages.blogs.data.activePost') - это не очень хорошее решение. компоненты привязаны к форме стейта.

    15:23
    @jsunderhood я оч устал рефакторить, поэтому сторы редакса у меня это "база данных". локальный стейт — для UI штук (eg dropdownIsVisible).

    Еще кстати из базы данных нужно гибко выбирать и кэшировать новые данные. Поэтому мне нравится подход Relay

    @jsunderhood я оч устал рефакторить, поэтому сторы редакса у меня это "база данных". локальный стейт — для UI штук (eg dropdownIsVisible).

    15:28

    Кстати пока у нас тут жарко, прогоню телегу. Нам во Франкфурт нужен реакт удаленщик. Пишите кому интересно в лс @raxpost

    15:40

    # Четверг 20 твитов

    Буквально пару лет назад мне было интереснее на сервере. Сейчас все наоборот

    9:22

    В бекенде все кристализовалось: devops, data analysis, API. Конечно все еще есть интересные задачи (gamedev например), но их все меньше

    9:22

    При этом есть вероятность, что API скоро кристализуется в BAAS, потому что это рутина

    9:22

    А на клиенте вот можно вместо работы спорить нужно ли разделять view и где должен быть стейт,параллельно играясь всякими rx и прочими сагами

    9:23

    И пока на клиенте весело и задорно с реактом, на сервере царит мракобесие во главе с Express

    9:23

    Несколько месяцев назад я написал статью почему экспрес зло yarax.ru/2016/02/26/exp…

    9:32

    Туда пришел TJ и сказал, чувак, мопед не мой, дизайн node/http - говно

    9:32

    И это отчасти правда, но node/http это низкий уровень. Задача прикладных библиотекарей - делать правильные абстракции

    9:32

    Поэтому нет смысла спорить что лучше koa или hapi, пока все они наследуют дизайн node/http лишь обрастая сахаром

    9:33

    Не может же быть такого, наверняка кто-то уже написал либу с правильным разделением http имплементации от логики ручек?

    9:35

    Это же делается элементарно, я даже накидал небольшой гист gist.github.com/yarax/e68c7623…

    9:36

    Объясню чуть подробнее. Довольно очевидно, что апи должно описываться декларативно.

    12:43

    То есть у либы есть вся информация в каком формате данные приходят из http и в каком должны туда уходить. http - это контекст

    12:43

    Очень хочется сказать слово монада, но обещал этого не делать

    12:43

    Так почему этот мутирующий непредсказуемый req носится по всему приложению, собирая в себе все что не попадя?

    12:43

    Если задача ручки - сделать запрос в базу, обработать данные и вернуть их, зачем ей этот req?

    12:43

    Ладно, не пошло, давайте лучше посмотрим как енот ездит на велосипеде pic.twitter.com/wxCGR8QWi3

    13:38
    @jsunderhood это Backend as a Service? Почему тогда рутина?

    В том смысле, что все сводится к декларативному описанию апи, а дальше банальные запросы к базе

    @jsunderhood это Backend as a Service? Почему тогда рутина?

    15:28

    А имея какой-ть full text search engine и GQL на фронте, можно делать вот такие штуки почти вообще без бекенда github.com/nordsimon/elas…

    15:31
    Собрал в кучу слайды с @OdessaJS — gist.github.com/boccob/2243904… cc: @jsunderhood
    16:59

    # Пятница 35 твитов

    @jsunderhood абстракции текут (с)

    Текут конечные монструозные низкоуровневые решения. Не просто текут, а находятся постоянно на грани фола

    @jsunderhood абстракции текут (с)

    7:21

    Говоря об абстракциях, @nikitonsky недавно написал довольно очевидную (почему-то еще не для всех) статью про это tonsky.livejournal.com/307231.html

    7:26

    Ну да бог с ней с философией, нравится людям express, пусть старадают :) Давайте поговорим о реактивном программировании

    7:27

    Я использую

    7:30
    @jsunderhood если быть точным, то Rx, Bacon, Kefir не есть FRP :-)

    Расскажи подробнее

    @jsunderhood если быть точным, то Rx, Bacon, Kefir не есть FRP :-)

    7:47
    @jsunderhood rx etc-это императивные effectful реактивные не-формальные системы.

    А ну я понял что ты имеешь, меня тоже смущает, что почему-то все добавляют в аббревиатуру букву F

    @jsunderhood rx etc-это императивные effectful реактивные не-формальные системы.

    7:56

    Говоря о событиях, например нам нужен момент, когда на серв все асинх сервисы готовы. Это можно сделать например так gist.github.com/yarax/3dac9ae1…

    8:06
    @jsunderhood кстати, вот обзорный спич про таксономию фрп - youtube.com/watch?v=Agu6ji…
    8:07
    Neat redux-observable example with RxJS 5: github.com/redux-observab… pic.twitter.com/19gj1Z9lOR

    А вот пример использоваться Rx в Redux. Как вам такой подход?

    Neat redux-observable example with RxJS 5: github.com/redux-observab… pic.twitter.com/19gj1Z9lOR

    8:14

    Люди, указавшие в опросе вариант "другая" напишите плз какая именно и почему

    8:16
    @jsunderhood вот в контексте RxJS отличный пример и статья про построение Redux-like приложения victorsavkin.com/post/137821436…
    8:28

    Тем временем нам поступает интересный фидбек от слушателей pic.twitter.com/EMhAJ15zEf

    8:58
    If you want to know how your expression of Rx works you can use this one jsbin.com/gogofa/4/edit?…
    @OdessaJS
    9:03
    @8gene @nikitonsky @jsunderhood цель любой абстракции есть вытеснение иной абстракции из головы. Жизнь есть борьба абстракций. 👻
    9:20
    @8gene @nikitonsky @jsunderhood на уровне котика квантовых полей нет - они схлопываются ещё до зачатия котика.

    От экспресса до котика в квантовых полях

    @8gene @nikitonsky @jsunderhood на уровне котика квантовых полей нет - они схлопываются ещё до зачатия котика.

    9:22

    Мое мнение, что использовать стримы там, где можно промизы, избыточно и непрозрачно. Но возможно я не прав, раскажите, про ваши юзкейсы

    9:49
    @jsunderhood @raxpost На промисах всегда нужно ждать их окончания, со стримами же можно начинать отправлять ответ клиенту почти сразу же.

    Окончание промиза означает что данные fulfilled и с ними можно работать. Можешь код привести?

    @jsunderhood @raxpost На промисах всегда нужно ждать их окончания, со стримами же можно начинать отправлять ответ клиенту почти сразу же.

    10:02
    @jsunderhood 1) если надо (будет) результаты резолва промисов комбинировать, 2) если везде стримы и есть два промиса в коде

    Да, в этом случае оправдано

    @jsunderhood 1) если надо (будет) результаты резолва промисов комбинировать, 2) если везде стримы и есть два промиса в коде

    10:40
    @jsunderhood свою пилю :D npmjs.com/package/rstore

    Круто!

    @jsunderhood свою пилю :D npmjs.com/package/rstore

    11:50

    Еще немного о типах. Недавно пришлось работать с кодом, который делает всякую арифметику с бюджетами.

    12:40

    Значения приходят извне и могут быть чем угодно. Что мы имеем: undefined, null, NaN, String, Number и никакой определенности

    12:40

    Тайпчекеры (например Maybe во Flow) не позволят вам cложить number с undefined

    12:41

    Это лучше чем ничего, но недостаточно, т.к код обрастет страшными ифами и станет нечитабельным

    12:41

    Очень хочется изобрести свой тип Maybe, но такие попытки выглядят немного смешными github.com/chrissrogers/m… по сути они ничего не решают

    12:41

    Как вариант - сделать вид, что Maybe у нас есть и написать арифм ф-ии работы с ним: gist.github.com/yarax/841ea9df…

    12:41

    В итоге null рассматривается как у Flow - тип Nothing и с этим уже можно работать

    12:41
    Если менять конструкцию инвалидного кресла, у человека новая нога все равно не вырастет. #javascript #it twitter.com/jsunderhood/st…

    Строгая типизация не избавляет от разруливания union типов, просто не будет NaN и undefined

    Если менять конструкцию инвалидного кресла, у человека новая нога все равно не вырастет. #javascript #it twitter.com/jsunderhood/st…

    12:57
    @just_hank_moody хорошая статья tjournal.ru/users/24702/po…, могу заметить что весь движ начался с @jsunderhood и jsunderhood.ru
    14:01
    Друзья, рад сообщить: 8-й Node.js Meetup мы проводим в Яндексе! 13 июля, среда, 19:00. Регистрируйтесь events.yandex.ru/events/yagosti… #MoscowNodeJS
    14:43

    Почти 100 человек проголосовало и из них целых 83% вообще не используют FRP. Отсюда у меня следующий вопрос

    15:38
    @jsunderhood есть ещё третий вариант: мне нравится идея, но выглядит слишком сложно и боюсь брать на проект куда придут ещё люди после меня
    15:47
    @jsunderhood кстати, о нашем милом и добром реакте: twitter.com/forwebdev/stat…

    Cons какие-то мутноватые

    @jsunderhood кстати, о нашем милом и добром реакте: twitter.com/forwebdev/stat…

    19:36
    @jsunderhood С ним код получается сложнее, если мне будет нужна абстракция которая усложняет я пойду в хаскель монады писать.
    19:37
    @vladimore @jsunderhood иногда в JS что-то не прокатывает. Например в JS4 не прокатило полноценное ООП. И это на пике популярности ООП. 👻

    Да, было время все пытались притягивать за уши js к ООП

    @vladimore @jsunderhood иногда в JS что-то не прокатывает. Например в JS4 не прокатило полноценное ООП. И это на пике популярности ООП. 👻

    19:39
    @jsunderhood @vladimore удивительное то что не притянули тогда JS. Странно это. Имхо.
    19:44

    # Суббота 40 твитов

    @taujavarob Мне кажется для JS sweet spot это императивный код на низком уровне и иммутабельность и базовое ФП на высоком. @jsunderhood
    7:12
    @freiksenet_ru @mr_mig_by @jsunderhood усложняют люди, которые выбирают неправильные абстракции для конкретного случая :)
    7:12

    Норм визуализашка по Rx методам rxmarbles.com

    9:21
    let capitalism = function(){ this.wellfare++; };
    let communism = () => { this.wellfare++; };
    9:24

    Давайте чуть-чуть про фулстек.

    10:23
    @jsunderhood @raxpost есть распространенное мнение что человек-фулстек это как "не вашим и не нашим". Что думаешь про это?

    Есть такое, частенько это ощущаю. Всегда тебя будут считать квалификацией ниже, чем профильные

    @jsunderhood @raxpost есть распространенное мнение что человек-фулстек это как "не вашим и не нашим". Что думаешь про это?

    10:27

    Но я с собой ничего не могу поделать, есть Computer Science и мне интересно все, что с этим связано

    10:34

    Еще для понимания всей системы в целом и принятия правильных решений полезно знать как работает каждая часть

    10:35

    Времени конечно на все не хватает не будет хватать, но хорошо знать самые важные элементы нужно

    10:37

    Поэтому я запланировал себе на этот год получить сертификат lpi.org

    10:39

    Расскажите про ваш опыт и ощущения фулстека

    10:39

    К тому же все меняется каждую неделю только на фронте, информатика с математикой не меняются

    10:42
    @jsunderhood, я на бэке, нра фронт как недостающий вариант
    10:43
    @jsunderhood отличный опыт, отличные ощущения. Но печаль, потому что работать приходится с людьми, у которых такой суперсилы нет

    Это да, но оно в твоей голове, я писал про мнение окружающих. Тут как обычно, каждый считает себя самым умным

    @jsunderhood отличный опыт, отличные ощущения. Но печаль, потому что работать приходится с людьми, у которых такой суперсилы нет

    10:49
    @jsunderhood а ещё можно вести беседы со всеми специалистами и посещать любые конфы - всегда интересно и понятно
    10:50

    Бек мне не нравится тем, что все самое интересное там происходит на нагрузках. А настоящие нагрузки редко где есть

    10:51

    Получается такой кружок избранных, если ты получил там опыт, тебе открыта дорога дальше по соотв технологии

    10:52
    @jsunderhood Без понимания бэка фронту жить будет очень тяжко. Это отсутствие возможности общаться на одном языке.

    Если нет базового понимания, то все совсем плохо

    @jsunderhood Без понимания бэка фронту жить будет очень тяжко. Это отсутствие возможности общаться на одном языке.

    10:53

    А быть одновременно на беке в нагрузках/биг дате и на фронте - нереально, тут хочешь не хочешь надо выбирать

    10:54

    А уметь написать апи + базовое знание основных БД, не весть какой скил

    10:55
    @jsunderhood Расставлять приоритеты. Можно в одно погружаться по полной, а в остальное — по остаточному принципу, по чуть-чуть.

    Вот в бек с нагрузками к сожалению нельзя погрузится частично. И даже дома пет проджект будет бесполезен

    @jsunderhood Расставлять приоритеты. Можно в одно погружаться по полной, а в остальное — по остаточному принципу, по чуть-чуть.

    10:56
    @jsunderhood Даже если в качестве джуна, подай-принеси, посмотреть, как умные люди работают.
    11:14
    @jsunderhood начинал с ruby. потом перекочевал в js, тк изначально шёл в dev, чтобы делать законченные продукты (а без js тут никак) 1/3
    11:23
    @jsunderhood на текущем проекте бэк рельсовый. но жить в 2 языках, один из которых js, (мне) нереально, не успеваю. ruby уже чужой 2/3
    11:23
    @jsunderhood поэтому единственный вариант фулстек для меня—это нода. но имо каждый фронт должен быть фулстек, хоть немного. иначе тяжело 3/3
    11:23
    @jsunderhood Фронт веселее и приятнее, бек это скукота и рутина. Наклепай говнорест, заверни в него недоорм. 😖
    11:42

    По поводу ноды, да очень удобно не переключать синтаксис языков.

    12:11

    Забавно, раньше все думали что смогут переиспользовать код клиент-сервер. Оказалось это не нужно. Но сработало в плане npm

    12:13

    Хейтеры обычно говорят что на беке есть языки лучше. Типо вот в питоне тоже появился евентлуп

    12:15

    И что js ужасен. Но, если вы страдаете от типизации - берите typescript. От колбеков - async/await

    12:17

    Единственное что нельзя поменять - дебильные методы, половина которых мутирует обьект, половина - нет

    12:18
    @jsunderhood сейчас программистов гораздо гораздо больше. И % математиков среди них стал мизерным.
    12:20
    @jsunderhood Засада в том, что, по моим наблюдения, пуфон не всегда лучше. Не всегда быстрее, уж точно.
    12:20
    @jsunderhood В питоне зато все методы мутируют.

    Ну хоть какая-то определенность

    @jsunderhood В питоне зато все методы мутируют.

    12:34
    @jsunderhood JS решает проблемы без понтов, макро и штанги. Никто не ценит идейность JS, поэтому его просто развивать.

    Да, идейность это ограничения. Поэтому безыдейный js получился таким гибким

    @jsunderhood JS решает проблемы без понтов, макро и штанги. Никто не ценит идейность JS, поэтому его просто развивать.

    12:36
    @jsunderhood И я не говорю что питон или хаскель плохие (хотя питон конечно плохой), просто объясняю почему мнение "js говно" это отлично.

    Проблема в том, что можно добавлять новый функционал, но нельзя выпиливать старое говно из-за бекворд компатибилити

    @jsunderhood И я не говорю что питон или хаскель плохие (хотя питон конечно плохой), просто объясняю почему мнение "js говно" это отлично.

    12:43
    @jsunderhood Делаю фронт (реакт), делаю бек (питон), всё нравится, где мой вариант?
    14:40
    @freiksenet_ru @jsunderhood поэтому чистый питон стоит дешевле чем фулстек? )

    Вакансий кстати именно на фулстек мало почему-то по моим наблюдениям

    @freiksenet_ru @jsunderhood поэтому чистый питон стоит дешевле чем фулстек? )

    14:42
    @jsunderhood делаю фронт, бек, архитектуру, big data, machine learning, semantic web и R&D - по-моему, это лучшая работа в мире :3

    Воу

    @jsunderhood делаю фронт, бек, архитектуру, big data, machine learning, semantic web и R&D - по-моему, это лучшая работа в мире :3

    15:36
    @yamalight @jsunderhood но в конце тебя всё равно в дурку посадят.
    16:17

    # Воскресенье 30 твитов

    @webholt ты опять взял интерпретируемый язык. сравни с чем-то побыстрее) @jsunderhood

    А это тоже вопрос. Все помешались на Go, потому что он быстрый. А зачем им скорость еще не придумали

    @webholt ты опять взял интерпретируемый язык. сравни с чем-то побыстрее) @jsunderhood

    8:11

    Сишники при этом как сидели, так и сидят, их все устраивает. Нет, вот теперь каждый пхпшник считает своим долгом написать на Go

    8:12

    На моей памяти, узким местом всегда были базы данных и никогда - сам язык. Для этого нужны нагрузки уровня fb/badoo/vk

    8:16
    @jsunderhood да тут, послушать, у всех проекты уровня fb/Google/Yandex
    8:31
    @jsunderhood Ну, хз. Когда та же запросы к базе занимают 90% бюджета быстродействия, наверное, нужно, чтобы всё работало быстро.

    Это как так, открыть сокет и начать слушать данные это 90% бюджета?

    @jsunderhood Ну, хз. Когда та же запросы к базе занимают 90% бюджета быстродействия, наверное, нужно, чтобы всё работало быстро.

    8:48

    Если запросов очень много, то это либо кривость архитектуры, либо половина из них не нужна клиенту. И тут нода хороша евент лупом

    8:50

    Поскольку у нас получилась неделя абстракций, давайте посмотрим выступление на эту тему Cheng Lou на React Europe youtu.be/mVVNJKv9esE

    9:12
    @jsunderhood вполне себе нужно, с изоморфными приложениями

    Кстати интересная тема. Давайте посмотрим кейсы изоморфа: сервер рендер, валидация. Что-то еще?

    @jsunderhood вполне себе нужно, с изоморфными приложениями

    10:40

    У нас мы используем одну валидацию на клиенте и сервере, основанную на свегер схеме. Пока полет нормальный

    10:46
    @jsunderhood @operatino переиспользование логики

    А вот это как раз то о чем я писал,как мне кажется это не взлетело. Потому что общих кейсов не так много. Как у вас?

    @jsunderhood @operatino переиспользование логики

    10:47
    @jsunderhood у нас есть переиспользование SQL запросов между сервером и мобильным приложением
    11:05
    @jsunderhood Но в целом да, редко выходит что-то пошарить между платформами.
    11:05

    Расскажите кто использует React сервер рендер, чем это вам помогает?

    11:08
    @jsunderhood любые утилиты, сервисы, комбинирование запросов можно на том же сервере делать если нету отдельного АПИ сервера с доступом
    11:22
    @jsunderhood static site generator
    11:22
    @jsunderhood сайт работает без js. Ну и роботы, конечно.
    12:35

    Еще один базворд не затронули - микросервисы

    13:23

    Сама по себе модульность - вещь хорошая и работающая, но как любое хорошее дело ее легко запороть

    13:23

    Вам нужны микросервисы, если: нужна распределенность, знаете как разделить бд, знаете как настроить кластер и CI

    13:23

    Конечно докер. Но контейнеризация-вещь молодая, мало утилит, они сырые, бест практикс нет. Мы потратили несколько месяцев только на кластер

    13:24

    Что касается разработки: все выносить в либы (npm через git), никогда не лезть в зону другого мс, заложиться на разные транспорты

    13:24

    В общем никто не мешает использовать разные языки в контейнерах, если есть кому эти языки потом поддерживать

    13:24

    В целом эти советы полезнее, чем вся эта книжка pic.twitter.com/B2KVcprZhy

    13:25

    Ну и традиционная рубрика других посмотри, себя покажи. Кидайте ссылки на ваши личные проекты

    14:26
    @jsunderhood mds-online.ru поиск и послушать онлайн "Модель для сборки"
    15:52
    @jsunderhood Генератор стайлгайдов для Реакта (вдруг кто-то ещё о нём не знает): github.com/sapegin/react-…
    16:57
    @jsunderhood npmapi.invntrm.ru — быстрое открытие github-репозиториев для npm-пакетов
    17:06
    @mxtnr @jsunderhood $ npm repo pkg — вот так проще
    17:13

    Вот и время прощаться. Кстати через час финал ЧЕ. Как вы к футболу?

    18:06

    Спасибо всем, кто участвовал в дискуссиях, это была классная неделя. Пишите фидбек по github.com/yarax/typelint, мне он очень важен :)

    18:07

    github.com

    other

    ← @smashercosmo
    @chicoxyzzy →

    @iamstarkov c любовью разработал
    @iamstarkov бережно курирует авторов