Организованное программирование | Кирилл Мокевнин

Организованное программирование | Кирилл Мокевнин pinned «В сегодняшнем выпуске мы с  Артёмом Арутюняном погрузились в тему стейт-менеджмента во фронтенде и функционального реактивного программирования. Разберем реальные кейсы и технологические подходы, которые позволяют совершенствовать управление состоянием в современных…»

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

Альтернативные площадки ВК Видео | Аудио
https://www.youtube.com/watch?v=Lbq_NwIKUrI

Написал мощную статью на хабр про то как на самом деле надо собеседовать разработчиков. Вложил туда так сказать весь опыт с 2009 года, когда я начал впервые собеседовать и с тех пор провел более 1000 собесов! https://habr.com/ru/articles/879902/ не забудьте поделиться с друзьями ;)

Организованное программирование | Кирилл Мокевнин pinned «В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают…»

Собеседования: Истории и раздражающие практики

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

В сегодняшнем выпуске мы поговорили с Юрием Жлобой — разработчиком из Wargaming. Почему Erlang стал революцией для телеком-индустрии, а Elixir сделал функциональное программирование удобным для бизнеса? Этот выпуск — глубокий разбор технологий, которые обеспечивают стабильность и масштабируемость в самых требовательных системах.

Альтернативные ссылки ВК Видео | Аудио

https://www.youtube.com/watch?v=lpmZJ2xnsaE

У меня пропал сон

Где-то лет в 35 со мной что-то случилось. Я стал просыпаться в 6 независимо от того во сколько я уснул. Что самое страшное у меня пропала способность “доспать” если я не выспался. Вообще никаких шансов, проснулся - вставай, потому что иначе будешь тупо лежать, но не уснешь. Всегда раньше удивлялся бабушкам и дедушкам, которые так в 4 вставали. А теперь сам такой стал. У вас есть такой эффект?

Идеальное решение

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

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

Может быть и так, но если исходить сразу из ограничений, то мы никогда не придем туда, куда надо идти, с точки зрения смыслов, что может нас сильно замедлить и ослабить по отношению к конкурентам. Вместо выставления границ, лучше поступить по другому. Сначала мы можем представить, что нет никаких ограничений и мы можем сделать все что хотим моментально. Каким бы тогда выглядело наше решение? Идеальное решение. Что в него входит:

* Система выполняет функцию с минимальным количеством ресурсов
* Противоречия устраняются максимально элегантно

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

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

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

Кто-то скажет, Кирилл погоди, это же из ТРИЗ и будет прав. Там это называется Идеальный Конечный Результат (ИКР).

Ссылки: Телеграм | Youtube | VK

В этом выпуске мы снова встретились с Дмитрием Коваленко, чтобы разобраться, почему Rust заслужил столько внимания в сообществе разработчиков. Получился содержательный и насыщенный разговор, полезный и начинающим, и опытным специалистам.
Присоединяйтесь, чтобы узнать, чем Rust может усилить ваш tech stack и как писать надёжный, эффективный код!

https://www.youtube.com/watch?v=bKyxOaP-mDg

Альтернативные площадки ВК Видео | Аудио

Про менеджеры версий

Когда надо сменить версию языка под проект, то для этого обычно используют либо докер, либо менеджеры версий. Под каждый язык есть как минимум один такой, а то и пачка: nvm, gvm, rvm, rbenv и так далее. Десятки их. В общем задолбаешься если постоянно надо между языками переключаться. Поэтому кто-то догадался написать универсальный менеджер.

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

Начать можно отсюда: https://asdf-vm.com/guide/getting-started.html

// Вариант установки для brew

// Ставим asdf и зависимости
brew install asdf

// Ставим плагин для ноды
asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
// И его зависимости
brew install gpg gawk

// Устанавливаем последнюю версию nodejs и делаем ее доступной глобально
asdf global nodejs latest

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

p.s. А какой менеджер версий используете вы?

Ссылки: Телеграм | Youtube | VK

В этом выпуске мы с Дмитрием Коваленко, опытным разработчиком и контрибьютором таких проектов, как Material-UI, Cypress и FFmpeg. Затронули тему низкоуровневого программирования, обсудили работу с ассемблером и оптимизацию производительности на уровне процессора.
Эпизод получился насыщенным: мы подробно обсудили технологии, архитектуру и программирование на уровне железа.

Альтернативные площадки: ВК Видео | Подкаст

https://youtu.be/BsNgohFW6rM

Что такое CodeBasics

Я планирую серию постов, про архитектуру нашего открытого проекта https://code-basics.com/ru, о котором сейчас немного расскажу. Где-то в 2015 году, задумал я сделать проект в стиле CodeAcademy как дополнение к Хекслету. То есть это простые курсы по основам языков с тренажером в браузере. Ключевые фишки проекта:

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

Целей было несколько. Например на тот момент, рекомендовать кому-то платные курсы было зашкваром (сразу считалось рекламой), поэтому программисты тупо стеснялись говорить про Хекслет даже если хотели. Этот проект открывал такую возможность всем без риска, что тебя заклюют. И еще я оглядывался на не безызвестный сайт learn.javascript.ru, мне хотелось добиться похожей популярности по ряду языков, чтобы например когда речь шла про то где учить php, все не задумываясь отвечали, конечно на кодбейзиксе (я все еще мечтаю об этом!).

Большую часть курсов я написал на бейзиксе сам, но часть была написана ребятами из нашего сообщества. И это очень круто, потому что это позволило появиться на сайте курсам по лиспам и элексиру. Самая интересная история была, когда один парень нам нафигачил курс по python, а потом мы взяли его на работу (привет Леша!). На гитхабе проекта созданы репы под все языки, так что если вам интересно, то велкам, можно просто прийти и начать коммитить.

У проекта есть несколько интересных вещей с архитектурной точки зрения, о которых хочется рассказать. Например то, как мы переложили работу с контентом на гитхаб, решив множество задач без кодинга (права, версионирование итп). Про то как устроена база данных, так чтобы иметь версионирование уроков и не ломать людям все сразу при обновлении курсов. Про то как мы его написали на phoenix/elixir, а потом переписали на rails. В общем там реально много интересных концепций. А прямо сейчас я его еще переписываю на инерацию, так что будет что рассказать про фронтендовые примочки в новой реальности.

Короче не проект, а сказка. А на днях мы вышли с ним https://productradar.ru/ это типа нашего продуктханта. Эту неделю идет голосование за лучший проект и мы там вчера вышли на первое место с 104 голосами. Но прямо в спину нам дышит другой проект, который видимо тоже пытается поднажать. В общем, вы знаете что надо делать :)

Организованное программирование | Кирилл Мокевнин pinned «Ruby, Ruby, Ruby. В этом выпуске мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails. В подкасте обсудили: - Современное состояние языка Ruby, его развитие и применение в больших проектах…»

Ruby, Ruby, Ruby. В этом выпуске мы поговорили с Владимиром Дементьевым, ведущим разработчиком в компании "Злые Марсиане", контрибьютором в Ruby и Ruby on Rails.
В подкасте обсудили:
- Современное состояние языка Ruby, его развитие и применение в больших проектах
- Подходы к созданию устойчивой архитектуры приложений на Ruby и опыт использования языка в open-source проектах
- Эволюцию фреймворка Ruby on Rails, включая новые возможности, такие как асинхронная обработка
- Личный опыт Владимира в разработке таких проектов, как AnyCable, и его вклад в создание инструментария для разработчиков

https://www.youtube.com/watch?v=fBJGj6sd9AQ (первый раз запустили видео как премьеру, можно там прямо в процессе обсуждать)

