Всем привет! С вами запоздалый разработчик бэкенда @yelbota.

Я работаю чем-то типа CTO в компании DataMonsters. А вообще я люблю #Scala.

Устраиваю московский митап по Scala. Следующий в конце августа.

Еще мы недавно начали подкаст про Scala. Об этом отдельно.

Знаете почему я опаздал? Потому что пароль копипастил задом на перед. Ха-ха.

Сегодня мы будем говорить... Никогда не догадаетесь. О Scala!

Знаете, первые программистские деньги я заработал разрабатывая на MUMPS. Это был интересный опыт, если вы понимаете о чем я.

Потом было очень много AS3/Flex, Java. В 2010 познакомился со Scala, а с 2013 полностью на нее перешел. С тех пор не отпускает.

А если серьезно, то я стараюсь думаю на высоком уровне. На низкий спускаюсь, только когда проектирую свои велосипеды или все тормозит.

Можете представьте, что любите язык даже тогда когда проект инкрементально компилируется минуту? Так вот это Scala. pic.twitter.com/KYXkSG0mxL

Есть миф, что на Scala сложно начать писать. В действительности гораздо проще чем на MUMPS, уж поверьте.

Кайф в том, что можно начать писать "как обычно". То есть как на любом другом языке с си-образным синтаксисом.

Без всякого функционального программирования и монад.

Но язык устроен так, что постепенно вы начинаете втягиваться в ФП. Сначала вы перестаете пользоваться var.

@backendsecret Потом вы откажитесь от мутабельных коллекций.

@backendsecret Дальше вы познаете магию flatMap и поймете что такое тайпклассы.

Ваш код станет чистым и понятным.

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

То есть я утверждаю, что Scala простой язык.

При этом он мощнее чем любой другой язык из мэйнстрима.

Но если писать на Scala-как-на-улучшеной-Java то лучше наверно выбрать Kotlin.

То есть очень просто. Чуть непривычный синтаксис. Удобство быстро уносит в дивный новый мир аппликатиных функторов.

В обычном Scala слишком много JVM. Java-библиотеки ломают "лестницу". По этому я предлагаю начинать со Scala.js.

bit.ly/2ax433Y Scala.js лучшная Scala. Ой, кажется кто-то стучит в двель. Пожалуйста помо

Про задачи. Scala хороша, как ни странно, для бэкенда, представляете? Особенно бэкенда-без-состояния.

Если кто не в курсе большинство бэкендов которые мы пишем держат свое состояние вовне. На пример в СУБД. Это называется без-состояния.

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

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

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

По этому Scala плавно будет вас подводить к такому стилю разработки. Со временем вы перестанете понимать почему раньше писали по-другому.

На фоне нового @backendsecret придумал новый вид извращения, архитектура на основе чистых микросервисов, такие себе сервисы стесняши

Тем, кто хочет глубже погрузиться в мир функционального программирования на Scala можно рекомендовать книгу bit.ly/2aI1P0N

Для тех, кто живет энергией и угорели по изменению состояния, есть Akka akka.io. Это реализация модели акторов на Scala.

Если на пальцах, то актор это процесс. У него есть память, он умеет принимать сообщения и отправлять сообщения другим акторам.

Система акторов может быть распределена на кластер из несколько машин. Akka содержит инструменты для поддержания работы такого кластера.

@backendsecret для приверженцев корпорации зла есть AKKA .net

Но и на одной машине можно запустить миллионы акторов.

Кстати, можно поиграться со Scala прямо в браузере scala-js-fiddle.com

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

Расскажу историю про MUMPS. Изначально система работала так:

Есть отделение банка, там стоит компьютер и терминалы для операцинисток.

Терминалы работают как терминалы. Окошки в текстовом режиме.

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

В конце дня журнал транзакций пакуется в ARJ.

Компьютер дозванивается до центрального офиса и происходит обмен журналами.

Не спрашивайте в каком году это писалось. Я не знаю.

10 лет назад мы на этой системе делали киоск для приема комунальных платежей.

Все это "отделение банка" засовывалось в термирал как для оплаты телефона. Красочный клиент на Delphi ходил на этот CLI и делал проводки.

Вечером киоск дозванивался по GPRS до интернета и обменивался журналами с центральным сервером. Хайтэк.

Far be it from me to draw any premature conclusion about this... pic.twitter.com/z3zRD3VTbs

@backendsecret дык у нас доси крутится в основе бизнеса тулза писанная в 85-м, пашет так-же только обмен данными допилили постоянный :p

