Я сперва не про кейлогер даже предполагал, а скорее компрометацию в случае неуникальности.
Интересно, какой природы бэкдор. Если вход залогирован, то похоже, что аутентификационные данные были переданы. Хотя, кто знает, как оно у них там под капотом реализовано. Всё таки публичные/госсервисы должны быть опенсорсными)
100 км пешком за день, это вы замахнулись. Скорость пешая: 5 км/ч. Итого 20 часов марш-бросок. Т.е. сутки подряд почти без отдыха. А если не налегке, а местность не идеальный тратуар, погодные услрвия… Выжить конечно можно, но восстанавливаться в лёжку пару дней предётся, не то что воевать.
Имхо, чем больше прозрачности в процессах, в т.ч. принятия решений, тем меньше вопросов они вызывают у всех причастных, и тем объективнее они вынуждены быть.
Я представляю мотивы, по которым информация о ФОТ хочется скрыть. Это и попытка обыграть рынок (например, HR считает что знает его лучше сотрудников и соискателей, и пытается демпинговать), и манипуляция сотрудниками (разделяй и властвуй, каждому морковку по размеру).
С другой стороны, обыграть рынок задача неблагодарная. По моему опыту подбора кандидатов, фильтр по зп, один из самых эффективных, получаешь то за что платишь, и люди в подавляющем большинстве очень адекватно оценивают свои ожидания по зп (т.е. прекрасно сами ориентируются на рынке. Я про middle и выше, у начинающих конечно этот навык редко развит).
А для планов роста, при достаточном кол-ве сотрудников, кажется более эффективным иметь прозрачную систему грейдов, связанную с тарифной сеткой, и метрик для их достижения. Это снимает вопросы почему мидл Вася получает на 20% больше чем тот же мидл Петя. Требует меньше усилий на администрирование (не надо помнить, кто кому когда что обещал, повышал или нет и т.д., критерии роста в з.п. для всех одинаковы).
Конечно можно предположить, что вот нам нужна конкретная «звезда», и мы готовы заплатить больше чем платим старожилам, и принято на рынке, но… Может стоит остыть и подумать, как вписать «звезду» в грейды и тарифную сетку (и следовательно свои процессы). Может это новая единица в штатном расписании, раз готовы столько платить, с отдельной должной инструкцией и соответствующими ожиданиями по результатам.
Звучит, может утопично, но не вижу принципиальных проблем в реализации такой системы. Кажется, что она может быть актуальна и удобна всем. И мерятся в этом случае не придётся.
Немного «армейская» система получается, но отлаженные процессы тем и отличаются от ручного управления, что они повторяемы, масштабируемы и требуют дисциплины.
О, разделение труда повышает эффективность.
Почему интересно приходится чаще наблюдать лоббирование идей про вовлечённость разработчиков в бизнес и перекладывание экспертизы о продукте в разработку, чем высокую компетентность в предметной области среди тех же маркетологов и проч. Естественный отбор не работает что ли?
PS: на редкость читабельный перевод для Хабра, спасибо.
А смотрели возможность использовать yarn для установки пакетов? Когда столкнулся с тем что npm i занимает значительную часть pipeline, это позволило заметно оптимизировать процесс по времени.
Автор неоднократно приводит наличие диплома как нечто основополагающее. У меня есть пара аргументов против:
1. Я собеседовал ~100 человек за последние годы, и не нашёл корреляции между полученным дипломом и эффективностью сотрудников.
2. Да, у меня нет профильного диплома высшего образования, я благополучно работаю ведущим разработчиком/тим-лидом много лет в разных компаниях, и никогда это не было препятствием к трудоустройству.
Что я делаю не так?
Если верно понял, то вы решаете проблему генерации запроса и получения данных в «сыром» виде, без собственно маппинга в объекты, который и осуществляет ORM.
Не затруднит вас добавить в бенчмарк Doctrine, провести сравнение результатов для данных проецированных в объекты?
Я думаю всё это будет, вопрос времени. Дядя Боб исходит из практического опыта коммерческой разработки. Его практический опыт начинается в 70-ых. Самим технологиям несколько десятков лет, по меркам серьёзных наук это немного. Мне кажется мы в этом вопросе находимся на уровне античных философов, которые эмперически выводили основные наблюдаемые связи в окружающей природе. А вы уже требуете подходов основанных Ньютоном 2000 лет спустя)
Был в своё время IT-union, помню. Мне с коллегами помогали как-то в конфликте с бывшим работодателем. Сейчас у них даже сайта нет, хотя я туда публиковался. Всё что удалось найти: vk.com/itunion_info EgorKotkin Знакомы с ними?
Хм, чтобы понять бизнес-логику в коде написанном в прошлом году предыдущей командой, я трачу многие, многие часы день за днём. Учитывая что и язык реализации прекрасно знаю, и хозяйственная сфера современна мне, и кто-то из авторов даже консультирую… А вы говорите 1000 летнее легаси, авторы которого давно мертвы, поможет.
Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.
Конкретно в приведённом вами примере, лично я, в зависимости от роли. Договариваться с подрядчиком на берегу о критериях приёмки, либо вытаскивать проект из богомерзкого тимсити.
Infrastructure as code, Configuration as code…
Под СКВ должно находиться всё необходимое для развёртывания приложения в любом окружении с нуля, после клонирования. Не знаю насчёт передачи кодов и ГОСТов, по мне это современный, и единственно разумный подход.
Благо инструментарий для поддержки такой концепции очень активно развивается последние годы.
Интересно, какой природы бэкдор. Если вход залогирован, то похоже, что аутентификационные данные были переданы. Хотя, кто знает, как оно у них там под капотом реализовано. Всё таки публичные/госсервисы должны быть опенсорсными)
100 км пешком за день, это вы замахнулись. Скорость пешая: 5 км/ч. Итого 20 часов марш-бросок. Т.е. сутки подряд почти без отдыха. А если не налегке, а местность не идеальный тратуар, погодные услрвия… Выжить конечно можно, но восстанавливаться в лёжку пару дней предётся, не то что воевать.
Я представляю мотивы, по которым информация о ФОТ хочется скрыть. Это и попытка обыграть рынок (например, HR считает что знает его лучше сотрудников и соискателей, и пытается демпинговать), и манипуляция сотрудниками (разделяй и властвуй, каждому морковку по размеру).
С другой стороны, обыграть рынок задача неблагодарная. По моему опыту подбора кандидатов, фильтр по зп, один из самых эффективных, получаешь то за что платишь, и люди в подавляющем большинстве очень адекватно оценивают свои ожидания по зп (т.е. прекрасно сами ориентируются на рынке. Я про middle и выше, у начинающих конечно этот навык редко развит).
А для планов роста, при достаточном кол-ве сотрудников, кажется более эффективным иметь прозрачную систему грейдов, связанную с тарифной сеткой, и метрик для их достижения. Это снимает вопросы почему мидл Вася получает на 20% больше чем тот же мидл Петя. Требует меньше усилий на администрирование (не надо помнить, кто кому когда что обещал, повышал или нет и т.д., критерии роста в з.п. для всех одинаковы).
Конечно можно предположить, что вот нам нужна конкретная «звезда», и мы готовы заплатить больше чем платим старожилам, и принято на рынке, но… Может стоит остыть и подумать, как вписать «звезду» в грейды и тарифную сетку (и следовательно свои процессы). Может это новая единица в штатном расписании, раз готовы столько платить, с отдельной должной инструкцией и соответствующими ожиданиями по результатам.
Звучит, может утопично, но не вижу принципиальных проблем в реализации такой системы. Кажется, что она может быть актуальна и удобна всем. И мерятся в этом случае не придётся.
Немного «армейская» система получается, но отлаженные процессы тем и отличаются от ручного управления, что они повторяемы, масштабируемы и требуют дисциплины.
Разве это законно?
Почему интересно приходится чаще наблюдать лоббирование идей про вовлечённость разработчиков в бизнес и перекладывание экспертизы о продукте в разработку, чем высокую компетентность в предметной области среди тех же маркетологов и проч. Естественный отбор не работает что ли?
PS: на редкость читабельный перевод для Хабра, спасибо.
А смотрели возможность использовать yarn для установки пакетов? Когда столкнулся с тем что
npm iзанимает значительную часть pipeline, это позволило заметно оптимизировать процесс по времени.Логично. Дешевле оригинал загадить, а результат достигнут. https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0_%D1%83%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2/12_%D1%80%D0%B5%D0%B4%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2
Вспоминаем SRP.
С этим нововведением, если нам необходимо поменять модификатор видимости, смотрим diff в конструкторе.
1. Я собеседовал ~100 человек за последние годы, и не нашёл корреляции между полученным дипломом и эффективностью сотрудников.
2. Да, у меня нет профильного диплома высшего образования, я благополучно работаю ведущим разработчиком/тим-лидом много лет в разных компаниях, и никогда это не было препятствием к трудоустройству.
Что я делаю не так?
Не затруднит вас добавить в бенчмарк Doctrine, провести сравнение результатов для данных проецированных в объекты?
Я думаю всё это будет, вопрос времени. Дядя Боб исходит из практического опыта коммерческой разработки. Его практический опыт начинается в 70-ых. Самим технологиям несколько десятков лет, по меркам серьёзных наук это немного. Мне кажется мы в этом вопросе находимся на уровне античных философов, которые эмперически выводили основные наблюдаемые связи в окружающей природе. А вы уже требуете подходов основанных Ньютоном 2000 лет спустя)
Спасибо!
Вот стоило посетовать на недостаток публикаций, как в ленте появилась расшифровка детального доклада на тему https://m.habr.com/ru/company/oleg-bunin/blog/487258/
А можете раскрыть немного подробностей?
С интересом много лет слежу за его развитием, но пока не использовал в проде и под нагрузкой, и мало встречается публикаций на тему подобного опыта.
Автор, пиши исчо!
Реквестирую "Войну и Миръ браузеров" и "1000 и 1 спецификация или сказки XHTML-зады".
EgorKotkin Знакомы с ними?
Можете развернуть свою мысль? Не вижу связи между автоматизированным хромом и действиями гугла.
Хм, чтобы понять бизнес-логику в коде написанном в прошлом году предыдущей командой, я трачу многие, многие часы день за днём. Учитывая что и язык реализации прекрасно знаю, и хозяйственная сфера современна мне, и кто-то из авторов даже консультирую… А вы говорите 1000 летнее легаси, авторы которого давно мертвы, поможет.
Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.
Конкретно в приведённом вами примере, лично я, в зависимости от роли. Договариваться с подрядчиком на берегу о критериях приёмки, либо вытаскивать проект из богомерзкого тимсити.
Под СКВ должно находиться всё необходимое для развёртывания приложения в любом окружении с нуля, после клонирования. Не знаю насчёт передачи кодов и ГОСТов, по мне это современный, и единственно разумный подход.
Благо инструментарий для поддержки такой концепции очень активно развивается последние годы.