Я считал, что эта статья может являться неким введением в тему "для чего создан язык". Что ж, плюсы языка, которые тут отметили, расширение классов до наборов и изменение 1 ключевого слова. Что-то мне подсказывает, что в реальной разработке скорость ввода ключевого слова вообще ни на что не влияет. А вот добавление замечательного нового языка - уже квест для всей команды. Любопытно...
Прочитал статью вроде как по математике. В конец вывод - перебор нужно доводить до конца. Ну, приведите примеры доведенных до конца переборов на множестве хотя бы натуральных чисел
"Начали конференцию по хардкору – со взлома Яндекс Погоды. Пока Денис Рогинский рассказывал о модели машинного обучения для прогнозирования дождя на основе данных от пользователей, все вместе убедили сервис в том, что прямо сейчас над ЦДП идет дождь "
Итак, вы задали вопрос про мотивацию и самовыгорание в сфере. Что я могу сказать по этому поводу. Если вы делаете что-то такое, что вам не нравится, перестаньте, пожалуйста, делать это
Предположим, что задачу тоже не решили. Почему мы должны в это верить? В статье имеется ряд достаточно ярких бездоказательных утверждений.
«Вчера я слетал на луну, и на своём опыте доказал, что ракета на магнетроне-резонаторе — это реальность».
Да, и просто логические ляпы. В статье ли, или в головах — не ясно.
С точки зрения нейросети первый и второй способ не отличаются, особенно если не расшифровывать классификатор голов.
Спасибо за комментарий, это близко к тому, что было на практике. Только я решил добавить ещё «оптимизаций» после того, как в целом удовлетворительный результат уже был достигнут. Порядка двух минут на билд на неплохом железе меня раздражало.
С оптимизациями результат лучше в 5 раз, чем без них, без — порядка двух минут.
Артём, добавлю свои 5c. Такие задачи, как использование Spring Boot, обосновывать заказчику нет смысла и необходимости, а при этом при грамотном ведении проекта остаются области, которые можно заполнять такими задачами. Старайтесь логически вырулить в эту сторону в будущем.
Как я уже писал, изначально это огромный opensource проект, в котором основная причина медленной сборки — его размеры.
Рефакторинг кода — это, конечно, хорошая тема для этого проекта, но такая статья будет совершенно не интересна для аудитории Хабра.
При этом описанная ситуация не является уникальной, поэтому мой опыт может пригодиться другим.
Проект, который я собирал, по размерам должен быть сопоставим с karaf или camel, и в нём как раз много модулей. Он отчасти есть в opensource, но по NDA я не думаю, что могу публично назвать его.
Насчёт смысла собирать и пересобирать такой большой проект — если вы ещё раз пробежите текст статьи, там как раз и упоминается возможность не собирать постоянно все модули. Надеюсь, кому-то эта возможность пригодится помимо меня, поэтому я и написал об этом.
Про takari — спасибо за наводку!
Я считал, что эта статья может являться неким введением в тему "для чего создан язык". Что ж, плюсы языка, которые тут отметили, расширение классов до наборов и изменение 1 ключевого слова. Что-то мне подсказывает, что в реальной разработке скорость ввода ключевого слова вообще ни на что не влияет. А вот добавление замечательного нового языка - уже квест для всей команды. Любопытно...
Постоянно по тексту перевода происходит путаница между словами "development" и "deployment" в названии окружений.
Он же там не задачу 4х красок обсуждал. К чему такая подмена понятий?
Прочитал статью вроде как по математике. В конец вывод - перебор нужно доводить до конца. Ну, приведите примеры доведенных до конца переборов на множестве хотя бы натуральных чисел
Для тех, кто боится чужой базы, там есть on-premise версия
"Начали конференцию по хардкору – со взлома Яндекс Погоды. Пока Денис Рогинский рассказывал о модели машинного обучения для прогнозирования дождя на основе данных от пользователей, все вместе убедили сервис в том, что прямо сейчас над ЦДП идет дождь "
Это успех.
Итак, вы задали вопрос про мотивацию и самовыгорание в сфере. Что я могу сказать по этому поводу. Если вы делаете что-то такое, что вам не нравится, перестаньте, пожалуйста, делать это
«Вчера я слетал на луну, и на своём опыте доказал, что ракета на магнетроне-резонаторе — это реальность».
Да, и просто логические ляпы. В статье ли, или в головах — не ясно.
С точки зрения нейросети первый и второй способ не отличаются, особенно если не расшифровывать классификатор голов.
С оптимизациями результат лучше в 5 раз, чем без них, без — порядка двух минут.
Рефакторинг кода — это, конечно, хорошая тема для этого проекта, но такая статья будет совершенно не интересна для аудитории Хабра.
При этом описанная ситуация не является уникальной, поэтому мой опыт может пригодиться другим.
Насчёт смысла собирать и пересобирать такой большой проект — если вы ещё раз пробежите текст статьи, там как раз и упоминается возможность не собирать постоянно все модули. Надеюсь, кому-то эта возможность пригодится помимо меня, поэтому я и написал об этом.
Про takari — спасибо за наводку!
Не совсем, правда, понял, как вы выкручивались базовыми планами… уточните?