Всем привет. Давайте сегодня поговорим про велосипедостроение. Плюсы, минусы, подводные камни.

Общепринятое мнение заключается в том, что если что-то уже написано, то второй раз писать лучше не надо. Правильно - переиспользовать.

Это хорошо и правильно. Но почему я должен использовать говно, если оно уже написано?

Большая часть софта это жуткое bloatware. Это же относится к популярным библиотекам и фреймворкам.

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

Кроме этого многие инструменты имеют перекрывающую друг друга функциональность и разную идеоматику.

Самое страшное начинается, когда мы сами делаем какой-то инструмент. В этом случае мы транзитивно передаем зависимости нашим пользователям.

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

1) Их нужно писать. Для каждого велосипеда можно легко подсчитать стоимость разработки умножив ЗП программиста на трудозатраты.

2) Чем больше функциональности, тем дороже. В готовые инструменты вложены человекодесятилетия труда.

3) Не работает с первого раза. Первая версия велосипеда будет сырой. Это верно так же, как для любого другого ПО.

Таким образом у нас получается сложный компромис. Каким образом решить: писать свое, или использовать чужое? Попробую изложить свой рецепт.

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

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

С другой стороны, не надо писать системообразующие велосипеды, если только ваша команда не обладает топовой экспертизой в этой области.

Мой путь: берем мэйнстимовое системообразющее решение (на пример Scala+Akka), дополняем качественными утилитами, все остальное пишем сами.

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

На пример в мире Scala все пихают Akka куда можно и куда нельзя. Зачем использовать Akka, если у вас нет стэйта?

Аkka нужна когда у нас есть долгоживущие объекты со стэйтом. Какие-нибудь игроки или комнаты к примеру.

Вот, к примеру, мы делали мессенджер. Там скачала стэйт жил в Akka-акторах. Со временем стейт переехал в БД и Akka стала только мешать.

Я имею в виду, что без стейта не будет кластера. Будут просто _независимые_ вычислительные единицы.

Пойду поработаю. Вечером под пиво обсудим опенсорс и социализацию. А пока опрос. Комитите в открытые проекты?

@backendsecret :) twitter.com/glorphindale/s…

Вы исходники видели? Там же кошмар! Не то что у Windows.

@backendsecret нет, но очень хочу. Раз 6 формировал pull request’ы, но в процессе их появления решал проблему без кода и отменял их.

@backendsecret @saymons21_root да, это так. Линукс потому и ставят в некритических местах, а не на рабочих станциях.

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

pic.twitter.com/C28zX5dX3Q

Лично я комичу почти исключительно в свои проекты. Очень редко куда-нибудь еще. Из крупных проектов был маленький PR в Scala.js.

Когда-то относительно давно активно участвовал во Flexmojos. Это была такая мавен-инфраструктура для Adobe Flex.

Не могу не воспользоваться случаем попиарить свою любу для JSON в Scala github.com/fomkin/pushka

И свой HTTP-сервер для API github.com/fomkin/vodka Юзать его нельзя, но присоединиться к разработке можно. Это для тех кто хочет в Scala.

Три стадии опьянения:
1) Забранчил, пофиксил, забыл запушить
2) Пофиксил, запушил, забыл забранчить.
3) Забранчил, запушил, забыл пофиксить.

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

Лучший способ оценить программиста - посмотреть как он работает в репе. Сам код, подписи к комитам, наличие README, как сборка сделана.

Вообще я считаю, что пустой гитхаб в 2016 году это звоночек. Либо перед нами "программист старой закалки" либо с ним что-то не так.

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

Потому что он нашел ошибку в документации. Потому что у него появилась хорошая идея и он решил сделать PoC.

Я мечтаю что бы компания, где я работаю, производила много хорошего опенсорса. Пока это не так. Привет @data_monsters

На открытие проектов требуются дополнительные ресурсы, которые сложно выделить. И бизнес не всегда согласен. Так что увы и ах.

В будущем проприетарного кода не будет. Программы будут доступны под свободными лицензиями. Дело Столлмана живет! pic.twitter.com/9vNqyeveqt

После трудовой недели могу себе позволить немного крепкого! pic.twitter.com/PmcnUEMezh

Кстати тема с гитхабом должна работать в обе стороны. У компании должны быть открытые проекты, а не их видимость (я знаю вы читаете меня).

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

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

@backendsecret да, так в гугол зовут

Когда-нибудь будут языки в которых мы будем параметризовать вычислительную систему алгоритмом, а интерфейс будет заменен ИИ.

@backendsecret - Каким вы видите свой гитхаб через 5 лет?

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

