Как-то на кофе-брейке один из сотрудников спросил инженеров по автоматизации: «Что из рабочего опыта вы реализовали для удобства в своей квартире?». К его большому удивлению, самым популярным ответом оказалось «ничего», а на втором и последнем месте был «датчик движения для света». Вроде бы парадокс на тему «сапожника без сапог», но на самом деле любой из автоматчиков умеет отличать профессиональное заболевание («а не замутить ли сенсорный кран в туалете, прикольно же») от настоящей потребности.

Другой вопрос, если речь идёт об удобстве эксплуатации чего-нибудь побольше, чем дачный домик, да еще и чтоб инженерных систем было много. Если этажей больше одного, а помещений хотя бы десятка два, то для бесперебойного и безаварийного обслуживания такого здания приходится содержать целый взвод дяденек. В плохие дни они будут бегать со стремянкой, ругательствами и отверткой и прикладывать все силы, чтобы клиенты не заметили протекающий унитаз или погасший светильник. В спокойные дни они будут играть в Counter-Strike, а вам — если вы вдруг директор — будет казаться, что вы зря платите им деньги.

Если кто думает, что такой работы уже не осталось, так я сам в аналогичном месте имел третье место в общем зачёте за терроров. А если вы вдруг директор, ваши деньги вам дороги, а траффик от игрушек валит работу офисной почты, то наличие автоматики инженерных систем — это неиллюзорная возможность сократить персонал до 2 человек и одного монитора, хотя и большого, не меньше, чем на 50 дюймов.

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

В общих чертах запрос от заказчика именно таким и был: очень быстро нарастить вычислительные мощности под свой ИТ-проект там, где дополнительного места совсем нет. Решено было построить модульный ЦОД. И сделать это недорого. Спустя год готов рассказать, как это было. Как мы делали полную предварительную сборку и разборку ЦОДа на площадке в Сибири. Как поливали его водой из мойки “Керхер” и разогревали, как духовку. 

Заодно поделюсь нашим опытом обхода граблей при строительстве модульных дата-центров. А также расскажу о некоторых граблях, на которые мы все-таки наступили, но в каске.

Всем привет! Я CV-разработчик в КРОК. Уже 3 года мы реализуем проекты в области CV. За это время чего мы только не делали, например: мониторили водителей, чтобы во время движения они не пили, не курили, по телефону не разговаривали, смотрели на дорогу, а не сны или в облака; фиксировали любителей ездить по выделенным полосам и занимать несколько мест на парковке; следили за тем, чтобы работники носили каски, перчатки и т.п.; идентифицировали сотрудника, который хочет пройти на объект; подсчитывали всё, что только можно.

Я все это к чему?

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

Моделируем ситуацию

Представим, что мы устроились в молодую компанию “N”, деятельность которой связана с ML. Работаем мы над ML (DL, CV) проектом, потом по каким-либо причинам переключаемся на другую работу, в общем делаем перерыв, и возвращаемся к своей или чужой нейроночке.

1. Наступает момент истины, нужно как-то вспомнить на чем ты остановился, какие гиперпараметры пробовал и, самое главное, к каким результатам они привели.

Привет Хабр! Меня зовут Когунь Андрей. В КРОК я руковожу группой разработчиков Java (у нас большая распределённая по всей стране команда). Ещё я провожу встречи московского сообщества Java разработчиков JUG.MSK. Делаю это исключительно в корыстных целях: фотографируюсь там со всеми докладчиками, и однажды открою галерею с самыми интересными людьми в мире Java-разработки. Также помогаю делать конференции для разработчиков: JPoint, Joker и DevOops — в качестве члена программного комитета. Ну и для души, так сказать, преподаю Java-технологии студентам.

В КРОК мы с коллегами в основном занимаемся заказной разработкой. Одно из наших направлений — так называемые учётные системы. Их надо делать по возможности быстро. Они типовые, различия обычно наблюдаются только в доменной модели. Поэтому мы постоянно боремся за то, чтобы писать меньше бойлерплейт-кода, будь то тривиальные геттеры-сеттеры, конструкторы и т.п. или CRUD-репозитории и контроллеры. Мы для этого активно пользуем кодогенерацию.

Про неё сейчас и расскажу: покажу как взять кодогенерацию под контроль, чтобы она стала реально полезным инструментом разработчика. Попутно расскажу про технологию Xtend и покажу практические приёмы как с ней можно работать. Покажу как создавать собственные активные аннотации, писать и отлаживать код процессора аннотаций.

• Когда и какие права возникают у вас (как физлица) на код.
• Как правильно устроена передача имущественных прав на код работодателю.
• Тимлид, который делал ревью, — он соавтор или кто?
• Можно ли коммитить в свой pet-project с рабочего компьютера в рабочее время?
• Какой геморрой предстоит пройти, чтобы правильно использовать код, если вы его заказали?

1. Крупнейшие промышленные компании страны.
2. Вендоров технологий с меняющихся рынков.
3. Молодых разработчиков.
4. ИТ-инженеров с опытом работ в сфере или в конкретных нужных технологиях.