Среди разработчиков распостранено мнение, что не имеет значения на какую
компанию работать: продуктовую, сервисную, аутстафф, стартап, не-ІТ. Лишь бы
платили денег и желательно побольше.
Согласно опросу ДОУ [https://dou.ua/lenta/articles/portrait-2020/?from=doufp],
65% разработчиков заняты в аутсорсе, остальные—в продукте и стартапах. Рискну
предположить, что в "настоящем" продукте работает гораздо меньше 35%—под
"настоящим" я понимаю компанию которая была...
Пяток лет назад я попал на серию статей Егора Бугаенко об организации работы в
распределённой команде. Одной из ключевых особенностей этой системы был запрет
на любые коммуникации вне гитхаб тикетов
[https://www.yegor256.com/2014/04/17/how-xdsd-is-different.html#no-informal-communications]
. Проблема потерянных пакетов, отсутствия документации и незафиксированных
договорённостей мне очень знакома.
Позже эту же идею, поощрение структурированного текстового общения я увидел в
блогах малоизвестной...
"Rotting software" це серйозна проблема. Вибухове зростання індустрії генерує
таке ж зростання кількості інструментів розробки та пришвидшує старіння існуючих
рішень.
В 2015 для розробки стартапа ми взяли мікросервіси та Spring Cloud Netflix
[https://spring.io/projects/spring-cloud-netflix]. До 2017 половину з цього
стеку сам Netflix перевів у maintenance режим, а деякі рішення просто
задепрекейтив у себе та залишив напризволяще. Ми ще не встигли вийти...
В предыдущей части я рассказал о ядре
[https://www.rozhkov.me/modern-web-applications-architecture/]. Теперь пройдемся
о внешних вещах.
На Heroku эфемерная файловая система. Это значит, что после перезагрузки
инстанса, например при редеплое, все записанные файлы пропадут. Основной контент
сайта—это фото, поэтому их нужно где-то хранить. Для этого мы используем AWS S3
[https://aws.amazon.com/s3/]. Файлы прозрачно загружаются на S3 с помощью RoR,
для этого...
На той неделе я писал о том, что знания алгоритмов и умение быстро решать задачи
из литкода мне никогда не пригождались
[https://www.rozhkov.me/useless-computer-science-knoweledge/].
Ну что ж, instant karma! На выходных я писал компилятор телеграмовских сообщений
в html—это нужно для двухсторонней синхронизации с Ghost. Взял собщение из
телеги, конвертнул в html, засунул в Ghost, получил пост на сайте, Profit! Изи
таска.
Телеграм присылает...
В прошлом материале [https://www.rozhkov.me/useless-computer-science-knoweledge/] я
перечислил вещи, которые я не использую на практике. Сегодня поговорим о том,
что важно и нужно. Поехали.
Как устроены и работают разные базы данных и хранилища, как работают индексы,
зайчатки CAP, как работают транзакции, что такое план запроса, что такое N+1—на
мой взгляд это одни из важнейших знаний которыми должен обладать любой
разработчик имеющий дело...
В культуре собеседований западных продуктовых компаний и тех кто под них косит
принято гонять кандидатов по базам CS: решать алгоритмические задачи, спрашивать
заковыриствую теорию. Бытует мнение, что на практике эти знания применяются
крайне редко—поэтому мы, кандидаты, подгораем от необходимости этих знаний на
собесах. Зачем спрашивать, если у вас формочки?
Оставив в стороне целесообразность проведения таких интервью я сфокусируюсь на
своём опыте—какие знания из "...
Когда твоя компания предоставляет услуги для другой компании то часто между вами
сильно усложняется коммуникация и взаимодействие.
Например, у некоторых корпоративные правила требуют, чтобы все шло через
электронную почту. У других—ты не можешь достучаться напрямую до нужных тебе
людей, а можешь действовать только через посредников.
Это сильно усложняет процесс и делает его каким-то бесчеловечным. Я уверен что
на том конце провода такие же люди, которые...
Есть у меня такая отрицательная черта—не особо думать перед выбором чего-то.
Главное ввязаться, а там разберемся.
Терпеть не могу планировать и двигать колбаски на диаграммах ганта. Писать
спецификации и участвовать в длительных обсуждениях роадмапа на следующие 10
лет. Обсуждать то, что не нужно прямо сейчас и уже, что не горит.
Выбирать товары, технику и перечитывать миллион обзоров. Пытаться поймать самое
лучшее.
Закладывать архитектуру на столетия...
На первой работе я провел 7 с хвостиком лет. На второй—был первым
сотрудником-инженером.
Раньше мне это казалось крутым. Будучи в компании незнакомых коллег я всегда
пользовался возможностью похвастаться "я тут уже Х лет!", "вот этот проект
стартовал много лет назад, еще когда тут из вас никого не было!", "я тут первый
инженер, а вы не знали? да, вот эти все...
Что отличает продуктивного инженера от посредственного? Почему один делает
задачу месяц, а другой—пару часов?
Возьмём бота. По моим оценкам, джун управится с задачей за 40 часов, а
прокачанный чел—за 4-8, минимимум в 5 раз быстрее. Я посмотрел историю Toggl и
нашел задачу очень схожую с квиз-ботом, которую сделал как раз за 4 часа. За
счет чего достигается такая скорость?
Первое и самое главное—наличие...
