Спасибо за мысли! У нас эти советы не все применимы из-за специфики (stateless, api), но похожую идею, только, наоборот, с выключением логов для конкретного пользователя тоже реализовывали. Были случаи, когда клиенты начинали упорно долбить запросами при закончившемся ключе, организовывая мини-DDOS с "белых" IP, и надо было их либо вручную под протоколы обработки DDOS подводить, хотя всё стабильно работало, либо минимизировать число записей в логах.
Про один шаг немного не понял. В очередь пишутся все записи с момента старта работы над запросом и до момента его окончания. Иначе никак - мы не знаем, в какой момент может произойти событие-триггер.
При этом все ошибки уровня выше Info логируются незамедлительно, как и положено, специально, чтобы избежать проблемы с "всё упало, а логи не записались". И дополнительно пишутся в кэш, чтобы можно было их потом разобрать вместе с остальными.
Основные операции, типа добавления в очередь и поднятия уровня логов, сделаны потокобезопасными. При этом, да, если вызвать ToString в неправильном месте, можно словить эффекты с синхронизацией, но ими я сознательно пренебрёг в угоду скорости.
Алгоритм работы получается следующим: перегруженный логгер сообщения ниже порогового уровня не пишет в лог сразу, а сохраняет в очередь. Потом middleware принимает решение - показывать эти сообщения, или игнорировать. Логика такая: если нет признаков потенциального инцидента, то и все сообщения уровня Debug, или Info в рамках текущего запроса можно игнорировать. А если признаки есть, то не просто ошибку показываем, а выливаем в логи всё сохранённое, чтобы было проще разбираться.
Старлайнер тогда можно и сразу на Землю своим ходом отправить.
Я уже в целом писал чуть выше: https://habr.com/ru/news/823632/#comment_26964904. Вопрос в том, что никто толком не понимает, на сколько серьёзная проблема у Стралайнера. Может она не особо критичная и можно спокойно отправлять экипаж обратно на этом корабле, а не затевать дорогостоящую спасательную миссию. А может, будет как с Колумбией, когда посчитали проблему не критичной, подлатали на орбите, а шаттл посадку не выдержал.
Очень, очень надеюсь, что это так и за последние 10 лет действительно сделали очень большой скачок вперёд в деле спасения экипажей с орбитальных станций и кораблей. По крайней мере те же американцы после шаттлов стали прикручивать САС, или её аналоги почти везде. Так что тенденция однозначно положительная.
Но, к сожалению, в целом исторический опыт пока говорит немного обратное. 10 лет назад Virgin Galactic угробили одного из членов экипажа (второй чудом выжил), так как корабль не имел ничего похожего на САС. Собственно, сам по себе режим "спасательной шлюпки" появился только в Дрегонах, которые летают к МКС с 2020 года. До этого либо "родной" корабль, либо внеплановый запуск спасательной экспедиции с земли, причём наготове резервный корабль держали далеко не всегда. Да и сейчас при выходе на внепланово низкую орбиту корабля с повреждениями (с невозможностью вернуться, дотянуть до МКС, или продержаться на орбите больше нескольких дней) у экипажа шансов, по сути, нет.
Ну и запуск сыроватого старлайнера без явной готовой запаски это пока также, боюсь, что в целом подтверждает. Посмотрим, как оно будет и очень надеюсь, что инженеры примут верное решение, каким бы оно, по итогу, ни было.
По туристической могут в сроки не уложиться, но в целом - да, конечно. В любом случае, какой-то вариант наверняка можно найти. Вопрос, как обычно, в деньгах. И сейчас инженеры боинга и наса пытаются понять, на сколько большие проблемы у старлайнера и что выгоднее. На одной чаше весов риск гибели двух астронавтов и крупные репутационные потери как боинга, так и наса против успешного приземления и "у нас всё круто, мы просто заботились о безопасности экипажа". А на другой - стоимость спасательной операции (в любой форме) и гарантированные репутационные издержки (по сути, признание, что старлайнер ненадёжный корабль и мы зря запустили на нём людей).
Какое решение по итогу будет принято - никто из обитателей Хабра, думаю, пока не знает.
Там проблемы несколько сложнее, чем просто пересадить из корабля в корабль.
Во-первых, запасного корабля на станции просто нет. То есть если они улетят, допустим, на Crew dragon, или нашем Союзе, то уже его экипаж останется без корабля и придётся посылать за ними отдельный «пустой» рейс. А это, помимо денег, ещё и риски для остающихся на станции, так как до прилёта нового борта они останутся без возможности эвакуации.
Во-вторых, частичная несовместимость систем и разный опыт наработки на «чужой» аппаратуре. А это дополнительные риски при любых ЧП. Не знаю, как на эту тему у Crew dragon и Starliner, но скорее всего также.
В-третьих, банально, полётные скафандры и ложементы одного корабля не очень совместимы с другими. Это не критично в невесомости и при земной гравитации, но при посадочных 3-5 g запросто может превратиться в большую проблему.
В общем, понятно, что если совсем прижмёт, будут и такой вариант рассматривать, но пока есть надежда на реанимацию старлайнера, возврат на нём до последнего основным вариантом будет.
Так и IT, как индустрия, это тоже не только техногиганты. Мелкому магазинчику формата "у дома", какому-нибудь суши-бару, кофейне и т.д. тоже бывает нужно починить комп, проложить сетку, помочь с выбором роутера, склепать сайт, или выложить на него инфу... И они не пойдут за этим в условные "Гугл", "Яндекс" и "Сбер-технологии". И даже в мелкую IT-фирмочку, зачастую, не пойдут. И дорого и потребность в услугах очень редкая. А вот раз в несколько месяцев вызвать знакомого частного подрядчика с минимальной наценкой - запросто.
Про фриланс, как явление в IT, объяснять, думаю, не надо. И да, у топовых фрилансеров с доходами может быть всё очень хорошо, но есть ещё и не топовые. И даже далеко не топовые.
Люди в целом существа разные и живущие в разных условиях. Кому-то 200к в месяц "маловато будет", для кого-то это недосягаемый идеал и "вы там все зажрались", а кто-то получает 30к и ему вполне нормально. У кого-то дофига свободного времени, а кто-то не может себе позволить на пару-тройку месяцев бросить всё и проучиться на курсах. В общем, все ситуации немного разные.
А что вас смущает? IT - это не только сеньоры, не только разработчики и не только в Москве. Условный админ на аутсорсе в куче мелких фирмочек тоже IT-шник, даже если не читает Хабр, не оставляет свою з/п в калькуляторе карьеры и не умеет в программирование на (подставьте название любимого языка). И 200к в месяц для него могут быть о-о-очень хорошим доходом.
Вы забыли про ещё одну важную фичу Ĉ - автоматический учёт некоторых праздников и интеллектуальное изменение кода в соответствии с ними. Теперь компилятор сам 1-го апреля будет менять при компиляции в IL-код true на false, переставлять местами значения в enum-ах, а переменные окружения Development и Production начнут изменять своё значение в течение суток. Но последнее не точно, так как может потребовать изменений не только в языке, но и в самой платформе ;)
Скорее всего, это цена за газообразный объём. В Вики написано, что «продажная цена … составляет $825 за 5 литров, что в пересчёте на граммы означает приблизительно $1200 за грамм».
Разумеется, нет. Но тут не всё от работодателя зависит.
Если в одной компании з/п только на хлеб с маслом хватает, а в другой ещё и икорку сверху положить можно, то толковые спецы рано или поздно переберутся во вторую компанию, а первой достанутся те, кто послабее, и дальше она уже, возможно, и на маслице зарабатывать не сможет. Этот процесс может быть очень не быстрым, но вымывание кадров неизбежно произойдёт.
И дальше у первой компании варианты: либо тоже повышать зарплаты, либо готовиться через несколько лет закрывать бизнес.
Вопрос в том, какой процент этих вкатывальщиков дальше реально нормально работает.
В ВУЗах на ИТ-специальностях реально толковых ребят процентов 10-20. Ещё процентов 20-30 из категории «можно работать». Причём это из тех, кто дошёл до 3-4 курса. Отчисленных в начале не считаем. Если с ними, то упадёт ещё раза в полтора-два, причём это на специальностях с высоким проходным баллом.
На курсах «вкатывальщиков» многое зависит от самих курсов, конечно. Но в среднем у онлайн-курсов конверсия в 10% (это процент успешно закончивших) считается очень хорошей. Причём «закончил» не равен «успешно работаю». Да, человек получает возможность «зацепиться», но вот сможет ли он работать в хорошей компании с высокими зарплатами - вопрос. Тут у меня, к сожалению, реальной статистики нет, но из примерно десятка толковых новичков, с которыми приходилось работать последние 5 лет, я не знаю ни одного, кто сознался бы, что заканчивал такие курсы.
Поэтому да, курсы «вкатывальщиков» безусловно дают какой-то выхлоп, но я бы не стал рассчитывать на то, что оттуда прямо поток готовых специалистов течёт.
И да, перфокарты я в руках держал (хотя в работе уже и не использовал) ;)
Думаю, тут основная проблема в том, что ИИ сейчас (причём в очередной раз) идёт по классической кривой Гартнера.
Это когда при знакомстве с любой новой технологией наступает сперва "пик завышенных ожиданий" (особенно если технология достаточно активно продвигается) и все бегают со словами "сейчас мы перевернём мир".
Потом наступает "пропасть разочарования", когда люди технологии накушались, поняли, что она не во всех их реальных задачах (а не тех, что в пиарных демо) помогает и начинают её активно критиковать, попутно говоря, что она реально почти нигде не работает.
Ну а потом, если технология пережила "яму страданий", то она находит свою стабильную нишу и начинает использоваться уже как надо. Со своими классными зонами применения и областями, где "ну да, тут оно не работает".
ИИ сейчас, похоже, пока ещё не добрался до верхней точки пика, хотя критические статьи уже начинают потихоньку проскакивать. Проблемы у ИИ есть, и они реальны. Преодолимы ли они "с наскока", или нет - будущее покажет. Равно как верно и то, что до своего максимума ИИ технологии ещё тоже даже близко не добрались.
Здравствуйте, я многопоточное приложение на C# и у меня для вас плохие новости…
Понятно, что можно переключиться на потокобезопасные коллекции, но вот понимать, где надо, а где не надо их использовать в масштабе большого приложения - это уже уровень абстракции, пока ИИ не сильно доступный.
Ещё эту идею ещё можно расширить до "пойти и договориться с остальными точками-конкурентами, что они сложный ремонт будут не в Мск отправлять, а отдавать поближе, в такую навороченную ремонтную организацию за выигрыш по срокам и экономию на доставке". Но основных проблем/вопросов в любом случае будет минимум три: 1. Где взять деньги на начальное вложение? Это уже далеко не 500-700 т.р. на точку, как в статье, которые при желании найти можно и потеря которых будет печальна, но в большинстве случаев не критична. 2. Где найти нормальных спецов "на месте"? В статье явно упоминается, что у конкурентов попытки делать сложный ремонт были и они обычно портили. То есть конкретно в примере из статьи рынок спецов уже пропылесосили и те, кого нашли, явно делают фигню. 3. Окупится ли рынок "сложного" ремонта на масштабах конкретно данного города? Тут надо садиться и считать. У меня такой статистики точно нет. Частично она есть у того, кто уже попробовал в упрощенную модель бизнеса и может адекватно оценить и процент сложных ремонтов и перспективы с учётом возможных договоров с конкурентами и т.д..
Но там ещё интереснее. Полез сейчас в оригинальную статью. Там есть вот такое: "Мы провели анализ на основе 661 анкеты. Из них основную часть (69%) составили наемные сотрудники. В их числе более трети респондентов (33%) работают в крупных компаниях. Бо́льшая часть опрошенных из числа наемных сотрудников (60%) работает в IT. Остальные — представители других отраслей, включая финансы, промышленность, науку, образование и государственный сектор."
Если вкратце, то лучше, конечно, такое исследование, чем никакого, но в целом с выборкой и ошибками у исследования могут быть довольно существенные проблемы, особенно там, где ответы начинают дробить на колонки. Там на глаз погрешность выборки процентов в 10-15 вылезает только в путь.
Так что как "общая мысль", "видим тенденцию" и "есть предположение..." вполне сойдёт, но вот для количественных оценок объём выборки выглядит откровенно маленьким. Это, кстати, не претензия к авторам исследования (собрать и обработать 650+ анкет труд не малый), скорее как предостережение тем, кто попробует на основании этих данных делать какие-либо выводы.
Не совсем. Там указано, что большинство опрошенных владельцев компаний считают, что они работают с проектами с открытым кодом. При этом степень работы может быть разная.
Например, в фирме на 100 человек 10 проектов и один из них вполне официально, с разрешения руководства и под его базовым контролем (выбор лицензии, решение, что можем коммитать, а что нет) делается как опенсорс. Итог: в этой фирме примерно 10% разработчиков и 100% руководителей могут сказать, что они работают с проектами с открытым кодом.
Про директоров-технарей тоже, кстати, зря. В небольших фирмах на пол сотню человек, а то и выше ген директор запросто может быть «играющим».
TIOBE строит индекс популярности, основываясь на запросах в гугл, данных о языках в проектах в популярных репозиториях и т.д. Поэтому, если предельно огрубляя, в университете Х студентам задали сделать лабораторку по Go, они задали 100500 запросов вида "как сложить элементы массива в Go" а потом создали в github 100500 проектов на Go из 1 файла. К реальной популярности в профессиональной среде это имеет весьма опосредованное отношение, но в следующем году Go поднимется ещё на одну ступеньку рейтинга.
Для понимания: Дельфи+Паскаль в top-10 по индексу TIOBE уверенно входил ещё лет 5 назад, да и сейчас на 12-м месте.
Поэтому, да, TIOBE явно не особо объективен с точки зрения профессиональной среды, но с полностью объективными статистиками, увы, тяжело.
Спасибо за мысли! У нас эти советы не все применимы из-за специфики (stateless, api), но похожую идею, только, наоборот, с выключением логов для конкретного пользователя тоже реализовывали. Были случаи, когда клиенты начинали упорно долбить запросами при закончившемся ключе, организовывая мини-DDOS с "белых" IP, и надо было их либо вручную под протоколы обработки DDOS подводить, хотя всё стабильно работало, либо минимизировать число записей в логах.
По сути, да, это кэш.
Про один шаг немного не понял. В очередь пишутся все записи с момента старта работы над запросом и до момента его окончания. Иначе никак - мы не знаем, в какой момент может произойти событие-триггер.
При этом все ошибки уровня выше Info логируются незамедлительно, как и положено, специально, чтобы избежать проблемы с "всё упало, а логи не записались". И дополнительно пишутся в кэш, чтобы можно было их потом разобрать вместе с остальными.
Основные операции, типа добавления в очередь и поднятия уровня логов, сделаны потокобезопасными. При этом, да, если вызвать ToString в неправильном месте, можно словить эффекты с синхронизацией, но ими я сознательно пренебрёг в угоду скорости.
Алгоритм работы получается следующим: перегруженный логгер сообщения ниже порогового уровня не пишет в лог сразу, а сохраняет в очередь. Потом middleware принимает решение - показывать эти сообщения, или игнорировать.
Логика такая: если нет признаков потенциального инцидента, то и все сообщения уровня Debug, или Info в рамках текущего запроса можно игнорировать. А если признаки есть, то не просто ошибку показываем, а выливаем в логи всё сохранённое, чтобы было проще разбираться.
На рабочих компах могут быть ограничения на установку стороннего ПО, а чуть-чуть поправить картинку надо.
В целом для задачи «раз в 2 года надо иконку примитивную сделать» спец приложения не особо нужны.
Есть даже комиксы, которые авторы целенаправленно в паинте рисуют. Мотивацию не спрашивайте, просто констатирую.
Старлайнер тогда можно и сразу на Землю своим ходом отправить.
Я уже в целом писал чуть выше: https://habr.com/ru/news/823632/#comment_26964904. Вопрос в том, что никто толком не понимает, на сколько серьёзная проблема у Стралайнера. Может она не особо критичная и можно спокойно отправлять экипаж обратно на этом корабле, а не затевать дорогостоящую спасательную миссию. А может, будет как с Колумбией, когда посчитали проблему не критичной, подлатали на орбите, а шаттл посадку не выдержал.
Очень, очень надеюсь, что это так и за последние 10 лет действительно сделали очень большой скачок вперёд в деле спасения экипажей с орбитальных станций и кораблей. По крайней мере те же американцы после шаттлов стали прикручивать САС, или её аналоги почти везде. Так что тенденция однозначно положительная.
Но, к сожалению, в целом исторический опыт пока говорит немного обратное. 10 лет назад Virgin Galactic угробили одного из членов экипажа (второй чудом выжил), так как корабль не имел ничего похожего на САС. Собственно, сам по себе режим "спасательной шлюпки" появился только в Дрегонах, которые летают к МКС с 2020 года. До этого либо "родной" корабль, либо внеплановый запуск спасательной экспедиции с земли, причём наготове резервный корабль держали далеко не всегда. Да и сейчас при выходе на внепланово низкую орбиту корабля с повреждениями (с невозможностью вернуться, дотянуть до МКС, или продержаться на орбите больше нескольких дней) у экипажа шансов, по сути, нет.
Ну и запуск сыроватого старлайнера без явной готовой запаски это пока также, боюсь, что в целом подтверждает. Посмотрим, как оно будет и очень надеюсь, что инженеры примут верное решение, каким бы оно, по итогу, ни было.
По туристической могут в сроки не уложиться, но в целом - да, конечно. В любом случае, какой-то вариант наверняка можно найти. Вопрос, как обычно, в деньгах. И сейчас инженеры боинга и наса пытаются понять, на сколько большие проблемы у старлайнера и что выгоднее. На одной чаше весов риск гибели двух астронавтов и крупные репутационные потери как боинга, так и наса против успешного приземления и "у нас всё круто, мы просто заботились о безопасности экипажа". А на другой - стоимость спасательной операции (в любой форме) и гарантированные репутационные издержки (по сути, признание, что старлайнер ненадёжный корабль и мы зря запустили на нём людей).
Какое решение по итогу будет принято - никто из обитателей Хабра, думаю, пока не знает.
Там проблемы несколько сложнее, чем просто пересадить из корабля в корабль.
Во-первых, запасного корабля на станции просто нет. То есть если они улетят, допустим, на Crew dragon, или нашем Союзе, то уже его экипаж останется без корабля и придётся посылать за ними отдельный «пустой» рейс. А это, помимо денег, ещё и риски для остающихся на станции, так как до прилёта нового борта они останутся без возможности эвакуации.
Во-вторых, частичная несовместимость систем и разный опыт наработки на «чужой» аппаратуре. А это дополнительные риски при любых ЧП. Не знаю, как на эту тему у Crew dragon и Starliner, но скорее всего также.
В-третьих, банально, полётные скафандры и ложементы одного корабля не очень совместимы с другими. Это не критично в невесомости и при земной гравитации, но при посадочных 3-5 g запросто может превратиться в большую проблему.
В общем, понятно, что если совсем прижмёт, будут и такой вариант рассматривать, но пока есть надежда на реанимацию старлайнера, возврат на нём до последнего основным вариантом будет.
Так и IT, как индустрия, это тоже не только техногиганты. Мелкому магазинчику формата "у дома", какому-нибудь суши-бару, кофейне и т.д. тоже бывает нужно починить комп, проложить сетку, помочь с выбором роутера, склепать сайт, или выложить на него инфу... И они не пойдут за этим в условные "Гугл", "Яндекс" и "Сбер-технологии". И даже в мелкую IT-фирмочку, зачастую, не пойдут. И дорого и потребность в услугах очень редкая. А вот раз в несколько месяцев вызвать знакомого частного подрядчика с минимальной наценкой - запросто.
Про фриланс, как явление в IT, объяснять, думаю, не надо. И да, у топовых фрилансеров с доходами может быть всё очень хорошо, но есть ещё и не топовые. И даже далеко не топовые.
Люди в целом существа разные и живущие в разных условиях. Кому-то 200к в месяц "маловато будет", для кого-то это недосягаемый идеал и "вы там все зажрались", а кто-то получает 30к и ему вполне нормально. У кого-то дофига свободного времени, а кто-то не может себе позволить на пару-тройку месяцев бросить всё и проучиться на курсах. В общем, все ситуации немного разные.
А что вас смущает? IT - это не только сеньоры, не только разработчики и не только в Москве. Условный админ на аутсорсе в куче мелких фирмочек тоже IT-шник, даже если не читает Хабр, не оставляет свою з/п в калькуляторе карьеры и не умеет в программирование на (подставьте название любимого языка). И 200к в месяц для него могут быть о-о-очень хорошим доходом.
Вы забыли про ещё одну важную фичу Ĉ - автоматический учёт некоторых праздников и интеллектуальное изменение кода в соответствии с ними. Теперь компилятор сам 1-го апреля будет менять при компиляции в IL-код true на false, переставлять местами значения в enum-ах, а переменные окружения Development и Production начнут изменять своё значение в течение суток. Но последнее не точно, так как может потребовать изменений не только в языке, но и в самой платформе ;)
Скорее всего, это цена за газообразный объём. В Вики написано, что «продажная цена … составляет $825 за 5 литров, что в пересчёте на граммы означает приблизительно $1200 за грамм».
А это уже немного другие порядки.
Разумеется, нет. Но тут не всё от работодателя зависит.
Если в одной компании з/п только на хлеб с маслом хватает, а в другой ещё и икорку сверху положить можно, то толковые спецы рано или поздно переберутся во вторую компанию, а первой достанутся те, кто послабее, и дальше она уже, возможно, и на маслице зарабатывать не сможет. Этот процесс может быть очень не быстрым, но вымывание кадров неизбежно произойдёт.
И дальше у первой компании варианты: либо тоже повышать зарплаты, либо готовиться через несколько лет закрывать бизнес.
Вопрос в том, какой процент этих вкатывальщиков дальше реально нормально работает.
В ВУЗах на ИТ-специальностях реально толковых ребят процентов 10-20. Ещё процентов 20-30 из категории «можно работать». Причём это из тех, кто дошёл до 3-4 курса. Отчисленных в начале не считаем. Если с ними, то упадёт ещё раза в полтора-два, причём это на специальностях с высоким проходным баллом.
На курсах «вкатывальщиков» многое зависит от самих курсов, конечно. Но в среднем у онлайн-курсов конверсия в 10% (это процент успешно закончивших) считается очень хорошей. Причём «закончил» не равен «успешно работаю». Да, человек получает возможность «зацепиться», но вот сможет ли он работать в хорошей компании с высокими зарплатами - вопрос. Тут у меня, к сожалению, реальной статистики нет, но из примерно десятка толковых новичков, с которыми приходилось работать последние 5 лет, я не знаю ни одного, кто сознался бы, что заканчивал такие курсы.
Поэтому да, курсы «вкатывальщиков» безусловно дают какой-то выхлоп, но я бы не стал рассчитывать на то, что оттуда прямо поток готовых специалистов течёт.
И да, перфокарты я в руках держал (хотя в работе уже и не использовал) ;)
Думаю, тут основная проблема в том, что ИИ сейчас (причём в очередной раз) идёт по классической кривой Гартнера.
Это когда при знакомстве с любой новой технологией наступает сперва "пик завышенных ожиданий" (особенно если технология достаточно активно продвигается) и все бегают со словами "сейчас мы перевернём мир".
Потом наступает "пропасть разочарования", когда люди технологии накушались, поняли, что она не во всех их реальных задачах (а не тех, что в пиарных демо) помогает и начинают её активно критиковать, попутно говоря, что она реально почти нигде не работает.
Ну а потом, если технология пережила "яму страданий", то она находит свою стабильную нишу и начинает использоваться уже как надо. Со своими классными зонами применения и областями, где "ну да, тут оно не работает".
ИИ сейчас, похоже, пока ещё не добрался до верхней точки пика, хотя критические статьи уже начинают потихоньку проскакивать. Проблемы у ИИ есть, и они реальны. Преодолимы ли они "с наскока", или нет - будущее покажет. Равно как верно и то, что до своего максимума ИИ технологии ещё тоже даже близко не добрались.
Здравствуйте, я многопоточное приложение на C# и у меня для вас плохие новости…
Понятно, что можно переключиться на потокобезопасные коллекции, но вот понимать, где надо, а где не надо их использовать в масштабе большого приложения - это уже уровень абстракции, пока ИИ не сильно доступный.
Ещё эту идею ещё можно расширить до "пойти и договориться с остальными точками-конкурентами, что они сложный ремонт будут не в Мск отправлять, а отдавать поближе, в такую навороченную ремонтную организацию за выигрыш по срокам и экономию на доставке". Но основных проблем/вопросов в любом случае будет минимум три:
1. Где взять деньги на начальное вложение? Это уже далеко не 500-700 т.р. на точку, как в статье, которые при желании найти можно и потеря которых будет печальна, но в большинстве случаев не критична.
2. Где найти нормальных спецов "на месте"? В статье явно упоминается, что у конкурентов попытки делать сложный ремонт были и они обычно портили. То есть конкретно в примере из статьи рынок спецов уже пропылесосили и те, кого нашли, явно делают фигню.
3. Окупится ли рынок "сложного" ремонта на масштабах конкретно данного города? Тут надо садиться и считать. У меня такой статистики точно нет. Частично она есть у того, кто уже попробовал в упрощенную модель бизнеса и может адекватно оценить и процент сложных ремонтов и перспективы с учётом возможных договоров с конкурентами и т.д..
И это тоже может быть, кстати.
Но там ещё интереснее. Полез сейчас в оригинальную статью. Там есть вот такое: "Мы провели анализ на основе 661 анкеты. Из них основную часть (69%) составили наемные сотрудники. В их числе более трети респондентов (33%) работают в крупных компаниях. Бо́льшая часть опрошенных из числа наемных сотрудников (60%) работает в IT. Остальные — представители других отраслей, включая финансы, промышленность, науку, образование и государственный сектор."
Если вкратце, то лучше, конечно, такое исследование, чем никакого, но в целом с выборкой и ошибками у исследования могут быть довольно существенные проблемы, особенно там, где ответы начинают дробить на колонки. Там на глаз погрешность выборки процентов в 10-15 вылезает только в путь.
Так что как "общая мысль", "видим тенденцию" и "есть предположение..." вполне сойдёт, но вот для количественных оценок объём выборки выглядит откровенно маленьким. Это, кстати, не претензия к авторам исследования (собрать и обработать 650+ анкет труд не малый), скорее как предостережение тем, кто попробует на основании этих данных делать какие-либо выводы.
Не совсем. Там указано, что большинство опрошенных владельцев компаний считают, что они работают с проектами с открытым кодом. При этом степень работы может быть разная.
Например, в фирме на 100 человек 10 проектов и один из них вполне официально, с разрешения руководства и под его базовым контролем (выбор лицензии, решение, что можем коммитать, а что нет) делается как опенсорс. Итог: в этой фирме примерно 10% разработчиков и 100% руководителей могут сказать, что они работают с проектами с открытым кодом.
Про директоров-технарей тоже, кстати, зря. В небольших фирмах на пол сотню человек, а то и выше ген директор запросто может быть «играющим».
TIOBE строит индекс популярности, основываясь на запросах в гугл, данных о языках в проектах в популярных репозиториях и т.д. Поэтому, если предельно огрубляя, в университете Х студентам задали сделать лабораторку по Go, они задали 100500 запросов вида "как сложить элементы массива в Go" а потом создали в github 100500 проектов на Go из 1 файла. К реальной популярности в профессиональной среде это имеет весьма опосредованное отношение, но в следующем году Go поднимется ещё на одну ступеньку рейтинга.
Для понимания: Дельфи+Паскаль в top-10 по индексу TIOBE уверенно входил ещё лет 5 назад, да и сейчас на 12-м месте.
Поэтому, да, TIOBE явно не особо объективен с точки зрения профессиональной среды, но с полностью объективными статистиками, увы, тяжело.