Роман Московский romankonstant

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

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

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

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

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

В данной статье приведены примеры вопросов и задач по React Hooks для собеседования

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

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

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

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

Расскажите про ваше понимание «хорошего тимлида»

У собеседника должно быть четкое и непротиворечивое понимание, что он вкладывает в понятие «тимлид» и какие критерии используются для оценки работы тимлида.

Возможно, это понимание даже прописано в должностных инструкциях.

Где-то тимлид должен быть разработчиком (то есть, писать код) с минимальной общественной нагрузкой, где-то руководителем, где-то пытаться совместить.

Разрабатываете на React или просто интересуетесь данной технологией? Тогда добро пожаловать в мой новый проект — Тотальный React.

Введение

Я работаю с React уже 5 лет, однако, когда дело касается структуры приложения или его внешнего вида (дизайна), сложно назвать какие-то универсальные подходы.

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

Данная статья представляет собой своего рода набор правил разработки React-приложений, доказавших свою эффективность для меня и команд, с которыми я работал.

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

Предлагаемые подходы не являются истинной в последней инстанции. Это всего лишь мое мнение. Существует много разных способов решения одной и той же задачи.

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

Можно спросить, а причем здесь техдолг, если конференция DevOps? Холиварить об этом можно, например, в рамках DevOps-фуршета, но настолько ли это широкое понятие? Мы узнали, что Артем относит к техдолгу все изменения и доработки, инфраструктурные модификации и изменения процессов, изменения структур команд, направленные на устранение гэпов — которые были допущены (осознанно или нет) в рамках запуска продуктов и фич, и которые со временем сильно мешать жить.

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

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

Задуматься о создании политики конфиденциальности (ПК) стоит уже на этапе  разработки продукта или услуги. Выпускать на рынок решение без грамотно оформленной ПК – все равно что повесить на компанию мишень для потенциальных юридических преследований.

Законы, которые регулируют ПК в России
Чтобы разобраться в том, как правильно прописать политику конфиденциальности, необходимо знать, на какие законодательные акты нужно опираться. В России ПК регулирует целый ряд законов:

Приветствую! Поговорим о Vue.js? Эта статья будет наиболее подходящей для людей уже знакомых с React. Также в этой статье я не буду пытаться быть объективным, а всего-навсего поделюсь своими впечатлениями и мыслями от достаточно молодого и прогрессивного фреймворка Vue после достаточного длительного использования React в качестве основного инструмента. Еще мы с вами посмотрим как может выглядеть совершенно простое Todos приложение на Vue, познакомившись с некоторыми его основами.

Для начала давайте посмотрим на динамику развития фреймворка, взятого из соответствующего исследования о популярности front-end инструментов:



Вышеприведенный график построен с использованием возможностей проекта NPM Trends. Здесь показано изменение количества загрузок соответствующих пакетов с течением времени. В частности, на нашем графике представлены данные за 6 месяцев 2020 года. Тут хорошо видно то, что React, по исследуемому показателю, значительно обходит конкурентов. А количество загрузок Vue, с другой стороны, постепенно растёт и сейчас находится в районе полутора миллионов.

Это неспроста, ведь Vue в качестве основных преимуществ располагает высокой скоростью, низким порогом вхождения и, что меня больше всего привлекает, лаконичной и приятной структурой. React — это мощный и замечательный инструмент, однако вы вряд ли сможете найти хотя бы 2 одинаково структурированных проекта на этом фреймворке. Да, разработчик способен довольно гибко определять архитектуру и подходы к написанию приложений, но всегда ли это хорошо? Наш сегодняшний герой позволит вам не допускать путаниц и каких-то проблем с тем, когда вы, например, садитесь на новый проект. Давайте посмотрим на Vue в деле. Я буду представлять уже готовый код приложения с пояснениями. Как установить фреймворк и создать приложение вы можете узнать из официальной документации.

Вполне возможно оценить компонент и сказать, что он легко пишется на HTML и CSS. Соглашусь, это легко, когда вы работаете, только чтобы практиковаться, но в реальном проекте всё по-другому. Идеальный адаптивный компонент, который вы только что создали, быстро перестаёт работать, когда сталкивается с реальным контентом настоящего проекта. Почему? Потому, что, пока вы рассуждаете о разработке компонента, вы можете упустить крайние случаи. Сегодня, специально к старту нового потока нашего курса по веб-разработке, поделюсь переводом статьи, в которой показан простой на первый взгляд компонент, за которым стоит огромная работа. Ради реалистичности это будет пример прямо из Facebook Messenger.

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

Подготовленный фондом OWASP cписок 10 наиболее актуальных уязвимостей приложений – это отличный ресурс для разработчиков, стремящихся создавать защищенные продукты. Дело в том, что многие мобильные приложения по своей природе уязвимы для угроз безопасности. Вспомним, к примеру, ряд нашумевших атак, произошедших за последние годы. К ним можно отнести шпионское ПО Pegasus для WhatsApp, посредством которого злоумышленники смогли заполучить управление устройствами пользователей мессенджера. Еще одним примером явился взлом приложения Pokémon Go, который позволил пользователям с помощью реверс-инжиниринга манипулировать GPS-данными и ловить больше покемонов.

Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон — от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было «по фану» кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.

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

