Это только теоретическая возможность подачи документов наступит. Далее их будут долго и мучительно проверять. Раньше запросто 3 года могли размышлять. Теперь якобы хотят быстрее, особенно если заплатить 5к евро пошлину с человека за ускоренное рассмотрение, где "ускоренное" -- это 8 месяцев (публично сроки не называют). То есть, по факту хорошо, если за 5 лет получится обрести паспорт.
Это известное когнитивное искажение. Мы волей-неволей считаем, что везде так же, как вокруг нас. Если у нас платят X, значит и там платят примерно столько же.
Но вот, к примеру, известная статья https://newsletter.pragmaticengineer.com/p/trimodal-nature-of-tech-compensation показывает, что в одном городе вполне могут сидеть люди с одним названием должности, доход которых отличается в 5 раз.
Это пример псевдограмотности. По поводу "ихний" можно заглянуть в словарь Зализняка.
А по поводу ударения в глаголах вида "звонит" можно прочитать его же книгу "История русского ударения" или хотя бы лекцию члена РАН Плунгяна "Русский язык в современном мире". И там будет хорошо описано, как эти ударения перемещаются со временем, подчиняясь общим тенденциям языка. И что во времена Пушкина ударение в глаголе "варит" было чаще на последнем слоге. Но сейчас переехало на первый. Что и ждёт другие похожие глаголы. И это нормально. Нет смысла сопротивляться естественному преобразованию языка.
С некоторой вероятностью, пропадёт желание поправлять окружающих. Особенно, когда контекст обсуждения совсем иной.
В этом самый смак и состоит. Как человек знает, что получил публичный ключ своего собеседника, а не ment-in-the middle? Эта часть покрыта туманом войны и проходит через серверы условного whatsapp.
Господа, "Сирия" (обе части) -- лучшая RTS в плане игровой механики, что мне попадалась. Даже ватно-телевизионный сюжетный нарратив не смог испортить удовольствие. Ждём новых шедевров
Там хоть и речь про PGP/GPG, но суть остаётся той же: идеи, конечно, крутые, но надо смотреть реальности в глаза -- пипл не хавает.
Проблема XMPP во фрагментации инфраструктуры. С одной стороны, это федеративная архитектура, не баг, а фича. Но по факту плохо совместимые клиенты и расширения. В теории работает отлично, но на практике пользуются 3.5 анонимуса
Как напоминает Грин, обычные чаты в Telegram не защищены сквозным шифрованием по умолчанию, как в Signal или WhatsApp.
Это же осознанный выбор. Как это работает в Whatsapp по их заявлению: сквозное шифрование по умолчанию... НО! Whatsapp очень навязчиво предлагает сохранить незашифрованную резервную копию сообщений в постороннем хранилище. Уверен, 99% пользователей так делают. Притом, часть делают это осознанно -- мало кто хочет при смене устройства потерять всю историю переписки. Это полностью подрывает саму идею.
Telegram пошёл другим путём, разделив чаты на обычные и секретные -- чувствительная переписка явно устраивается в виде секретных чатов, остальная синхронизируется.
Cоздает внутренний конфликт интересов и может закончиться не сильно хорошо.
Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.
В итоге я регулярно наблюдал встречи, когда продуктовая разработка просит ускорить релизы, а эксплуатация их тормозит, как может. Когда разработка хочет добавить побольше компонентов-зависимостей, а сисадмины стараются умерить их пыл.
Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.
Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).
Люблю это как пример провального перевода. Оригинальное название Dark Fields в данном контексте скорее переводится как "белые пятна" или как "неизведанные области".
Если авторы измеряют ее в штуках нанятых программистов в единицу времени, то у меня для них неприятные новости
Увы, такими темпами можно вообще отказаться от измерения чего-либо.
Это примерно как отказаться всех тестов и замеров производительности у отдельных компонентов сложной программной системы, в пользу исключительно e2e тестов и замеров всей системы в сборе. Правда в том, что нужно и то и другое для разных целей.
Для начала оговорим, что, судя по контексту, тут речь про рекрутеров (это лишь одна HR ролей). Они бывают штатные и внештатные. Возьмём для простоты внештатных и посмотрим на систему оплаты их труда. Общепринятая рыночная практика -- внештатный рекрутер получает деньги, если приведённый ими кандидат принял предложение о работе.
За всех остальных приведённых кандидатов внештатный рекрутер не получает ничего.
За дальнейшую судьбу сотрудника в компании внештатный рекрутер обычно не отвечает -- его задача привести кандидатов, а дальше уже ответственность перекладывается на нанимающих сотрудников компании.
Таким образом, видим, что внештатный рекрутер отвечает только за начальный этап воронки набора сотрудников. Первая наивная мысль -- раз платят за нанятых сотрудников (поштучно или взвешенно в зависимости от размера компенсации или уровня квалификации), то в интересах рекрутера навалить в эту воронку как можно больше кандидатов. Однако, такой подход по факту не работает: если внештатный рекрутер начинает приводить неподходящих кандидатов и, как следствие, конверсия кандидатов в сотрудники снижается, порожняком нагружая сотрудников компании собеседованиями, то компания перестанет сотрудничать с этим рекрутером. Похожая история может произойти и с кандидатами, которые тоже обычно не заинтересованы бесплодно собеседоваться на неподходящие роли.
Вот и видим, что у внештатного рекрутера появляются естественным образом две метрики эффективности -- число приведённых кандидатов и их конверсия.
И компания будет готова заплатить больше тому внештатному рекрутеру, который сможет показать лучшие метрики.
Вот такими метриками эффективности и разделяются границы составных частей системы. И важно из замерять -- это базовый принцип декомпозиции, активно применямый в науке для исследований и в управлении сложными системами.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы. И мы знаем, что заметная часть разработчиков -- формошлёпы и CRUD-оделы, чья работа не подразумевает значительной исследовательской работы с большихм коэффециентом неопределённости.
vmware == вендорлок. Что, если завтра они поднимут цену в 10 раз или технологически свернут не туда? Или перестанут оказывать услуги для клиентов в определённой юрисдикции?
Я застал пеереезд в vwmare на openstack в одной большой и известной организации году так в 2012. Даже тогда, во времена господства vmware в области виртуализации, это был прямо прорыв.
Насколько я понимаю, аналогия Event Notifications в Яндекс Облаке - Audit Trails.
Не совсем. Сбор аудитных логов есть отдельно от Event Notifications в AWS и GCP.
Суть Event Notifications в том, что на события в сервисе можно повесить свои кастомные обработчики. Например, запустить cloud serverless function / lambda.
Впрочем, допускаю, что эту же функциональность вполне можно самому реализовать на основе аудитных логов, которые придётся постоянно мониторить.
Можно источник?
теперь 8
Это только теоретическая возможность подачи документов наступит. Далее их будут долго и мучительно проверять. Раньше запросто 3 года могли размышлять. Теперь якобы хотят быстрее, особенно если заплатить 5к евро пошлину с человека за ускоренное рассмотрение, где "ускоренное" -- это 8 месяцев (публично сроки не называют). То есть, по факту хорошо, если за 5 лет получится обрести паспорт.
Так идея же ровно в безопасности работы с памятью
Это известное когнитивное искажение. Мы волей-неволей считаем, что везде так же, как вокруг нас. Если у нас платят X, значит и там платят примерно столько же.
Но вот, к примеру, известная статья https://newsletter.pragmaticengineer.com/p/trimodal-nature-of-tech-compensation показывает, что в одном городе вполне могут сидеть люди с одним названием должности, доход которых отличается в 5 раз.
многие антиотладочные приёмы можно обойти, переопределив ключевые объекты до старта отлаживаемого кода:
зачем реверсить исполняемый код, когда все ответы видны в сетевых пакетах?
Это пример псевдограмотности. По поводу "ихний" можно заглянуть в словарь Зализняка.
А по поводу ударения в глаголах вида "звонит" можно прочитать его же книгу "История русского ударения" или хотя бы лекцию члена РАН Плунгяна "Русский язык в современном мире". И там будет хорошо описано, как эти ударения перемещаются со временем, подчиняясь общим тенденциям языка. И что во времена Пушкина ударение в глаголе "варит" было чаще на последнем слоге. Но сейчас переехало на первый. Что и ждёт другие похожие глаголы. И это нормально. Нет смысла сопротивляться естественному преобразованию языка.
С некоторой вероятностью, пропадёт желание поправлять окружающих. Особенно, когда контекст обсуждения совсем иной.
Можно перечень?
В этом самый смак и состоит. Как человек знает, что получил публичный ключ своего собеседника, а не ment-in-the middle? Эта часть покрыта туманом войны и проходит через серверы условного whatsapp.
Они нынче добавили шифрование для бэкапов.
зачем их косить?
Господа, "Сирия" (обе части) -- лучшая RTS в плане игровой механики, что мне попадалась. Даже ватно-телевизионный сюжетный нарратив не смог испортить удовольствие. Ждём новых шедевров
На сходную тему написал хороший пост автор Signal protocol и реализации шифрования в Whatsapp. https://moxie.org/2015/02/24/gpg-and-me.html
Там хоть и речь про PGP/GPG, но суть остаётся той же: идеи, конечно, крутые, но надо смотреть реальности в глаза -- пипл не хавает.
Проблема XMPP во фрагментации инфраструктуры. С одной стороны, это федеративная архитектура, не баг, а фича. Но по факту плохо совместимые клиенты и расширения. В теории работает отлично, но на практике пользуются 3.5 анонимуса
Это же осознанный выбор. Как это работает в Whatsapp по их заявлению: сквозное шифрование по умолчанию... НО! Whatsapp очень навязчиво предлагает сохранить незашифрованную резервную копию сообщений в постороннем хранилище. Уверен, 99% пользователей так делают. Притом, часть делают это осознанно -- мало кто хочет при смене устройства потерять всю историю переписки. Это полностью подрывает саму идею.
Telegram пошёл другим путём, разделив чаты на обычные и секретные -- чувствительная переписка явно устраивается в виде секретных чатов, остальная синхронизируется.
Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.
В итоге я регулярно наблюдал встречи, когда продуктовая разработка просит ускорить релизы, а эксплуатация их тормозит, как может. Когда разработка хочет добавить побольше компонентов-зависимостей, а сисадмины стараются умерить их пыл.
Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.
Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).
PM -- по умолчанию всегда Project Manager, так же как "филфак" по умолчанию филологический, а не филосовский.
Скажем, PMBOK -- про управление процессами, а не продуктом.
Забавно, что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.
Люблю это как пример провального перевода. Оригинальное название Dark Fields в данном контексте скорее переводится как "белые пятна" или как "неизведанные области".
Увы, такими темпами можно вообще отказаться от измерения чего-либо.
Это примерно как отказаться всех тестов и замеров производительности у отдельных компонентов сложной программной системы, в пользу исключительно e2e тестов и замеров всей системы в сборе. Правда в том, что нужно и то и другое для разных целей.
Для начала оговорим, что, судя по контексту, тут речь про рекрутеров (это лишь одна HR ролей). Они бывают штатные и внештатные. Возьмём для простоты внештатных и посмотрим на систему оплаты их труда. Общепринятая рыночная практика -- внештатный рекрутер получает деньги, если приведённый ими кандидат принял предложение о работе.
За всех остальных приведённых кандидатов внештатный рекрутер не получает ничего.
За дальнейшую судьбу сотрудника в компании внештатный рекрутер обычно не отвечает -- его задача привести кандидатов, а дальше уже ответственность перекладывается на нанимающих сотрудников компании.
Таким образом, видим, что внештатный рекрутер отвечает только за начальный этап воронки набора сотрудников. Первая наивная мысль -- раз платят за нанятых сотрудников (поштучно или взвешенно в зависимости от размера компенсации или уровня квалификации), то в интересах рекрутера навалить в эту воронку как можно больше кандидатов. Однако, такой подход по факту не работает: если внештатный рекрутер начинает приводить неподходящих кандидатов и, как следствие, конверсия кандидатов в сотрудники снижается, порожняком нагружая сотрудников компании собеседованиями, то компания перестанет сотрудничать с этим рекрутером. Похожая история может произойти и с кандидатами, которые тоже обычно не заинтересованы бесплодно собеседоваться на неподходящие роли.
Вот и видим, что у внештатного рекрутера появляются естественным образом две метрики эффективности -- число приведённых кандидатов и их конверсия.
И компания будет готова заплатить больше тому внештатному рекрутеру, который сможет показать лучшие метрики.
Вот такими метриками эффективности и разделяются границы составных частей системы. И важно из замерять -- это базовый принцип декомпозиции, активно применямый в науке для исследований и в управлении сложными системами.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы. И мы знаем, что заметная часть разработчиков -- формошлёпы и CRUD-оделы, чья работа не подразумевает значительной исследовательской работы с большихм коэффециентом неопределённости.
vmware == вендорлок. Что, если завтра они поднимут цену в 10 раз или технологически свернут не туда? Или перестанут оказывать услуги для клиентов в определённой юрисдикции?
Я застал пеереезд в vwmare на openstack в одной большой и известной организации году так в 2012. Даже тогда, во времена господства vmware в области виртуализации, это был прямо прорыв.
Не совсем. Сбор аудитных логов есть отдельно от Event Notifications в AWS и GCP.
Суть Event Notifications в том, что на события в сервисе можно повесить свои кастомные обработчики. Например, запустить cloud serverless function / lambda.
Впрочем, допускаю, что эту же функциональность вполне можно самому реализовать на основе аудитных логов, которые придётся постоянно мониторить.