​​​​Юридические вопросы

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

Ребята из Т—Ж делают крутое СМИ про деньги, в котором простым языком разбирают юридические вопросы вроде аренды/покупки недвижимости, налоговых вычетов и всего подобного → https://journal.tinkoff.ru/

Ребята из «Модульбанка» ведут «Дело» — издание для предпринимателей, в котором так же просто рассматриваются взаимоотношения предпринимателя и государства → https://delo.modulbank.ru/

Юристы Владимир Беляев и Дарья Тимохина делятся лаконичными шаблонами документов без воды и канцелярита → http://outlaw.center/documents.html

​​Наконец дошли руки до постепенного обновления сайта Форвеба. Выкинул Вордпресс, перешёл на статику, минимально задизайнил, выкинул старые неактуальные статьи, но впереди всё ещё много работы.

Если интересно, следите за разработкой — github.com/forwebdev/site
Заходите почитать статьи, если ещё их не видели — forwebdev.ru

​​«Цель» Голдратта

Доступное и увлекательное введение в теорию ограничений, применимую практически к любому процессу, системе и даже к личной жизни — http://andrew-r.ru/notes/goldratt-the-goal

Как составить личный финансовый план и как его реализовать

https://www.mann-ivanov-ferber.ru/books/mif/finplan/

По рекомендации @dielone (спасибо!) прочитал книгу о том, как взять под контроль свои финансы, начать откладывать и не потерять сбережения. По сути обо всём этом должны рассказывать в школе ¯\_(ツ)_/¯

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

Всё сводится к контролю доходов и расходов и регулярному инвестированию (это возможно при любом уровне дохода). Автор доступно и поверхностно рассказывает об инструментах инвестирования вроде облигаций, ПИФов, ETFов, акций, валют и драгоценных металлов, и объясняет риски и преимущества каждого инструмента.

---

Кстати, если вам тоже интересны инвестирование и защита накоплений от инфляции, ребята из чатика Форвеба сделали отдельный ламповый тематический чат, присоединяйтесь и делитесь опытом или задавайте вопросы — https://www.tgoop.com/joinchat-Cm9nK1B1_XOmiLDQOtgfcg

Неплохая идея для улучшения UX формы регистрации: новая версия Chrome предлагает использовать автоматически сгенерированный рандомный пароль

Пользуетесь менеджерами паролей?
anonymous poll

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

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

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

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

👥 495 people voted so far.

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

Одним утром я открыл Телеграм и увидел в @forwebdev рекламу каких-то миостимуляторов, которую не публиковал; оказалось, что незадолго до этого произошла утечка данных одного сервиса, и мой пароль на этом сервисе совпадал с паролем моего аккаунта в Амплифере. Злоумышленники каким-то образом получили доступ к моему и ещё нескольким аккаунтам в Амплифере и опубликовали эту злочастную рекламу. Рекламу я удалил, но картинки из неё теперь живут в виде стикеров.

Когда используешь один и тот же пароль на разных сайтах ↑

Читатель делится способом запоминать пароли без мучений (правда утечка паролей такого вида всё равно опасна):

​​Хорошая статья на Т—Ж о том, с чего следует начинать любой стартап или бизнес: исследование потребностей клиента. 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: покрытие кода работает хорошо как индикатор проблем. Если оно низкое, вероятно, тестов написано слишком мало. Но использовать покрытие как индикатор качества тестов нельзя: высокого покрытия можно добиться даже без единой проверки.