Привет! Меня зовут Константин Берлинский, я разработчик в БКС. Некоторое время назад я прошёл курс продакт-менеджеров. Подробнее об этом можно прочитать здесь. Но сейчас не об этом. А о том, чем знания о продакт-менеджменте и стартапах полезны разработчику в корпорации даже если он не планирует создавать свой продукт или становиться продактом.

Итак, MVP. Достаточно заезженная тема, на мой взгляд. Каждый, кто хоть как-то связывал себя с разработкой программного обеспечения за последние 5 лет, с 99% вероятностью слышал эти 3 буквы. Но даже несмотря на обилие информации, народ все равно наступает на грабли «идеального продукта» при создании проектов.

Эта статья не претендует на то, чтобы быть истиной в последней инстанции. Она не про важность и необходимость MVP. И не про его роль в бережливом запуске стартапов. Я просто порассуждаю о том, каким должен быть минимально жизнеспособный продукт на момент пилотного выхода на рынок.

Начну с вирусной зарисовки пути развития стартапа по принципу MVP, которая гуляет по интернету и которую вы наверняка встречали.

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

Всем привет! Хочу очередной раз поднять тему про найм. Только я собираюсь поговорить об этом с точки зрения кандидата, а не работодателя. Ведь собеседование, вопреки многим стереотипам, процесс двусторонний — вопросы может задавать не только интервьюер, но и сам соискатель. За прошлый год я провёл порядочное количество собеседований, и абсолютное большинство кандидатов огорчило меня отсутствием вопросов о компании, всего 5 человек стали меня расспрашивать о работе.

Я же считаю, что вопросы на собеседовании должен задавать и сам кандидат, ведь ему предстоит там работать. Из стандартного описания вакансии невозможно понять, что творится в компании, да и на собеседовании принято всё немного приукрашивать. Я думаю, что соискатель должен максимально использовать собеседование для того, чтобы выяснить реальное положение дел в компании. Мало кому захочется попасть в некомфортные условия или в убыточную компанию без перспектив. Если интересно, как во время собеседования получить реальное представление о компании, то добро пожаловать под кат. Я дам список вопросов, которые обычно не ждут интервьюеры, возможно кому-то они помогут принять правильное решение при поиске работы.

Аве Кодер!

Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?

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

Есть ли способ улучшить свои навыки в 10 раз? Есть ли какой-то волшебный секрет, который — если бы вы только знали это — открыл бы для вас совершенно новый мир мастерства и производительности в разработке программного обеспечения?

Вот где сомневающиеся думают: «Здесь не удастся срезать углы! Каждый должен практиковаться, чтобы стать хорошим!» И это действительно так, но что практикуют специалисты чтобы ускорить разработку программного обеспечения, и есть ли одна ключевая вещь, которая может иметь огромное значение?

Да! Есть!

Но даже если я поделюсь им с вами — даже если я подробно изложу его для вас — вам может потребоваться 10 лет, чтобы вырасти и полностью оценить его простоту.

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

Этот секрет является ключевым отличием между средней производительностью и 10-кратной производительностью. Используя рычаги, которые дает этот секрет, вы можете быть на порядок эффективнее.

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

Секрет того, чтобы быть в 10 раз более продуктивным, заключается в овладении абстракцией. Многие разработчики относятся к «абстракции» как к грязному слову. Вы можете услышать совет, например, «не абстрагируйтесь слишком рано» или знаменитое в Zen Python «явное лучше, чем неявное», подразумевая, что конкретное лучше, чем абстрактное. И все это хорошие советы — в зависимости от контекста.

Кейси Розенталь (Casey Rosenthal), CEO и сооснователь Verica.io, выступил на митапе Test in Production. Кейси развенчал некоторые мифы о надёжности и объяснил, что многие интуитивные действия по увеличению надёжности систем на самом деле контрпродуктивны. Более того, он объяснил, как концепция непрерывной проверки (Continuous Verification) помогает разработчикам избегать таких подводных камней.

Полное выступление Кейси:

Подумайте, есть ли среди ваших знакомых люди старше 65 лет. Скорее всего, некоторые из них страдают старческими психическими расстройствами, например, забывчивостью или снижением концентрации внимания. Тем не менее отдельным людям почему-то удается сохранить остроту ума. Моему свекру 83 года, он врач на пенсии, но до сих пор редактирует книги и ведет несколько медицинских сайтов.

Почему же одним пожилым людям удается сохранить гибкость мышления, а другим нет? «Суперстарики» (термин придумал и ввел в употребление невролог Марсель Месулам) — это люди, чьи память и внимание не просто лучше средних показателей своей возрастной группы, но находятся на уровне здоровых и активных 25-летних людей. Мы с коллегами из Массачусетской больницы не так давно провели исследование, чтобы понять, с чем связан феномен суперстариков.

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

Аналитика рынка разработчиков и CTO:

• Сколько денег хотят разработчики и CTO, которые не ищут работу и как можно их замотивировать
• 4 ключевых причины, которые могут снижать стоимость разработчиков и что может повышать их ценность;
• 12 факторов, с помощью которых вы можете заинтересовать опытных экспертов;
• Могут ли кандидаты стоить для вас дешевле. Что делать, если у вас проблемы с наймом. Как кризис и пандемия повлияли на хантинг. Общие рекомендации современного хантинга.

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

Мой брат недавно отучился на компьютерщика и сейчас завершает стажировку в области фронтенд-разработки. Он узнал и о CSS Grid, и о CSS Flexbox, но в том, как он пользуется этими механизмами создания макетов, я отметил одну особенность, с которой я уже сталкивался. А именно, ему тяжело даётся принятие решений о том, когда использовать Grid, а когда — Flexbox. Например, он использовал CSS Grid для создания макета заголовка сайта. При этом он отметил, что довести проект до ума ему было нелегко, и что ему пришлось долго экспериментировать с grid-column и настраивать всё до тех пор, пока у него не получилось то, что ему было нужно.



Честно говоря, мне это не понравилось. Поэтому я решил поискать какой-нибудь ресурс, который помог бы моему брату как следует уяснить различия между Grid и Flexbox и дал бы возможность взглянуть на примеры, созданные с использованием обеих этих технологий. Но ничего подходящего мне найти не удалось. Тогда я решил написать статью, посвящённую Grid и Flexbox. Надеюсь, она получилась понятной.

От автора бестселлера «Сожги свое портфолио!» для всех фрилансеров, дизайнеров и компаний, которые устали брать цены с потолка в надежде заработать. «Среднестатистический дизайнер размышляет так: “Сколько мне взять за работу? Может, ХХХ? Да, вроде нормально. Столько и возьму”. Затем он вставляет цифры в простенькое коммерческое предложение и отсылает клиенту, скрестив пальцы и надеясь на согласование. Это касается не только фрилансеров, но и многих компаний. Я был владельцем такой компании пятнадцать лет. Половину этого времени я при помощи шестого чувства выдумывал цены в погоне за тендером. Скорее всего, многие из вас делают так же. Берут цену наугад. Ставят ее в коммерческое предложение. Отправляют клиенту и надеются на лучшее. Все изменится, когда я покажу вам работающий способ ценообразования на творческие услуги, который позволит сделать ваше коммерческое предложение наиболее выигрышным и увеличить прибыль». Майкл Джанда

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

С удалённой работой перегрузить себя ещё проще — ходить никуда не надо, никто не зовёт попить кофе, а список вариантов отдохнуть «снаружи» сократился.

В онлайне только и разговоров, как работать эффективно и сохранять баланс с отдыхом, но ведь гораздо проще включить YouTube, заесть чем-то сладеньким. Через час устать ещё больше: «Какого чёрта, я хотел посмотреть полезное видео, а смотрю как УАЗ наматывается на столб»?!

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

В этой статье я расскажу, почему медитация — лучшее средство от стресса и перегрузок.

Асхат Уразбаев (ScrumTrek)

Прежде, чем начнем говорить, как это все выглядит изнутри, с какими проблемами мы сталкиваемся, когда тренируем команду, вопрос: те, кто работает по Agile, что для вас значит, что Agile команда является Agile командой? Как вы это определяете?

Много лет назад, я пришел в один legacy-проект, который разрабатывал Владимир Филонов (pyhoster). Так я и познакомился с одним из организаторов MoscowPython, любителем копаться во внутренностях библиотек, а потом рассказывать об этом. Иронично, что теперь он собирается рассказывать, как выжить, если вам достался legacy. Это еще раз доказывает, что legacy порождают даже те, кто потом учит, как с этим жить. Мне очень хочется расспросить Владимира о том, что такое legacy, как им поменьше зарастать, как бороться, когда уже по уши в legacy, а когда всё бросать и писать заново (спойлер: никогда).

Но сперва посмотрите ролик, чтобы прочувствовать всю боль погружения в legacy…

В недавнем выпуске подкаста DotNet&More мы обсуждали с Максимом Аршиновым его предстоящий доклад на Московский .Next "Блеск и нищета предметной модели". С позицией Максима можно будет легко познакомиться непосредственно на конференции. И, в качестве дополнения, я бы хотел рассмотреть видение великого спора Анемичная VS "Богатая" ("Насыщенная") доменные модели через призму некогда популярных GRASP шаблонов

Дискуссии идут достаточно давно, например:

• Anemic Domain Model [Перевод]
• [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
  Судя по 190 комментариями к последней статье, данная тема не теряет актуальности.

Прежде чем начать разбор, хотелось бы прояснить предмет спора. Основное отличие анемичной модели от богатой в том, что она не содержит бизнес логику в теле класса. Частным примером анемичной модели может быть всем известный паттерн DTO.

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

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

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

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

Чем больше читаю про ООП, тем больше возникает ощущение, что ООП понимают не только лишь все. Очередная статья этому пример.

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

Accumulating technical debt may lead your company to a crisis. But it may also become a powerful driver of massive process changes and help with engineering practices adoptions. I'll tell you about it on my own example.

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