VK: https://vk.com/orgprog Подкасты: https://podcast.ru/1734325321

А нука ребята, кто сразу наметанным взглядом скажет какую типовую orm проблему мы тут наблюдаем?

Makefile: Заменяем документацию командами

Когда-то много лет назад, я задолбался писать длинные и составные команды, которые были нужны в разных проектах. Особенно актуальной эта проблема стала с появлением Docker и Docker Compose. Некоторые связки для запуска, апдейта и изменений, требовали прямо таки серьезных многострочников. Типа такого:

 docker run -it --rm \
  -v $(CURDIR):/runner/project \
  quay.io/ansible/ansible-runner ansible-vault edit

Выходов из этой ситуации было несколько, например, скидывать их куда-то в доку типа README.md и копировать оттуда. Частично мы так и делали, но оно все время устаревает и просто задалбывает.

Часть команд можно запихнуть во встроенный инструментарий языков, к ним относятся rake tasks, npm scripts и так далее. И это даже хорошо работает, но только до тех пор пока команды простые и скорее относятся к инструментам на этом же языке. Если ваша задача запустить подряд пяток команд Docker Compose, то большинство этих инструментов будут неудобными. Да это пытаются решить тем что создают универсальные запускалки, но ни одна из них не стала по настоящему популярной сквозь разные экосистемы. Почти все эти инструменты носят локальный характер для какого-то языка или конкретного стека.

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

Другой подход это алиасы в bash/zsh/fish. Но мне эта идея никогда не нравилась, потому что алиасы глобальны, а большая часть команд локальна для какого-то проекта. Несмотря на это алиасы все же заняли свое место в этой системе, но не рукопашные, а те что идут в коробке из ohmyzsh. Далеко не все знают, но это по сути ключевая фича этого инструмента. Вы только посмотрите, что он позволяет делать с гитом https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git (а там есть комбо для всех популярных консольных утилит).

Ну и наконец, самый, как оказалось удобный подход. У нас есть старый добрый Make, который либо стоит уже сразу, либо крайне просто ставится в систему. У него есть команды, зависимости и возможность писать консольные команды напрямую (для большинства ситуаций). Еще году в 2015 я полностью перевел все свои проекты на Makefile, которые не просто решили проблему написания и запуска команд, но и создали некий универсальный язык, заменяющий доку. В любом моем проекте открыв Makefile можно понять все, что нужно для работы с проектом: make setup, make test, make lint, make run все эти команды универсальны независимо от стека.

include make-app.mk
include make-compose-app.mk
include make-compose.mk
include k8s/Makefile

project-setup: ansible-generate-env compose-setup

ansible-generate-env:
 docker run --rm -e RUNNER_PLAYBOOK=ansible/development.yml \
  -v $(CURDIR)/ansible/development:/runner/inventory \
  -v $(CURDIR):/runner/project \
  quay.io/ansible/ansible-runner

Прикольно то, что со временем это стали видеть многие и даже популярные проекты стали внедрять Makefile. Я помню был пост Андрея Ситника, где он рассказывал, как перевел команды для своей либы с npm scripts на Makefile и был удивлен как все упростилось.

В общем рекомендую. Мое видео на тему: https://www.youtube.com/watch?v=pK9mF5aK05Q

Ссылки: Телеграм | Youtube | VK

Организованное программирование | Кирилл Мокевнин pinned «В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка Go и его роли в современном программировании. Разобрали, как Go стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков.…»

В этом выпуске мы поговорили с Алексеем Палажченко об эволюции языка Go и его роли в современном программировании. Разобрали, как Go стал выбором для крупных проектов, включая создание баз данных, и почему он продолжает завоёвывать популярность среди разработчиков. Также обсудили, как новые фичи, такие как дженерики и итераторы, меняют подход к разработке.

- Простота и лаконичность Go как основы его философии.
- Влияние Google на развитие языка и баланс между минимализмом и новыми возможностями.
- Рынок Go-разработчиков, востребованность специалистов и нишевые преимущества языка.
- Сравнение Go с другими языками, такими как Rust и Python, для разных типов задач.
- Проблемы обратной совместимости и подходы к оптимизации производительности.
https://www.youtube.com/watch?v=M5XJ_Ojjm8M

Альтернативные ссылки: VK | Аудио

А с какого ритуала у вас начинается утро за компьютером? Я обновляю плагины в виме :)

Как я надел очки

У меня всегда было хорошее зрение несмотря на то, что где-то лет с 12 я плотно подсел на компы, а потом и на экран телефона. Несколько лет назад, доктор меня предупредил, что где-то ближе к 40, оно начнет портится, это нормальный процесс, через который проходят все. Сейчас мне 39 и ухудшение пока не заметно слава богу, но морально я готов. Несмотря на это, я уже ношу очки, возможно вы замечали в подкастах.

Где-то, лет 15 назад, я понял что сидение за экраном делает больно моим глазам. Это связано с тем, что глаза начинают редко моргать и увлажняться + постоянная фокусировка на предметы близко к лицу. Поэтому существует множество разных рекомендаций, от регулярного отрыва от экрана и рассматривания предметов в далеке (но ни в коем случае не вращение глаз) до использования капель и спец очков с антибликовым и другими покрытиями.

В общем, ощущение что в глаза насыпали песок было настолько сильным, что я не мог просидеть больше 20 минут. Проблему решили глазные капли, но я быстро устал их использовать, капать каждый день по несколько раз в день годами, это то еще удовольствие. Поэтому я пошел в салон и купил очки. Проблема ушла где-то на 10 лет, пока ребенок мне однажды не сломал их. Глаза вроде не болели, поэтому я ничего не стал делать, а продолжил работать без них. Да и за компом я уже проводил меньше времени, а на созвонах они вроде и не нужны. Но буквально года полтора назад, я снова почувствовал что глазам плохо уже не только за компом, но и просто за просмотром экрана телефона. К боли добавилось то, что экран стал размытым, правда только для одного глаза. Вот тут то и накатила паника, а может это конец? Пришлось с одной стороны уменьшить время за техникой и всегда включать яркий свет когда смотрю в экран. Это помогло только частично, поэтому пришлось идти дальше и покупать капли. В конце концов, я плюнул и снова заказал очки. И только после этого все прошло. Но теперь, в отличие от прошлого опыта, я ношу очки не только когда сижу за компом, но и когда смотрю в телефон. А по итогу я ношу их большую часть времени дня. Работаем дальше.

p.s. кстати кому интересно, я после долгого изучения reddit купил себе warby parker. Была еще попытка взять недорогие с амазона, но они быстро поцарапались.

Ссылки: Телеграм | Youtube | VK

Чтож, пришла пора подводить итоги года нашего уютного канала. В целом можно сказать, что год был для него неплох. Органически канал вырос на 5 тыщ подписчиков и дошел до 8500. До 10 тыщ не добрали, но ничо.

В этом году я дал жару и написал 173 поста. Как это возможно, учитывая что я пишу два раза в неделю, а в году 365 дней, я не понимаю. Самый эпичный пост про то как сломалось, что и очевидно. Хочешь охваты, говори про факапы/боль/страдай.

Самое интересное это миллион просмотров и 7 тыщ комментов на 173 поста!!! Это товарищи дохрена. Почти инфлюенсер :)

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

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

Всем добра и мира, до новых встреч. Ну и поставьте чтоли сердечко, если канал в него попал :)

p.s. Боты, от вас тоже жду теплых слов

