• Оцените шансы хакнуть криптообменник и получите книжку с кабанчиком в подарок
    +1
    Есть такое. Признаюсь мне читать эту книгу было легче на английском. Некоторые термины прямо жутко режут глаз. Ну что делать, все равно лучше на нормальном русском потихоньку начинать разговаривать, а не одними англицизмами ))
  • Оцените шансы хакнуть криптообменник и получите книжку с кабанчиком в подарок
    +3
    да ладно, тут же не автомобиль разыгрывается )) мы все на доверии
    я подумал, что полезнее дать ответы и пояснения, чем попытаться выяснить супер победителя
  • Как синхронизировать сотни таблиц базы в Kafka, не написав ни одного продюсера
    0
    Спасибо за статью!
    Вы пишете что вы хотите перейти на событийную архитектуру. Но при этом, вроде бы, решили другую задачу — синхронизировали таблицы (те по сути построили такую большую мат вьюху).

    Мне кажется если мы говорим про события, то речь идет о следующем: сервис генерирует событие (как бы факт), это событие кидается в топик и куча других сервисов подписывается на эти события и как-то на них реагируют. Суть именно в возможности отреагировать на событие.

    Если мы говорим о синхронизации таблиц — то мы просто хотим чтобы данные были одинаковые и мы никак нам особо ничего не надо делать при их изменении. Например, НСИ часто нам нужно просто синхронизировать, но никак не надо реагировать на изменение позиций в справочнике. Я правильно понимаю, что вы решали именно задачу синхронизации НСИ?

    Есть ли у вас именно события? Если да, то интересно как вы обеспечиваете целостность при записи в Kafka?
  • Как эффективно релизить монолит, в который коммитят 150+ разработчиков из разных офисов
    0

    Автор, вы не могли бы ответить? Правда интересно).

  • Как эффективно релизить монолит, в который коммитят 150+ разработчиков из разных офисов
    +1
    Спасибо!
    вообще впечатляет что вы смогли реализовать такую схему для монолита с 150+ разработчиками. Я подозреваю, что у вас все же основной ресурс для улучшения метрик — это переход на микросервисы. Подозреваю, что сборки у вас идут очень долго (десятки минут, часы), возможно, автотесты прогоняются также долго, если вы используете ручное тестирование и регресс — то это также жутко долго. В итоге, возможно, реально ттм у вас измеряется месяцами и возможность выкроить лишние минуты оптимизируя процесс релизов смысле не имеет.
    У нас вот 16 разработчиков и вы в какой -то момент пришли к тому, что сборки и автотесты выполняются очень долго (под 15 мин) и ничего с этим поделать не особо не можем. В итоге стали выделять микросервисы.

    Но может я не прав, тк вы не привели значения метрик. Ситуацию понять сложновато.
    Подскажите пожалуйста.
    Как часто вы делаете релизы?
    Как часто у вас обнаруживаются проблемы в канареечных релизах?
    Упомянуто что вы используете е2е тесты — те это что-то типа selenium? используете ли вы модульные тесты (unit)?
    какой у вас ттм? и что вы под ттм понимаете?
  • Kubernetes в ДомКлик: как спать спокойно, управляя кластером на 1000 микросервисов
    +2

    Подскажите, пожалуйста, как часто вы выкатываете релизы на прод?
    Используете ли вы кросфункциональнвн продуктовые / фича команды? Если да, то какого размера?
    Какое у вас среднее время производства фичи? ( ну типа от момента когда взяли в работу и до выпуска на прод?)

  • Программное обеспечение дешевле в мелкой таре
    –1

    А с аргументами автора какими конкретно вы Не согласны?

  • Программное обеспечение дешевле в мелкой таре
    0
    Очень интересная реконструкция истории создания авто ).

    По поводу того, что ПО имеет максимальную экономию на масштабе после того как оно разработано — об этом автор прямо пишет.

    Однако будьте аккуратны: после того, как программное обеспечение разработано, эффект экономии на масштабе становится неограниченным. Мир переключается. Созданное программное обеспечение, вероятно, демонстрирует большую экономию на масштабе, чем любой другой продукт, известный человеку. (С экономической точки зрения, затраты на изготовление первого экземпляра чрезвычайно высоки, но затраты на изготовление идентичной копии (изготовление) по сути близки к нулю — «Ctrl-C Ctrl-V»).


    Не очень понял в итоге с чем вы согласны или не согласны. Поясните, пожалуйста.
  • Программное обеспечение дешевле в мелкой таре
    –2
    в смысле???
    попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее, чем если бы вы эти требования реализовывали маленькими партиями (релизами/версиями).
  • Программное обеспечение дешевле в мелкой таре
    0
    Выкопать ровную, соответствующую определённым допускам по ширине, глубине и полосе отвода (которые тоже проверяются вручную), траншею длиной 100 км силой только 500 землекопов с лопатой будет дороже, чем 100 участков по одному километру

    почему? не понял вашу мысль
  • Программное обеспечение дешевле в мелкой таре
    0
    Автор говорит про другое.
    Вот вы начинаете делать большую систему. Вы можете запланировать большой релиз — делать его полгода и потом выпустить в прод, или вы можете работать маленькими, например, двухнедельными релизами.

    Выбор из этих двух вариантов не так уже очевиден. Многие менеджеры скажут, что работать большими полугодовыми релизами гораздо удобнее — можно посадить аналитиков и они спокойно напишут большое ТЗ, потом посадить разработчиков и они все запрограммируют, потом отдать на тестирование и тд. Так вот автор в статье приводит аргументы и показывает, что это не так. Что в ИТ с этим проблемы и выгоднее ПО выпускать маленькими партиями / релизами.
  • Программное обеспечение дешевле в мелкой таре
    0
    Мне кажется только все совсем наоборот.
    Есть анализ ситуации/сбор статистики/логика/аргументация/причинно-следственные связи и из этого вытекают какие-то решения, которые целесообразны для определенных ситуаций.
    А уже потом некоторые решения облекают в форму «ценностей XXX» и доводят до широкого круга лиц просто потому-что так проще ))).
    Кому охота разбираться с теорией очередей, законом Литла и тп? гораздо проще сформулировать пяток «ценностей» и рекламировать их )))

    Правда отсюда же и возникают проблемы с внедрением того же Agile. Консультанты помохали флагами, люди пошли внедрять, но у них ничего не получается.

    Автор статьи, конечно, тоже далек от научной точности, но все же он идет гораздо дальше. Если интересны научное обоснование принципов разработки ПО (в тч практик Agile), то рекомендую изучить книгу на которую в тч ссылается автор статьи (https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009).
  • Программное обеспечение дешевле в мелкой таре
    0
    Нет, пенсы. Но тут требуется пояснение. В оригинале используется термин marginal cost, что может переводиться как «предельные издержки» на производство дополнительной единицы продукции (см. ru.wikipedia.org/wiki/Предельные_издержки).

    Т.е. если 1 пинта стоит 49 пенсов, а 2 пинты стоят 85 пенсов, то получается что во втором случае вы как бы покупаете первую пинту за 49, а вторую пинту уже за 36 пенсов. Поэтому автори и пишет, что marginal cost второй пинты = 36 пенсов. Ну и аналогично с 4 пинтами.

    Подправил в тексте немного, чтобы было понятнее.
  • 10 идей из книги «Как управлять интеллектуалами»
    +2
    там фишка немного другая, продвинутые конторы из Кремниевой долины стараются использовать всякие подходы при которых люди наделяются большими полномочиями и могут принимать много решения самостоятельно… т.е. они уходят от централизованного принятия решений, когда босс все решает и спускает решения вниз и тд. Например, сейчас читаю книгу про OKR и там упоминается, что Google переиначил «правило 7» 0- если раньше говорили, что менеджер может управлять не более 7 подчиненными, то Google считает, что менеджер должен управлять не менее 7 подчиненными ))).

    Та же Amazon известна своими тупицца тим, которые на само деле имеют очень высокую автономность в принятии решений и тд.
  • 10 идей из книги «Как управлять интеллектуалами»
    +1
    В книге автор пишет про то что по его мнению лучше всего работают плоские структуры максимум из 3-х уровне. Четко автор не отвечает на ваш вопрос. Я думаю, что имеется ввиду что точно должен писать код ТЛ, очень желательно — менеджер ТЛ. Про директора — не уверен, скорее всего, тут уже никак не получится это делать.
  • 10 идей из книги «Как управлять интеллектуалами»
    +1
    да, было 0/1, но я проверил в оригинале, там оказалось -1
  • 10 идей из книги «Как управлять интеллектуалами»
    +1
    Звучит очень странно… 11 — это максимум, а 10 — это опасно низкий уровень…

    да, но так в источнике. Я так понял, что все пункты для автора важны и если где-то вы не добираете — значит в какой-то части у вас опасная просадка )
    Какое-то противочречие… Видимо вопрос об устных отчётах?

    Спасибо! мой косяк, перепутал +1 и -1.
  • 10 идей из книги «Как управлять интеллектуалами»
    +1
    вот недавно прочитал книгу хорошую по этой теме и сделал обзор также на хабре, посмотрите здесь
  • QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
    0
    6. Я так понял, что у вас используются фича флаги + автотесты + скорее всего вы часто мержите в мастер и за счет качественных автотестов гарантируете, что мастер всегда в стабильном состоянии. Зачем вам итерации? просто релизьте мастер тогда когда это потребуется… или даже просто автоматически каждый день или вообще «непрерывно» после каждого мержа. В этом случае куча скрамовских ритуалов уходит за ненадобностью…
  • QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
    +1
    Спасибо за статью, очень интересно.
    Несколько вопросов.
    1. Какой длительности у вас спринты?
    2. Шаг 4 у вас возникает в конце каждого спринта? или только тогда когда фича полностью готова? те, например, если фича делается в течение 3 спринтов, то шаг 4 возникнет только в конце 3-го спринта?
    3. Если шаг 4 возникает тогда когда готова фича, то не возникает ли проблем с тем, что если задача крупная, то PO довольно поздно проверит, что все реализовано так как он задумывал и вообще что то что он задумал — правильно? (по-моему опыту довольно много косяков еще на уровне постановки задачи PO и плохо, когда этот шаг откладывается)
    4. Если на шаге 4 у вас PO видит какие-то улучшения/косяки, то что вы делаете? откладываете их на следующий спринт? или фиксите сразу?
    5. Вы пишете, что по сути ручного тестирования нет. Разработчик знает, что за ним никто не перетестирует. Насколько вы уверены, что после выпуска очередного спринта система не рухнет? как вы добились этой уверенности?
    6. Зачем вам вообще спринты? если у вас хорошо развиты инженерные практики — автотесты/фича флаги и тд, то может стоит переходить на непрерывную поставку?

  • Безопасность REST API от А до ПИ
    +1
    API1:2019 Broken Object Level Authorization
    — Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.


    Подскажите, пожалуйста, какие есть способы реализовать это? Дело в том, что мы это реализовываем в своих проектах через т.н. реализацию МРД (модели разграничения доступа, но, возможно, это наш внутренний термин).

    МРД — это документ в котором мы прописываем для каждого объекта правила доступа нему со стороны каждого субъекта. Потом эту МРД реализуем в коде на Java. Но получается жутко сложно, много ошибок и косяков.

    Может есть какая-то книжка или бест-практика как это реализовывать проще?
  • Просто скажите «нет» end-2-end тестам
    0
    В общем резюмируя, я не против тестов. Я против идиотских «пирамид», планок покрытия «не меньше 146%», я за здравый смысл. Если у вас в логике куча алгоритмов или математики — то тут юнит тесты как раз то, что вам нужно. Если же у вас веб приложение с классическим CRUD — то возможно вам больше подойдут e2e. Если архитектура быстро меняется, код часто переписывается, то e2e — ваш вариант. Если вы энтерпрайз, который существует с 10 лет, то юнит тесты скорее всего ваш бро. Если у вас преимущественно синьоры, то возможно юнит тестов можно писать меньше. Если джуны — лучше больше — потому что юнит тесты еще и форсят single responsibility


    по моему опыту покрытия 60-70% unit-тестами вполне хватает для того, чтобы почти исключить регресса, вообще разные типы автотестов — они не для разного, они для того же самого. Паттерн «пирамида тестирования» и автор не утверждают, что e2e не нужны… в статье просто показывается, что экономически целесообразно использовать соотношение

    По-хорошему, Google предлагает разделение 70/20/10: 70% модульных тестов, 20% интеграционных тестов и 10% end-2-end тестов. Точное соотношение будет отличаться для каждой команды, но в целом она должна сохранять форму пирамиды.
  • Просто скажите «нет» end-2-end тестам
    0
    это вообще-то перевод статьи сотрудника Гугл от 2015 года, мы в DevOps командах уже более полугода используем этот подход, все хорошо
  • Просто скажите «нет» end-2-end тестам
    –2
    потому что она актуальна и по сей день, статья очень полезная и крутая…
    я с удивлением обнаружил что перевода на хабре нет.
    если для вас это очевидно, то я вас искренне поздравляю

    но я не уверен, что судя по комментарию про docker compose и далее, что мы на одной волне
    вы точно говорите про e2e тесты — которые полностью имитируют поведение пользователя?
    вы реально считаете, что их можно прогнать в сколько -нибудь сложной системе за пару минут??? ну не знаю… насколько я знаю у нас средняя скорость выполнения e2e тестов — 5.5 штук/минуту
    если вы у вас десяток e2e тестов, ну ок…
  • Просто скажите «нет» end-2-end тестам
    +1
    мне кажется тут не стоит занимать крайние позиции, идея автора (и вообще пирамиды тестирования) следующая:
    — очень очень много unit тестов влечет c высокой вероятностью общее корректное функционирование всей системы
    — если еще к очень много-много unit-тестов добавить немножечко (тк они дорогие и ненадежные) e2e тестов- то вероятность корректного функционирования станет совсем высокой (но все равно до 100%)

    и эта стратегия более экономически целесообразна, чем стратегия — писать только e2e тесты.
  • Просто скажите «нет» end-2-end тестам
    +1
    В основном unit-тестами, немного e2e и совсем мало руками.
    Здесь речь идет про паттерн «пирамида тестирования», рекомендую:
    martinfowler.com/bliki/TestPyramid.html
    habr.com/ru/post/358950

    Хочу сказать, что у нас это работает. Судя по автору статьи — в гугле тоже.
  • Просто скажите «нет» end-2-end тестам
    +1
    PS у нас на проекте вообще нет позиции тестировщик, также мы вообще не проводим ручное тестирование. Есть только модульные и е2е тесты. Полный прогон всех тестов занимает 20 минут. Чаще всего нам хватает 2-3 релиза в неделю. Но технически мы можем делать несколько релизов на прод в день (полный цикл от пуша в ветку, до заливки на прод где-то 2 часа). Как вы такое сделаете с ручным тестированием и без автоматических е2е тестов?


    это круто!
    На наших проектах у нас тоже нет тестировщиков, мы пишем много-много unit-тестов, интеграционные и контрактные тесты. Перед выпуском делаем ручной смоук небольшой на 30 мин, в идеале, соглашусь его тоже стоит автоматизировать — это как раз те самые e2e тесты… но пока это не было необходимостью.

    Это тоже довольно интересно, ни разу не слышал, чтобы в проекте был допустимый процент упавших тестов. Всегда все 100% тестов должны быть зелёными, как юнит, так и е2е тесты.


    это тоже для меня было удивительным — но из перевода слов не выкинешь ).

    И уж в данном контексте откровенно смешно жаловаться на низкую скорость и надёжность е2е тестов. Ручной человеческий труд всегда будет на порядок медленнее и с большим количеством ошибок и срезанных углов, чем прогон набора автоматических тестов.


    В статье автор сравнивает по скорости и надежности unit-тесты и e2e тесты и в целом посыл статьи сводится к тому, что стратегия писать «много unit и мало e2e» лучше, чем «много e2e и мало unit». Мне кажется вы тоже с этим согласны судя по вашему тексту.

  • Просто скажите «нет» end-2-end тестам
    +2
    Кстати, да, вы правы. Не обратил внимание.
  • Просто скажите «нет» end-2-end тестам
    –5
    Ну вообще-то это перевод статьи автора, работающего в гугл… судя по примерам, возможно, над разработкой Google Docs. Не думаю, что к продуктам Google можно применить в общем смысле характеристику «сервис уровня зааплоадил картинку».

    В целом здесь речь идет про известный паттерн «пирамида тестирования», который не утверждает, что e2e не нужны совсем… он говорит, что распределение должно быть — 70% unit, 25%- integration и что осталось в порядке убывания на контрактные тесты, e2e и ручные тесты (% просто для ориентира).
  • Управляя коллективом, нарушьте все правила
    0
    спасибо за глубокий комментарий
    я не претендую на звание специалиста в этой области, но для меня, как я уже писал, книга стала откровением
    может быть я что-то упустил
    0) да, думаю, что идеи книги применимы в том числе и к менеджерам
    примеров, когда CEO становятся очень молодые люди — полно, примеров перепрофилирования в программисты тоже много…
    1) В книге пишут, что один из признаков таланта — это то, что вам нравится эта область. Мне кажется в вашем примере у вашего знакомого есть талант/предрасположенность к математике. Поэтому если выбирать между вами и вашим знакомым при прочих равных — то стоит выбрать знакомого.
    2) Согласен. Однако, я видел кучу примеров в своей практике, когда студент за пару лет быстро вырастал в супер-специалиста сеньора. И видел примеры, когда пришедший в компанию сеньор так и оставался на своем уровне или даже деградировал. Поэтому при найме неплохо учитывать все же этот эфемерный «талант». Для этого HR пытаются эту область систематизировать, разработали кучу практик — структурированное интервью, поведенческие интервью, всякие там наборы софт скилов.

    Вообще не надо зацикливаться, кстати, на хард скиллах. Вот Spotify оценивает кандидатов по 5 направлениям из которых только одно — связано с хард скиллами

    Values team success over individual success
    Continuously improves themselves and their team
    Holds themselves and others accountable
    Thinks about the business impact of their work
    Demonstrates mastery of their discipline

    3) Да, согласен. Это немного противоречит другой идеи авторов — поставьте цель и дайте возможность человеку найти способ ее достижения. Получается, мы как бы сами решили, что нам нужны люди определенного типа и дальше стараемся набирать именно таких, а не других. С другой стороны, авторы же не дают готовых отраслевых стандартов! Они говорят — подумайте, что для вашей компании подходит лучше всего и набирайте таких людей. Например, если вам подходит авторитарный стиль управления, то набирайте таких менеджеров. Если демократичный стиль управления — набирайте таких.
    4) Согласен. Лучшие работник — это родитель с ипотекой )). Именно поэтому в том числе важно попытаться понять все мотивы/таланты/предрасположенность. Возможно, что как бы не нуждался человек в работе — у него все равно ничего не получиться. Поэтому вместо очень нуждающегося родителя с ипотекой вам лучше взять свободного талантливого студента )).
  • Управляя коллективом, нарушьте все правила
    0
    ну зря вы так
    возможно, вы сами можете что-то применить тоже
    вы же не всегда только исполнитель, наверное.
  • Управляя коллективом, нарушьте все правила
    +1
    много воды? фууф, я вот сидел несколько дней пытался урезать и больше ни слова не смог выкинуть )))
    удачи на новой работе) для меня книга была тоже полезна повышением уровня «осознанности». Многое и так делаешь, но не на систематическом уровне.
  • В adidas перешли на Kubernetes, сократив время релизов в ~100 раз
    +1
    В реальности, наверное, года 3-4 люди сначала страдали, искали корни проблем, искали решения, пробовали разные подходы, кто-нибудь охрип доказывать и обосновывать переход на какой-нибудь Kanban или Scrum традиционным менеджерам, внедряли кучу инженерных практик типа user stories, TDD, Code review, feature branches, branch by abstraction, evolutionary database design, trank based development и тп, лажали, переделывали, опять лажали, что-то у них получалось, обучали других, распространяли успешные практики… ну и в конце концов под конец внедрили Kubernetes до кучи)))) ну и теперь флант публикует такую новость )))
  • Массовая загрузка данных, или Как накормить китайскую деревню
    +1
    serverless решения — это сейчас очень популярное направление, безусловно это круто. К сожалению, сейчас по крайней мере их применение ограничивается ИМХО системами, когда у вас в основном простая stateless логика, оркеструющая 3-d party сервисы… что-то более сложное и к тому же чувствительное по ИБ (пересданные, конфданные и тд) уже не получится сделать (в смысле сделать можно что угодно, но за разумные деньги и чтобы это можно было потом развивать — там ограниченный инструментарий, куча разных телодвижений нужно сделать, чтобы ч-н закодить).

    Интересно у вас есть опыт создания serverless? поделитесь… так как у меня только теоретический

    Ну те ИМХО пока ГИС вы не сделаете даже на продвинутых Амазонах и гуглах… увы ((( поэтому эти все радости нам пока недоступны ((
  • Массовая загрузка данных, или Как накормить китайскую деревню
    +2
    Я описал реальный пример иллюстрирующий те условия, которые актуальны на многих наших проектах. Для других систем требования могут меняться. Очень может быть, что модель останется той же, просто если у нас срок загрузки максимальный = 1 сутки, то в другой системе = 1 часу, например. Но суть, возможно, не поменяется от этого.
    Не могу же я придумывать примеры для китайцев под каждый возможный временной дедлайн в самом деле )))
    скорее всего просто нужно под соотвествующий дедлайн оценить экспериментально/аналитически нужный объем железа, чтобы обслужить прогнозируемый поток запросов.
    В любом случае, владелец системы будет стоять перед выбором — меньшая эффективность использования железа/ресурсов vs более длительное обслуживание запросов.

    >> Представьте что до крайнего срока успешно загружены 80% налоговых деклараций по прибыли. Что будет с остальными 20%?
    я не очень представляю последствия того, что декларации не загружены до крайнего срока. Напишите, плз,
    — какой вообще срок дается на загрузку?
    — если срок прошел, то что будет? штраф? какого размера?
  • Массовая загрузка данных, или Как накормить китайскую деревню
    +1
    Теоретически может быть. С точки зрения денег, тоже должно быть тоже самое, если не лучше.
    Знаете ли вы к-н облака, подходящие для размещения ГИС -систем? и еще чтобы там были бы как бы неограниченные ресурсы? те реально можно было рассчитывать на то, что можно онлайн выделить ресурсы под 150 млн китайцев?

    Правда, иметь ресурсы — это еще пол дела. Надо чтобы еще система умела масштабироваться, а это штука не очень линейная.
  • Массовая загрузка данных, или Как накормить китайскую деревню
    +2
    Да, это попытка объяснить на пальцах базовые вещи. Для меня было удивительно, что очень многие этого не понимают.
  • Боль, таблетки и две кареты скорой помощи, или Как мы все-таки забрались на пятое место IronStar 226 в Сочи
    +1
    вот у вас расширенное сознание, если вы такое можете предположить
    велик у Димы свой,
    а насчет 900к — мы сами в шоке были от того, что могут быть такие цены
    вообще читайте внимательнее))
  • Боль, таблетки и две кареты скорой помощи, или Как мы все-таки забрались на пятое место IronStar 226 в Сочи
    +1
    Сильно сказано — не вытягивают ))))) очень смешно.

    Может не хотят или травмы… А если захотят, то никто из любителей и рядом не постоит. Хотя у нас по любителям тоже не простые челы стартуют — к-н КМС/МС по плаванию или волокон — тоже так себе любитель.

    Из недавних примеров — вон Андрей Брюханков стартовал в 2018 году на половинке Ironstar и вынес всех в одну калитку. Вон Зеленов вернулся после того как завязал и всех вынес на Ironstar 226 с рекордом трассы, хотя полгода до этого весил еще под 120 (или что-то около того).

    На ЧМ по полной дистанции и особенно половинке полно олимпийцев — те же Фродено, Браунли и тд.
  • Боль, таблетки и две кареты скорой помощи, или Как мы все-таки забрались на пятое место IronStar 226 в Сочи
    +1

    Это точно ))) затягивает )) надо на Трилайф запостить, пусть триатлеты поржут