>И кстати говоря, такие же решения просто бесят в МойОфис и Р7/OnlyOffice, где нет полноценной работы с документами извне
Это не "костыль", а решение проблемы за счет реализации того, чего в принципе нет в OpenOffice-пакетах. Microsoft потому все и любят, что они сделали чудо, на которое другие вовсе не способны.
А зачем вообще привязываться к конкретным офисным пакетам? Если библиотека позволяет сделать так, чтобы документ был отредактирован таким образом, что его корректное отображение будет в большинстве редакторов (в том числе в МойОфис, ОпенОфисе итд) - это же лучше.
Интересует как вы пытались использовать продукт для тестирования ваших плагинов, поделитесь, очень интересно!
Примерно с осени 2024 года, почти сразу с "запретом на покупку из России", Rider "внезапно" стал доступен в режиме Community, что позволяет с удобством разрабатывать на C# под любой отечественной ОС.
Те, для кого он перегружен - вполне довольны VS Code, который так же везде очень хорошо работает.
Можете поделиться чем вас не устраивают данные IDE?
Прекрасно совмещается с импортозамещением. Не совмещается только устаревший .NET Framework, а вот нормальный .NET Core вполне себе внедряется во всю.
Прелесть .NET в том, что он с открытым исходным кодом и для нужного спокойствия можно даже собрать его из исходников, хотя по факту всех ИБ-шников с кем лично мне приходилось взаимодействовать это не беспокоило, брали все из наших поставок.
Единственное, что обычно беспокоит ИБшников - поддержка последних версий. То етсь устаревший .NET 5 уже правда не вкатить, да и .NET 7 уже вышел из поддержки. Поэтому требуют LTS-ные версии 6 или 8. Это немного усложняет жизнь, так как приходится постоянно обновлять версию фреймворка и тратить ресурсы на обеспечение совместимости с новыми пакетами, но это так, житейские проблемы.
Местами встречаются инциденты, когда не хотят ставить отдельно .NET Runtime, но в этом плане хорошо спасает возможность собрать автономную сборку, когда все нужные системные библиотеки встраиваются в релизную сборку. Тогда продуктами можно пользоваться на компьютерах пользователей как нативные без доустановки .NET.
Тем не менее, как мне кажется, вариант по-умолчанию будет основным и в целом он хорош для не совсем опытных пользователей. Но этот метод буду советовать всем старичкам
По началу я тоже обрадовался, прочитав такую возможность, но загвоздка заключается в этой фразе:
after the Blazor bundle is downloaded
То есть скачивание рантайма все-равно происходит, а в условиях плохой сети и дорогого трафика это не очень интересно. Хотелось бы именно работы в браузере какого-то скомпилированного JS из C# без рантаймов.
Но, конечно, в тех условиях, когда сеть и трафик позволяют, стоит использовать этот режим.
Чтобы наше приложение было доступно извне по доменному имени или IP адресу, нужно использовать обратный прокси.
На самом деле уже нет. Могу путать версию, но толи с 6, толи с 7 версии ASP.NET появилась возможность настраивать HTTPS протокол с сертификатом непосредственно в Kestrel (через appsetting.json). Пример такой настройки:
Но, конечно, Kestrel не дает всего разнообразия настроек веб-серверов как Apache2/httpd и Nginx, тем не менее, для стартовых небольших проектов вполне себе рабочая история
Для государственных учреждений - вполне себе нормальный перечень требований. Когда я начинал свою карьеру в 2009 году в качестве техника в одном ГосНИИ, это был минимальный набор, который надо было знать и уметь делать. И как студент-отличник третьего курса университета - я вполне себе это все умел делать.
Когда я после ГосНИИ перешел в конце 2012 в коммерческую организацию - очень долго не понимал как это порой берут джунов без этой всей базы, а получают они больше. чем я раньше получал в НИИ. Но, к сожалению вот такая вот у нас практика.
Поэтому многие толковые, талантливые ребята уходят из НИИ так же, как в свое время ушел я - на зарплату x3 и требования / 4 (делить на четыре)
Пошел перепрочел несколько источников по терминологии, во многих упоминается в том числе то, что:
Задача специалиста — создать продукт, который удовлетворит потребности пользователей и принесёт компании прибыль.
То есть не отменяя то, что есть задача принести финансовые результаты своей компании, все же закрыть потребности заказчиков тоже нужно.
В целом мне вообще трудно представить как эти две стороны можно отделить друг от друга - как в прицнипе возможно принести прибыль продуктом, если он не приносит ценности конечным заказчикам? Кто же будет платить деньги за такой продукт. Возможно, в каких-то сферах такое возможно, но, по крайней мере в B2B я о таком не слышал никогда.
А вот прочитав концепцию DM вполне себе вижу применимость на своей же практике - не всегда с точки зрения продукта мне как менеджеру продукта стоит "ломать его" ради удовлетворения одного (пусть очень дорогого) заказчика. Другой вопрос, что его хотелки можно удовлетворить альтернативными методами. Например, в том числе в своем продукте для него сделать кастомный модуль именно для этого заказчика (и тех, кто захочет такой же модуль), но чтобы 100 других заказчиков не почувствовали на себе изменений и продолжили счастливую жизнь без этого кастома.
Во время прочтения всей статьи не мог поверить своим глазам - читаю практически про себя. А я работаю менеджером продукта, но не только в стратегии, а и в том, что перечислено в этой статье (так же забочусь о команде, помогая в этом владельцу продукта).
Добавил:
Почитал быстро статейки в "западных интернетах" и увидел, что в целом роли пересекающиеся, но все же Product Manager - чуть шире (что так же соответствует моей работе).
Грубо говоря, Delivery Manger отвечает за конкретную поставку конкретному заказчику (или пулу похожих заказчиков), а Product Manager отвечает за поставку всему разнообразию заказчиков и решает конфликты приоритетов и пожеланий. Понравилось описание, что Product отвечает за "портфель поставок".
То есть в целом корректно, что я "распознал" себя. Меня можно, получается, и Delivery, и Product менеджером звать.
Спасибо больше за ностальгическую статью. Я один из тех извращенцев, которые одинаково любят и тройку и четверку. В свое время четверка стала действительно глотком свежего воздуха после уже слегка поднадоевшей тройки.
Мне очень нравился этот сказочный стиль - та самая нотка, которую создатели игры потеряли при переходе со второй части на третью (во второй как раз тоже была подобная "сказка" и когда появилась тройка, помню мы с братом долго плевались на то, что она "слишком серьезная"). Ну а музыка - просто наслаждение, до сих пор в плейлисте для расслабления стоит.
И да, эта фишка с отдельно перемещающимися существами - мне очень зашла, тем более что играя еще в двойку и тройку я постоянно задавался вопросом "Почему существа не могут ходить отдельно от героя?". Понятно со всякими орками и нежитью - хорошо, они.неорганизованные, но с представителями Замка и Оплота - казалось, что они должны быть дружными и иметь возможность жить и действовать без лидера.
А еще больше мне зашло то, что в один отряд можно было поставить нескольких героев - вот это вообще была пушка-бомба! Учитывая то, что как раз перед четверкой я играл активно в Might & Magic 8, где ходил тоже отрядом героев, я прям представлял себе схожие истории, только уже в стратегическом режиме от третьего лица. Я тогда очень сильно заботился о каждом персонаже, продумывал его персональное развитие и это мне очень сильно нравилось, выделяя игру перед тройкой.
Ну, раз просите подводные камни, то... Заваривайте чаек, присаживайтесь на топчан и слушайте :-)
Проблема №1 - "Питон программисты" Питон программистов много, это факт... Но в разрезе программирования RPA-решений картина выглядит довольно печально. Прям профи-профи в этой сфере не так то много, а те, кто не супер-профи, с высокой долей вероятности пишут в разных стилях и применяют разные подходы. Как итог - наняв нового программиста вы получите целое приключение с его адаптацией (или через месяц обнаружите, что старые программисты не могут поддерживать робота от новичка)
Проблема №2 - "ОпенСорс" Любимая мантра всех опенсорсников - "Это октрытый код, ты сам как программист можешь исправить ошибку, никакого вендорлока. А еще ты уверен, что нет никаких дыр, так как сообщество ух как старается". По факту эти розовые очки разбиваются о то, что именно те проблемы, которые получите вы - никто другой не встретит (или их это не будет волновать как вас). При попытке залезть в исходный код опенсорса вы потратите кучу времени и сил, и с высокой долей вероятнсти даже если получится устранить баг - можно сгенерировать себе новые.
Как обратная ситуация - злоумышленники могут проанализировать опенсорс решения, которые вы используете, найти в нем дыры и воспользовавшись ими получить несанкционированный доступ к памяти ваших роботов, отправив все самы важные циферки из важных документиков в недружественные страны
Проблема №3 - "Масштабирование эксплуатации" Действительно, на планке примрено до 10 роботов - играться в простенькие решения, которые написаны самостоятельно, это прикольно. Но как только у вас начинается опыт с десятком роботов, которые работают на десятках машин под парой десятков учетных записей... Контролировать этот "Зоопарк" теми же опен сорс средствами становится крайне проблематично. Легко упустить ошибки в работе одного конкретного робота на одной конкретной учетке, легко упустить то, что расписания запуска перестали работать и так далее.
В целом можно еще ворох проблем дать вам, но, по классике остановимся на раз-два-три.
В заключении хочется донести простую мысль - Отдавая деньги вендору за лицензии вы в первую очередь покупаете свое время, которое не потратите на решение очень многих сложных проблем. За вас их уже либо решили, либо помогут решить, когда окажется, что эта проблема касается только вас.
Обычно я и мои партнеры использовали 2-4 ядра и 4-8 гб оперативки, и особых проблем не испытывали.
Здесь в гайде не перечислен один дистрибутив, который мы так же ставили, но он вызвал проблемы - Ubuntu. Судя по всему, с ней что-то не так, потому что ее оболочки (что через установку ubuntu-desktop, что через установку gnome) тормозят и ведут себя именно так, как вы написали.
Если у вас проблемы с дистрибутивами, которые перечислены выше - скорее всего проблема где-то на уровне качества Интернет-соединения. Можно для контроля попробовать подключиться с заниженным разрешением экрана и цветностью, как правило это решает проблему плохой связи.
Цель данной публикации - сделать централизованный единый хороший гайд.
У каждого человека свое представление о прекрасном, и лично в моем представлении хороший гайд должен содержать всю информацию, достаточную для достижения вполне конкретной поставленной цели без отсылания человека на прочтение информации на других ресурсах по ссылкам.
Собственно говоря, точно таким же способом как и вы, я мог ограничить гайд просто ссылками на вики всех дистрибутивов, но... Тогда это был бы не гайд, его нельзя было бы распечатать и идти по нему гарантировано достигнув цели.
И самоцели обеспечить безопасность в создании виртуального рабочего места под короткие задачи - у меня не было. Но если вы составите такой гайд, который будет универсален и без ссылок, я обязательно его присоединю. Если вам это не интересно - честно, мне тоже. Предлагаю дальше не тратить наше общее время на демагогию
Да, про "Tunneling RDP over SSH" не случилось по той причине, что в кейсах, где этот гайд применяли - он был не нужен. Инцидентов взлома зафиксировано не было.
Как указал в самой статье - если у вас есть компетенции и навыки настройки под разные дистрибутивы "с нуля" - поделитесь, обязательно добавлю в статью с упоминанием вашего профиля.
Что касается MATE - тот образ, который используется в Яндекс.Облаке, не дал мне возможности установить эту оболочку "из коробки" без добавления дополнительных репозиториев. А KDE дал. Именно поэтому в статье написал именно так, как вы процитировали.
Не называть это VDI - ваше право, не буду спорить. То, что есть специалисты, которые используют такие стенды на регулярной основе с долговременным хранением там данных - моя реальная практика, в смысле из того что наблюдал "за спиной" у других.
Правильно ли это или вредно и плохо? Отдельный вопрос для хорошего холивара, участвовать в котором не вижу большого смысла.
Что-то странное. У меня ни на винде, ни стандартная сборка для линукса не глючат и работают прекрасно. Можете поделиться историями где что у вас не работало, чтобы я мог подготовиться?
Если что, я использую Криптопро в сочетании с руТокеном в основном для входа и работы с ФНС, реже подписываю файлы.
Где все эти освободившиеся после ухода зарубежных компаний крутые специалисты, про обилие которых тут только самое ленивое эйчар-агентство не тиснуло статью, не особо понятно…
Надо понимать две вещи:
1) Не все специалисты, работавшие в западных компаниях - высококлассные. Порой даже в каких-нибудь "задрипанных" НИИ с ЗП 20к в месяц специалисты сильнее, чем в ушедших компаниях.
2) Действительно сильные специалисты, как правило, мало ищут работу "в открытую". У них есть своя база знакомых в разных других хороших компаниях и их буквально приглашают лично на очень хорошие ставки. То есть вероятность того, что на вашу вакансию сам собой откликнется действительно классный спец из ушедшей из России компании - стремиться к нулю.
В целом статья - это хорошая шпаргалка начинающему управленцу, но вот заголовок и вступление, конечно, слишком кликбейтные и не совсем перекликаются с тем, что оставляет статья после прочтения.
Наверное, статью будет приятно почитать обычным программистам, дизайнерам и прочим ребятам, кто занимается непосредственно "ручной работой" в разработке и не занимал руководящих должностей хотя бы уровня тим-лида продолжительное время.
Если же читать эту статью с точки зрения человека, кто так или иначе руководит командами несколько лет, то она читается примерно так (переводя на язык программистов):
Надо в коде писать комментарии. Если однажды начать их писать не так хорошо, то в результате на них забьют. И будет бардак в коде
Надо пользоваться системами контроля версий с gitflow. Если все вести в одной ветке - это плохо.
Ну и так далее (я конечно утрирую, но все же).
Искренне желаю каждому обычному разработчику побывать в шкуре управленца - это очень сильно меняет мировоззрение и подход к разработке как таковой. Даже если окажется, что "управление - не мое" (среди моих знакомых примерно 90% ушло из управления примерно такой фразой), то вернувшись к бытью обычным разработчиком качественно поменяется подход к задачам, их оценке и ответственность за исполнение. Ну а эта статья, как уже написал выше - довольно неплохо показывает слабые места, с которыми все так или иначе встречаются.
Да, но... В Notepad++ "спрятанные" символы видно очень бытсро. Соответственно всякие DLP будут находить подобные утечки
Вы сами дали себе ответ:
>И кстати говоря, такие же решения просто бесят в МойОфис и Р7/OnlyOffice, где нет полноценной работы с документами извне
Это не "костыль", а решение проблемы за счет реализации того, чего в принципе нет в OpenOffice-пакетах. Microsoft потому все и любят, что они сделали чудо, на которое другие вовсе не способны.
А зачем вообще привязываться к конкретным офисным пакетам? Если библиотека позволяет сделать так, чтобы документ был отредактирован таким образом, что его корректное отображение будет в большинстве редакторов (в том числе в МойОфис, ОпенОфисе итд) - это же лучше.
Интересует как вы пытались использовать продукт для тестирования ваших плагинов, поделитесь, очень интересно!
Примерно с осени 2024 года, почти сразу с "запретом на покупку из России", Rider "внезапно" стал доступен в режиме Community, что позволяет с удобством разрабатывать на C# под любой отечественной ОС.
Те, для кого он перегружен - вполне довольны VS Code, который так же везде очень хорошо работает.
Можете поделиться чем вас не устраивают данные IDE?
Прекрасно совмещается с импортозамещением. Не совмещается только устаревший .NET Framework, а вот нормальный .NET Core вполне себе внедряется во всю.
Прелесть .NET в том, что он с открытым исходным кодом и для нужного спокойствия можно даже собрать его из исходников, хотя по факту всех ИБ-шников с кем лично мне приходилось взаимодействовать это не беспокоило, брали все из наших поставок.
Единственное, что обычно беспокоит ИБшников - поддержка последних версий. То етсь устаревший .NET 5 уже правда не вкатить, да и .NET 7 уже вышел из поддержки. Поэтому требуют LTS-ные версии 6 или 8. Это немного усложняет жизнь, так как приходится постоянно обновлять версию фреймворка и тратить ресурсы на обеспечение совместимости с новыми пакетами, но это так, житейские проблемы.
Местами встречаются инциденты, когда не хотят ставить отдельно .NET Runtime, но в этом плане хорошо спасает возможность собрать автономную сборку, когда все нужные системные библиотеки встраиваются в релизную сборку. Тогда продуктами можно пользоваться на компьютерах пользователей как нативные без доустановки .NET.
Интересно, не заметил, спасибо.
Тем не менее, как мне кажется, вариант по-умолчанию будет основным и в целом он хорош для не совсем опытных пользователей. Но этот метод буду советовать всем старичкам
По началу я тоже обрадовался, прочитав такую возможность, но загвоздка заключается в этой фразе:
То есть скачивание рантайма все-равно происходит, а в условиях плохой сети и дорогого трафика это не очень интересно. Хотелось бы именно работы в браузере какого-то скомпилированного JS из C# без рантаймов.
Но, конечно, в тех условиях, когда сеть и трафик позволяют, стоит использовать этот режим.
На самом деле уже нет. Могу путать версию, но толи с 6, толи с 7 версии ASP.NET появилась возможность настраивать HTTPS протокол с сертификатом непосредственно в Kestrel (через appsetting.json). Пример такой настройки:
Но, конечно, Kestrel не дает всего разнообразия настроек веб-серверов как Apache2/httpd и Nginx, тем не менее, для стартовых небольших проектов вполне себе рабочая история
Для государственных учреждений - вполне себе нормальный перечень требований. Когда я начинал свою карьеру в 2009 году в качестве техника в одном ГосНИИ, это был минимальный набор, который надо было знать и уметь делать. И как студент-отличник третьего курса университета - я вполне себе это все умел делать.
Когда я после ГосНИИ перешел в конце 2012 в коммерческую организацию - очень долго не понимал как это порой берут джунов без этой всей базы, а получают они больше. чем я раньше получал в НИИ. Но, к сожалению вот такая вот у нас практика.
Поэтому многие толковые, талантливые ребята уходят из НИИ так же, как в свое время ушел я - на зарплату x3 и требования / 4 (делить на четыре)
Пошел перепрочел несколько источников по терминологии, во многих упоминается в том числе то, что:
То есть не отменяя то, что есть задача принести финансовые результаты своей компании, все же закрыть потребности заказчиков тоже нужно.
В целом мне вообще трудно представить как эти две стороны можно отделить друг от друга - как в прицнипе возможно принести прибыль продуктом, если он не приносит ценности конечным заказчикам? Кто же будет платить деньги за такой продукт. Возможно, в каких-то сферах такое возможно, но, по крайней мере в B2B я о таком не слышал никогда.
А вот прочитав концепцию DM вполне себе вижу применимость на своей же практике - не всегда с точки зрения продукта мне как менеджеру продукта стоит "ломать его" ради удовлетворения одного (пусть очень дорогого) заказчика. Другой вопрос, что его хотелки можно удовлетворить альтернативными методами. Например, в том числе в своем продукте для него сделать кастомный модуль именно для этого заказчика (и тех, кто захочет такой же модуль), но чтобы 100 других заказчиков не почувствовали на себе изменений и продолжили счастливую жизнь без этого кастома.
Во время прочтения всей статьи не мог поверить своим глазам - читаю практически про себя. А я работаю менеджером продукта, но не только в стратегии, а и в том, что перечислено в этой статье (так же забочусь о команде, помогая в этом владельцу продукта).
Добавил:
Почитал быстро статейки в "западных интернетах" и увидел, что в целом роли пересекающиеся, но все же Product Manager - чуть шире (что так же соответствует моей работе).
Грубо говоря, Delivery Manger отвечает за конкретную поставку конкретному заказчику (или пулу похожих заказчиков), а Product Manager отвечает за поставку всему разнообразию заказчиков и решает конфликты приоритетов и пожеланий. Понравилось описание, что Product отвечает за "портфель поставок".
То есть в целом корректно, что я "распознал" себя. Меня можно, получается, и Delivery, и Product менеджером звать.
Спасибо больше за ностальгическую статью. Я один из тех извращенцев, которые одинаково любят и тройку и четверку. В свое время четверка стала действительно глотком свежего воздуха после уже слегка поднадоевшей тройки.
Мне очень нравился этот сказочный стиль - та самая нотка, которую создатели игры потеряли при переходе со второй части на третью (во второй как раз тоже была подобная "сказка" и когда появилась тройка, помню мы с братом долго плевались на то, что она "слишком серьезная"). Ну а музыка - просто наслаждение, до сих пор в плейлисте для расслабления стоит.
И да, эта фишка с отдельно перемещающимися существами - мне очень зашла, тем более что играя еще в двойку и тройку я постоянно задавался вопросом "Почему существа не могут ходить отдельно от героя?". Понятно со всякими орками и нежитью - хорошо, они.неорганизованные, но с представителями Замка и Оплота - казалось, что они должны быть дружными и иметь возможность жить и действовать без лидера.
А еще больше мне зашло то, что в один отряд можно было поставить нескольких героев - вот это вообще была пушка-бомба! Учитывая то, что как раз перед четверкой я играл активно в Might & Magic 8, где ходил тоже отрядом героев, я прям представлял себе схожие истории, только уже в стратегическом режиме от третьего лица. Я тогда очень сильно заботился о каждом персонаже, продумывал его персональное развитие и это мне очень сильно нравилось, выделяя игру перед тройкой.
Ну, раз просите подводные камни, то... Заваривайте чаек, присаживайтесь на топчан и слушайте :-)
Проблема №1 - "Питон программисты"
Питон программистов много, это факт... Но в разрезе программирования RPA-решений картина выглядит довольно печально. Прям профи-профи в этой сфере не так то много, а те, кто не супер-профи, с высокой долей вероятности пишут в разных стилях и применяют разные подходы. Как итог - наняв нового программиста вы получите целое приключение с его адаптацией (или через месяц обнаружите, что старые программисты не могут поддерживать робота от новичка)
Проблема №2 - "ОпенСорс"
Любимая мантра всех опенсорсников - "Это октрытый код, ты сам как программист можешь исправить ошибку, никакого вендорлока. А еще ты уверен, что нет никаких дыр, так как сообщество ух как старается". По факту эти розовые очки разбиваются о то, что именно те проблемы, которые получите вы - никто другой не встретит (или их это не будет волновать как вас). При попытке залезть в исходный код опенсорса вы потратите кучу времени и сил, и с высокой долей вероятнсти даже если получится устранить баг - можно сгенерировать себе новые.
Как обратная ситуация - злоумышленники могут проанализировать опенсорс решения, которые вы используете, найти в нем дыры и воспользовавшись ими получить несанкционированный доступ к памяти ваших роботов, отправив все самы важные циферки из важных документиков в недружественные страны
Проблема №3 - "Масштабирование эксплуатации"
Действительно, на планке примрено до 10 роботов - играться в простенькие решения, которые написаны самостоятельно, это прикольно. Но как только у вас начинается опыт с десятком роботов, которые работают на десятках машин под парой десятков учетных записей... Контролировать этот "Зоопарк" теми же опен сорс средствами становится крайне проблематично. Легко упустить ошибки в работе одного конкретного робота на одной конкретной учетке, легко упустить то, что расписания запуска перестали работать и так далее.
В целом можно еще ворох проблем дать вам, но, по классике остановимся на раз-два-три.
В заключении хочется донести простую мысль - Отдавая деньги вендору за лицензии вы в первую очередь покупаете свое время, которое не потратите на решение очень многих сложных проблем. За вас их уже либо решили, либо помогут решить, когда окажется, что эта проблема касается только вас.
Обычно я и мои партнеры использовали 2-4 ядра и 4-8 гб оперативки, и особых проблем не испытывали.
Здесь в гайде не перечислен один дистрибутив, который мы так же ставили, но он вызвал проблемы - Ubuntu. Судя по всему, с ней что-то не так, потому что ее оболочки (что через установку ubuntu-desktop, что через установку gnome) тормозят и ведут себя именно так, как вы написали.
Если у вас проблемы с дистрибутивами, которые перечислены выше - скорее всего проблема где-то на уровне качества Интернет-соединения. Можно для контроля попробовать подключиться с заниженным разрешением экрана и цветностью, как правило это решает проблему плохой связи.
Цель данной публикации - сделать централизованный единый хороший гайд.
У каждого человека свое представление о прекрасном, и лично в моем представлении хороший гайд должен содержать всю информацию, достаточную для достижения вполне конкретной поставленной цели без отсылания человека на прочтение информации на других ресурсах по ссылкам.
Собственно говоря, точно таким же способом как и вы, я мог ограничить гайд просто ссылками на вики всех дистрибутивов, но... Тогда это был бы не гайд, его нельзя было бы распечатать и идти по нему гарантировано достигнув цели.
И самоцели обеспечить безопасность в создании виртуального рабочего места под короткие задачи - у меня не было. Но если вы составите такой гайд, который будет универсален и без ссылок, я обязательно его присоединю. Если вам это не интересно - честно, мне тоже. Предлагаю дальше не тратить наше общее время на демагогию
Да, про "Tunneling RDP over SSH" не случилось по той причине, что в кейсах, где этот гайд применяли - он был не нужен. Инцидентов взлома зафиксировано не было.
Как указал в самой статье - если у вас есть компетенции и навыки настройки под разные дистрибутивы "с нуля" - поделитесь, обязательно добавлю в статью с упоминанием вашего профиля.
Что касается MATE - тот образ, который используется в Яндекс.Облаке, не дал мне возможности установить эту оболочку "из коробки" без добавления дополнительных репозиториев. А KDE дал. Именно поэтому в статье написал именно так, как вы процитировали.
Не называть это VDI - ваше право, не буду спорить. То, что есть специалисты, которые используют такие стенды на регулярной основе с долговременным хранением там данных - моя реальная практика, в смысле из того что наблюдал "за спиной" у других.
Правильно ли это или вредно и плохо? Отдельный вопрос для хорошего холивара, участвовать в котором не вижу большого смысла.
Что-то странное. У меня ни на винде, ни стандартная сборка для линукса не глючат и работают прекрасно. Можете поделиться историями где что у вас не работало, чтобы я мог подготовиться?
Если что, я использую Криптопро в сочетании с руТокеном в основном для входа и работы с ФНС, реже подписываю файлы.
Надо понимать две вещи:
1) Не все специалисты, работавшие в западных компаниях - высококлассные. Порой даже в каких-нибудь "задрипанных" НИИ с ЗП 20к в месяц специалисты сильнее, чем в ушедших компаниях.
2) Действительно сильные специалисты, как правило, мало ищут работу "в открытую". У них есть своя база знакомых в разных других хороших компаниях и их буквально приглашают лично на очень хорошие ставки. То есть вероятность того, что на вашу вакансию сам собой откликнется действительно классный спец из ушедшей из России компании - стремиться к нулю.
В целом статья - это хорошая шпаргалка начинающему управленцу, но вот заголовок и вступление, конечно, слишком кликбейтные и не совсем перекликаются с тем, что оставляет статья после прочтения.
Наверное, статью будет приятно почитать обычным программистам, дизайнерам и прочим ребятам, кто занимается непосредственно "ручной работой" в разработке и не занимал руководящих должностей хотя бы уровня тим-лида продолжительное время.
Если же читать эту статью с точки зрения человека, кто так или иначе руководит командами несколько лет, то она читается примерно так (переводя на язык программистов):
Надо в коде писать комментарии. Если однажды начать их писать не так хорошо, то в результате на них забьют. И будет бардак в коде
Надо пользоваться системами контроля версий с gitflow. Если все вести в одной ветке - это плохо.
Ну и так далее (я конечно утрирую, но все же).
Искренне желаю каждому обычному разработчику побывать в шкуре управленца - это очень сильно меняет мировоззрение и подход к разработке как таковой. Даже если окажется, что "управление - не мое" (среди моих знакомых примерно 90% ушло из управления примерно такой фразой), то вернувшись к бытью обычным разработчиком качественно поменяется подход к задачам, их оценке и ответственность за исполнение. Ну а эта статья, как уже написал выше - довольно неплохо показывает слабые места, с которыми все так или иначе встречаются.