Организованное программирование | Кирилл Мокевнин pinned «В этом выпуске мы поговорили с Кирой Кузьменко, которая поделилась своим опытом и взглядом на современные реалии IT-рынка. Обсудили, как меняются ожидания работодателей, почему мультифункциональность стала ключевым навыком, и что нужно, чтобы оставаться востребованным…»

В поисках идеального UI KIT

Решил на выходных провести время с пользой и перевести code-basics на inertiajs + react + ts + новый ui kit. И неожиданно для себя, уткнулся в проблему с последним. После нескольких дней плотного изучения и попыток внедрить какое-то количество решений, я уперся что для моих задач бутстрап по прежнему на коне.

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

Кто, то скажет, Кирилл погоди, но он же не может вот это, там нельзя вот так и вообще. И у меня есть что на это скзазать. Во-первых, многие до сих пор в голове представляют себе bootstrap 3, где кастомизация была слабая. Начиная с 4 версии и особенно в 5, он очень гибкий для готового набора компонентов. Мало кто например догадывается что на хекслете бутстрап, а в стандартных вещах (не лендах) там почти нет кастома (и это за 11 лет жизни проекта). Во-вторых, я на нем делаю свой проект, где нет абстрактного бизнеса, который может что-то захотеть, что бутстрап не может (картинка: я и есть бизнес). С самого начала была выбрана стратегия подстраиваться под него (кроме лендов), чтобы не тратить время и деньги на UI.

И, в общем, я бы и дальше продолжил им пользоваться без тени сомнения, если не вот эти. но:

- Так как проект переводится на inertia + react, то весь фронтенд уезжает в jsx, а там нужны не классы, а нормальные react компоненты с поддержкой ts и местами логикой (какие-нибудь модалки). У бутстрапа нет своей либы для этого. Есть react-bootstrap, но его делают энтузиасты в свободное от работы время. В общем ненадежно и с отставанием
- Все же сейчас в bootstrap компонентов меньше чем хотелось бы и они как-то не горят их добавлять. Всякие хитрые селекты, автокомплиты и более навороченные с точки зрения UI штуки. Не хочется ходить все это ставить со стороны и заниматься интеграциями (до сих пор мучаемся с select2 для автокомплита).
- Этот пункт меня не радует, но против массы не попрешь. Любая технология проходит путь с восходом и затмением, которое часто связано с приходом нового поколения, отрицающего все старое. Бутстрап, чтобы он не делал, уже отслужил свое в головах большинства. И чем дальше, тем меньше шансов найти кого-то кто от него в восторге. Пофиг даже если человек не работал с ним, это легко наверстать, но вот это ощущение, что это что-то старое, с чем не хочется возиться.

Вот с такими мыслями я засел вечером в пятницу за комп. Загуглил все что есть из популярного chakra, material, mantine, tailwind и все что на базе него daisyUI, nextUI, shadcn, ant.design, primereact, fluentui, blueprint, baseweb.design. Кроме этого видел еще десяток, но по коммитам, звездам и форкам они не вызывают доверия. Слишком высок риск что их забросят.

Изучил их доку, половину попробовал поставил и немного поверстал. В конце-концов выработал такой алгоритм поиска:

- Проверяю есть ли компонент navbar. Если его нет, то либа заставит меня делать то, от чего я хочу уйти
- Смотрю на верстку navbar, если это просто набор элементов из которых собирается navbar, то это не bootstrap-style конструктор. Это скорее конструктор компонентов типа tailwind. Navbar, который мне нужен, это прямо компонент в этом UI Kit с поддержкой схлопывания до бургера, дропдаунов и всего такого
- Смотрю наличие готовых блоков/сниппетов/примеров страниц. Я работаю без дизайнера и мне нужно видеть примеры компоновок компонентов и страниц.
- Ну и конечно же дока. Кто видел доку бутстрапа, понимает что такое хорошее описание.

Нашел ли я что-то идеальное? К сожалению нет. Пытаюсь завести mantine, так как он ближе всех отвечает моим запросам. Но в целом, мир UI хочет чтобы я был фанатом гибкости и кастомизации :)

Ссылки: Телеграм | Youtube | VK

В этом выпуске мы поговорили с Кирой Кузьменко, которая поделилась своим опытом и взглядом на современные реалии IT-рынка. Обсудили, как меняются ожидания работодателей, почему мультифункциональность стала ключевым навыком, и что нужно, чтобы оставаться востребованным специалистом.
https://www.youtube.com/watch?v=36v3KnpmZyM

Альтернативные ссылки: VK | Аудио

Принятие решение по новым проектам

Программисты любят зарубиться в какую-то разработку с места в карьер. Щас побыстрому закодим, мы ж понимаем как это сделать. Да и могут закодить ведь. Накидаю примеры, чтобы было понятно:

1. Версионирование документов
2. Систему прав
3. Восстановление удаленных вещей из корзины
4. Какую-нибудь аналитическую систему

Особенность всех эти штук, в том, что для них надо продумать ux и какую-то архитектуру, которая позволит потом это поддерживать расширять и вот это все. И каждую из подобных фич можно напилить самостоятельно. Но, по опыту, это часто получается довольно криво, особенно если фичи не продуманы со стороны UX и разработчикам приходится самим принимать решение как это сделать. На выходе мы получим что-то не очень удобное в использовании и потом нас ждет череда переписываний (справедливости ради, это произойдет в любом случае)

У меня есть очень простая рекомендация и подход. Когда разработчик говорит что знает как сделать и сделает, я всегда спрашиваю, на какой пример он будет ориентироваться? Какие хорошие примеры он изучил и какие плохие примеры он знает? Речь идет про любые другие проекты. Наверняка все это там уже реализовано по 10 раз. И вот только когда он видел как бывает хорошо и с этим согласилась команда, которая будет использовать эту фичу, то можно приступать. Если же программист делает это исключительно на базе своих представлений, то я бы попросил его отложить кодинг и потратить время на изучение.

Ссылки: Телеграм | Youtube | VK

Тест для ботов. Напишите кто вас создал и зачем. Вами управляет скайнет?

Что происходит с ютубом?

Ребят, расскажите что там на самом деле. Надо переживать или работает? Где вы щас смотрите видео? Как вы смотрите мои выпуски?

На всякий куда подписаться, чтобы не пропускать выпуски:

https://vk.com/orgprog
https://rutube.ru/channel/35573563/
https://dzen.ru/orgprog
https://podcast.ru/1734325321
https://vk.com/orgprog

В этом выпуске мы поговорили с Андреем Апанасиком о современном геймдеве, его вызовах и трендах. Обсудили, почему разработчики всё чаще выбирают готовые игровые движки вроде Unreal Engine и Unity вместо создания собственных решений. Андрей поделился своим опытом разработки игр, рассказал о том, как меняются подходы к созданию геймплея и почему маркетинг стал ключевым элементом успеха в игровой индустрии.
https://youtu.be/ZBgRe8FOvx0

Профессиональное развитие. Нам это не задавали

Чья ответственность заниматься своим развитием? Компании или человека? Многие ответят “конечно человека” и будут правы. Да компания может этому способствовать, но может и не способствовать, однако это не может и не должно нас останавливать.

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

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

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

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

Ссылки: Телеграм | Youtube | VK

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

https://www.youtube.com/watch?v=Y3zVRIs8Ux4

Пошли первые ласточки по нашему видео продакшену, зацените: https://www.youtube.com/shorts/sLU4az5m_zg Как вам? Постить я сюда их не буду, потому что по плану мы будем делать 10-20 шорстов в месяц. Кстати, там на видео я как будто смотрю в камеру, на самом деле это обработка.

