О превосходстве одних технологий над другими

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

Сперва добейся / Болтать — не мешки ворочать

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

Работа, которая мне не нравится 1/∞

В продолжение темы об интересной и неинтересной работе. Я люблю выдавать результат. Длинные задачи, бесконечные проекты и доработки меня напрягают. Мне нравится сделать что-то, довести его до минимально рабочего состояния, запустить и пойти дальше. Если быстро не получается выдать что-то или выполнить минимальные требования к качеству, то интерес к задаче быстро пропадает и заниматься ею нет никакого желания. Что это могут быть за задачи такие нехорошие? Для меня самое первое – обработка данных.

Вендор-лок наоборот

Для тех, кто не знает, “вендор-лок” — это такая тема, когда вы подвязываетесь (в чем угодно) закрытую технологию какого-нибудь производителя, делаете на его платформе какое-то решение, а дальше не можете с него слезть. Самый распространённый пример — использование, например, базы данных Oracle или облака AWS. Вначале может быть все хорошо и радужно, но чем дальше в лес тем толще партизаны, и вот уже весь ваш бизнес завязан на кучу технологических решений, которые в любой момент по желанию вендора могут изменить свое поведение или ценовую политику.

Рассказать я и сам могу, а вот сделать как?

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

Фулл-стек системы управления проектами

Любимая тема при старте проекта — “какой системой будем пользоваться для управления?”. Кажется что вот сейчас выберем правильную и хорошую систему и проект сделается сам по себе. На моей первой работе (в 2007) была самописная штука сделанная на базе платформы, которую компания и разрабатывала/продавала (сама платформа — это ERP конструктор для телекомов, тоже очень навороченная). Для заказчиков продавались модуля для работы с сетями, инвентарём и труднопереводимым словом resource/service provisioning, а для внутренних нужд пилились свои модули.

Работа, которая мне нравится

В любой работе есть 20% интересной и сложной части и 80% рутины и полировки. Вначале ты довольно долго подступаешься к задаче, превозмогаешь, а дальше раз—основная проблема решается и остается только “задеплоить код”. Вторая фаза естественно будет занимать гораздо больше времени нежели первая. Basecamp визуализируют это в виде так называемых Hill Charts. Вначале ты долго ползешь на гору, не знаешь, что будет дальше, кое-как добираешься до вершины, понимаешь, что дальше лезть уже некуда и надо спускаться.

Рецензия на книгу Егора Бугаенко "Code Ahead"

Я очень давно хотел закупиться у Егора всеми его книгами, но как-то так получалось, что все митапы и конференции с его участием я пропускал (из рук автора купить книги можно со скидосом в 50%). Но вот, месяц назад Егор анонсировал что он будет в Киеве на конфе QA-чего-то там и потом будет делать митап. Я незамедлительно написал что хочу купить все книги, получил положительный ответ и уже на самом митапе затарился.

Обсуждение багов в синхронных чатах

Вчера со мной произошла забавная ситуация. На одном из проектов меня попросили добавить REST API метод. Ничтоже сумнящеся я нафигачил его, отдал фронтенд разработчикам сигнатуру и пошел заниматься своими делами. Через некоторое время мне пишет в личку разработчик, который пилит свою функциональность на базе моего API, говорит “не работает” и прикладывает скриншот из постмана где написано 404. Я быстро смотрю и вижу что там неверный хост, указываю на это. Разработчик исправляет и опять показывает 404.

Продажа жопочасов

Большинство из нас продает жопочасы. Работа ли это в найме фулл-тайм или парт-тайм активности — практически всегда вопрос денег сводится к месячной (или годовой) ставке или часовому рейту. Все так делают, потому что это удобно. Оценивать работу разработчика и проекты сложно, поэтому никто не хочет задаваться этим вопросом. Легко оценить простую повторяющуюся работу, например укладку плитки. Плиточник берет фиксированную сумму за квадратный метр уложенной плитки с поправочными коэффициентами на сложность поверхности и количество подрезок, но даже с ними вычислить стоимость будет довольно просто.

Resume Driven Development

Один из частых вопросов у любого инженера (и не только) — как и когда учить новое? Технологии (по крайней мере внешне) обновляются довольно быстро, количество инструментов, которыми необходимо владеть для ежедневной работы растёт и нужно все это как-то изучать и применять. Для решения этой проблемы и была придумана методология RDD она же Resume Driven Development. Для начала ответим на вопрос “как?”, он же “форма обучения”. Я считаю, что всё нужно изучать на реальных и нужных кому-то проектах (e.

Как разжечь срач в интернете

Есть несколько тем на которые у любого человека есть что сказать: религия политика отношения Обсуждение любой из этих тем моментально провоцирует срач и в терминальных случаях приводит к “вычислю по ІР”. Два года назад в твиттер треде про women in tech мне люди на полном серьезе угрожали физической расправой хотя я вроде ничего оскорбительного или радикально-провокационного не говорил. Хотите пошуметь — выбирайте одну из этих тем и вперед —гарантированно получите мощнейшую дискуссию, правда совершенно деструктивную и бесполезную.

Главный язык который должен знать любой разработчик

Помимо английского. Язык который пригодится везде и всегда, бекендеру и фронтендеру, и даже не только разработчику, но и тестировщику, бизнес-аналитику, (дев)опсу и вообще кому угодно. Язык который можно сказать в своей базовой форме универсален посреди всех платформ и практически не изменялся десятилетиями. Язык, к вызовам которого сводится 80% всей разработки вообще. Это… SQL! Во времена JavaEE ходили шутки что вся разработка это пересылка XML из одной системы в другую. Описание это не совсем точное, потому что там упущен момент вытягивания данных с помощью SQL из базы, конвертации их в XML, отсылки куда надо по SOAP и обратной процедуре.

Полиглотопроблемы

Я “знаю” кучу языков программирования. Начал с синей книжки по С которую отец мне дал читать когда у меня еще компьютера не было, потом в школе Basic, Pascal и немного JS, потом в университете Pascal, asm х86 и микроконтролерный, Java, Ada, потом на работе Java, SQL, Bash, потом на другой работе Python, JS, Bash, потом на третьей работе Objective C, PHP, Ruby, JS, SQL. Сейчас 60/20/10/10 это Ruby/JS/Java/Python (SQL не считаем).

Продукт против платформы

Платформа В любой софтверной компании которая перерастает определенный уровень (несколько лет работы и 10+ разработчиков примерно) со временем начинает выделяться такая штука как “платформа” — набор фреймворков, библиотек, базовых инфраструктурных вещей, которые являются общими для всей компании и используются повсеместно. Например, некая абстракция для доступа к хранилищам данных, или более высокоуровнево — сервис управления пользовательскими данными и авторизацией. Платформу пытаются делать “правильно” и вылизывать до совершенства внедряя всякие технологичные вещи.

О хвастовстве

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