Я вас очень прошу подробно расписать что вы имете ввиду про 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 , который на удивление хорош (только документация отстой).
Поддерживаю. Правда в том, что никто не знает UML. Все только "припоминают" что-то о UML, но не более.
В связи с этим простым фактом, для большинства UML будет выглядеть ничем не лучше самостоятельного поделия на чём угодно, от draw.io до фотографии листочка бумаги.
Я вот 99% всех диаграмм рисовал в Gliffy, но с тех пор как убили Chrome Apps, пришлось искатб альтернативы, но пока что ничего лучше так и не нашёл. Gliffy по ощущениям был как ручка с бумагой. Ничего лишнего, все кнопки под рукой, всё было супер интуитивно.
Признаться честно, мне вообще пофиг как со мной общается бездушная железяка) Пусть приложение мне кидает ошибки в стиле "штошь ты делаешь, идиот?", лишь бы потом за этим следовало: "не надо делать Х, а то у меня ломается Y. Правильно делать Z. Дерзай".
Все эти вежливые/невежливые формы обращения - информационный мусор. С моей точки зрения, правильное сообщение об ошибке:
"Не удалось войти в аккаунт. Проблемы с авторизацией на сервере. Повторите через 5 минут. В случае повторного появления ошибки, обратитесь в поддержку".
Рядом: 1. Рабочая (!) кнопка/ссылка "написать обращение". Ведёт на страницу, не требующей логина, если сама программа для работы не требует логина. В ином случае логин должен быть тот же самый, что и для входа в программу. А то начинается: логин для программы один, для форума техподдержки - другой.
Совсем хорошо, если вместе с нажатием на кнопку, программа передаёт в URL еще и код ошибки, чтобы перед написанием сообщения, мне рядом с формой показали похожие (с таким же кодом ошибки) предыдущие темы, чтобы я не плодил лишнего и не ждал.
2. Кнопка Details в который будет техническая информация. Если я технически-подкованный пользователь, то я даже из банального стектрейса иногда смогу понять, что же всё-таки не так и возможно как-то исправить ситуацию. Совсем хорошо - если в Details хранится путь до логов программы.
Тем не менее сегодня популярен подход "что-то пошло не так". Даже без кода ошибки. Что лично я воспринимаю как "ты слишком тупой, тебе не понять нашего гения, так что страдай".
В том и суть. Я писал в одно и то же место о проблемах:
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 , который на удивление хорош (только документация отстой).
Поддерживаю. Правда в том, что никто не знает UML. Все только "припоминают" что-то о UML, но не более.
В связи с этим простым фактом, для большинства UML будет выглядеть ничем не лучше самостоятельного поделия на чём угодно, от draw.io до фотографии листочка бумаги.
Я вот 99% всех диаграмм рисовал в Gliffy, но с тех пор как убили Chrome Apps, пришлось искатб альтернативы, но пока что ничего лучше так и не нашёл. Gliffy по ощущениям был как ручка с бумагой. Ничего лишнего, все кнопки под рукой, всё было супер интуитивно.
Конечно нет, ведь вилка зарплат указана в вакансии. Указана ведь?)
Признаться честно, мне вообще пофиг как со мной общается бездушная железяка) Пусть приложение мне кидает ошибки в стиле "штошь ты делаешь, идиот?", лишь бы потом за этим следовало: "не надо делать Х, а то у меня ломается Y. Правильно делать Z. Дерзай".
Все эти вежливые/невежливые формы обращения - информационный мусор. С моей точки зрения, правильное сообщение об ошибке:
"Не удалось войти в аккаунт. Проблемы с авторизацией на сервере. Повторите через 5 минут. В случае повторного появления ошибки, обратитесь в поддержку".
Рядом:
1. Рабочая (!) кнопка/ссылка "написать обращение". Ведёт на страницу, не требующей логина, если сама программа для работы не требует логина. В ином случае логин должен быть тот же самый, что и для входа в программу. А то начинается: логин для программы один, для форума техподдержки - другой.
Совсем хорошо, если вместе с нажатием на кнопку, программа передаёт в URL еще и код ошибки, чтобы перед написанием сообщения, мне рядом с формой показали похожие (с таким же кодом ошибки) предыдущие темы, чтобы я не плодил лишнего и не ждал.
2. Кнопка Details в который будет техническая информация. Если я технически-подкованный пользователь, то я даже из банального стектрейса иногда смогу понять, что же всё-таки не так и возможно как-то исправить ситуацию. Совсем хорошо - если в Details хранится путь до логов программы.
Тем не менее сегодня популярен подход "что-то пошло не так". Даже без кода ошибки. Что лично я воспринимаю как "ты слишком тупой, тебе не понять нашего гения, так что страдай".