В этом выпуске мы с Андреем Ситником. обсудили будущее фронтент разработки и большой сдвиг в сторону баз данных на клиенте с автоматической синхронизацией вместо классических апи вызовов. Или короче, поговорили о движках синхронизации. Андрей рассказал про движение Local First, которое предлагает ряд принципов создания веб-приложений, одновременно решающих задачи владения данными и совместной работой. Благодаря движкам синхронизации, Local First приложения получают возможность работать офлайн и хранить свои данные там где нужно, не завязываясь на конкретный, обычно облачный, провайдер. Это позволяет строить более быстрые, безопасные и защищенные в плане владения данными приложения. https://www.youtube.com/watch?v=-57r5AARRgY

Провел сегодня прямой эфир https://www.youtube.com/watch?v=6FXLzctHGRM Оч рекомендую если вы пытаетесь понять логику работадателей при принятии решений о найме новичков и не только

Последние месяцы канала

Вы наверное заметили, что последний месяц-два я снизил свою активность по написанию полноценных авторских постов. Хочу рассказать почему и чем я сейчас занимаюсь.

Помимо просто праздников (в штатах щас самое праздничное время) и поездок с детьми, я начал активно работать над перерождением Ютуба, в первую очередь, на Хекслете. Мы планируем по полной программе начать записывать и выкладывать не просто разговоры, но и нормальные контентные выпуски. Для этого я нашел классного продюсера, который, кстати помогает мне выпускать подкаст “организованное программирование” (вы заметили что это повлияло на звук и монтаж?). А последние недели мы занимаемся тем что подбираем темы, пишем сценарии, собираем домашнюю студию. У меня дома сейчас куча всякого оборудования, которое наконец-то собрано и готово к работе. Уже были пробные записи, но пока всплывает еще много проблем, начиная от кривого меня, которому надо уметь правильно выражать эмоции и ставить паузы (я планирую брать уроки по этой теме), до хренового света и камеры. Вот над всем этим мы и работаем.

Помимо ютуба, я последние месяцы взялся за пересборку smm на Хекслете. Просмотрел почти 500 кандидатов (ручками без автофильтров!) и кажется нашел человека, который затащит. Он выходит 9 декабря, но пока его нет, в каналах Хекслета тишина, потому что меня, все же, не хватило сразу на столько активностей. Но планы у нас грандиозные, на фоне мы проводим разные исследования и интересную журналистскую работу, результаты которой я буду делиться и там и тут.

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

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

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

Давайте попробуем в комментах устроить секцию вопросов/ответов. Хочется поболтать)

Ссылки: Телеграм | Youtube | VK

Организованное программирование | Кирилл Мокевнин pinned «Новый выпуск уже доступе для просмотра, в этот раз разбираем Clojure. В этом выпуске мы погружаемся в мир функционального программирования вместе с Николаем Рыжиковым — одним из ведущих специалистов по Clojure в России. Николай делится своим уникальным опытом…»

Новый выпуск уже доступе для просмотра, в этот раз разбираем Clojure. В этом выпуске мы погружаемся в мир функционального программирования вместе с Николаем Рыжиковым — одним из ведущих специалистов по Clojure в России. Николай делится своим уникальным опытом использования Clojure как в разработке коммерческих проектов, так и в создании open-source инструментов.

Мы обсуждаем, чем Clojure отличается от других языков, почему его философия минимализма и неизменяемости так важна для современной разработки, и какие задачи лучше всего решать с его помощью. Николай рассказывает о том, как этот язык помогает ему создавать лаконичный, надежный и масштабируемый код, который легко поддерживать. https://www.youtube.com/watch?v=7eJ3yUgbzSA

Поделитесь вашим путем по языкам программирования в коммерческой разработке. Начну с себя:

2007 - php
2008 - plsql, oracle
2009 -python, ruby
2011 - javascript, coffescript
2014 - erlang
2017 - elixir, clojure, clojurescript
2022 - java
2023 - typescript

Ссылки: Телеграм | Youtube | VK

Организованное программирование | Кирилл Мокевнин pinned «Minimal Modeling - новый подход для проектирования баз данных В этом выпуске я поговорил о проектировании баз данных с Алексеем Махоткиным (он был техническим директором того самого Undev). У Леши богатейший опыт в работе с БД, который вылился в разработку…»

Minimal Modeling - новый подход для проектирования баз данных

В этом выпуске я поговорил о проектировании баз данных с Алексеем Махоткиным (он был техническим директором того самого Undev). У Леши богатейший опыт в работе с БД, который вылился в разработку своей собственной методики моделирования баз данных, которая называется Minimal Modeling. Скоро выходит книга посвященная этому подходу, а здесь мы разбираем принципы лежащие в его основе.

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

https://www.youtube.com/watch?v=vYYZy1EulUk

Организованное программирование | Кирилл Мокевнин pinned «3 раза я был в подлодке в качестве гостя. Пришла пора отплатить ребятам и в этот раз я позвал на подкаст Катю, с которой мы поговорили про подкастинг. Как ребята стартовали и шли к успеху, когда почувствовали, что пришел успех и как их нагнал хейт. В подкасте…»

Заблуждения относительно работы пагинации

Нашел на просторах сети список, хочу поделиться с вами:

1. Количество элементов на странице фиксировано навсегда.
2. Количество элементов на странице фиксировано для одного пользователя.
3. Количество элементов на странице фиксировано для одного набора результатов.
4. Страницы просматриваются только в одном направлении.
5. Ни один элемент не будет добавлен в набор результатов во время его извлечения.
6. Ни один элемент не будет удалён из набора результатов во время его извлечения.
7. Порядок сортировки элементов остаётся стабильным.
8. За один раз будет извлечена только одна страница результатов.
9. Страницы будут извлекаться по порядку.
10. Страницы будут извлекаться своевременно.

Ссылки: Телеграм | Youtube | VK

3 раза я был в подлодке в качестве гостя. Пришла пора отплатить ребятам и в этот раз я позвал на подкаст Катю, с которой мы поговорили про подкастинг. Как ребята стартовали и шли к успеху, когда почувствовали, что пришел успех и как их нагнал хейт. В подкасте мы обсуждаем все от технических деталей организации своего подкаста до влияния на индустрию. https://www.youtube.com/watch?v=Lwgmz7qVXEM

Организованное программирование | Кирилл Мокевнин pinned «Выпуск про отличие бигтеха от небольших компаний и стартапов опубликован и доступен в видео и аудио версиях на всех платформах (ссылки описании к ролику) https://youtu.be/Lo4F8NMmkN0?si=8FJpN-Ymx1jj6P5S В этом выпуске мы с Евгением Козловым обсуждаем, как…»

Видели скриншоты красных флагов найма в яндексе?

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

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

В остальном видно, что это попытка брать готовых спецов, с перспективой роста. Разберем по пунктам.