А пока 90% нашей работы это машинерия. Обертки вокруг алгоритмов, которые тоже по 100 раз надо переписывать, потому что платформозависимость

@backendsecret это не связано, но одно скажу точно: программист, не зарабатывающий деньги для компании, не нужен ни в 30, ни в 20 лет.

@raxpost @backendsecret @saymons21_root сервер можно перезагрузить и никто не заметит, а рабочую станцию нельзя :-)

Ребята, я знал, что бомбанет. Спокойно, гитхаб не универсальный критерий. Собеседование не заканчивается его предъявлением.

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

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

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

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

Делать опенсорс - это инвестировать в свое будущее. Точно так же как читать умные книжки и проходить курсы.

На этом и закончим. А то уже очепятки делать начинаю. Завтра поговорим про роль образования и что нужно уметь программисту в 2016 году.

На последок вброшу свой прошлогодний пост bit.ly/2aAJyTn

Кстати с минуту на минуту будет трансляция моего любимого #DevZen devzen.ru/live/ Общение в гитлере gitter.im/DevZenRu/live

Начало записи #devzen задерживается минут на 10, так что вы еще можете успеть к самому началу! devzen.ru/live/

На пример есть задача: нужно распознать американский футбол или европейский. Можно бешено учить нейросеть, а можно посмотреть локацию IP.

Если с US айпишника загружена картинка, то американский, в противном случае европейский. Докладчик утверждает что точность большая.

Такой вот feature engineering.

А есть и просто чисто формальные системы.

Я не специалист по ML, но по моему это очевидно. Поправьте если не прав.

Что на фотографиях с хаски всегда снег.

Доклад про футбол (десятая минута). youtube.com/watch?v=d8sEmG…

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

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

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

При этом я долгое время считал, что правильно поступил, что люди зря тратят время в ВУЗах.

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

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

Тем не менее программировать без образования можно. Причина: у нас кустарное ремесло. Информатика далека от решения реальных задач.

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

Буквально нет никакого моста между академической информатикой и промышленных программированием.

Промышленное программирование существует параллельно. Знаменитые паттерны (вообще антинаучная кустарная хрень), "знания фреймворков".

Теперь микросоервисам и правильному сервис дискавери еще учат.

И для программиста это начинает составлять основу знаний. Получается есть одна кучка с паттернами и этим всем. Это он применяет ежедневно.

И есть вторая кучка с "алгоритмами и структурами данных". Он не забывает их исключительно ради собеседований.

Почему мне нравится функциональщина? Потому что она основана на науке. Вместо грубых "паттернов" там есть теория категорий.

ФП дисциплинирует. Что бы быть хорошим в ФП нужно уметь видеть закономерности.

Без образования тяжело в ФП. Теория категорий не базовая дисциплина. Все материалы подразумевают что ты заботал и хорошо помнишь математику.

@backendsecret twitter.com/scienceporn/st…

И ты начинаешь ботать. Но выясняется что у любой дисциплины есть такой же контекст. Получается что математику надо учить с детства.

Мне в седьмом классе на вопросы "почему у квадратного уравнения два корня? и вообще что значит два корня?" училка сказала, что я тупой.

С тех пор я знаю математику так. Мне понятно что такое группа, полугруппа, моноид и функтор. Но не понятно что такое линейное пространство.

Хотя в последнее время начинаю врубаться. Надо ведь соответствовать, когда в команде два кандидата наук с цитируемыми публикациями.

В будущем без образования программировать не получится. ФП заменит то что есть сейчас, как станок с ЧПУ заменил кустарное производство.

Она упрощается потому что умные ребята ее упрощают и удешевляют. Со временем "операторы станков" и станут не нужны.

Некоторые сомневаются, что кодирующие обезьянки станут не нужны. Помните такую профессию "эникейщик"?

Это такой мальчик, который виндовс умел переустанавливать и Ctrl+Alt+Del, "загрузить в безопасном режиме".

Их нет. Так же как вымирают "админы на сетке". Так же вымрут специалисты по вордпрессу или какому-нибудь BPM-движку.

Никогда больше не буду пытать сделать заказную разработку в России. Никогда.

Такие дела, котятки. Надо получать образование и развивать его. Или вас заменит какой-нибудь клауд сервис написаный парой умных дядек.

Важный вопрос. Чем вы руководствуетесь?

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

Три столпа ООП: костылирование, инкостыляция и поликостылизм.

Иногда я жалею что вырос воспитанным человеком.

Чем вы занимаетесь, когда не работаете или учитесь? Я воспитываю сына, читаю худ. литературу, играю на PS4, катаюсь на велике.

