Ну и вот моя статистика по каналу за 2020 год,

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

Вообщем новость как-то прошла мимо меня.

Оказывается килобайт уже давно (с 1998 года!) не 1024 байт, а 1000.
А 1024 байт теперь называется Кибибайт.

Proof: https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D0%B1%D0%B8%D0%B1%D0%B0%D0%B9%D1%82

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

Проклятие знания. Вики определение - более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей.

Как проявляется?
Например при написании документации, вы можете опускать или упрощать некоторые моменты которые неочевидны другим коллегам.
У опытного специалиста описание для решения какой-то задачи может получится инструкция из двух пунктов.
1. Взять задачу
2. решить задачу.

Как решать проблему?
В случае документацией, сделать канал для обратной связи, регулярно проверить документацию на ее применимость.
Да и с другими кейсами тоже. Обратная связь это важная штука.


https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%BA%D0%BB%D1%8F%D1%82%D0%B8%D0%B5_%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D1%8F
https://hbr.org/2006/12/the-curse-of-knowledge

Интересная статья с альтернативными путями развития для разработчиков (да и вообще для технических специальностей).

Есть конечно такие экзотические специальности как R&D, DevMarketing. Но в остальном очень хороший взгляд на вопрос.

https://www.freecodecamp.org/news/alternative-career-paths/

https://nohello.net/

"Imagine calling someone on the phone, going hello! then putting them on hold... "

Поддерживаю авторов сайта и тоже пытаюсь сразу писать суть.

"Пассивный" доход с $0 до $10000 ежемесячно, всего за 6 лет!
Простите за кликбейтный заголовок, но это правда)

Есть такая замечательная книга "Спроси Маму. Как общаться с клиентами подтвердить правоту своей бизнес-идеи, если все кругом врут?", автор Роберт Фитцпатрик.

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

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


http://writeusefulbooks.com/

Google запустил свою базу уязвимостей. Чисто технически можно встроить в свой pipeline. Хороша альтернатива платным решениям.
Вы ему версию вашего OSS пакета/пакетов. А он вам на выходе список уязвимостей.

 curl -X POST -d \
          '{"version": "1.0.0", "package": {"name": "foo", "ecosystem": "bar"}}' \
          "https://api.osv.dev/v1/query?key=$API_KEY"

Пока есть следующие ограничения:
There is a rate limit of 100 requests/min.
This is currently filled with vulnerabilities found by OSS-Fuzz (mostly C/C++ projects)

Готовых оберток пока не нашел.

https://github.com/google/osv

Хорошая история ходит в интернете. В общем white hacker участвовавший в bounty program нашел уязвимость через заражение dependency проектов. Проблема известна давно. Но он к ней плотнее и под другим углом.

1. Нашел какие внутренние имена пакетов использует определенная компания. Например 'paypal-logger'
2. Сделал свою либу 'paypal-logger' с таким именем и опубликовал ее в открытых репозиториях.
3. Дождался пока проекты сбилдятся и подтянут новую либу.
3. Получил доступ к внутренней сети компании и запустил свой код.
4. Profit!

В числе тех где сработало, есть громкие имена, Apple, Shopify. Почти все отчислили парню bounty reward.


https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

На этой неделе коллективный твиттер аккаунт https://twitter.com/itunderhood ведёт Барух Садогурский из jfrog.
Больше писать не имеет смысла, если не читали Баруха почитайте, если читали, то знаете что пишет он интересно.

Notion.so написали небольшой постмортем и по сбоям в феврале.

C Декабря по Январь у них было 5 кратное увеличение количества дневных пользователей. И на 40% увеличилось количество регистраций.

Привлек еще такой момент:

For architectural simplicity and to keep shipping velocity high, most of our user content has been stored in a single database instance. For safety and redundancy, it's replicated and synced across multiple instances, but the maximum throughput of a single instance can result in degraded performance. This has worked for us for quite a while, but now we're nearing the limits of this approach. Our number one infrastructure priority is to re-architect this database to scale horizontally.

Смелое решение для компании которая в апреле 2020 года компания, имея 4 миллиона пользователей, привлекла 50 миллионов долларов при оценке в 2 миллиарда долларов (wiki). Похоже рост случился быстрее чем ожидали. Первая версия продукта вышла в 2016 году.