- Отсеивающие критерии (курсы, стажировки, джуновый опыт) Инвертированный вариант “не берем без опыта”, аналогично могли бы написать что ищут мидлов и выше.
- Сбербанк (ведущие позиции, 1-2 года опыта) Человек либо там работал и знает о чем говорит, либо слышал про это либо обжигался при найме. Возможно это стандартная тема при накрутке (накрутчики часто используют один паттерн) поэтому прописали отдельно.
- не it-образование при небольшом опыте (3-4) опять же просто опыт конкретного человека, он сделал для себя такой вывод. А мы можем сделать вывод (с высокой степенью вероятности), что у человека вероятно 10+ лет опыта и сильный вуз за спиной, поэтому про 3-4 года он пишет как “небольшой”
- Задачи (одна верстка, 1c, битрикс, wordpress) - почему такие вещи вообще выносят в подобные списки? Просто подобных ребят довольно много и опыт собесов показывает что среди них мало релевантных, поэтому проще исключить их из подбора, кандидатов все равно много, а время у спецов на собесы немного и оно дорогое.
- Попрыгунчики (до года везде) - если у человек в таком формате больше 3 мест, я и сам смотрю с подозрением, потому что на определенных позициях, вкатываться только полгода, а то и год. Все это время компания тратит ресурсы, вовлекая и обучая человека. Коммуникация опять же. Бывает что это зависит не от человека, например стартапы все время заканчиваются? Бывает конечно. Стоит ли ради единиц таких рисковать? Зависит от компании и нанимающих ребят, но яндекс явно не та компания, которая будет этим заморачиваться, как, впрочем и многие другие крупняки, у которых на входе очередь.
- Если хочет меньше 200к - и хотя я тут немного удивился, все же подобный критерий всплывает у меня в голове, когда я беру специалиста, например, из маркетинга, и эти специалисты указывают прямо неадекватно низкую планку по зп, например в три-четыре раза меньше чем по рынку, типа 30 тысяч на smm специалиста. Тут просто наверняка либо студент без опыта, либо человек не планирует фултайм и не скажет об этом до собеса, а на собесе начнет продавать услуги (дада в маркетинге так происходит), так как хочет проектную работу, набрать таких десяток и сидеть не гудеть
- От 40 и старше Чего греха таить, когда мне было 25, я думал 40 это все, списывать только. Скоро мне 40 и мнение за годы конечно поменялось. Но я все равно понимаю почему они так пишут, люди в этом возрасте слишком себе на уме, что может стать проблемой и в своей практике я с этой корреляцией сталкивался. При этом конкретно этот критерий несмотря на определенную корреляцию по каким-то параметрам просто не приемлем в современном мире в открытом виде. Эджизм убрать невозможно потому что это не люди глупые,  а потому что мы так устроены (у всех есть лимиты на подбор партнера по возрасту например). Поэтому такие вещи если и делаются, то про себя и на основе косвенных факторов (и да это происходит в штатах тоже налево и направо)

И да, чем больше компания, тем больше всякого такого внутри бывает, потому что там работают люди со всеми мнениями, какие только встречаются. Для меня это просто локальные флуктуации, не более

А что вы думаете по этому поводу?

Ссылки: Телеграм | Youtube | VK

Выпуск про отличие бигтеха от небольших компаний и стартапов опубликован и доступен в видео и аудио версиях на всех платформах (ссылки описании к ролику) https://youtu.be/Lo4F8NMmkN0?si=8FJpN-Ymx1jj6P5S

В этом выпуске мы с Евгением Козловым обсуждаем, как строятся процессы и принятие решений в крупных технологических компаниях, зачем нужны многоуровневые собеседования и алгоритмические задачи, а также поговорим о том, как внутренние платформы помогают масштабировать IT-команды. Евгений поделится своим опытом перехода от аутсорсинга к Big Tech, расскажет о вызовах, с которыми сталкиваются разработчики, и объяснит, что действительно важно для успешной карьеры в IT. Будет много интересного и полезного для тех, кто хочет понять, что значит работать в Big Tech и чем это отличается от небольших компаний.

Вакансии пост. Редко такое публикую, но попробуем. Нам в Хекслет нужен smm-менеджер (или как говорят контент-менеджер, smm-маркетолог), с опытом ведения каналов технической направленности и желанием в эту сторону развиваться. Если вы такой или у вас есть знакомые подходящие под вакансию, порекомендуйте позязя https://hh.ru/vacancy/108869389 (откликаться лучше там же)

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

Семантический I18n

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

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

Но в какой-то момент, даже эта система тяжелеет. Когда в проекте тысячи ключей, то снова появляется дублирование и неиспользуемые ключи (легче всего их убрать если у вас gettext). А еще появляется ощущение постоянной грязи, места, в котором все навалено. Можно ли от этого избавиться?

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

