Заметки Андрея Романова
1.31K subscribers
40 photos
100 links
Разработка интерфейсов, дизайн, программирование и всё остальное. Вопросы, пожелания, комментарии — @andrew_r

http://andrew-r.ru
Download Telegram
Неплохая идея для улучшения UX формы регистрации: новая версия Chrome предлагает использовать автоматически сгенерированный рандомный пароль
Пользуетесь менеджерами паролей?
anonymous poll

Не пользуюсь и придумываю пароли сам – 212
👍👍👍👍👍👍👍 43%

Пользуюсь и генерирую рандомные пароли – 154
👍👍👍👍👍 31%

Пользуюсь и придумываю пароли сам – 104
👍👍👍 21%

Не пользуюсь и генерирую рандомные пароли – 25
👍 5%

👥 495 people voted so far.
Удивительно, что по результатам опроса большинство не пользуется менеджерами паролей и придумывают пароли сами. Кажется, такой вариант жизнеспособен только если у вас хорошая память или если вы используете один и тот же пароль на многих сайтах 🤔 Раньше я тоже почти везде использовал один и тот же пароль, но горький опыт научил меня так не делать.

Одним утром я открыл Телеграм и увидел в @forwebdev рекламу каких-то миостимуляторов, которую не публиковал; оказалось, что незадолго до этого произошла утечка данных одного сервиса, и мой пароль на этом сервисе совпадал с паролем моего аккаунта в Амплифере. Злоумышленники каким-то образом получили доступ к моему и ещё нескольким аккаунтам в Амплифере и опубликовали эту злочастную рекламу. Рекламу я удалил, но картинки из неё теперь живут в виде стикеров.
This media is not supported in your browser
VIEW IN TELEGRAM
Когда используешь один и тот же пароль на разных сайтах ↑
Читатель делится способом запоминать пароли без мучений (правда утечка паролей такого вида всё равно опасна):
Forwarded from Влад
Привет! По поводу паролей — есть метод и без хорошей памяти, и без генераторов. У пароля должна быть какая-то статическая часть, как у классического, и какая-то динамическая, которая зависит от контекста ввода (название сервиса, самое банальное). Чтобы скомпрометировать пароли от других сервисов, нужен человек с логикой. По крайней мере, я не слышал про алгоритмы, которые этим занимаются.
​​Хорошая статья на Т—Ж о том, с чего следует начинать любой стартап или бизнес: исследование потребностей клиента. TL; DR в прикреплённом скриншоте. Ну а у меня к статье есть яркий пример того, как делать стартапы не нужно.

Моим первым местом работы после фриланса был омский стартап по автоматизации дистрибьюторского бизнеса, в котором я отвечал за вёрстку и учился фронтенду. До моего прихода примерно полтора года разрабатывались бэкенд и мобильные приложения, с моим приходом начали делать веб-кабинеты. Когда собрали первую более-менее рабочую версию системы со всей необходимой функциональностью, основатели поехали в Москву на какую-то промышленную выставку с нашей целевой аудиторией. Показали систему, собрали контакты потенциальных клиентов, стали их обзванивать, но продажи не шли. Оказалось, что подобные системы уже существуют и вполне успешно используются нашими потенциальными клиентами. Спустя месяц стартап закрылся, а в счёт последней зарплаты мне отдали мой рабочий ноутбук.
​​Нашёл достойную замену адблоку: umatrix.

Это бразуерное расширение, которое по умолчанию запрещает сайтам доступ к сторонним ресурсам вроде скриптов и кук с других хостов (запрет на доступ к какому-то ресурсу при необходимости можно снять). Если адблок блокирует только рекламу (и то не всю), то umatrix блокирует ещё и всякую гадость вроде скриптов аналитики и трекинга.
Что нужно делать, чтобы стать техническим директором?

Из книги Камиль Фурнье «От разработчика до руководителя»:

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

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

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

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

Технические директора в большинстве работают в небольших компаниях, часто являясь их соучредителями. Если вы хотите пойти таким путём, найдите компанию, из которой ранее уже уходили сотрудники, чтобы основать что-то своё. Именно в ней вы сможете найти своих будущих соучредителей или возможность быстро попасть в новую компанию»
​​Почему не стоит использовать компоненты высшего порядка (HOCs) в Реакте и какая им есть альтернатива — http://andrew-r.ru/notes/react-hocs
​​Если вы устали от постоянного чувства гонки за технологиями и лучшим будущим, возможно вам поможет хороший совет Тима Маринина о важности пустого пространства в жизни — https://marinintim.com/2018/negative-space/
​​Автоматизация релизов с помощью semantic-release

