*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

В комментариях к статье 15 базовых советов по Git для эффективной работы каждый день развернулась дискуссия на тему эффективности использования тех или иных команд и опций. Надо признать, что git предоставляет столько различного функционала, что во-первых, за всем становится невозможно уследить, а во-вторых, его можно совершенно по-разному вписывать в рабочий процесс.

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Важное уточнение — все описанное в нашей статье не стоит рассматривать как чек-лист формальных правил. Это скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но, если в одном человеке сочетаются несколько из них, то вероятность этого сильно увеличивается. 

Источник: https://mlr3book.mlr-org.com/

Содержание:

1. Немного истории и сравнение с конкурирующими решениями
2. Технические детали: R6-классы и пакет data.table
3. Основные составляющие ML-пайплайна в mlr3
4. Настройка гиперпараметров
5. Обзор экосистемы mlr3
6. Пайпы и граф вычислений

Если ты – молоток, то во всём увидишь гвоздь

Исходный код

За последнее время у меня накопилось достаточно материалов по разработке плагинов для IntelliJ IDEA, чем и собираюсь поделиться с хабрасообществом.

Среда разработки и инфраструктура

Предыстория

Всем привет! Я хотел бы рассказать историю о страшных конфигах и как их удалось причесать и сделать вменяемыми. Я работаю над довольно большим и относительно старым проектом, который постоянно допиливается и разрастается. Конфигурация задается с помощью маппинга xml-файлов на java-бины. Не самое лучшее решение, но оно имеет свои плюсы — например, при создании сервиса можно передать ему бин с конфигурацией, отвечающий за его раздел. Однако, есть и минусы. Самый существенный из них — нет нормального наследования профилей конфигурации. В какой-то момент я осознал, что для того, чтобы поменять одну настройку, я должен отредактировать около 30 xml-файлов, по одному для каждого из профилей. Так больше продолжаться не могло, и было принято волевое решение все переписать.

Требования

• Наследование и переопределение (или fallback). Должна быть возможность задать некий базовый профиль, унаследовать от него дочерние и переопределить или добавить в них те места, которые необходимо
• Маппинг в java-бины. Переписывать по всему проекту использование конфигурации с бинов на проперти вида mongodb.directory.host не хотелось, использовать map-ы из map-ов тоже.
• Возможность писать в конфиге комментарии. Не критично, но удобно и приятно.

Хотелось бы, чтобы конфиг выглядел примерно так:

name = "MyTest"
description = "Apache Tomcat"

http {
    port = 80
    secure = false
}
https {
    port = 443
    secure = true
}

mappings = [
        {
            url = "/"
            active = true
        },
        {
            url = "/login"
            active = false
        }
]

Как я этого добился — под катом.

Гораздо привлекательнее выглядит использование R-интерфейсов к TensorFlow и Keras с бекендами на выбор (TensorFlow, Theano, CNTK), подробной документацией и множеством примеров. В этом сообщении будет разобрано решение задачи сегментации изображений на примере соревнования Carvana Image Masking Challenge (победители), в котором требуется научиться отделять автомобили, сфотографированные с 16 разных ракурсов, от фона. "Нейросетевая" часть полностью реализована на Keras, за обработку изображений отвечает magick (интерфейс к ImageMagick), параллельная обработка обеспечивается parallel+doParallel+foreach (Windows) или parallel+doMC+foreach (Linux).

Я занимаюсь прогнозированием временных рядов уже более 5 лет. В прошлом году мною была защищена диссертация по теме «Модель прогнозирования временных рядов по выборке максимального подобия», однако вопросов после защиты осталось порядочно. Вот один из них — общая классификация методов и моделей прогнозирования.

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

В чем разница между методом и моделью прогнозирования?

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

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

Совокупность метода и модели образуют полный рецепт!

Привет, Хабр. В своей статье я расскажу вам, что интересного произошло в мире машинного обучения за последний год (в основном в Deep Learning). А произошло очень многое, поэтому я остановился на самых, на мой взгляд, зрелищных и/или значимых достижениях. Технические аспекты улучшения архитектур сетей в статье не приводятся. Расширяем кругозор!

SAP HANA: как это работает

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

«Сказка ложь – да в ней намек…»