Первый вариант это неймспейсы (https://www.i18next.com/principles/namespaces). Мы можем разделить все ключи на разные большие блоки, которые обычно хранятся в разных файлах. Делать это можно по фичам или по слоям. Например переводы для писем в одном месте, а переводы для фронтенда в другом. Сюда же добавляем вложенность. Например если у нас есть меню, то мы можем расположить переводы внутри ключа “top-menu”. Ниже пример с хлебными крошками:

{
    "breadcrumbs": {
        "home.index": "Главная",
        "admin": {
            "home.index": "Админка",
            "colleges": {
                "index": "Колледжи",
                "create": "Новый",
                "edit": "{{name}}"
            },
            "users.index": "Пользователи",
            "users.create": "Новый",
            "users.edit": "{{name}}",
            "colleges_team_members.index": "Сотрудники колледжей",
            "colleges_team_members.create": "Новый сотрудник",
            "colleges_team_members.edit": "{{name}}"
        }
    }
}

Дальше всех в этом отношении продвинулись Rails. I18n там встроен во все слои сразу причем с учетом семантики. Все что я сейчас напишу ниже, можно подсмотреть тут: https://github.com/hexlet-basics/hexlet-basics/tree/main/config/locales

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

ru:
  activerecord:
    models:
      user: "Пользователь"
    attributes:
      base:
        name: “Название”
      user:
        name: "Имя"
        email: "Электронная почта"

Когда мы вызываем атрибуты модели в формах или представлениях, Rails автоматически подставляет переводы, если они заданы в config/locales. Например, в форме для модели User, если мы вызовем <%= f.label :name %>, Rails отобразит перевод для user.name как "Имя", если он указан. Если он не указан, Rails попробует взять общее название по ключу base, затем попробует отработать fallback (https://www.i18next.com/principles/fallback) и в самом конце, попробует подставить имя ключа преобразованное в текст (первая буква заглавная).

Сообщения об ошибках также поддерживают i18n. Если у нас есть валидации, например, для обязательного заполнения атрибута name, мы можем указать сообщение об ошибке. Модель:

class User < ApplicationRecord
  validates :name, presence: true
  validates :email, presence: true, uniqueness: true
end

Переводы:

ru:
  activerecord:
    errors:
      models:
        user:
          attributes:
            name:
              blank: "Имя не может быть пустым"

Тоже самое касается любого другого слоя. Единственное место где ключи создаются как попало это шаблоны, в которых нет никаких правил заранее, кроме одного. Rails позволяет использовать формат ключа с точкой в начале .keyname, который означает относительный путь. В таком случае слева автоматически подставляется путь до шаблона. Пример: https://github.com/hexlet-basics/hexlet-basics/blob/main/app/views/web/account/profiles/edit.html.slim#L24

Ссылки: Телеграм | Youtube | VK

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

Прямо сейчас у нас прямой эфир php-линча, где мы будем разбирать проблемы Laravel. Заходите https://youtu.be/KpSfWe7XS3A

Сняли офигенный видос про REST API. Даже если вы думаете что все понимаете, обязательно посмотрите, узнаете про typespec, typebox и много другого интересного: https://www.youtube.com/watch?v=W9sYAdiLnt8

Как управлять текстами в проектах и при чем тут i18n

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

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

* 100% дублирование всех названий. Если у нас есть какое-то поле “Имя”, то оно будет повторено в каждом месте. В крупных проектах это может превращаться в десятки, а то и сотни повторений только для одного названия. А таких не уникальных текстов на сайтах большинство.
* Ручная интерполяция. В тех ситуациях, когда текст содержит динамические части, придется все это закодить руками и тут мы приходим к следующей проблеме
* Учет числа (плюрализация). Часто бывает, что надо писать слово в зависимости от количество элементов: 1 сообщение, 2 сообщения и так далее. Если хардкодить тексты, то эта задача становится проблемой и, часто, говнокодом.

Как минимум, часть проблем может уйти, если вместо текстов вставленных прямо по месту использования, создать словари, например, в json или yaml и дальше использовать их, но даже это решение не справляется с плюрализацией и интерполяцией. Лучше предпочесть специализированное решение и оно есть. Причем, в большинстве бекенд фреймворков оно уже встроено в сам фреймворк (laravel, django, rails и т.п.) это I18n.

I18n работает примерно так, мы описываем файлы с ключами (включая вложенные) и значения (тексты, возможно с интерполяцией)

{
  "key_one": "item",
  "key_other": "items",
  "keyWithCount_one": "{{count}} item",
  "keyWithCount_other": "{{count}} items"
}

А затем используем в нужном месте программы

i18next.t('key', {count: 0}); // -> "items"
i18next.t('key', {count: 1}); // -> "item"
i18next.t('key', {count: 5}); // -> "items"
i18next.t('key', {count: 100}); // -> "items"
i18next.t('keyWithCount', {count: 0}); // -> "0 items"
i18next.t('keyWithCount', {count: 1}); // -> "1 item"
i18next.t('keyWithCount', {count: 5}); // -> "5 items"
i18next.t('keyWithCount', {count: 100}); // -> "100 items"

Кто-то скажет, погодите, а при чем тут I18n? А вот так. I18n это, на базовом уровне, не инструмент перевода, а инструмент управления текстами. Даже если у вас один язык и другие не планируются, i18n нужно использовать для управления строками. Таким образом полностью решается вопрос дублирования, решается вопрос плюрализация (это базовая фича всех i18n), а еще там есть форматирование:

i18next.t('intlNumber', { val: 1000 });
// --> Some 1,000

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

И еще. Во многих бекенд фреймворках свой формат и свои тексты. Фронтенд может создавать свои, а может переиспользовать тексты с бекенда, хотя бы частично. Для этого ко многим фреймворкам понаписаны утилиты, которые позволяют взять бекенд тексты и перекинуть их во фронтенд. Например https://github.com/fnando/i18n-js

Ссылки: Телеграм | Youtube | VK

p.s. А как вы работаете с текстами в своих проектах?

Организованное программирование | Кирилл Мокевнин pinned «Новый выпуск с core-разработчиком Python (автором async) Юрием Селивановым, в котором, мы говорим о разработке на Python: будет много про Open Source, контрибьют в Python, инструменты и технологии. Рассмотрим, где сейчас активно применяется Python в веб-разработке…»

Новый выпуск с core-разработчиком Python (автором async) Юрием Селивановым, в котором, мы говорим о разработке на Python: будет много про Open Source, контрибьют в Python, инструменты и технологии. Рассмотрим, где сейчас активно применяется Python в веб-разработке, Data Science и Machine Learning, а также сравним его с другими языками, такими как Go, Erlang и Rust. http://youtube.com/watch?v=kVCTHuWwCR0

Зачем компании делают скидки?

Не технический пост для инженеров, на тему того, как компании проявляются снаружи и что происходит внутри. Пишу его, потому что знаю как многие идеализируют происходящее вокруг: “смотрите, эта компания вкладывается в климат” и многие на это ведутся. И я не хочу сказать, что компании делают какое-то зло, речь идет исключительно про понимание реальных целей, а не вторичных. Ниже кейсы и возможные интерпретации (подчеркну, возможные):

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

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

Ссылки: Телеграм | Youtube | VK

Продолжаю серию постов про организацию процессов в компании. В этот раз написал про принципы организации структуры корп доков и баз знаний. Советы универсальные. Забирайте: https://vc.ru/office/1592491-kak-organizovat-strukturu-hraneniya-korporativnyh-dokumenty-tak-chtoby-ne-stradat

Хабр жив! В этом выпуске мы вместе с Алексеем [Boomburum] Шевелёвым, одним из первых рейтинговых авторов, а теперь руководителем отдела по работе с пользователями Хабра, погружаемся в историю самого культового в ру-сегменте ИТ-портала и обсуждаем проблемы контента, авторов, карму, минусы в комментариях и многое другое. https://www.youtube.com/watch?v=_lvcEUi1MtE

Хочу рассказать небольшую, но важную штуку, связанную с поиском работы. Найм в любой области обладает сезонностью. Общая схема такая: В конце января начинается набор, который доходит до пика в марте-апреле, затем резкое снижение (майские) и плато летом. Затем к сентябрю снова начинается рост найма, который доходит до пика в октябре. В ноябре начинается спад, который доходит до самой низкой точке в декабре, когда никто не нанимает, так как праздники и никто не хочет платить новым людям за 10 праздничных дней, когда они еще ничего не сделали. Дальше цикл повторяется.

Ссылки: Телеграм | Youtube | VK

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

Сначала я долго искал сервис, который умеет не только стандартные вещи типа цепочек, триггеров и разнообразных диалогов, но и управление закрытыми сообществами с подпиской на них. В итоге нашел не очень известных ребят, но с обалденной функциональностью: winwinbot.ru. Мне понадобилось где-то пару дней плотно потыкать ботов, чтобы примерно понять принципы организации диалогов и организацию реакции на разные действия. Дальше уже пошло легко.

Суммарно у нас будет под десяток ботов, про которые я еще расскажу, например, через такой бот мы хотим сделать онбординг сотрудников Хекслета. На текущий момент из них запущены три: Хекслет.Карьера - это наш новый продукт, который мы пока обкатываем на студентах, а потом откроем наружу. Хекслет.Наставники - через этого бота управляем наставниками и закрытой группой для них в телеге (переехали из матермоста). По плану в этом боте будет много всякого, включая курсы обучения наставничеству (можно делать прямо в боте). И бот, который я настраивал последние дни и сегодня запустил https://t.me/HexletLearningBot (@HexletLearningBot).

Сейчас этот бот знакомит с проектами Хекслета и дает удобный доступ (меню) к ним (группы, каналы, сообщества, курсы и т.п.). В будущем он будет сопровождать прямо по обучению на Хекслете. Собственно потыкайте) Как вам?

Ссылки: Телеграм | Youtube | VK

Написал пост про управление паролями и доступами в компании. Полезно тем, у кого нет выделенных безопасников. Больше как инструкция для своих, но может быть полезно и другим: https://vc.ru/life/1568530

Новый выпуск подкаста уже доступен для прослушивания. https://www.youtube.com/watch?v=1XAbFkMaWxw Здесь мы вместе с Валентином Удальцовым, автором канала Пых, обсуждаем PHP. Поговорим про весь путь его развития — от старых подходов до новых тенденций, PHP-комьюнити и контрибьютах в версии PHP.

Рубрика: текстовый собес. Я задаю пять вопросов, вы отвечаете в комментариях :) Поехали =>

1. Достаточно ли валидации в ORM при реализации проверки на уникальность, например, email при регистрации? Раскройте
2. Какие последствия возможны при отправке email прямо в контроллере? Как можно решить эти проблемы?
3. Как бы вы реализовали смену email на сайте, так чтобы соблюсти баланс между сложностью и безопасностью?
4. Можно ли доверять email, который мы получаем по oauth от соц сетей и мержить аккаунты автоматически? Приведите примеры
5. Как ограничить отправку email пользователю, который добавил письмо нашего проекта в спам? И почему это стоит делать (или не стоит)?