На работе мне регулярно нужно публиковать NPM-пакет и вести для него список изменений. Раньше я делал это вручную, и поэтому на это уходило ощутимое количество времени: нужно было сформировать список изменений, определить следующую версию, выполнить npm publish, дождаться прогона всех тестов и самой публикации.

Если вы столкнулись (или в будущем столкнётесь) с такой же проблемой, сразу внедряйте semantic-release: он автоматизирует всю рутину и максимально исключает человеческий фактор (например, неправильный выбор следующей версии пакета). semantic-release встраивается в CI, так что для публикации новой версии пакета достаточно просто запушить код в репозиторий.

Что особенно круто — процесс публикации максимально абстрагирован и разбит на шаги, а вся специфичная логика реализуется через плагины. Это позволяет делать публикацию куда угодно, а не только в NPM, да и вообще кастомизировать процесс публикации: например, можно реализовать отправку списка изменений в Slack после публикации.

Единственное, что от вас потребуется — один раз настроить инструмент и затем выполнять соглашения по именованию коммитов, по которым он будет автоматически определять следующую версию пакета и формировать список изменений. Кстати, требования к именованию коммитов — ещё одно косвенное преимущество: история изменений становится чище и читабельнее.
​​Секрет продуктивности от Bell Labs

Начал осваивать материалы, рекомендуемые на mtdv.io. Первой стала статья How to be a star engineer Роберта Келли, написанная по мотивам его исследования в Bell Labs в середине 80-х годов.

Что отличает продуктивных работников, считающихся «звёздами», от обычных крепких середняков? Наивно кажется, что дело в таланте, высоком IQ или в чём-то подобном. Исследование показало, что их отличают далеко не врождённые трудноприобретаемые качества, а подход к работе. Келли обнаружил девять стратегий вроде инициативности и нетворкинга, отличавших звёзд от обычных работников.

Суть в том, что этим девяти стратегиям можно научиться: по результатам исследования Bell Labs запустили внутреннюю программу повышения продуктивности для сотрудников, где в течение нескольких недель они осваивали каждую из стратегий. Прохождение программы повысило продуктивность участников как по их собственному мнению, так и по мнению их менеджеров и коллег.

Учитывая то, что исследованию уже практически 30 лет, поразительно, что ни о чём подобном не рассказывают в школах или вузах.

Сама статья (ПДФ, ~350 КБ): How to be a star engineer
Больше подробностей об исследовании и его результатах: How Bell Labs Creates Star Performers
Книга по мотивам исследования: How to be a star at work
Выжимка книги (ПДФ, ~60КБ)
​​Прозрачность, забота о пользователе и просто красота: ребята из Timestripe не поленились сделать понятное и наглядное объяснение принципа работы их механизма шифрования пользовательских данных — https://timestripe.com/encryption/
​​Почему не нужно стремиться к 100% покрытию кода юнит-тестами

http://andrew-r.ru/notes/unit-tests-coverage

TL;DR: покрытие кода работает хорошо как индикатор проблем. Если оно низкое, вероятно, тестов написано слишком мало. Но использовать покрытие как индикатор качества тестов нельзя: высокого покрытия можно добиться даже без единой проверки.
​​Альтернатива DuckDuckGo

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

Уже несколько месяцев я использую StartPage: приватный поисковик, который рекомендовал даже Эвард Сноуден. Его преимущество перед DuckDuckGo отлично описано на главной странице:

“You can’t beat Google when it comes to online search. So we’re paying them to use their brilliant search results in order to remove all trackers and logs. The result: The world’s best and most private search engine.”
Принцип: сначала платить себе

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

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

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

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

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

План — половина дела, его ещё нужно выполнять. Очевидный способ — заниматься делами в свободное время после работы. Проблема в том, что после работы мы устаём, и хочется потупить в сериал, а не проходить какой-нибудь сложный курс или делать сайд-проект. Решение — выделять себе утром перед работой время на личные дела и учёбу. Это решение работает, но требует дисциплины и соблюдения режима (нужно рано ложиться и рано вставать). Главное не пытаться резко перестроиться с подъёма в 9 утра на подъём в 5 утра, иначе постигнет разочарование :–)
​​О приватных данных

Прочитал на днях расследование от The New York Times о том, как мобильные приложения собирают и продают данные о наших передвижениях. Несмотря на заявления рекламных компаний о деперсонализации данных, журналистам NYT достаточно легко удалось связать записи с реальными людьми.

Вряд ли многие бы согласились каждый день отчитываться перед чужими людьми о своих передвижениях, поисковых запросах, посещённых сайтах и переписке. А ведь регулярное использование смартфона и компьютера немногим от этого отличается (достаточно взглянуть на myactivity.google.com, если вы пользуетесь сервисами Гугла и не меняли стандартные настройки). Ладно смартфоны и компьютеры — впереди умные дома, автомобили и чёрт знает что ещё.

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