суббота, 27 июля 2019 г.

[work.thoughts] Мысля насчет расценок в зависимости от языка программирования

В последнее время, когда приходится писать код, делаю это либо на C++17, либо на C++14, либо на C++11. Либо, внезапно, на чистом C. C++98 уже давно не попадалось.

И если возврат с C++17 на C++14 как-то особым приключением не воспринимается, хотя к плюшкам C++17 уже привык, то вот переход с C++17 на C++11 -- это уже испытание. Ну а чистый C -- это какая-то, бл*дь, темная вселенная, нормально существовать в которой могут, такое ощущение, только люди альтернативно одаренные. Ну или те, от которых скрывают наличие жизни за пределами C.

Но к чему я этим решил поделиться? А вот к чему.

Похоже, что нужно выстраивать ценник в зависимости от степени свежести стандарта языка программирования. Скажем, есть базовая цена для C++17 (для наших еб*ней с прицелом на заказчиков из РФ -- это где-то $25/hour для проекта от двух-трех месяцев длительностью без горящих сроков).

Тогда для C++14 будет базовая цена + 5%.

Для C++11: базовая цена + 25%. А если нужно жить с GCC ниже 4.8 или MSVS2013, то + 50%.

Для C++98: базовая цена * 2.

Для чистого C: базовая цена * 3.89. В случае, если заказчик согласен на частичный рефакторинг с постепенным затаскиванием C++ных частей в C-шную кодовую базу (или постепенный перевод с C на C++), то базовая цена * 2.17.

Ибо нех*й.

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

PS. Если кто-то остался один на один с древним C-шным или C++ным кодом, без которого вам не обойтись, но с которым вы не знаете, что делать, то вам сюда. И да, это реклама. Проплачена мной.

пятница, 26 июля 2019 г.

[prog.c++] rotor: библиотека, разработанная под влиянием SObjectizer-а

Полку акторных фреймворков для C++ прибыло!

Собственно, вот: rotor. Автор пробовал использовать SObjectizer, но у SObjectizer-а нет интеграции с wxWidgets, а интеграция с Asio находится под двойной лицензией. Поэтому автору показалось проще сделать свое решение. Более подробно о причинах можно прочитать здесь.

Безотносительно того, как я сам оцениваю объективность/субъективность причин, толкнувших на создание rotor-а, хочется пожелать автору удачи. Во-первых, потому, что C++у нужно больше фреймворков, хороших и разных. Во-вторых, потому что это только начало. Выкатить первую версию и даже развивать ее в первые несколько лет не проблема. А вот дальше сложнее. Особенно с учетом того, что универсальные акторные фреймворки в мире C++ как-то особо не взлетают.

Ну а меня впечатляет другое: как-то незаметно для меня SObjectizer превратился в большой и сложный инструмент. Настолько, что кто-то уже хочет чего-то полегче. Ну это типа ты сделал текстовый процессор уровня Microsoft Word, а пользователи говорят, да не, нам бы чего-то не сложнее WordPad-а :)