Из худ. литературы в последнее время очень нравится Нил Стивенсон. Особенно хорош Алмазный Век.

Из игр меня очень впечатлила Child of Light. Такая европейская JRPG для девочек допубертатного возраста. Невероятно крутая.

@backendsecret делаю подкаст @podcastcode, копаюсь в математике музыки, бегаю, читаю

Саундтрэк к Child of Light шикарный youtube.com/watch?v=93h-8M…

@backendsecret сплю. в чём-нибудь новом ковыряюсь (но всё реже и реже :(

И крутого еще To The Moon. В нее прям на ноуте можно играть. Там меньше про игру, больше про историю.

Есть интересная тема. Но прежде маленкий опрос. Тормозит? http://185.143.172.173:9190 (новые тудушки под скорлом)

Окей. 10 голосов. У 2 тормозит, у 8 нет. Будем считать результат достаточным.

"При чем же здесь бэкенд?" - спросите вы. Отвечаю. Эта программа работает полностью на сервере. На клиенте пару строчек служебного кода.

Вот так примерно выглядит код gist.github.com/fomkin/2d20996…

Схема такая. Сервер отправляет на клиент команды па манипуляцию с DOM, клиент присылает события от пользователя.

Таким образом мы вновь получаем тонкий клиент. Только с юзер-экспириенсом одностраничного вэб-приложения.

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

Мы получаем бесшовную разработку "все в одном месте". Пользователь экономит батарею и процессор, потому что на клиенте ничего не выполняется

Это PoC, по этому никаких оптимизаций не делалось. Крутится на серваке с 512 МБ.

Теперь о коде. Кто понимает что здесь написано bit.ly/2aWm0JG?

Фронтэндеры должны были узнать Redux/React с поправкой на Scala.

@backendsecret я Java разработчик. Но все понял, Доктор, это плохо?

@backendsecret О, под Emscripten кстати были демки с GUI ещё. Даже игры запускают (OpenTTD, например: epicport.com/ru/ttd)

А вот и он github.com/lihaoyi/Scalite К сожалению заброжен :(

А можешь пойти и почитать книжку по судостроению. Спроектировать в CADe детали, взять станок и запилить их. Потом собрать лодку.

А теперь представь что это происходит в XVII веке. Все обычно выбирают первый путь. Второй путь пока не понятен.

@backendsecret О, а могу попиариться? Набросал как-то вечером github.com/iamale/twt. Подходит для любых языков с {}

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

И кустари такие говорят: "Ну и чо?". Ни кто же не понимает, что вторым способом можно построить авианосец @borovikov

@backendsecret пока это выглядит так, что мне рекомендуют сделать лодку в виде сферы, так как у неё наименьшая площадь при заданном объёме

Продолжая про толстый-сервер-на-скале. Будем звать его Королев. Я устал писать REST (хотя я его обычно не пишу), а вы?

Есть всякие GraphQL и прочее, но в конечном итоге все сводится к построению AP системы, а это сложно (призывается @gritzko) @filipovskii

@backendsecret @filipovskii ага, первые 10 лет точно

Так что радикальное предложение: пускай все будет на серваке.

Скорость разработки драматически вырастет. Надежность тоже, ведь система становится проще.

Бизнес выиграет. Кроме того мы пополним ряды бэкендеров грамотными фронэндерами, а код-манкиз спишем в утиль.

@backendsecret 😃 радикальное предложение в ответ — не писать сервера самим, всё равно они делают одно и то же m.youtube.com/watch?v=XRWZqq…

Тоже хорошая тема. Пишем толстенный клиент, прямой коннект к базе, роли, хранимочки. Как в 90е. Tasty! @filipovskii

Для смартфорна придется городить API конечно @iamale_ru

Мы не путаем термины "клиент" и "пользовательский интерфэйс"? @filipovskii

То есть BaaS для самых простых случаев? @filipovskii

Да без разницы @chikiro_twi

Я давно уже на C пишу функции, так что с ФП знаком не по наслышке twitter.com/backendsecret/…

Выложили первый выпуск #Scalalaz #podcast soundcloud.com/aleksey-fomkin…

Availability + Partition Tolerance @Uznick

@backendsecret Не, не было такого. Redux отчасти инспирирован Elm Architecture. React изначально был сделан на SML вроде бы.

Всем доброе утро (или что у вас там). Сегодня у меня уже не получится с вами пообщаться. Надеюсь было интересно :)

С вами был @yelbota P.S Подписывайтесь на комиксы про DataWorld @data_monsters