User
Всем привет. У меня накопилось несколько интересных решений для HomeAssistant, которыми я хочу поделиться. Сегодня я хочу сделать одометр для пылесоса.
Зачем?
Первоначально один мой знакомый попросил помочь ему с автоматизацией - сделать уведомление, когда заканчивается вода в пылесосе. Но как сделать подобное если пылесос никак не отслеживает уровень воды? Но каждый же может примерно оценить на сколько ему хватает бака?
В продуктовых компаниях все задачи часто помещают в одну очередь. В итоге разработчики стрессуют из-за объема задач и дедлайнов, хватаются за разные таски, переключаются между ними и с трудом доводят дела до конца. А если прилетает что-то незапланированное, работа может встать на неопределенный срок.
Меня зовут Артур Нек, я управляющий партнер Kaiten и Канбан-консультант. В статье на примере своей компании расскажу, как выстроить процессы в небольшой команде разработчиков, чтобы она оперативно обновляла продукт, но не выгорала.
Говорят, у менеджеров никогда нет времени - у них постоянные созвоны и миллион разных дел. Свободный слот в их расписании найти сложнее, чем билеты на концерт твоей любимой группы. Создаётся впечатление, что чем выше твоя должность, тем больше времени в сутках тебе нужно, чтобы всё успевать. И начинает казаться, что помочь тут может только маховик времени из мира волшебства. Так вот, это не так. Если к вашему тимлиду нужно записываться за 2 недели, или вы сами менеджер, и у вас постоянно не хватает ни на что времени, то знайте - это не норма.
Чаще всего мы просто не умеем управлять своим временем. Пытаемся быть везде, делать всё. Но через какое-то время должно прийти понимание простого факта - невозможно решать проблему нехватки времени простым масштабированием рабочих часов. В такой тупик часто упираются менеджеры-новички, но к некоторым понимание, как быть более эффективным, не приходит ещё очень долго. У новоиспеченного тимлида может сформироваться ощущение, что он обязан обрабатывать весь поток входящей информации и как-то на него реагировать, - помогать, решать их проблемы и т.п., т.е. тратить на все это время. Ведь он теперь тимлид, на нем всё держится! И вообще, хочется показать коллегам, что не зазнался и не превратился в небожителя, который теперь игнорирует все проблемы “простых смертных”, а наоборот всё ещё бывший коллега-разработчик, весь в доску свой и небезразличный. Но с такой загруженностью у него просто не остается времени на высокоуровневый взгляд на работу, при котором видны проблемы всего проекта. Когда же планировать стратегические - кадровые, архитектурные и коммуникационные - решения?
У начинающих тимлидов пухнет голова от того, что им нужно делать. И тут легко не заметить, что более важный вопрос - чего, наоборот, делать не следует. В этой статье разберем, как выявить подобные вещи, почему за них не стоит браться и куда их девать.
Мы писали о том, как организованы рабочие дни наших специалистов, рассказывали о разных подходах, в частности о технике помидорро. Однако те, у кого ни один из предложенных вариантов не заработал, обычно жалуются, что на воплощение хорошей идеи в жизнь не хватает сил. Все подобные техники основаны на предположении, что человек может почти неограниченно управлять своей производительностью. А по факту это не так. Да, управление доступно в определенных пределах, но возможности силы воли у каждого ограничены. Кому-то легко заходит очередной эксперимент с рабочим и нерабочим временем, а у кого-то нет сил даже на то, чтобы начать.
Поэтому сегодня расскажу про другой подход. Здесь вы не найдете “волшебного совета”, который гарантирует успевание и мотивацию. Но, возможно, почерпнете идеи о том, как можно строить свой день иначе.
В этой статье я расскажу о том, как и зачем подписывать и верифицировать коммиты в git при помощи gpg.
Всем привет! Меня зовут Леонид, я владелец сервиса Поиск VPS. Весной я уже опубликовал две статьи по оплате услуг иностранных хостеров при помощи SWIFT и криптовалют. К сожалению, карты, выпущенные российскими банками, все еще не работают в большинстве стран мира, да и не у всех есть желание и возможность оплачивать услуги указанными выше способами, поэтому сегодня я хочу предложить выборку хостеров, принимающих оплату российскими картами и предоставляющих виртуальные серверы не в России.
При составлении списка я ориентировался на количество стран, в которых возможно заказать наиболее универсальную услугу, а именно виртуальные серверы, а также минимальную цену не выше 300 рублей, 5 долларов или 5 евро в месяц. У большинства хостеров возможен заказ услуг в России, а там, где это возможно, приведена ссылка на точки Looking Glass.
Я была С++ разработчиком, когда мне предложили стать тимлидом. В моей новой команде были и разработчики, и QA-инженеры. В тестировании я имела поверхностные знания, поэтому долгое время не понимала, как подступиться к задаче по развитию QA-специалистов. Поиск решения занял несколько лет, и в этой статье я поделюсь своим опытом. Надеюсь, она будет полезна для тех тимлидов, которые в тестировании не так хороши, как в программировании.
О том, как замаскировать QEMU с Linux под приложение на Windows.
В некоторых задачах Linux просто необходим. И самым ярким тому примером на сегодня является наличие системы WSL. Однако не везде ею можно пользоваться. Некоторые предприятия принципиально застревают на Win7. И их можно понять. Эта система не столь требовательна к железу (особенно к видео-подсистеме), не ломится чуть-что в интернет, да и в Ultimate варианте вообще не требует подключения к глобальной сети.
В большей части случаев можно обойтись родными для системы средствами разработки и сторонними инструментами. Но представьте себе, что для работы Вашего комплекса нужно собрать вместе более десятка не маленьких opensource проектов с перекрёстными зависимостями. Причём часть из них написана под python (и тут никаких проблем нет - виртуальная среда и всё ок), а часть собирается в бинарные исполняшки, от которых зависят другие модули. И тут может быть как минимум три решения.
*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".
В комментариях к статье 15 базовых советов по Git для эффективной работы каждый день развернулась дискуссия на тему эффективности использования тех или иных команд и опций. Надо признать, что git предоставляет столько различного функционала, что во-первых, за всем становится невозможно уследить, а во-вторых, его можно совершенно по-разному вписывать в рабочий процесс.
Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.
В этой части я покажу как изначально выглядело деление пользовательского интерфейса и что из себя представляли Вид и Контроллер. Попробую рассказать почему в современных GUI библиотеках используется их объединение и какие вообще интересные решения можно найти в этой области на сегодняшний день. Ссылки на первоисточники приведены в начале первой части.
Начну с Вида. Не смотря на то, что Вид определяется как модуль, отображающий Модель – "а view is a (visual) representation of its model", на практике к Виду, как правило, просто относят все графические элементы GUI, то есть Видом считается все то, что мы видим на экране ЭВМ.
Понятно, что тут содержится некое противоречие, поскольку такие графические компоненты как меню, кнопки, тулбары служат не для отображения информации о системе, а прежде всего для управления системой. Клавиатура и мышь всегда были средством управления программой и находились в «ведомости» Контроллера (как бы его не трактовали). Поэтому кажется нелогичным и странным, что кнопки, сделанные из пластмассы, считаются элементами управления и относятся к Контроллеру, а кнопки, нарисованные на экране, и по сути выполняющие те же самые функции (производить входящие события), почему то относят к Виду.
— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.
Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».
Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…
И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.
Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.