Ссылки: Телеграм | Youtube | VK

На канале появился новый выпуск: “SOLID принципы в 2024: Полный разбор и прожарка”, который мы записали вместе с S0ER. Этот выпуск особенный, потому что здесь мы разбираем принципы играя в адвоката дьявола. Я объясняю почему они не нужны, а Женя наоборот https://www.youtube.com/watch?v=qHh_B97OjEY

Буквально на днях мы провели опрос о карьере и уже прилетело больше 200 ответов. Я закинул их в chatgpt чтобы собрать какие-то общие выводы. Они мне показались интересными, поэтому я решил поделиться с вами.

Возраст участников и опыт:
• Участники имеют широкий возрастной диапазон: от 18 до 45+ лет. Это свидетельствует о том, что в сфере IT присутствуют как молодые специалисты, только начинающие свою карьеру, так и опытные профессионалы.
• Большинство людей уже работают в IT, с началом карьеры от 2000-х до 2020-х годов, что указывает на участие как новичков, так и тех, кто работает в индустрии уже более 20 лет.

Грейд и текущие роли:
• Преобладают участники уровня middle и senior, что говорит о высоком уровне экспертизы. Однако, есть и джуниоры, и даже стажеры, что подчеркивает разнообразие опыта.
• Ряд участников занимают позиции лидов (team lead, tech lead), а также руководящие роли, что свидетельствует о высоком уровне ответственности и лидерства.

Стек технологий:
• Наиболее часто встречающиеся технологии: JavaScript (включая React, Vue), Python, Go и PHP.
• Многие специалисты работают с бекендом и фуллстеком, что отражает текущие тенденции в IT, где важна гибкость и умение работать на разных уровнях стеков.

Навыки и развитие:
• Значительная часть респондентов указывает на необходимость прокачки Hard Skills (жесткие навыки), что говорит о приоритете технических компетенций для карьерного роста.
• Soft Skills также упоминаются, особенно среди тех, кто уже занимает лидирующие позиции или хочет развиваться в менеджменте.

Карьерные планы:
• Многие специалисты стремятся к повышению грейда, особенно те, кто уже находится на позиции Middle или Senior.
• Около трети участников опроса хотят расти в своей текущей компании.
• Некоторые рассматривают возможность перехода в более крупные компании или компании мечты, такие как FAANG (Facebook, Apple, Amazon, Netflix, Google), или крупные международные компании.
• Некоторые рассматривают собственный бизнес или стартап в качестве долгосрочной цели.

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

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

Ссылки: Телеграм | Youtube | VK

p.s. У вас совпадает?

Ребят я провожу опрос на тему карьерного и профессионального роста. Пройдите пожалуйста небольшую анкету, если вы думаете качаться или уже качаетесь. Это сильно повлияет на канал и активности, которые будут проводиться. А они будут, тут в закромах я работаю над запуском клуба, но пока это секрет (хехе). Кликать сюда -> https://forms.gle/x3anpqUnwLGRy4336

Если кто-то из вас готов со мной на часовое интервью (касдев), то отметьте там внутри галочку. Я планирую поговорить с 10 людьми, кому интересен рост и прямо на созвоне проконсультирую, дав по мере возможности рекомендации для вашей ситуации.

Вы когда нибудь слышали про A,B и C игроков? Если нет, то попробуйте примерить это на себя или своих подчиненных если они у вас есть

💡 Обычно, оценивая сотрудников, мы используем классификации junior, middle и senior. Но это не всегда работает, как ожидается. Иногда синьор может не давать ожидаемых результатов, а джуниор, наоборот, быстро растёт и показывает высокую эффективность, значительно превышая ожидания.

Вот почему важно не просто смотреть на уровень, а использовать другую классификацию — A, B и C-игроков. Одним из главных преимуществ этой системы является её простота: всего 4 вопроса, которые позволяют быстро и эффективно оценить каждого сотрудника без сложных систем проверки навыков.

* A-игроки — лидеры. Они берут ответственность, быстро учатся новому и всегда решают задачи на 100%.
* B-игроки — добросовестные исполнители, но им иногда нужна поддержка и руководство.
* C-игроки — те, кто тормозит процесс. Им нужно всё объяснять, и даже тогда они не всегда справляются.

🎯 Как понять, кто есть кто? Вот те самые вопросы, которые помогают это определить:

* Что происходит, когда вы делегируете им задачу?
* Как они справляются, когда нужно делать что-то новое?
* Что они делают, когда сталкиваются с преградами?
* Хотели бы вы снова нанять сотрудника с такими качествами?

Теперь разберёмся, как действуют A, B и C-игроки в этих ситуациях:

- A-игроки:
    * Делегируешь задачу — уверен, что она будет выполнена лучше, чем если бы делал ее сам.
    * Когда нужно сделать что-то новое, они учатся сами.
    * Столкнулись с проблемой — сразу просят помощь.
    * Нанимая новых сотрудников, хочешь найти таких же, как они.
- B-игроки:
    * Делегируешь задачу — они справляются, но им нужна поддержка.
    * Нужно новое задание — им потребуется помощь в обучении.
    * Столкнулись с проблемой — тратят время, пытаясь разобраться сами.
    * При найме стремишься найти кого-то лучше.
- C-игроки:
    * Делегируешь задачу — сомневаешься, что она будет выполнена качественно.
    * Нужно новое задание — им нужно объяснять всё по шагам, и результат под вопросом.
    * Столкнулись с проблемой — молчат и затягивают процесс.
    * Нанимая, стараешься найти кого-то совершенно другого.

✅ Самое важное — избавляйтесь от C-игроков. Они замедляют развитие команды.
🔥 А вот B-игроков можно развить в A-игроков с помощью наставничества.

Ссылки: Телеграм | Youtube | VK

Этой теме посвящены целые книги: https://www.amazon.com/Player-Definitive-Playbook-Employees-Leaders/dp/1630479926

Насколько хорошо вы понимаете как работает транзакционность в базе данных? Ниже список из 10 заблуждений относительно работы транзакций:

- Транзакция всегда завершится успешно.
- Транзакция блокирует данные, пока не завершится.
- Транзакции всегда атомарны.
- Если операция завершилась успешно, то все данные были обновлены.
- Атомарность всегда гарантирует отсутствие конфликтов.
- Операции записи в кэши или файловые системы также атомарны.
- Откат (rollback) всегда возможен.
- Атомарные операции всегда производятся быстро.
- Сетевые запросы в рамках транзакции всегда атомарны.
- Все системы одинаково поддерживают атомарные операции.

Давайте в комментариях разберем каждый пункт, почему такое может произойти

Ссылки: Телеграм | Youtube | VK

Около 15 лет я работаю (программирую и пишу все тексты) в виме на 13 дюймовом мониторе моего ноутбука. Те кто не видел меня за работой говорят "это же не удобно", те кто видел - "можно медленнее, а то я не успеваю". Давно хотел про это рассказать, тред об эффективности =>

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

Начнем издалека. Один из базовых навыков это слепая печать. Дело не только в том, что не смотришь на клавиатуру, а в том, что правильная постановка рук очень помогает эффективно нажимать всякие комбинации. Например использовать оба шифта. Подробнее https://guides.hexlet.io/ru/typing/.

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

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

Общая концепция была такая: использование мышки должно быть сведено к минимуму. Фактически я использую мышку, а точнее трекпад только для серфинга в интернете. Переключение программ, вкладок, набор и редактирование кода, все на 100% без мышки и это еще до вима.