Вообщем это ни в коем случае не порицание, а просто история про то, что недооценивают все.

https://www.notion.so/Focus-on-performance-reliability-89f937a6ccc04905b1dcfa878537e08d

Точка зрения на + и - работы в больших тех компаниях (FAANG).

Если сжать статью до пары предложений. В не "software driven" компаниях у вас есть больше возможностей добавить ценности. Эта ценность как для конечного клиента (влияние на продукт) так и для компании (влияние на окружение, автоматизация etc., выстраивание процессов).
Дальше мои мысли. Сравнивать одно с другим как минимум неверно, вопрос в том чего хочется вам. Хочется просто кодить и выжимать максимум, один путь. Хочется понимать управление продуктом в целом? Иметь больше влияние и искать узкие места? Понимать как, почему внедряется то или иное изменение? Другой путь.

https://stackoverflow.blog/2021/02/17/the-pros-and-cons-of-being-a-software-engineer-at-a-big-tech-company/

Не совсем про ИТ, но очень хороший пример аналитики.

Яндекс посчитали, насколько выгодно пользоваться я.такси по сравнению с личными автомобилями разного класса. По ссылке интересная интерактивная табличка.

https://yandex.ru/company/researches/2020/auto-cost

Интересно про марсоход Perseverance. Там используется vxworks (как и на Curiosity) но вот в дроне который спускал его, решили использовать свой opensource linux дистрибутив - fprime.

F´: A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework. F´ (F Prime) is a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications.

Кому может понадобится этот репозиторий кроме NASA не знаю, но у репозитория уже 5.6K звезд и 676 форков.

Статья что это за OS VxWorks и о ее производителе Wind River (В 2009 году Wind River была приобретена Intel)

В гитхабе нашли "забавный" баг. Вам могла прилететь кука другого зарегистрированного пользователя. Говорят что повлияло всего на "0.001% of authenticated sessions"

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

https://github.blog/2021-03-08-github-security-update-a-bug-related-to-handling-of-authenticated-sessions/

Статьи из серии как софт скилы важны для всех кто в ИТ уже конечно порядком поднадоели. Кстати редко встречаю статьей о том как их развить в рамках рабочего процесса (если видели, поделитесь в личку).
Но именно в этой статье мне понравился вот этот абзац про переговорщика. Мне кажется это мегаважно, не всегда идти на пролом, а действовать по ситуации, обсуждать с действующими лицами.
Ну и да, 3 пункта по тех (ака хард скилам) и 8 пунктов(!) по софт скиллам.

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

https://www.redhat.com/architect/what-is-software-architect

Ну и еще раз про софт скиллс, пока далеко не ушли. Уже не первый раз читаю статьи в стиле. "Если софт скиллс так важны, то может не называть их софт?" Были предложения назвать core skills.
Пока читал, заинтересовался этимологией фразы. Ниже ссылка на одну из версий происхождения этого определения.

https://code.joejag.com/2018/the-origin-of-soft-skills.html

Если вы ждали знака начать писать на хабре, то вот он)
Сам курс не проходил, но выглядит довольно интересно. Закинул в беклог покупок.

http://it-content.pro/how-to-write/

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

https://www.wired.com/story/giving-open-source-projects-life-after-a-developers-death

Чек лист от Charles Li по поиску проблем ну и бонусом интересный кейс с ошибкой на балансере в Ebay.

Итак, порядок действий при сбоях (переведно и адаптировано из статьи):

1. Устранение проблемы начинается с ее проверки, подтверждения и воспроизведения.

2. Далее нужно определить масштаб сбоя.

3. Поиск причин проблемы. Копайте до тех пор пока не найдется объяснение для каждого странного отклонения которого вы видели в процессе анализа.

4. Любые данные очень важны для определения первопричины. Логи, метрики приложений, чем больше тем лучше.

5. Главным приоритетом в продакшн среде является полное устранение или уменьшение масштаба проблемы, а не ее системное решение.

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

https://tech.ebayinc.com/engineering/sre-case-study-url-distribution-issue-caused-by-application/