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


Панель управления квартирой в феврале 2020 года (Home Assistant)

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


Строительство нашего дома в процессе — ноябрь 2016 года

tl;dr У 90% современных смартфонов диагональ экрана превышает пять дюймов. Появление таких дисплеев представило принципиально новые проблемы для разработчиков приложений и дизайнеров. Давайте посмотрим, как их решить.



После презентации Apple в январе 2007 года весь мир сжался до размера наших ладошек. Компания объединила iPod, телефон и браузер в едином устройстве. Apple представила на массовый рынок новый для себя класс устройств, которые нам сегодня известны как «смартфоны». Эти гаджеты работали без клавиатуры (как у BlackBerry) или стилуса (как Palm).

iPhone был спроектирован для удобной работы только одной рукой, с плавными движениями большим пальцем по экрану.

Как я пришел к покупке приточной вентиляции для квартиры с готовым ремонтом. Как купил ее за 150к и чуть не потратил деньги зря. Статья будет полезна тем, кто планирует купить очиститель воздуха, бризер или приточку.

Знакомьтесь, это Дима. Он тимлид и отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок — мотивирует, нанимает и, если надо, увольняет. Дима хочет работать только над важными задачами, но работает над миллионом самых разных, постоянно думает о работе и не высыпается. У него все горит: сроки, задачи, время и самооценка. Дима в аду.



Знакомая ситуация? Для Алексея Катаева (deusdeorum) — точно. Алексей больше 15 лет занимается веб-разработкой как backend, frontend, fullstack-разработчик и тимлид. Сейчас Алексей работает в Skyeng и как-то раз ему удалось сделать из команды суперкоманду — лучшую в компании. И с тех пор Алексей занимается тем, что создает в Skyeng суперкоманды на постоянной основе. Как он это делает, в расшифровке доклада, который участники TeamLead Conf 2019 назвали лучшим на конференции.


Рекомендуем посмотреть видео, если есть время, — Алексей заряжает энтузиазмом к переменам. А статья лучше подходит, чтобы просмотреть основные тезисы задуматься о чем-то, что раньше всегда ускользало.

Привет! Меня зовут Дмитрий Ли, я тимлид одной из команд разработки бэкенда в Badoo.

Когда я впервые стал тимлидом, я стал активно посещать конференции и читать умные книги об управлении командой. Однако в моей работе после этого менялось немногое. Я читал о том, каким я должен быть, в чём должен развиваться, но мне было неясно, что конкретно для этого нужно делать.

Мне пришлось не раз и не два наступить на одни и те же грабли, прежде чем я разобрался, что мешает наладить и улучшить мою работу. Поэтому для выступления на Saint TeamLead Conf я решил собрать из своего нынешнего опыта советы, которых мне не хватало на старте моей карьеры управленца. Эти вещи сильно упростили бы мне жизнь, если бы я знал о них раньше. 

Рецепты, которыми я хочу поделиться, в большей степени пригодятся начинающим тимлидам: я записал их как своеобразное наставление себе самому несколько лет назад. Эта статья написана по мотивам моего доклада на TeamLeads Conf.

ООП (Объектно-Ориентированное Программирование) стало неотъемлемой частью разработки многих современных проектов, но, не смотря на популярность, эта парадигма является далеко не единственной. Если вы уже умеете работать с другими парадигмами и хотели бы ознакомиться с оккультизмом ООП, то впереди вас ждет немного лонгрид и два мегабайта картинок и анимаций. В качестве примеров будут выступать трансформеры.

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

Первой в списке стояла слепая печать, которую давно откладывал. Теперь считаю её необходимой для каждого, для кого код и конфигурация – профессия. Под катом расскажу как перевернулся мой мир, и поделюсь советами как перевернуть ваш. Заодно приглашаю поделиться своими рецептами и мнениями.

11 сентября 1903 г. в семье осевшего в Москве крестьянина-старовера Павла Алимарина родился сын, которого назвали Ваней.

Ване Алимарину не везло с образованием. Нет, начальное образование он получил — в Рогожском училище.


Ваня Алимарин (в центре) — ученик Рогожского училища.

Нет, не в том Рогожском училище, которое сейчас Московское старообрядческое духовное училище, а том Рогожском училище, которое сейчас Детская музыкальная школа имени Н.А. Алексеева. Да, того самого Николая Александровича Алексеева, который знаменитый московский городской голова, основатель и первый директор училища. Который потом передал директорство своему двоюродному брату, известному предпринимателю и промышленнику Константину Сергеевичу Алексееву, более известному под сценическим псевдонимом «Станиславский». Да, тот самый, который «Не верю!».

Но я отвлекся. Вернемся к Ване, который закончил Рогожское училище.

Код — это мысль. Появляется задача, и разработчик думает, как её решить, как выразить требования в функциях и классах, как сдружить их, как добиться строгости и корректности и как подмастить бизнес. Практики, методики, принципы, шаблоны и подходы — всё нужно учесть и всё нужно помнить.

И вместе с этим мы видим повсеместную эпидемию менеджеров, хелперов, сервисов, контроллеров, селекторов, адаптеров, геттеров, сеттеров и другой нечисти: всё это мёртвый код. Он сковывает и загромождает.

Бороться предлагаю вот как: нужно представлять программы как текст на естественном языке и оценивать их соответственно. Как это и что получается — в статье.