Во всех операционках есть примерно один базовый набор комбинаций перемещения и выделения через стрелки + вариации с shift и ctrl. Это минимум который работает везде (в любых полях для ввода, не обязательно код) и который полезно научиться использовать.

Так как ctrl используется в комбо достаточно часто, то его лучше переместить на capslock, туда где он и был изначально. Это спасает от постоянного выламывания рук. Вимерам так вообще обязательно.

Еще одна важная кнопка - command, тут повезло маководам. Она лежит под большим пальцем и снимает опять же нагрузку с мизинца, значительно упрощая нажатие многих комбинаций. Сначала не привычно, потом уже страшно возвращаться обратно. Кстати, в крутых клавах все на больших пальцах

Дальше еще больше специфики маков. Так как у маков все унифицировано, то переключение вкладок во всех программах это: shift + command + []. Все доводится до автоматизма моментально. Дальше нам это пригодиться, когда я буду говорить про терминалы

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

В моей работе, в подавляющем большинстве случаев нужно работать с двумя программами: браузером и редактором. Они обе развернуты на весь экран и переключение по ним я делаю быстрым нажатием cmd + tab и обратно тем же самым нажатием. 100% автоматично для мозга и всегда одинаково

Так мы получаем первую ось переключения, я ее называю "в глубину". Очень важно чтобы программы было две, иначе трюк с cmd + tab не пройдет и придется думать о переключении. А вот внутри программ переключение идет "в ширину" по вкладкам и в браузере и в редакторе. Каким образом? Продолжение в первом комменте

Ссылки: Телеграм | Youtube | VK

Сегодня чуть с запозданием, но таки вышел выпуск про ATS https://www.youtube.com/watch?v=XDFxYkPty5g

Картинка для привлечения внимания. Я последние недели разрабатываю курс по REST API. Ух получается огонь, буду постепенно рассказывать про всякие штуки, которые я откопал и настроил в процессе. Про TypeSpec для описания спек с генерацией в openapi, про воронку валидации, про тестирование такого api и многое другое. Когда сделаем его для js/ts, то будем переносить на другие языки. Концепции там не поменяются, только некоторые либы и фреймворки, но общая история идентичная

Ссылки: Телеграм | Youtube | VK

Есть у меня список принципов, которых я придерживаюсь когда пишу код. Пришла пора ответить за слова. Лайк, тред, инфлюенс =>

"Язык — это инструмент" банально, но факт. Не прикипайте к языкам, язык для души и работы это разные вещи. Я не люблю го, но буду использовать там где он силен, я люблю кложу, но не буду использовать почти нигде (:D) PHP сила, TypeScript могила

"Написание кода — не цель" Задача самурая устранять боль, наиболее эффективным с точки зрения стоимость/затраты способом. Задачи могут решаться удалением кода или административным решением. Думайте о том как уменьшить количество состояний, а не запрограммировать их все

"Удаление кода лучше его написания" Я бы сказал нет кода нет проблем. Никому не нужно бесконечное число фич. Режьте все ненужное, постоянно осматривайтесь "а нахрен оно тут лежит?". Чувствуйте бизнес, будьте бизнесом, будьте

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

"Любое решение имеет плюсы" Даже если вас съели, у вас есть два выхода. Хороший программист рассматривает любое решение, даже то, которое ему не нравится. Мы тут не фильмы на нетфликсе выбираем.

"Уровень мышления определяет уровень решений" Очень похожая мысль на парадокс блаба https://nestor.minsk.by/sr/2003/07/30710.html но для картины мира в голове. Изучайте разные подходы, парадигмы, экосистемы. После js изучение python это трата времени (для мышления), а изучение java мощь

"Изменяемое состояние — это необходимость и корень всех бед", а не преждевременная оптимизация. Если надо что-то менять, то приходит жопа в: историчности, порядке действий, канкаренси, сложности восприятия, сложности реализации отладке, восстановлении, скорости и дальше по списку

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

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

"Однообразие лучше локальных оптимизаций" Это мега важный принцип. Моторная и ассоциативная памяти решают. Делайте одинаково, даже если местами кажется, что можно срезать. Например даже если состояния два, в базе все равно лучше строка: легко расширить, одинаковый код по проекту

"Тесты вселяют уверенность" Страх внесения изменения в проект заводит его в тупик. Юниты мешают изменениям. Интеграционные тесты решают. Не надо ничего мокать, стабы и нормальная инверсия всегда предпочтительнее. Работайте с базой по настоящему.

"Эксплуатация — это часть системы" Ответственность программистов довести фичу до прода, а не слить в main. Time To Market управляет проектами. Обязательно к прочтению: цель и проект феникс

"Код — это не продукт" хорошо понимаешь когда начинаешь делать бизнес, а там логистика, саппорт, продажи, сопровождение, аналитика, бухгалтерия, финансы. Из 80 сотрудников Хекслета только 5 человек работает над кодом платформы

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

Ссылки: Телеграм | Youtube | VK

В твиттере бурно обсуждают скриншот, на котором видно как на букинге описываются скрытые платежи в последний момент. С этими платежами конечная стоимость может легко увеличиваться в два и более раз. Естественно все это порождает праведный гнев и вопросы в стиле “зачем, прятать если конечная цена все равно такая же как если бы не прятали?”

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

Как это работает?

#пробизнес

Процесс продажи билетов очень похож на продажи игр в сторах. Он состоит трех точек касания (как минимум):

1. Листинг (список чего-либо), на котором мы быстро принимаем решение что нам подходит
2. Страница товара, с более подробным и заманивающим описанием и картинками
3. Страница чекаута, где происходит оплата

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

Гипотетический пример. Поездку в майами смотрят 100 000 людей в день из которых, только 5% переходят на страницы конкретных отелей (эта метрика называется CTR, она есть во всех списках, будь то список курсов, приложений или выдача в поиске). Это 5000 человек. Из них только 10% доходят до чекаута, а это 500 человек. Ну и дальше покупает скажем 20%, а это 101 человек.

Имея на руках такую воронку, маркетологи думают как ее оптимизировать, но не целиком, а поэтапно. Каждый этап это свои подходы и свои конверсии. Очен удобно, так работают 100% бизнесов. За десятилетия работы с воронками на онлайн проектах, выработались подходы и техники, которые все знают независимо от индустрии. Одна из классических схем, делать предложение как можно более привлекательным снижая базовую цену и показывая ее только в самом конце или вообще перенеся продажи за пределы воронки, например, как в играх, где игры могут быть вообще бесплатными, а дальше с вас будут чаржить без перерыва уже внутри, зарабатывая в разы больше денег (если не на порядки).

Именно поэтому пишут про минимальный платеж, про “от 1000 рублей” за билет на концерт, в самой заднице стадиона, про стоимость перелета без учета багажа и так далее. Главная цель - подвинуть как можно больше людей (говорят трафика) на следующий этап воронки.

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

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

Можно ли поправить законодательно? В теории да, но как правило, все обходится, поэтому эта задача очень сложная. Нужно последовательно выпускать патчи к законам постоянно наблюдая за ситуацией. Таким мало кто заморачивается серьезно и делается это не за один год. В конечном итоге мы покупаем молоко в пачках 900 грамм.

Ссылки: Телеграм | Youtube | VK

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

Релиз! В этом выпуске мы с Кириллом Игнатьевым, Senior Software Engineer в компании Bloomberg, разговариваем о больших компаниях и больших зарплатах 🙂 Обсуждаем процесс найма в FAANG (Facebook, Amazon, Google) и систему грейдов. Как она устроена и как внутри нее расти. https://www.youtube.com/watch?v=zkrLgz7lwgI