Хмм… Я тоже завалил какую-то шнягу на трансформацию бинарного дерева в конторе "с совой". Потом еще какую-то другую шнягу на ограниченный поиск в другой такой же "перспективной компании".
Я думаю упражнения — это хорошо, но есть один нюанс. Проходить они должны в нормальных рабочих условиях, максимально приближенных к боевым. Как часто вы impromptu будете объяснять комнате полной инженеров как манипулировать двоичными деревьями? А кодить по тимвьюверу на чужой машине, параллельно объясняя ход своих мыслей? А как на счет оптимизации кода под конкретный GC без телеметрии? Может подъем кубов с масштабируемой трехзвенкой с нуля в проде за час? Вы правда именно так работаете? Если ответ — реально "да", то, простите, я ваш вертеп укурков не пойду работать ни за какие деньги. Если "нет" — тогда зачем весь этот цирк с конями? Что вы проверяете?
Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.
В интервью очень многое — дань моде, к сожалению. Раньше было модно думать за пределами коробки, потому были круглые люки и автобусы набитые шариками. Сейчас модно хипстерство и коллаборешн, поэтому задачки и интерактив. Завтра будет найм только через нетворкинг и по количеству звезд на гитхабе. Если контора гоняется за трендами как ошпаренная, десять раз подумайте есть ли смысл там работать за +15К в год.
Если часть семантики закрыть на GADT + эмуляция поведенческих типов (это будет от пользователя спрятано и появится лишь в результирующем AST), то можно до какой-то степени быть уверенным и в семантической корректности кодогенерации.
Мне кажется это очень близко к тому, что мы пытаемся делать. Да, хороших утилит много. Скажем так, если семантика DSL не сильно ушла от исходного языка, по сути все что мы делаем — это красивый синтаксис + проверки. Тут все ложится на стандартные средства и корректность доказать дешево. Грусть приходит с трансформацией выражений, особенно когда тип результата тоже выводится в процессе.
Боевой пример: схема + условный GraphQL на входе и строго-типизированный результат на выходе. Баги в этой штуке наиболее опасные и приводят к тому, что компилятор превращается в бредогенератор. Код на выходе практически всегда компилится (мы ж все вывели автоматом!) и проходит все статические проверки (у нас ведь отличный транслятор в Java!), полностью документирован (генератор документации тоже не подкачал!), но делает какую-то фигню (упс...).
Может пример не совсем удачный. Представьте что у вас два поля — имя и фамилия. И оба — терминированные строки до 32 символов. С точки зрения компилятора имя можно присвоить фамилии и наоборот. С точки зрения семантики это будет ошибкой. Тесты и статический анализ такие вещи могут легко пропустить. Собственно идея которую пытались донести авторы — здорово когда система типов используемая в вашей программе отражает семантику. Тогда подобные ошибки можно отлавливать на этапе компиляции. Ну и еще делать кучу других классных штук, которые без семантической типизации либо делать трудно и дорого, либо вообще никак.
Лютое костыление — это из-за ограничений языка выбранного для примеров. В данном случае, по-моему, оправдано. Будь примеры на Скале или Хаскеле — началось бы "опять ваши монады-алгебры, ты на С попробуй!".
Со внутренними DSL — это из области "чем богаты, тем и рады". Если уж сильно приспичило, в той же Scala можно использовать макросы (та же идея — манипуляция AST в соответствующей фазе компиляции). А если совсем по-взрослому, то можно сделать плагин для компилятора. Или подождать пока уважаемые люди (Евгений Бурмако и компания) наконец определятся с поддержкой мета-программирования. Обещали завезти к 2020 в Scala 3.
В общем мы пытались, но потом решили отказаться. Работа с AST (в Scala) пока имеет два серьезных косяка, поэтому мы стараемся ее избегать:
во-первых IDE ничего не знает про ваши изощрения с деревьями. Поэтому либо трансформация тривиальная (трансформированное дерево после компиляции соответствует типу из контекста. т.н. blackbox), либо отрубает практически все вещи которые любят разработчики — от подсветки синтаксиса до подсказок и рефакторинга (т.н. whitebox). Даже на среднем проекте (сейчас у нас все DSL определения занимают порядка 105K строк) это уже очень грустно. Встроенные DSL выражения таки являются корректными выражениями на "основном" языке, поэтому с ними такой проблемы нет.
стоимость разработки новой фичи сильно растет, потому что надо заниматься разбором и трансформацией этих самых AST. Ну и верификацией всего этого кода, что тоже стоит дорого. Доказывать-то приходится трансформацию всего поля AST. А в Scala 2 деревья ого-го, и ко всему прочему с атрибутами и мутируемые. Короче вообще адъ и Израиль. Если немножко раскорячиться можно добиться того, что выражения DSL являются выполнимым и возвращают практически то, что нам надо, даже с грубой типизацией. Т.е. нам на этапе компиляции надо просто выполнить выражение и "допроверить" корректность. Мы так затащили подмножество SQL-92 внутрь нашего языка для поддержки маппинга таблиц и ETL ;-).
Про книжку Пирса совсем забыл. Огромное спасибо что напомнили!
Формальная спека позволяет убедиться, что ваш код в совокупности корректен и не приводит в запрещенные состояния. Гарантий что он будет решать поставленную бизнес задачу вообще говоря нет (мы гарантируем что процесс заказа пиццы завершится семантически корректным заказом и что его жизненный цикл соответствует спецификации, а имеет ли этот процесс какой-то смысл мы сказать не можем).
TDD проверяет выполнимость отдельных кейсов. Гарантии в совокупной корректности нет (мы можем показать что заказ пиццы три сыра за 10.99 в условиях успешной оплаты сработал как ожидалось, но сделать из этого вывод что он сработает во всех остальных случаях не можем).
Хмм. Как минимум я давно хотел перевести нашу методичку по DbC для Хабра...
С материалами по DSL все сложно, на самом деле. Наше приключение с ним началось с пинка от CTO, что во многом определило вектор дальнейшего развития. Так сказать по баллистической кривой. Насколько далеко мы ушли от велосипеда сказать трудно. Пожалуйста не забывайте что мы прикладники ;-)
Про DSL что могу вспомнить сходу:
Есть несколько хороших статей про то, как запилить DSL на Scala. В основном вариации на тему этого.
С формализмом я ничего напрямую применимого не нашел, ходил NorthEastern University на кафедру PRL, поил пивом людей со смежными интересами. Про интерпретаторы написано очень много чего. А вот про статические структуры не очень. Предлагают брать классические работы по системам типов и выводить оттуда.
Есть очень смешная поделка baysick которая демонстрирует некоторые приемы комбинаторного DSL. Практической пользы в последнем — никакой, разумеется. Никто так интерпретатор Бейсика писать не будет. А вот всякие декларативные системы правил так пишутся на ура.
Про DbC — наша методичка начинается с отсыла к Бертрану Мейеру, так что наверное я бы начинал с него. Так же статья на вики, если хочется уж совсем на пальцах. Эйфель мы, конечно, не используем. У нас DbC адаптирован под Java и Scala.
Вот это дискуссионный вопрос. Мне кажется тут больше от мотивации разработчика зависит, чем от его степени магистра/бакалавра и пр
Вы правы, мне стоило бы написать подробнее. Вероятнее тут наша территориальная специфика (Кэмбридж). Мотивировать инженера можно двумя путями — либо показав, что это круто и крутые чуваки так делают, либо спустив разнарядку сверху. Первое, как я писал выше, у нас не зашло. Второе у нас плохо прокатывает в силу культурных особенностей. Американские инженеры очень пассивно-агрессивные. Магистры скорее всего как минимум натаскались на линейной алгебре и хотя бы раз видели либо теорию категорий, либо мат. логику, либо еще что-то, поэтому с интересом (или хотя бы уважением) относятся к формальным методам. Местные бакалавры часто и с алгеброй-то знакомы шапочно и в большинстве встают в защитную позу сразу как видят греческую букву. Так что феномен, на мой взгляд, присутствует, просто объясняется тем, что те, у кого аллергия на формальные вещи, часто не идут на магистра в CS.
нужно серьёзное внимание уделять корректности кодогенерации
Это да. Мы постепенно эволюционируем в этом направлении, и, кстати, количество поддерживаемого кода внутри компилятора постепенно снижается, по мере перехода не "правильные" методы.
Спасибо, посмотрел. Немного не в нашу сторону. Вывести корректный алгоритмический код у нас особых проблем не вызывает (пока). После того, как мы переехали на представление в виде графов, большая часть задач "сделать из того это" сводится к обходу графов и поиску по ним. Опять же с оговоркой, что мы прикладники.
PlantUML, Graphviz/Dot, Tex/Tikz? :)
Дык мы через них и генерируем. Сначала был PlantUML, потом пришлось от него отказаться (баги + на статических диаграммах далеко не уедешь). Сейчас делаем интерактивные диаграммы с использованием Graphviz с web assembly напрямую.
Что вы думаете про промежуточные варианты (типа Design-by-Contract + DSL)?
Мы смотрели в сторону формальных проверок, но пришли к выводу что они для нас запредельно дороги, потому что порог входа высокий и разработчику без магистерской степени объяснить тот же TLA+ очень затруднительно. Продать формальные методы команде тоже оказалось не просто. Критика была в духе: "код писать все равно надо", "это избыточность", "зачем писать спеку в странном псевдокоде", "лучше тратить время на ревью или тесты" и т.д. Это не говоря уже о том, что все эти инструменты допускают математически корректные, но семантически неадекватные (с точки зрения предметной области) модели. Последнее расстраивало архитекторов ("вот я написал абсолютную чушь, а TLA+ всем доволен", "мне теперь что, программировать на ТеХ-е?!", "к вашему птичьему языку надо еще страницу наратива на простом английском, потому что строгость есть, а семантики нет").
В итоге для критических вещей мы написали DSL компилятор на базе Scala, который генерирует гарантированно (ну, когда автор с командой не налажали) корректный код для структур данных и интерфейсов сервисов (с проверками целостности, инвариантами, трансформациями между представлениями и прочим) на нескольких языках. А программеры живут под DbC и доказывают друг другу корректность устно проверяя контракты на ревью.
Получилось по-моему не плохо. С одной стороны, пришлось пожертвовать универсальностью и строгостью, но с другой стороны удалось выйти за пределы "башни из слоновой кости" в поле, к "ремесленникам".
Продать это команде оказалось проще ("круто, я не должен писать тупой код и тесты к нему", "ура-валидация!", "картинки! Оно умеет клевые доки и картинки!11"). К тому же у нас теперь есть бюджет на развитие методов верификации, потому что использование генерации уже себя окупило много раз. В вашей терминологии это что-то вроде "мануфактуры", я полагаю ;-)
Скорее всего будет очередной Гугл или Амазон ;-) А потом у них скопируют все кому не лень, если последние будут слишком жадничать. Кстати у Амазона уже есть wishlist, просто в него нельзя добавить еще не придуманные штуки. Скорее всего нельзя не потому, что это дико сложно сделать, а потому что не особо надо.
Очень интересно посмотреть на детали вашей ОГСВР, в частности как вы решаете вопрос с верификацией голосов (независимая от государства верификация, проверка легитимности голоса и т.д.). Раньше, к примеру, обсуждалась такая гипотеза: любое анонимное голосование является фальсифицируеммым. Как вы будете это решать?
С ОГСУП — я думаю это если и будущее, то уж очень-очень далекое. Государство — это прежде всего власть, и злоупотребления ею (в благих ли или в корыстных ли целях — субъективность наблюдателя). Ни один человек в здравом уме и трезвой памяти (особенно если этой памяти лет 40+) не отдаст государству столько контроля над собой, какие бы блага это не сулило (почитайте Оруэлла).
С практической же точки зрения:
"Если бы я слушал своих клиентов, я бы делал более быструю лошадь" — Генри Форд
Спрос не такой уж предсказуемый. Порвавшиеся штаны надо заменить сегодня, а не через 9 месяцев. Сколько ни тыкай в форму заказа, а произведут их тогда, когда произведут. Поэтому либо пойдешь на работу с дыркой на заднице, либо купишь то, что есть. А что есть? А есть рейтузы №3 на рост 2-10, потому что ИИ так посчитал. В теории — пишем баг репорт на ошибку 1 рода (не учел ИИ что я лазал через забор доставать мяч сыну) и ходим в подвернутых рейтузах №3. На практике — покупаем штаны у фарцы за нал и молчим. У партии в голове дзен, у населения — подпольный капитализм. Было уже.
Людям не все равно что делать. У вас фабрика медицинских расходников, вы делаете всякие штуки для больниц, вас распирает от того, какое обалденное дело вы делаете для бедных-несчастных. И тут вам валится заказ на расширение производства: силиконовые фаллосы, надувные сиськи и анальные пробки с блютус сабвуфером. Народ требует, что поделать. Заказ не отклонить, рейтинг завалится. Кто этим будет заниматься, с учетом того, что зарплаты зафиксированы? Удачи.
"People who care too much about numbers will eventually make up the numbers" — Уоррен Баффет ("люди, которые слишком верят в цифры рано или поздно их подделают"). Теслу с ее ИИ недавно можно было развернуть на дороге нарисовав правильные квадратики на асфальте. У нас после неудачного стечения обстоятельств в системе рекомендаций куча бывших военных, полицейских и пожарных получила предложения пойти поработать стриптизерами. Сколько подобных векторов атаки можно придумать на вашу систему — боюсь даже представить. Особенно если в этом заинтересованы те, кто эту систему обслуживает. И это мы еще не начали про "товар АНДРОИД ТЕЛЕФОН является дефицитом. Закажи 3 товара ПАРА РЕЗИНОВЫХ КАЛОШ и 7 товаров КУПОН НА БОРЩ В СТОЛОВОЙ №13 г. ЯКУТСК чтобы встать в очередь".
"Есть ложь, наглая ложь и еще есть статистика" — Марк Твен. Любая система способная к эволюции в конечном итоге оптимизирует себя под то, в чем оценивается ее работа. Что проще — объяснить человеку что он на самом деле хочет, или дать ему то, что он хочет? "Ешьте брюкву, она полезнее мяса". "Джинсы носят потенциальные предатели". "Косметика — для проституток". Для централизованной системы дешевле и проще манипулировать спросом, чем его удовлетворять, потому что говорящая голова в ящике дешевле и мобильнее производства во много раз. Опять же отсыл к Оруэллу.
"Профессионал — это тот, что простое делает сложно, а сложное не делает вообще" — автора не помню. Учреждение — это толпа профессионалов + административные рельсы. Они могут за 10 лет улучшить параметр ТТХ какой-то штуки на 5 процентов. Они не могут придумать кроссовки или вставляющиеся в уши наушники. В плане стоит "ботинки для бега" и "головные телефоны для спорта", поэтому на выходе будут обычные кеды с надписью "спринтер" и студийные наушники с ремнем под подбородок. Ведь на самом деле это более логично и проще производить. Чтобы сделать что-то новое, надо упороться по вожделенному предмету. А в учреждении ты приходишь в 8, уходишь в 5, получая фиксированную ЗП и в лучшем случае похвальную грамоту и авторское свидетельство. Твой успех — количество отработанных заявок к годовщине чего-то там. Потому идешь домой клепаешь кустарщину в свое творческое удовольствие. Откуда вы думаете сейчас наросло столько опенсорс проектов? Днем — копипаста, вечером — нетленка.
Не поймите меня неправильно. То, чем вы занимаетесь — очень нужно и интересно. Но ОГСУП — это утопия. Когда она будет уместна — она сама вырастет из цепочек поставок, интернет-торговли, интернета вещей и прочего, ее не надо создавать, регулировать, внедрять. Я думаю ОГСВР куда нужнее и интереснее в данный момент. Без решения этой проблемы все остальное останется на бумаге, потому что для "другого" государства нужны принципиально другие "государи".
Эта форма используется часто для DSL. В скале это одна из киллер фич. Вы описываете свои операторы для своего языка который вам подходит, получаете максимально выразительный код практически без boilerplate. Не все, конечно, ложится, но для всяких систем правил, ETL и прочего — очень удобно. Когда вы пишете просто императивный код есть соглашение, что когда есть символьные имена используется операторная нотация, а когда нет — обычная через "точку".
Ну собственно это и иллюстрирует основную проблему GraphQl, ODATA и прочих "да ну его нафиг этот сервисный уровень" подходов. Мы отдали клиенту право запрашивать все что он хочет. На практике это выливается в одну из трех альтернатив:
либо в написание довольно сложного транслятора, который умеет транслировать GraphQl запросы в наш бэкенд (предотвращение 1+M, кэширование, аффинность, индексы, вшивание проверки доступа и т.д.)
либо в написание 100500 вирутальных неявно связанных "вьюшек" в схеме (привет, REST),
либо в перекладывание ответственности на клиента (в жестком виде — 0.5 сек на запрос и дальше получи таймаут, или в более дружественном — мониторинг и уговаривание клиента поменять кривые запросы, с шантажом и угрозами если потребуется)
Скорее всего первый вариант не пойдет в качестве самописного, если вы не фейсбук. Так что реально у вас будет или middleware слой (вроде https://www.apollographql.com/) снаружи сервисов, либо прямой биндинг к БД внутри сервисов (вроде https://github.com/graphile/postgraphile), что, по сути как раз и есть альтернатива №3. В итоге, "золотая середина" — это альтернатива №2, по сути — тот же REST только сбоку.
Отдельно замечу, что прямая трансляция из GraphQl в БД не особо отличается от обмена SQL запросами, просто язык другой. Не ведитесь на обещания "GraphQl отлично работает в микросервисной среде". Ровно так он и работает — либо живите с 1+M проблемой, либо разбирайте запросы руками.
Спасибо! Под структурированными объектами имелось в виду, например, пользовательский профайл и к нему коллекция из фактов, каждый из которых может, например, содержать ещё и коллекцию событий. Если я правильно понимаю tf data хочет на вход многоколоночное представление, с ключами и значениями. Можно, конечно, развернуть все в вид user.facts.42.event.33.location.longitude, но ворчать такими "колонками" в трансформациях не айс. Особенно если надо, например, три последних локации с пользователя. Проблема именно с коллекциями переменного размера.
Питона боимся из-за питоньей типизации. Она конечно есть, но вроде того суслика. Все попытки заставить хотя бы intellisense работать в jupiter с нашими объектами провалились с позором. Ловить эти вещи на этапе компиляции значительно лучше чем на излете в стейджинге.
Вычисление градиентов распараллелить было бы очень круто. Спасибо!
Кстати, до этого наш СТО нарисовал библиотеку векторизации на Scala, работающую напрямую с Ignite. Она у нас даже продержалась пол года в проде, но потом вышел tf.transform, и мы решили от этого изделия отказаться...
Более того, структура URL-ов может измениться без ведома клиента, HATEOAS это позволяет
Не совсем. В REST (уровнем ниже) URL не может поменяться когда разработчику захотелось. Время жизни URL совпадает со временем жизни ресурса. Если вы пошли смотреть книжку, а URL вернул 404, значит книжки больше нет (семантически). Не сервер ушел, не разработчик передумал, а книжка — пффф — и исчезла. Ссылка отражает состояние и наоборот. Объяснить клиенту что "ну ты на URL не смотри, вообще-то ничего не поменялось" в рамках принципов REST нельзя никак.
Ну как же! А может редирект вернуть? Можно, но не стоит. Формально семантика редиректа — "мы переехали". Это костыль уровня протокола. Который, кстати, уже много раз засовывали куда не следует вроде авторизации и трекинга. Предполагаемое поведение клиента — повторить запрос по новому адресу и все. Для браузера это норм (у него время жизни страницы ограничено чем-то разумным), а вот для API — не годится: что клиенту дальше делать с ответом (в котором могут быть ссылки на другие ресурсы) — вообще говоря не определено. Например — автор редиректнутой книжки — это тот же самый автор или другой? Адрес другой, значит и автор другой? Или автор тот же самый, потому что адреса совпали с точностью до суффикса? Давайте разбирать URL и искать в нем уникальные идентификаторы на клиенте? Или вытащим ресурс "автор" и посмотрим на контент? Нет.
А как быть если мы накосячили, или внезапно решили что схема URL больше не отражает прекрасное? На этот случай в HATEOAS есть целое метафизическое болото про версионирование — приятного чтения, дружок, надеюсь тебе нравятся шутки про "ложки нет, а суслик есть".
TLDR: "постоянные ссылки которые могут измениться" могут измениться только через изменение версии схемы URL, а это решается версиями.
Здорово! Коллеги в параллельной команде как раз пытаются увязать TF с Ignite. Пара наболевших вопросов. Посоветуйте пожалуйста:
Основное затруднение — в Ignite лежат структурированные объекты, с реляциями между кэшами, а TF (tf.transform) хочет вектора. Писать трансформацию руками — очень занудное (а с учетом того, что на питоне — еще и весьма рискованное) занятие. Хотелось бы что-то вроде Graph QL или подобного, чтобы формировать векторы на стороне Ignite, а не тащить кучу данных в питон, чтобы потом большую часть просто выкинуть. Есть ли планы в этом направлении?
Побочное затруднение — никак не можем решить есть ли смысл гонять TF локально на Ignite нодах (или может вообще внутри процесса)? На момент начала проекта (год назад) бытовало мнение, что сеть будет "узким горлом", потому что внутренние query в Ignite очень быстрые. Сейчас мы в этом уже не уверены. Вот и по вашим цифрам получается что разница — всего 5%. Т.е. для записей размером, скажем, 4Кб, получается поток в 200К записей в секунду, что в общем соответствует нашим замерам скорости чтения прогретого кэша одним потоком. Как вы думаете: есть ли смысл в колокации вычислений для TF и Ignite?
Для меня основная критика UBI (в классической постановке) в том, что экономика, вероятно, быстро абсорбирует этот самый доход. И подобные эксперименты этот риск никак не исследуют. Логика очень проста — бедные, по меньшей мере, снимают жилье. Что арендодатель сделает, узнав что у арендатора появилось гарантированно 700 в месяц дополнительного дохода на человека? Правильно, поднимет аренду. Что сделает магазин на углу? То же самое из тех же соображений. Бензоколонка? Оператор мобильной связи? Как на счёт работы кассира в том же магазине? Вероятно зарплата если не уменьшится, то эти же 700 учтутся как-то по-другому (бенефиты порежут). И не по жадности, а потому, что бизнес в первую очередь думает о short term gains, да к тому же аналитик так посчитал. В итоге — рост цен, индексация под них, новый виток инфляции. За ним, с опозданием, подъем ставки этого базового дохода, чтобы люди не помирали с голоду. А потом повышение налогов, чтобы за это заплатить. И далее по кругу. Это естественно скорректируют — давать начнут не всем, а тем, кто больше нуждается. А как определить кому давать, а кому нет? А это опять процедуры, бюрократия, и т. д. То есть придём в самое начало.
В экономике есть два классических дефекта — бесплатные деньги (когда прибыль из ничего) и виртуальные деньги (когда в обороте деньги которых нет). Оба приводят к дизбалансу финансовых отношений. Примеров масса, от долгового рычага до спекуляции на форексе. UBI это просто ещё один.
А можно взгляд с другой стороны? Один из моих учителей рассказывал "однажды, еще в советские годы, я читал доклад на конференции; и, когда я закончил, в зале на 200 человек наступила гробовая тишина, а потом все разошлись. Следующие 5 лет мою работу не цитировал только ленивый, но это было худшее выступление в моей жизни".
Ревьювер, на время ревью, — это не начальник, это коллега. Даже если вы джун а он СТО компании. То, что он ревьювит ваш код ставит вас на одну полку. Поэтому когда я получаю много негативного фидбека по поводу своего PR, я мысленно квалифицирую ситуацию как один из двух вариантов.
придирки в духе "офромить это в стратегию, использовать такой-то паттерн, разве вы не читали великого ХХХ, это не канонично" и критика в основном не конструктивная, на мотив "так положено". Скорее всего, ревьювер — самодовольный индюк. Допилите ревью как он хочет, чтобы отвязался, и больше ему не подавайтесь с серьезными изменениями. Со временем он или сам сольется с процесса заколебавшись ревьювить однострочники, или будет индючить интернов до пенсии. Пофигу, главное чтобы был занят и не мешал. Инженеры из них как правило никакие.
замечания конструктивные и действительно по делу, чаще всего оформлены в виде вопросов или контр-примеров. Это золото профессии. Получить по рогам от мэтра приносит больше пользы чем семестр в МИТ. Наоборот когда получаешь +2 с пол оборота, это значит что либо ревьювер не особо разбирается в теме, либо ты занимаешься фигней ему (а может и всем вообще) не интересной, либо вся практика в компании вообще профанация. Повод задуматься.
Так что если вы ревьювер — не стесняйтесь завернуть PR 10 раз, вы таки помогаете человеку. Просто помните, что пока PR открыт вы с ним равны. Вы не мастер йода и он не ваш юный падаван. Вы его не учите. Вы вместе думаете как улучшить его идею. Больше задавайте вопросов, меньше комментируйте, больше диалога, меньше понтов. Если переписываете PR код — спросите согласен ли оппонент. В общем не будьте задницей и все будет отлично!
Хмм… Я тоже завалил какую-то шнягу на трансформацию бинарного дерева в конторе "с совой". Потом еще какую-то другую шнягу на ограниченный поиск в другой такой же "перспективной компании".
Я думаю упражнения — это хорошо, но есть один нюанс. Проходить они должны в нормальных рабочих условиях, максимально приближенных к боевым. Как часто вы impromptu будете объяснять комнате полной инженеров как манипулировать двоичными деревьями? А кодить по тимвьюверу на чужой машине, параллельно объясняя ход своих мыслей? А как на счет оптимизации кода под конкретный GC без телеметрии? Может подъем кубов с масштабируемой трехзвенкой с нуля в проде за час? Вы правда именно так работаете? Если ответ — реально "да", то, простите, я ваш вертеп укурков не пойду работать ни за какие деньги. Если "нет" — тогда зачем весь этот цирк с конями? Что вы проверяете?
Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.
В интервью очень многое — дань моде, к сожалению. Раньше было модно думать за пределами коробки, потому были круглые люки и автобусы набитые шариками. Сейчас модно хипстерство и коллаборешн, поэтому задачки и интерактив. Завтра будет найм только через нетворкинг и по количеству звезд на гитхабе. Если контора гоняется за трендами как ошпаренная, десять раз подумайте есть ли смысл там работать за +15К в год.
Куча новых слов, спасибо. Буду изучать.
Мне кажется это очень близко к тому, что мы пытаемся делать. Да, хороших утилит много. Скажем так, если семантика DSL не сильно ушла от исходного языка, по сути все что мы делаем — это красивый синтаксис + проверки. Тут все ложится на стандартные средства и корректность доказать дешево. Грусть приходит с трансформацией выражений, особенно когда тип результата тоже выводится в процессе.
Боевой пример: схема + условный GraphQL на входе и строго-типизированный результат на выходе. Баги в этой штуке наиболее опасные и приводят к тому, что компилятор превращается в бредогенератор. Код на выходе практически всегда компилится (мы ж все вывели автоматом!) и проходит все статические проверки (у нас ведь отличный транслятор в Java!), полностью документирован (генератор документации тоже не подкачал!), но делает какую-то фигню (упс...).
Может пример не совсем удачный. Представьте что у вас два поля — имя и фамилия. И оба — терминированные строки до 32 символов. С точки зрения компилятора имя можно присвоить фамилии и наоборот. С точки зрения семантики это будет ошибкой. Тесты и статический анализ такие вещи могут легко пропустить. Собственно идея которую пытались донести авторы — здорово когда система типов используемая в вашей программе отражает семантику. Тогда подобные ошибки можно отлавливать на этапе компиляции. Ну и еще делать кучу других классных штук, которые без семантической типизации либо делать трудно и дорого, либо вообще никак.
Лютое костыление — это из-за ограничений языка выбранного для примеров. В данном случае, по-моему, оправдано. Будь примеры на Скале или Хаскеле — началось бы "опять ваши монады-алгебры, ты на С попробуй!".
Со внутренними DSL — это из области "чем богаты, тем и рады". Если уж сильно приспичило, в той же Scala можно использовать макросы (та же идея — манипуляция AST в соответствующей фазе компиляции). А если совсем по-взрослому, то можно сделать плагин для компилятора. Или подождать пока уважаемые люди (Евгений Бурмако и компания) наконец определятся с поддержкой мета-программирования. Обещали завезти к 2020 в Scala 3.
В общем мы пытались, но потом решили отказаться. Работа с AST (в Scala) пока имеет два серьезных косяка, поэтому мы стараемся ее избегать:
Про книжку Пирса совсем забыл. Огромное спасибо что напомнили!
Это два ортогональных подхода.
Формальная спека позволяет убедиться, что ваш код в совокупности корректен и не приводит в запрещенные состояния. Гарантий что он будет решать поставленную бизнес задачу вообще говоря нет (мы гарантируем что процесс заказа пиццы завершится семантически корректным заказом и что его жизненный цикл соответствует спецификации, а имеет ли этот процесс какой-то смысл мы сказать не можем).
TDD проверяет выполнимость отдельных кейсов. Гарантии в совокупной корректности нет (мы можем показать что заказ пиццы три сыра за 10.99 в условиях успешной оплаты сработал как ожидалось, но сделать из этого вывод что он сработает во всех остальных случаях не можем).
Хмм. Как минимум я давно хотел перевести нашу методичку по DbC для Хабра...
С материалами по DSL все сложно, на самом деле. Наше приключение с ним началось с пинка от CTO, что во многом определило вектор дальнейшего развития. Так сказать по баллистической кривой. Насколько далеко мы ушли от велосипеда сказать трудно. Пожалуйста не забывайте что мы прикладники ;-)
Про DSL что могу вспомнить сходу:
Есть несколько хороших статей про то, как запилить DSL на Scala. В основном вариации на тему этого.
С формализмом я ничего напрямую применимого не нашел, ходил NorthEastern University на кафедру PRL, поил пивом людей со смежными интересами. Про интерпретаторы написано очень много чего. А вот про статические структуры не очень. Предлагают брать классические работы по системам типов и выводить оттуда.
Есть очень смешная поделка baysick которая демонстрирует некоторые приемы комбинаторного DSL. Практической пользы в последнем — никакой, разумеется. Никто так интерпретатор Бейсика писать не будет. А вот всякие декларативные системы правил так пишутся на ура.
Про DbC — наша методичка начинается с отсыла к Бертрану Мейеру, так что наверное я бы начинал с него. Так же статья на вики, если хочется уж совсем на пальцах. Эйфель мы, конечно, не используем. У нас DbC адаптирован под Java и Scala.
Скинул в личку, можем поделиться наработками.
Спасибо!
Вы правы, мне стоило бы написать подробнее. Вероятнее тут наша территориальная специфика (Кэмбридж). Мотивировать инженера можно двумя путями — либо показав, что это круто и крутые чуваки так делают, либо спустив разнарядку сверху. Первое, как я писал выше, у нас не зашло. Второе у нас плохо прокатывает в силу культурных особенностей. Американские инженеры очень пассивно-агрессивные. Магистры скорее всего как минимум натаскались на линейной алгебре и хотя бы раз видели либо теорию категорий, либо мат. логику, либо еще что-то, поэтому с интересом (или хотя бы уважением) относятся к формальным методам. Местные бакалавры часто и с алгеброй-то знакомы шапочно и в большинстве встают в защитную позу сразу как видят греческую букву. Так что феномен, на мой взгляд, присутствует, просто объясняется тем, что те, у кого аллергия на формальные вещи, часто не идут на магистра в CS.
Это да. Мы постепенно эволюционируем в этом направлении, и, кстати, количество поддерживаемого кода внутри компилятора постепенно снижается, по мере перехода не "правильные" методы.
Спасибо, посмотрел. Немного не в нашу сторону. Вывести корректный алгоритмический код у нас особых проблем не вызывает (пока). После того, как мы переехали на представление в виде графов, большая часть задач "сделать из того это" сводится к обходу графов и поиску по ним. Опять же с оговоркой, что мы прикладники.
Дык мы через них и генерируем. Сначала был PlantUML, потом пришлось от него отказаться (баги + на статических диаграммах далеко не уедешь). Сейчас делаем интерактивные диаграммы с использованием Graphviz с web assembly напрямую.
Спасибо за наводку!
Что вы думаете про промежуточные варианты (типа Design-by-Contract + DSL)?
Мы смотрели в сторону формальных проверок, но пришли к выводу что они для нас запредельно дороги, потому что порог входа высокий и разработчику без магистерской степени объяснить тот же TLA+ очень затруднительно. Продать формальные методы команде тоже оказалось не просто. Критика была в духе: "код писать все равно надо", "это избыточность", "зачем писать спеку в странном псевдокоде", "лучше тратить время на ревью или тесты" и т.д. Это не говоря уже о том, что все эти инструменты допускают математически корректные, но семантически неадекватные (с точки зрения предметной области) модели. Последнее расстраивало архитекторов ("вот я написал абсолютную чушь, а TLA+ всем доволен", "мне теперь что, программировать на ТеХ-е?!", "к вашему птичьему языку надо еще страницу наратива на простом английском, потому что строгость есть, а семантики нет").
В итоге для критических вещей мы написали DSL компилятор на базе Scala, который генерирует гарантированно (ну, когда автор с командой не налажали) корректный код для структур данных и интерфейсов сервисов (с проверками целостности, инвариантами, трансформациями между представлениями и прочим) на нескольких языках. А программеры живут под DbC и доказывают друг другу корректность устно проверяя контракты на ревью.
Получилось по-моему не плохо. С одной стороны, пришлось пожертвовать универсальностью и строгостью, но с другой стороны удалось выйти за пределы "башни из слоновой кости" в поле, к "ремесленникам".
Продать это команде оказалось проще ("круто, я не должен писать тупой код и тесты к нему", "ура-валидация!", "картинки! Оно умеет клевые доки и картинки!11"). К тому же у нас теперь есть бюджет на развитие методов верификации, потому что использование генерации уже себя окупило много раз. В вашей терминологии это что-то вроде "мануфактуры", я полагаю ;-)
Скорее всего будет очередной Гугл или Амазон ;-) А потом у них скопируют все кому не лень, если последние будут слишком жадничать. Кстати у Амазона уже есть wishlist, просто в него нельзя добавить еще не придуманные штуки. Скорее всего нельзя не потому, что это дико сложно сделать, а потому что не особо надо.
Очень интересно посмотреть на детали вашей ОГСВР, в частности как вы решаете вопрос с верификацией голосов (независимая от государства верификация, проверка легитимности голоса и т.д.). Раньше, к примеру, обсуждалась такая гипотеза: любое анонимное голосование является фальсифицируеммым. Как вы будете это решать?
С ОГСУП — я думаю это если и будущее, то уж очень-очень далекое. Государство — это прежде всего власть, и злоупотребления ею (в благих ли или в корыстных ли целях — субъективность наблюдателя). Ни один человек в здравом уме и трезвой памяти (особенно если этой памяти лет 40+) не отдаст государству столько контроля над собой, какие бы блага это не сулило (почитайте Оруэлла).
С практической же точки зрения:
Не поймите меня неправильно. То, чем вы занимаетесь — очень нужно и интересно. Но ОГСУП — это утопия. Когда она будет уместна — она сама вырастет из цепочек поставок, интернет-торговли, интернета вещей и прочего, ее не надо создавать, регулировать, внедрять. Я думаю ОГСВР куда нужнее и интереснее в данный момент. Без решения этой проблемы все остальное останется на бумаге, потому что для "другого" государства нужны принципиально другие "государи".
Спасибо! Как дела в Scala plugin с "good code is red"? Есть ли надежда увидеть поддержку whitebox прежде чем их выпилят в Scala3?
Эта форма используется часто для DSL. В скале это одна из киллер фич. Вы описываете свои операторы для своего языка который вам подходит, получаете максимально выразительный код практически без boilerplate. Не все, конечно, ложится, но для всяких систем правил, ETL и прочего — очень удобно. Когда вы пишете просто императивный код есть соглашение, что когда есть символьные имена используется операторная нотация, а когда нет — обычная через "точку".
Ну собственно это и иллюстрирует основную проблему GraphQl, ODATA и прочих "да ну его нафиг этот сервисный уровень" подходов. Мы отдали клиенту право запрашивать все что он хочет. На практике это выливается в одну из трех альтернатив:
Скорее всего первый вариант не пойдет в качестве самописного, если вы не фейсбук. Так что реально у вас будет или middleware слой (вроде https://www.apollographql.com/) снаружи сервисов, либо прямой биндинг к БД внутри сервисов (вроде https://github.com/graphile/postgraphile), что, по сути как раз и есть альтернатива №3. В итоге, "золотая середина" — это альтернатива №2, по сути — тот же REST только сбоку.
Отдельно замечу, что прямая трансляция из GraphQl в БД не особо отличается от обмена SQL запросами, просто язык другой. Не ведитесь на обещания "GraphQl отлично работает в микросервисной среде". Ровно так он и работает — либо живите с 1+M проблемой, либо разбирайте запросы руками.
Спасибо! Под структурированными объектами имелось в виду, например, пользовательский профайл и к нему коллекция из фактов, каждый из которых может, например, содержать ещё и коллекцию событий. Если я правильно понимаю tf data хочет на вход многоколоночное представление, с ключами и значениями. Можно, конечно, развернуть все в вид user.facts.42.event.33.location.longitude, но ворчать такими "колонками" в трансформациях не айс. Особенно если надо, например, три последних локации с пользователя. Проблема именно с коллекциями переменного размера.
Питона боимся из-за питоньей типизации. Она конечно есть, но вроде того суслика. Все попытки заставить хотя бы intellisense работать в jupiter с нашими объектами провалились с позором. Ловить эти вещи на этапе компиляции значительно лучше чем на излете в стейджинге.
Вычисление градиентов распараллелить было бы очень круто. Спасибо!
Кстати, до этого наш СТО нарисовал библиотеку векторизации на Scala, работающую напрямую с Ignite. Она у нас даже продержалась пол года в проде, но потом вышел tf.transform, и мы решили от этого изделия отказаться...
Не совсем. В REST (уровнем ниже) URL не может поменяться когда разработчику захотелось. Время жизни URL совпадает со временем жизни ресурса. Если вы пошли смотреть книжку, а URL вернул 404, значит книжки больше нет (семантически). Не сервер ушел, не разработчик передумал, а книжка — пффф — и исчезла. Ссылка отражает состояние и наоборот. Объяснить клиенту что "ну ты на URL не смотри, вообще-то ничего не поменялось" в рамках принципов REST нельзя никак.
Ну как же! А может редирект вернуть? Можно, но не стоит. Формально семантика редиректа — "мы переехали". Это костыль уровня протокола. Который, кстати, уже много раз засовывали куда не следует вроде авторизации и трекинга. Предполагаемое поведение клиента — повторить запрос по новому адресу и все. Для браузера это норм (у него время жизни страницы ограничено чем-то разумным), а вот для API — не годится: что клиенту дальше делать с ответом (в котором могут быть ссылки на другие ресурсы) — вообще говоря не определено. Например — автор редиректнутой книжки — это тот же самый автор или другой? Адрес другой, значит и автор другой? Или автор тот же самый, потому что адреса совпали с точностью до суффикса? Давайте разбирать URL и искать в нем уникальные идентификаторы на клиенте? Или вытащим ресурс "автор" и посмотрим на контент? Нет.
А как быть если мы накосячили, или внезапно решили что схема URL больше не отражает прекрасное? На этот случай в HATEOAS есть целое метафизическое болото про версионирование — приятного чтения, дружок, надеюсь тебе нравятся шутки про "ложки нет, а суслик есть".
TLDR: "постоянные ссылки которые могут измениться" могут измениться только через изменение версии схемы URL, а это решается версиями.
Здорово! Коллеги в параллельной команде как раз пытаются увязать TF с Ignite. Пара наболевших вопросов. Посоветуйте пожалуйста:
Основное затруднение — в Ignite лежат структурированные объекты, с реляциями между кэшами, а TF (tf.transform) хочет вектора. Писать трансформацию руками — очень занудное (а с учетом того, что на питоне — еще и весьма рискованное) занятие. Хотелось бы что-то вроде Graph QL или подобного, чтобы формировать векторы на стороне Ignite, а не тащить кучу данных в питон, чтобы потом большую часть просто выкинуть. Есть ли планы в этом направлении?
Побочное затруднение — никак не можем решить есть ли смысл гонять TF локально на Ignite нодах (или может вообще внутри процесса)? На момент начала проекта (год назад) бытовало мнение, что сеть будет "узким горлом", потому что внутренние query в Ignite очень быстрые. Сейчас мы в этом уже не уверены. Вот и по вашим цифрам получается что разница — всего 5%. Т.е. для записей размером, скажем, 4Кб, получается поток в 200К записей в секунду, что в общем соответствует нашим замерам скорости чтения прогретого кэша одним потоком. Как вы думаете: есть ли смысл в колокации вычислений для TF и Ignite?
Для меня основная критика UBI (в классической постановке) в том, что экономика, вероятно, быстро абсорбирует этот самый доход. И подобные эксперименты этот риск никак не исследуют. Логика очень проста — бедные, по меньшей мере, снимают жилье. Что арендодатель сделает, узнав что у арендатора появилось гарантированно 700 в месяц дополнительного дохода на человека? Правильно, поднимет аренду. Что сделает магазин на углу? То же самое из тех же соображений. Бензоколонка? Оператор мобильной связи? Как на счёт работы кассира в том же магазине? Вероятно зарплата если не уменьшится, то эти же 700 учтутся как-то по-другому (бенефиты порежут). И не по жадности, а потому, что бизнес в первую очередь думает о short term gains, да к тому же аналитик так посчитал. В итоге — рост цен, индексация под них, новый виток инфляции. За ним, с опозданием, подъем ставки этого базового дохода, чтобы люди не помирали с голоду. А потом повышение налогов, чтобы за это заплатить. И далее по кругу. Это естественно скорректируют — давать начнут не всем, а тем, кто больше нуждается. А как определить кому давать, а кому нет? А это опять процедуры, бюрократия, и т. д. То есть придём в самое начало.
В экономике есть два классических дефекта — бесплатные деньги (когда прибыль из ничего) и виртуальные деньги (когда в обороте деньги которых нет). Оба приводят к дизбалансу финансовых отношений. Примеров масса, от долгового рычага до спекуляции на форексе. UBI это просто ещё один.
А можно взгляд с другой стороны? Один из моих учителей рассказывал "однажды, еще в советские годы, я читал доклад на конференции; и, когда я закончил, в зале на 200 человек наступила гробовая тишина, а потом все разошлись. Следующие 5 лет мою работу не цитировал только ленивый, но это было худшее выступление в моей жизни".
Ревьювер, на время ревью, — это не начальник, это коллега. Даже если вы джун а он СТО компании. То, что он ревьювит ваш код ставит вас на одну полку. Поэтому когда я получаю много негативного фидбека по поводу своего PR, я мысленно квалифицирую ситуацию как один из двух вариантов.
Так что если вы ревьювер — не стесняйтесь завернуть PR 10 раз, вы таки помогаете человеку. Просто помните, что пока PR открыт вы с ним равны. Вы не мастер йода и он не ваш юный падаван. Вы его не учите. Вы вместе думаете как улучшить его идею. Больше задавайте вопросов, меньше комментируйте, больше диалога, меньше понтов. Если переписываете PR код — спросите согласен ли оппонент. В общем не будьте задницей и все будет отлично!