Интересная идея.
Как определяется http-ссылка на "оригинал"?
Что будет, если дистрибутив/пакет экзотический и его нигде нет?
Что будет, если ссылки на оригинал протухнут?
Не согласен, что студентам тяжело найти работу. Сейчас на рынке труда очень большой дефицит квалифицированных кадров. Поэтому многим компаниям приходится растить рабочую силу себе практически с нуля. Толковым студентам, как мне кажется, найти себе работу на 3-4 курсе в ИТ не составит проблемы.
Насчет документации — да, она не очень очевидна, как показал опрос.
Насчет иммутабельности — вы правы, но в статье специально она написана в кавычках. При этом это довольно распространенная ошибка, и ее легко допустить, особенно если мутабельность похоронена под слоями абстракций.
А про ленивость map — вы имеете в виду такую же ленивость, как в mapValues, или с мемоизацией? Насчет того, что разделять их на уровне типов — полностью согласен.
Я был на прошлой конференции, мне очень понравилось. После прочтения позиционирования конференции этого года я решил, что мне это не подходит.
На прошлой мне были доклады от дата-инженеров и devOps — т.е. про то, как весь зоопарк технологий запускать и тюнить, какие есть проблемы, с каким лучше работать в каких-то определенных задачах и т.п. Доклады по Data Science были тоже интересны, но уже для общего развития.
Ну так-то вообще можно дойти до написания на ассемблере.
Из примеров — да пусть даже обработка исключений и корректное завершение работы, которые описаны в статье.
Саму модель реализовать не зашкаливающе сложно, да. Однако чтобы это еще и быстро работало (читай, легковесные треды) и учесть крайние случаи — уже достаточно трудозатратно. Ну и писать свой велосипед тоже как-то не очень...
Пример про состояние переменной считаю некорректным, т.к. там сравниваются разные функции.
Кроме того, вычисление НОД через хвостовую рекурсию, на мой взгляд, более понятная реализация, чем циклом. По крайней мере она 1 в 1 отражает запись НОД(a,b) = HОД(b, a%b).
Да, хороший вариант. Отмечу, что тогда надо будет создать служебного пользователя для доступа только к нужным проектам, чтобы API с его авторизацией было. И из-за потенциально может потеряться информация, кто тикет создал.
Согласен, но заполнять информацию (описание, исполнитель, проект, категория и т.д.) где-то же надо? Если это в интерфейсе кибаны делать — придется копировать интерфейс создания тикета из RM. А если не заполнять — то появляется рутинная задача по исправлению всего этого дела для сгенерированных тикетов.
Да, такой вариант я упустил. Но там будут те же проблемы, что и с вариантом №2 (надо будет дублировать часть функциональности RM) и потенциально могут быть проблемы с авторизацией.
https://en.wikipedia.org/wiki/Formula_for_primes
Тема интересная, но хотелось бы увидеть сравнение с другими системами сообщений — например, кафкой или rabbitmq
Интересная идея.
Как определяется http-ссылка на "оригинал"?
Что будет, если дистрибутив/пакет экзотический и его нигде нет?
Что будет, если ссылки на оригинал протухнут?
Это далеко не свежая идея https://rg.ru/2017/06/07/v-moskve-nashli-avtomat-dlia-nakrutki-lajkov-i-podpischikov.html
А в Китае фермы для накруток держат уже несколько лет
Кажется, ваш reducer — это просто функтор. А сама идея — обычный конечный автомат, он же FSM.
Тут скорее перевод такой, в оригинале там по-другому написано
Чувак про Чёрча слышал вообще?
Так и ребята вроде учатся в загадочном "университете на Курской".
Не согласен, что студентам тяжело найти работу. Сейчас на рынке труда очень большой дефицит квалифицированных кадров. Поэтому многим компаниям приходится растить рабочую силу себе практически с нуля. Толковым студентам, как мне кажется, найти себе работу на 3-4 курсе в ИТ не составит проблемы.
Наверно, в статью стоит добавить сложность второго алгоритма.
Насчет документации — да, она не очень очевидна, как показал опрос.
Насчет иммутабельности — вы правы, но в статье специально она написана в кавычках. При этом это довольно распространенная ошибка, и ее легко допустить, особенно если мутабельность похоронена под слоями абстракций.
А про ленивость map — вы имеете в виду такую же ленивость, как в mapValues, или с мемоизацией? Насчет того, что разделять их на уровне типов — полностью согласен.
Я был на прошлой конференции, мне очень понравилось. После прочтения позиционирования конференции этого года я решил, что мне это не подходит.
На прошлой мне были доклады от дата-инженеров и devOps — т.е. про то, как весь зоопарк технологий запускать и тюнить, какие есть проблемы, с каким лучше работать в каких-то определенных задачах и т.п. Доклады по Data Science были тоже интересны, но уже для общего развития.
Ну так-то вообще можно дойти до написания на ассемблере.
Из примеров — да пусть даже обработка исключений и корректное завершение работы, которые описаны в статье.
Саму модель реализовать не зашкаливающе сложно, да. Однако чтобы это еще и быстро работало (читай, легковесные треды) и учесть крайние случаи — уже достаточно трудозатратно. Ну и писать свой велосипед тоже как-то не очень...
Предпосылки-то понятны, но не уверен, что это самый лучший вариант. Какие варианты, кстати, вообще рассматривались?
Как-то чужеродно выглядит range-оператор
..в этом dsl. Иeqтоже режет глаз.Пример про состояние переменной считаю некорректным, т.к. там сравниваются разные функции.
Кроме того, вычисление НОД через хвостовую рекурсию, на мой взгляд, более понятная реализация, чем циклом. По крайней мере она 1 в 1 отражает запись НОД(a,b) = HОД(b, a%b).
Да, хороший вариант. Отмечу, что тогда надо будет создать служебного пользователя для доступа только к нужным проектам, чтобы API с его авторизацией было. И из-за потенциально может потеряться информация, кто тикет создал.
Согласен, но заполнять информацию (описание, исполнитель, проект, категория и т.д.) где-то же надо? Если это в интерфейсе кибаны делать — придется копировать интерфейс создания тикета из RM. А если не заполнять — то появляется рутинная задача по исправлению всего этого дела для сгенерированных тикетов.
Да, такой вариант я упустил. Но там будут те же проблемы, что и с вариантом №2 (надо будет дублировать часть функциональности RM) и потенциально могут быть проблемы с авторизацией.