Когда тот, кто работает в сфере Data Science, собирается показать результаты своей деятельности другим людям, оказывается, что таблиц и отчётов, полных текстов, недостаточно для того чтобы представить всё наглядно и понятно. Именно в таких ситуациях возникает нужда в визуализации данных, в такой их обработке, которая позволит всем желающим в них разобраться и ухватить суть тех сложных процессов, которые они описывают.

В этом материале я расскажу о лучших бесплатных инструментах, позволяющих без особых сложностей создавать впечатляющие визуальные представления данных. При этом тут я не буду говорить о сложных системах вроде Power BI и Google Studio. Я выбрал те 8 инструментов, о которых пойдёт речь, из-за того, что ими легко пользоваться, из-за их приятного внешнего вида, из-за того, что работать с ними можно, не написав ни единой строчки программного кода и из-за того, что они бесплатны. Кроме того, они позволяют создавать интерактивные визуализации. А это значит, что графики, представляющие некие данные, могут содержать в себе больше сведений об этих данных, чем обычные изображения. Да и работать с такими графиками интереснее.



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

Я начал программировать на Go после достаточно продолжительного периода программирования на PHP. Полагаю судя по последним тенденциям, мой случай далеко не единичный. Go в целом набирает популярность среди Web разработчиков.

Евангелисты Svelte и других библиотек любят показывать примеры тормозящих компонентов на React. React и TypeScript дают много возможностей создавать медленный код. После доклада Виктора victor-homyakov вы сможете писать более производительные компоненты без усложнения кода.

— Здравствуйте, меня зовут Виктор, я один из разработчиков страницы поиска Яндекса. На ней каждый день сотни миллионов пользователей вводят свои запросы, получают страницу со ссылками или сразу с правильными ответами. Из-за такого количества запросов нам очень важно, чтобы наш код работал оптимально. И, конечно, я сразу должен затронуть тему преждевременной оптимизации кода.

Привет! Меня зовут Алексей Соколов. Я представляю компанию mail.ru. И сегодня мы с вами поговорим об Ansible.

Есть такой сегмент продаж B2B. Вроде всё просто: компания продаёт компании. Но если разбираться, то компании-клиенту продаёт менеджер. А компания-продавец должна, как минимум, не мешать этому менеджеру продавать. В идеальном случае компания будет ещё и помогать своим менеджерам продавать.

Есть две ситуации:

– Пришёл – продавай!

– Менеджер укомплектовывается “обоймой продаж”

Вариант 1. Пришёл – продавай!

Моё первое место работы в продажах именно таким и было. Я вышел на работу, директор дал мне 3-5 буклетов “о нашем добре”. Сказал “читай, завтра спрошу”. И, к слову сказать, обещание своё сдержал, спросил, что я там вычитал о “лучшем в мире добре”. После того как мной были прочитаны буклетики, было сказано “звони” и выделен мобильный телефон. Куда звонить, кому, что говорить, зачем говорить и что делать если меня не пошлют – это осталось за гранью обучения. “Ну да ладно” подумал я и начал звонить. Получать отказы, слушать, как звонят мои более опытные коллеги (сейчас-то я понимаю, что они звонили не в холодную, а по существующим клиентам. А тогда был молод и не опытен).

Сентябрь 2010.

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

Безусловно, наибольшее влияние на мнение инвесторов о стартапе оказывает мнение других инвесторов. Очень, очень мало инвесторов, которые сами решают вложить в некий стартап. Любой основатель стартапа подтвердит, что инвесторы чаще всего спрашивают не об основателях или продукте, они спрашивают: «Кто еще вкладывает?»

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

Конвертируемые векселя позволяют стартапам выходить из таких тупиков, предоставляя инвесторам, желающим вложиться первыми, более низкую (эффективную) ставку. Такую ставку первые инвесторы вполне заслуживают, так как они рискуют больше. Гораздо безопаснее вложиться в стартап, в который уже инвестировал Рон Конуэй (Ron Conway); тот, кто пришел следом, должен платить более высокую цену.

Есть несколько вещей, которыми можно заниматься вечно: смотреть на огонь, фиксить баги в легаси-коде и, конечно, говорить о DI — и всё равно нет-нет, да и будешь сталкиваться со странными зависимостями в очередном приложении.
В контексте языка GO, впрочем, ситуация чуть сложнее, поскольку явно выраженного и всеми поддерживаемого стандарта работы с зависимостями нет и каждый крутит педали своего собственного маленького самоката — а, значит, есть что обсудить и сравнить.

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

Привет, Хабр! Представляю вашему вниманию перевод очередной статьи «Design Patterns: Abstract Factory Pattern» автора Shubham Zanwar.

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