Flowcon, или Флакон – методика управления, в том числе – задачами. Потоком, проектом, разработкой, рутинными функциями, регуляркой и т.д.

Многие, узнав о методике и решениях на ее основе, задают вопросы – что да как, в чем суть, на основе каких «мировых практик» сделано, какие метрики используются, кому подходит, откуда вообще взялось. Я отвечал каждому индивидуально, но решил – все, стопэ, надоело писать одно и то же по сто раз. Программист я, или кто? Повторное использование может быть не только для кода, но и для информации. Напишу один раз, постараюсь ответить в статье на все вопросы, и будь что будет.

Лучше всего, мне кажется, в виде истории изложить, потому что рождение флакона тесно связано с моей, с позволения сказать, карьерой. Так и поступлю. Погнали.

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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

Обо всем по порядку.

У вас большой UIViewController? У многих да. С одной стороны, в нём работа с данными, с другой — с интерфейсом.

Задачи отделения логики от интерфейса описаны в сотнях статей про архитектуру: MVP, MVVM, VIPER. Они решают проблему потока данных, но не отвечают на вопрос как работать с интерфейсом: в одном месте остается создание элементов, лейаут, настройка, обработка ввода и анимации.

Давайте отделим view от controller и посмотрим чем нам поможет loadView().

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

Жизнь без света невозможна в принципе: не будет фотосинтеза, остановятся многие биохимические реакции, зрение человека и животных окажется совершенно бесполезным. И в то же время мы все с вами — жертвы светового загрязнения, которое покорило большие города по всему миру. Так зло или благо искусственный свет, где его мера и как он влияет на здоровье человека? Мы нашли повод поговорить об этом.



Мы собрали несколько самых популярных вопросов о свете и решили пролить на них свет — в прямом смысле слова, потому что лампы занимают огромную долю среди посылок, летящих из Gearbest по всему свету (вот это каламбур!). Ну что, добудем свет?

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

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



То, что доклад на эту тему был признан лучшим на конференции для тимлидов и о тимлидах, показывает, насколько действительно часто встречается такая ситуация. Но надо признать, конечно, что Евгений Кот (bunopus) заработал это «признание» еще и великолепным перформансом. С удовольствием делимся с вами его записью.

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

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких:

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

Они где-то там, в темноте. Невидимые, неслышимые и безмолвные. Забытые практически всеми жителями Земли– им уже давно не перепадают ни мнемоны, ни даже лямишки. У счастливчиков есть родственник, в наш дурацкий суетливый век зачем-то озаботившийся «генекологическим древом». У большинства нет даже этого.

Ты входишь туда, в эту непрогрядную черноту, один. Ты понятия не имеешь, куда идти. Всё, что у тебя есть – фамилия и инициалы. Жалкое имущество, если честно. Особенно если фамилия – Кузнецов или Смирнов. «Иметь в Германии фамилию Мюллер…», ога, ога. Но ты идешь, просто потому, что бываешь здесь частенько, и на ощупь знаешь расхожие тропки, где можно зацепить какой-то хвостик, унюхать какой-то след. Ты не знаешь, сколько ты будешь бродить, и понятия не имеешь, как ты выйдешь – с пустыми руками, или выведешь на свет человека.

Да, по-прежнему мало кому интересного, но уже не безразличного тебе. А это почему-то важно – вывести его на свет. Я не знаю почему. Горчев, уже довольно давно ушедший туда, как-то написал эссе, которого мне и под угрозой расстрела не написать. Вы наверняка его читали, про Предназначение, а если не читали, то вы какие-то странные люди, обкрадывающие сами себя. Ну да, то самое: «На самом же деле, узнать своё Предназначение не очень сложно: если человек делает что-то просто так, не за деньги, и вообще никому это на*** не нужно, то это означает, что вот это самое и есть его настоящее Предназначение». Я бы так громко не сказал, конечно, но что-то в этом есть.

Просто… Они там совсем одни, понимаете? Совсем-совсем. А так про них узнаю хотя бы я.

Ладно, если без романтики и соплей, то все очень просто.

На прошлой неделе я начал разговор о книге Криса Ноддера «Evil by Design», где рассказывается, как доводить пользователей до греха, получая от этого выгоду, и вкратце изложил методики из первых глав. Сегодня рассказываю об оставшихся грехах — гневе, зависти, вожделении и жадности: что кроется за типами поведения, которые мы описываем этими понятиями, и как маркетинговые тактики используют соответствующие слабости человеческой натуры в собственных целях.

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

Да, под Node.js можно написать сервер, но для бэковой разработки, все же, .net бесспорный лидер. На js, на мой взгляд, очень сложно написать гибкий и легко поддерживаемый бэкенд, хотя возможно многие со мной и не согласятся.

Давайте ударим автопробегом по бездорожью попытаемся вопреки всему этому написать SPA приложение с бэком на .net core и клиентом на js, из инструментов разработки будем использовать горячо любимую Visual Studio.

После этого туториала, я надеюсь, веб и бэк разработчикам будет проще найти почву под ногами в вражьей области и понять в какую сторону двигаться для более углубленного изучения. Поехали!

Если вы .NET программист, то вы наверняка объявляли и использовали события в своем коде. Несмотря на это, не все знают, как события работают внутри и какие особенности связаны с их применением. В этой статье я попытался описать работу событий как можно более подробно, включая некоторые частные случаи, с которыми редко приходится иметь дело, но про которые важно и\или интересно знать.