Интересный Twitter тред про "JIO эффект".
Jio это такая телеком компания в Индии. В 2016 году они стали раздавать 4G интернет бесплатно. За симками выстраивались очереди. Потом через год ввели плату за трафик. Минимальную. Дальше пошёл взрывной рост абонентов у компании. И говорят что это послужило очень большим толчком для развитию digital в Индии. Начиная с 2017 года Индия была и остаётся самым растущий рынком для многих компаний (FB, Google).

https://twitter.com/iam_preethi/status/1338283035876151298?s=19

Если по какой-то случайности вы не читали еще "Мифический человеко-месяц" Ф. Брукса., добавляйте в список. Только подумайте, книга написана в 1975 году (!) и до сих пор актуальна. А сколько шуток вокруг нее. Причем читать можно прям всем, даже тем кто не сильно в ИТ.

Помню когда читал книгу первый раз я смеялся в голос, мои домашние до сих пор вспоминают, "Читает какую-то техническую книгу и смеется."

https://habr.com/ru/company/raiffeisenbank/blog/533216/

Obsession (Одержимость, Навязчивая идея)

По моему мнению хорошие специалисты в любой сфере характеризуются именно этим словом. Это люди которым не все равно. Примерный портрет таков. У них уже есть профессиональный опыт. Сложилась какая-то картина мира/профессии. Встречаясь с какой-то проблемой или новым доменом они погружаются в него детально до тех пор пока эта новая область не войдет в общий "пазл". Обычно тут наступает "aha moment" и эти люди становятся еще сильнее, еще опытнее они видят как работает весь механизм. Не важно будь то двигатель автомобиля, ИТ-система или грамматика английского языка. И чем сильнее эта одержимость и внимательность к деталям тем сильнее специалист.
Но за все есть цена. Погружение в предметную область отнимает много сил. Одержимость, которая толкает человека вперед часто приводит к выгоранию.
Если вы такой специалист, понаблюдайте за собой. Сидите до ночи/утра что решить проблему которая никак не дается? Сбавьте темп, найдите еще один домен где применить свою одержимость.
Если вы руководитель такого специалиста. Понаблюдайте за своим подчиненным, предложите ему то же самое, найти еще одну область где можно применить его силу. Подумайте о бас-факторе на крайний случай.

Ну и вот моя статистика по каналу за 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