Но мы не видим конечную ценность для пользователя, ради которого разрабатываем продукт.
В тексте предлагается удивительный по своему безумию текст:
Допустим, если средний чек был 2 500 рублей, то после небольшого обновления продажи увеличились на 125 000 рублей.
На текущий момент я вижу, что я только что впарил наш товар большему количеству людей, но чёт я не вижу чтобы это решало проблемы пользователей) Это явно решает не их проблемы.
К другим пунктам тоже вопросы:
Приобретаем чувство ценности
И далее пример с тем, как прекрасно растут продажи той байды, что мы впариваем. Как это должно придать чувство ценности? Я как программист на эти продажи клал с высокой колокольни, я не на процент работаю.
Из этого ложного чувства ценности и псевдорешения проблемы пользователей (которые на самом деле решения одной проблемы - как бы побольше вытянуть из него бабла), выводится борьба со скукой. Но раз посылки ложные, то и вывод ложный.
Равно как и понимание "роста" очень разное у продажников и технарей. Вы опять же пытаетесь продать работу менеджера программисту. Ничего ужасного в этом нет, многие так и делают, но это только одна ветвь роста.
Итог, как я его вижу: метрики программисту не только не нужны, но ещё и вредят. Он начинает понимать, что его заплата не растет соответственно росту прибыли, он понимает, что вместо того, чтобы делать что-то полезное - занимается перекрашиванием кнопочек для того, чтобы вытянуть бабла из пользователей, по сути эксплуатирует баги подсознания.
Я вас очень прошу подробно расписать что вы имете ввиду про Microsoft. Определенная какая-то область?
В том и суть. Я писал в одно и то же место о проблемах:
Game Pass. Перенос подписки на другую учётную запись. Формально процедура не предусмотрена, но специалист поддержки просто отменил подписку на одном аккаунте и дал мне "подарочный" код, для активации на другом. И это при условии, что у меня ещё и регион поменялся и соответственно подписка на Game Pass должна была стоить дороже для нового аккаунта.
MS Office Home & Student. Установщик не мог скачать файлы (из-за санкций), предоставили оффлайн-установщик, хотя в интернете такой не найти официально. Активация фейлилась почему-то, но опять оказалось дело в регионе. В принципе, специалист поддержки предлагал уже фигануть активацию через их пубоичный прокси, но VPN помог.
Были проблемы с тем, что не подхватывалась OEM лицензия на Windows 10 Professional. По итогу, выдали новый код активации.
Были проблемы с установкой нескольких сетевых интерфейсов на Windows машине. Тут я уже фиг знает в чем была причина, специалист поддержки удаленно подключился к кому, что-то там потыкал в реестре и всё заработало.
И вот весь кайф в том, что я изначально обращался в один и тот же чатик, дальше меня тупо перекидывали к нужным людям без бесконечных ожиданий.
Да, но - внезапно! - Fragment ничего не гарантирует и вообще ответственно заявляет, что никакого отношения к Telegram не имеет и никакой ответственности за решения Telegram не несёт.
Он может продать тебе заранее незаконный по правилам Telegram никнейм, забрать деньги и... свалить в закат с отпиской ССЗБ.
Правильная аналогия была бы платить в пятерочке через терминал без гарантии того, что товар у тебя не отнимет охранник на выходе.
Во-первых, ну-таки это хабр. Здесь хорошие лонгриды любят и ценят.
Во-вторых, такова природа всех статей по метапрограммированию. Они требуют вдумчивого долгого чтения.
В-третьих, я потратил на беглое чтение (чтобы понять стоит статья прочтения) всего минут 5. Даже если статья вдруг выросла бы в 3 раза по объёму - вроде и ничего страшного.
Конечно, чукча читатель, чукча не писатель. Статей своих у меня ровно ноль, но именно как читателю мне показалось, что для того, чтобы статья стала чуть лучше, можно было бы:
Выкинуть всю часть про Lisp. Она не добавляет статье вообще ничего полезного. Суть проблемы и желаемый интерфейс понятны уже из первого С++ примера.
Более развёрнутого описания работы descriptor_t и visit_invoke_fn . Просто потому, что это буквально самая важная часть, половина обсуждаемой проблемы в том, чтобы придумать этот идентификатор. Вторая половина - как сохранять функции и типы аргументов к ним. Эта часть вынесена вообще под спойлер с кодом без единого внятного комментария, хотя является критичной для понимания вашего решения. Всё остальное - это пляска вокруг контейнера, сие не особо интересно, т.к. пишется относительно просто.
Не особо я понял часть про type_info. Деталей магии стоящей за этой языковой фичей я не помню, неплохо бы какие-то пояснения хотя бы под спойлер занести. В частности часть про изменения имени "от вызова к вызову". Также неплохо было бы рассмотреть помимо стандартного type_info еще хотя бы boost type_index.
Ну и да, как я сказал - нужны замеры по отношению к более "дубовым" решениям в стиле dynamic_cast. Как времени компиляции, так и работы в рантайме, для разного количества диспетчеризуемых типов.
Совсем хорошо - описать существуют ли какие-то известные вам ограничения применимости вашей библиотеки, чтобы можно было сразу понять, могу я себе её затянуть или нет. Может быть есть какие-то неочевидные вещи по контекстам применения или лицензионные ограничения.
В любом случае, спасибо за труд, библиотеку гляну.
Штука прикольная, но в статье категорически не хватает деталей.
Статью можно сократить до трёх предложений без потери смысла:
Есть проблема Х
Все решения, что есть - так себе
Я придумал либу - вот ссылка
Почему так?
1. Код под спойлерами невозможно прочитать, потому что в нём куча сущностей, про которые в статье ни слова. Да и те сущности что введены, не раскрыты ни разу. Например, фраза под спойлером для visit_invoke_fn : "применим трюк, чтобы комплилятор...". Какой трюк? Как он работает? Кем описан? Фиг пойми.
2. Не хватает каких-то деталей по части времени компиляции всего этого добра, какой стандарт С++ нужен (исходя из spaceship-оператора, полагаю, что не ниже С++20), сравнение по скорости с dynamic_cast / type_info-based решениями.
Ну и чисто придирка - вначале заявляется проблема взаимодействия кота и собаки, в финальном примере внезапно возникают космические объекты и коллизии. Неконсистентно.
Выглядит оно достаточно интересно, чтобы я сходил в исходники посмотреть, но видится мне в статье есть что улучить, чтобы получилась статья, а не просто заметка в стиле "Я тут пометапрограммировал и получилось прикольно. Дальше сами разбирайтесь".
Лично я стараюсь всё решить сам не потому что я крутой, а потому что работа достала монотонностью, поэтому для разнообразия можно и "KDE под FreeBSD пропатчить") Тупо интересно)
Если в B2B секторе поддержка ещё более или менее рабочая вещь, то в обыденной B2C жизни поддержка в 90% случаев существует не для того, чтобы решать проблемы, а для того, чтобы максимально деликатно сказать: "сам дурак, иди-ка ты отсюда".
Поддержка PVS в целом радует. Я редко общаюсь напрямую, т.к. этим занимаются DevOps-ы, но в целом на удивление оперативно решали мои проблемы, включая исправление багов в самой PVS.
P.S.
Меня приятно удивляет поддержка Microsoft. Эти ребята решают 100% даже самых упоротых проблем. Общаются с тобой по два часа. Даже несмотря на то, что РФ под санкциями. Причем чтобы написать им не надо пройти 1000 кругов ада.
Просто на сайте тыкаешь кнопочку и вот у тебя через 5 минут уже чат с живым человеком! У мегакорпорации. Бесплатно. Что за люди :)
Всё, что могу ответить - просто попробуйте Haskell :)
Остальное - очень долгая дискуссия, которую я вести не хочу. Большая часть из неё будет пересказом Core Guidelines, ведь там вполне себе нормально описано, когда auto хорошо, а когда плохо. И я по большей части согласен с Core Guidelines)
Строго типизированный != нужно указывать тип. Haskell строго типизированный язык, точно "строже" С++ (уж не знаю насколько корректно так говорить), но при этом писать типы нужно оч редко.
Конечно С++ не Haskell, но пока код относительно высокоуровневыйии не надо ковырять байтики, не писать тип бывает лучше, чем его писать.
Не так давно, месяца два назад, общался с ребятами, искали Rust-программиста. На что им буквально первым предложением я ответил, что в общем не против, но опыт только в С++, знания Rust на уровне "ознакомился". На что был получен ответ "не проблема".
На собеседовании: в общем, у вас нет опыта на Rust, так что надо будет сделать тестовое задание объемом в месяц, если тратить по 4-5 часов в день. Оплачивать не будем.
Был ещё забавный опыт, когда предлагали вакансию, но чтобы взяли, нужно пройти трехнедельное обучение у них (бесплатно), по итогам которого они решат, хотят ли они со мной сотрудничать или нет) Компания - обычная аутсорс галера, я с ними уже работал во времена фриланса года 4 назад, но они не вспомнили это. Искали Senior разраба.
Удивляет, что в опросе нельзя выбрать больше одного варианта) Мы вот используем сразу 3 из списка + неупомянутый вроде как отечественный SVACE , который на удивление хорош (только документация отстой).
А можно спросить как метрики решили эту проблему
В тексте предлагается удивительный по своему безумию текст:
На текущий момент я вижу, что я только что впарил наш товар большему количеству людей, но чёт я не вижу чтобы это решало проблемы пользователей) Это явно решает не их проблемы.
К другим пунктам тоже вопросы:
И далее пример с тем, как прекрасно растут продажи той байды, что мы впариваем. Как это должно придать чувство ценности? Я как программист на эти продажи клал с высокой колокольни, я не на процент работаю.
Из этого ложного чувства ценности и псевдорешения проблемы пользователей (которые на самом деле решения одной проблемы - как бы побольше вытянуть из него бабла), выводится борьба со скукой. Но раз посылки ложные, то и вывод ложный.
Равно как и понимание "роста" очень разное у продажников и технарей. Вы опять же пытаетесь продать работу менеджера программисту. Ничего ужасного в этом нет, многие так и делают, но это только одна ветвь роста.
Итог, как я его вижу: метрики программисту не только не нужны, но ещё и вредят. Он начинает понимать, что его заплата не растет соответственно росту прибыли, он понимает, что вместо того, чтобы делать что-то полезное - занимается перекрашиванием кнопочек для того, чтобы вытянуть бабла из пользователей, по сути эксплуатирует баги подсознания.
Т.е. прошедшей не так давно итерации отжатия никнеймов недостаточно для недоверия к телеге?
Проблема в том, что Telegram и есть Вася Пупкин) Который:
Создаёт товар
Продает тебе товар
Забирает у тебя товар
Игнорирует жалобы от спортлото.
Де факто, "покупка" никнейма - это аренда с нулевыми санкциями за нарушение договора.
В том и суть. Я писал в одно и то же место о проблемах:
Game Pass. Перенос подписки на другую учётную запись. Формально процедура не предусмотрена, но специалист поддержки просто отменил подписку на одном аккаунте и дал мне "подарочный" код, для активации на другом. И это при условии, что у меня ещё и регион поменялся и соответственно подписка на Game Pass должна была стоить дороже для нового аккаунта.
MS Office Home & Student. Установщик не мог скачать файлы (из-за санкций), предоставили оффлайн-установщик, хотя в интернете такой не найти официально. Активация фейлилась почему-то, но опять оказалось дело в регионе. В принципе, специалист поддержки предлагал уже фигануть активацию через их пубоичный прокси, но VPN помог.
Были проблемы с тем, что не подхватывалась OEM лицензия на Windows 10 Professional. По итогу, выдали новый код активации.
Были проблемы с установкой нескольких сетевых интерфейсов на Windows машине. Тут я уже фиг знает в чем была причина, специалист поддержки удаленно подключился к кому, что-то там потыкал в реестре и всё заработало.
И вот весь кайф в том, что я изначально обращался в один и тот же чатик, дальше меня тупо перекидывали к нужным людям без бесконечных ожиданий.
Да, но - внезапно! - Fragment ничего не гарантирует и вообще ответственно заявляет, что никакого отношения к Telegram не имеет и никакой ответственности за решения Telegram не несёт.
Он может продать тебе заранее незаконный по правилам Telegram никнейм, забрать деньги и... свалить в закат с отпиской ССЗБ.
Правильная аналогия была бы платить в пятерочке через терминал без гарантии того, что товар у тебя не отнимет охранник на выходе.
Чего я так понять и не смог, это почему надо покупать что-то у telegram через прослойку в виде fragment? Это выглядит по меньшей мере подозрительным.
Причем, если с их новой фичёй (виртуальные номера) ещё относительно понятно почему так, то конкретно с никнеймами выглядит как типичный скам.
Я не вижу в этом великой проблемы.
Во-первых, ну-таки это хабр. Здесь хорошие лонгриды любят и ценят.
Во-вторых, такова природа всех статей по метапрограммированию. Они требуют вдумчивого долгого чтения.
В-третьих, я потратил на беглое чтение (чтобы понять стоит статья прочтения) всего минут 5. Даже если статья вдруг выросла бы в 3 раза по объёму - вроде и ничего страшного.
Конечно, чукча читатель, чукча не писатель. Статей своих у меня ровно ноль, но именно как читателю мне показалось, что для того, чтобы статья стала чуть лучше, можно было бы:
Выкинуть всю часть про Lisp. Она не добавляет статье вообще ничего полезного. Суть проблемы и желаемый интерфейс понятны уже из первого С++ примера.
Более развёрнутого описания работы
descriptor_tиvisit_invoke_fn. Просто потому, что это буквально самая важная часть, половина обсуждаемой проблемы в том, чтобы придумать этот идентификатор. Вторая половина - как сохранять функции и типы аргументов к ним. Эта часть вынесена вообще под спойлер с кодом без единого внятного комментария, хотя является критичной для понимания вашего решения. Всё остальное - это пляска вокруг контейнера, сие не особо интересно, т.к. пишется относительно просто.Не особо я понял часть про type_info. Деталей магии стоящей за этой языковой фичей я не помню, неплохо бы какие-то пояснения хотя бы под спойлер занести. В частности часть про изменения имени "от вызова к вызову". Также неплохо было бы рассмотреть помимо стандартного type_info еще хотя бы boost type_index.
Ну и да, как я сказал - нужны замеры по отношению к более "дубовым" решениям в стиле
dynamic_cast. Как времени компиляции, так и работы в рантайме, для разного количества диспетчеризуемых типов.Совсем хорошо - описать существуют ли какие-то известные вам ограничения применимости вашей библиотеки, чтобы можно было сразу понять, могу я себе её затянуть или нет. Может быть есть какие-то неочевидные вещи по контекстам применения или лицензионные ограничения.
В любом случае, спасибо за труд, библиотеку гляну.
Хочу НИИ для исследования эффективности создания НИИ для решения социальных вопросов)
Штука прикольная, но в статье категорически не хватает деталей.
Статью можно сократить до трёх предложений без потери смысла:
Есть проблема Х
Все решения, что есть - так себе
Я придумал либу - вот ссылка
Почему так?
1. Код под спойлерами невозможно прочитать, потому что в нём куча сущностей, про которые в статье ни слова. Да и те сущности что введены, не раскрыты ни разу. Например, фраза под спойлером для
visit_invoke_fn: "применим трюк, чтобы комплилятор...". Какой трюк? Как он работает? Кем описан? Фиг пойми.2. Не хватает каких-то деталей по части времени компиляции всего этого добра, какой стандарт С++ нужен (исходя из spaceship-оператора, полагаю, что не ниже С++20), сравнение по скорости с dynamic_cast / type_info-based решениями.
Ну и чисто придирка - вначале заявляется проблема взаимодействия кота и собаки, в финальном примере внезапно возникают космические объекты и коллизии. Неконсистентно.
Выглядит оно достаточно интересно, чтобы я сходил в исходники посмотреть, но видится мне в статье есть что улучить, чтобы получилась статья, а не просто заметка в стиле "Я тут пометапрограммировал и получилось прикольно. Дальше сами разбирайтесь".
Потому что компания)
Лично я стараюсь всё решить сам не потому что я крутой, а потому что работа достала монотонностью, поэтому для разнообразия можно и "KDE под FreeBSD пропатчить") Тупо интересно)
Я бы "убежденный" переименовал в "опытный".
Если в B2B секторе поддержка ещё более или менее рабочая вещь, то в обыденной B2C жизни поддержка в 90% случаев существует не для того, чтобы решать проблемы, а для того, чтобы максимально деликатно сказать: "сам дурак, иди-ка ты отсюда".
Поддержка PVS в целом радует. Я редко общаюсь напрямую, т.к. этим занимаются DevOps-ы, но в целом на удивление оперативно решали мои проблемы, включая исправление багов в самой PVS.
P.S.
Меня приятно удивляет поддержка Microsoft. Эти ребята решают 100% даже самых упоротых проблем. Общаются с тобой по два часа. Даже несмотря на то, что РФ под санкциями. Причем чтобы написать им не надо пройти 1000 кругов ада.
Просто на сайте тыкаешь кнопочку и вот у тебя через 5 минут уже чат с живым человеком! У мегакорпорации. Бесплатно. Что за люди :)
Всё, что могу ответить - просто попробуйте Haskell :)
Остальное - очень долгая дискуссия, которую я вести не хочу. Большая часть из неё будет пересказом Core Guidelines, ведь там вполне себе нормально описано, когда auto хорошо, а когда плохо. И я по большей части согласен с Core Guidelines)
Строго типизированный != нужно указывать тип. Haskell строго типизированный язык, точно "строже" С++ (уж не знаю насколько корректно так говорить), но при этом писать типы нужно оч редко.
Конечно С++ не Haskell, но пока код относительно высокоуровневыйии не надо ковырять байтики, не писать тип бывает лучше, чем его писать.
Я тоже долго не любил auto :)
А потом я попробовал Haskell и теперь тоже нравится везде пихать auto, хотя моя бы воля, я бы как-нибудь и без него обошёлся)
Так, а разница-то в чём? По утиной типизации, наблюдаемый результат-то один.
Просто блюдут правила ведения бизнеса в России)
В большинстве реальных случаев сойдёт UML-like сиюминутный костыль из головы)
Не так давно, месяца два назад, общался с ребятами, искали Rust-программиста. На что им буквально первым предложением я ответил, что в общем не против, но опыт только в С++, знания Rust на уровне "ознакомился". На что был получен ответ "не проблема".
На собеседовании: в общем, у вас нет опыта на Rust, так что надо будет сделать тестовое задание объемом в месяц, если тратить по 4-5 часов в день. Оплачивать не будем.
Был ещё забавный опыт, когда предлагали вакансию, но чтобы взяли, нужно пройти трехнедельное обучение у них (бесплатно), по итогам которого они решат, хотят ли они со мной сотрудничать или нет) Компания - обычная аутсорс галера, я с ними уже работал во времена фриланса года 4 назад, но они не вспомнили это. Искали Senior разраба.
Удивляет, что в опросе нельзя выбрать больше одного варианта) Мы вот используем сразу 3 из списка + неупомянутый вроде как отечественный SVACE , который на удивление хорош (только документация отстой).