• DevOps в Сбербанк-Технологиях. Инструментальный стандарт
    0
    Вы, батенька, очень тонкий тролль, браво. Но статья не об этом.
  • DevOps в Сбербанк-Технологиях. Инструментальный стандарт
    0
    Безусловно рассматривали разное, результат рассмотрения вы видите. В будущем он может измениться. Если вы хотите продать что-то, то я — точно не тот человек, к которому стоит обращаться с такими вопросами)

    Ansible в контексте статьи лучше Puppet а) интеграцией в существующую Python-инфраструктуру б) наличием множества специалистов с хорошим знанием Python в) Отсутствием агента

    Про ELK стек ничего не знаю, к сожалению. Это не значит, что какие-то проекты или программы его не используют — Сбт большой :)

    Отмечу только, что в ППРБ существует своя собственная система мониторинга, в недрах которой кроме самописных решений используется еще и Splunk. О мониторинге будет одна из следующих статей об Сбт на Хабре, и скорей всего — доклад на JBreak/JPoint 2018. Вы о Splunk не спрашивали, но вдруг окажется полезным :)
  • DevOps в Сбербанк-Технологиях. Инструментальный стандарт
    –1
    Хмм, давно у фейсбука ~15 тысяч отделений в 83 субьектах РФ, ~80 тысяч банкоматов, требующих присутствия реальных живых людей? Не знал, ай да фейсбук
  • DevOps в Сбербанк-Технологиях. Инструментальный стандарт
    +1
    В данной статье рассматривается только девопс внутри ППРБ. ППРБ — это корная платформа банка, дело с которой имеют сотрудники банка. А за публичные интерфейсы (и баги в нем) отвечает другая программа — ЕФС. У них даже есть блог на Хабре: https://habrahabr.ru/company/efs, и они даже уже что-то начали выкладывать на Гитхаб: https://github.com/Sberbank-Technology. С какой скоростью и как ЕФС отвечает на запросы о багах я, к сожалению, сказать не могу.
  • DevOps в Сбербанк-Технологиях. Инструментальный стандарт
    0
    Да, пусть пишут мне в телеграм olegchir :)
  • DevOps в Сбербанк-Технологиях. Инструментальный стандарт
    +1
    Внедрением девопса занимаются все. Но есть люди, более ответственные за это, чем все остальные. Наример, архитекторы, местные аналоги SRE, разработчики девопс-инструментария (в Сбертехе очень много своих внутренних разработок), написатели скриптов для координации CI/CD, и так далее. Есть специальные команды, ответственные за внедрение практик девопса.

    В последнее время в России часто употребляют слово «девопс» в смысле должности. Это конечно, звучит несколько неграмотно, но зато позволяет не перечислять каждый раз длинный список этих «специальных особо ответственных». О ком конкретно речь в данном конкретном случае — обычно можно понять по контексту.
  • Моноиды, полугруппы и все-все-все
    0
    У автора есть множество статей в его блоге: blog.ploeh.dk
    где он обсуждает практические применения. К сожалению, зачастую, из-за терминологии звучат они как борщ из заумных слов. Наверное, поэтому он и начал писать эту серию постов, чтобы священные тексты начали поддаваться расшифровке.

    Я по-возможности буду тащить на Хабр самое ценное из брейндампов автора, но есть момент: он пишет целыми сериями, и переводить отдельный пост не имеет смысла. Нужно переводить сразу всю серию.

    ну и как всегда <маркетинг>можно прийти на конфу DotNext и задать ему такие вопросы лично</маркетинг>
  • Моноиды, полугруппы и все-все-все
    +2
    ну вот так :)

    моноид — это комбинация бинарной операции (например, конкатенации методом Concat) и типа данных над которым она работает (например, строки или массивы). Ну знаете, как в классическом ООП, класс — это абстрактный тип данных и набор операций над ним :)

    дальше, по вашему вопросу. Мы приходим к старому как мир вопросу способа описания/моделирования. Например, что такое квадрат? Это какой-то набор признаков (равные углы по 90 градусов, равные стороны), или алгоритм рисования квадрата? Мышление алгоритмами/построениями не идеально — например, в древности возникла задача изучения свойств диагонали квадрата (в частности квадратного корня из двух), что привело к построению несоизмеримых отрезков — есть легенда, что Пифагор по этой теме утопил ученика. Но в целом, доказательство и описание построением — вполне популярные и легитимные вещи. Квадрат — это нечто, что получилось в результате алгоритма рисвания квадрата

    возвращаясь к моноиду конкатенации. В результате применения этой бинарной операции может получиться последовательность. Точнее, последовательность обычно и получается именно этим способом.

    Откуда может взяться последовательность? Либо склейкой уже готовых последовательностей, либо надо собрать их из отдельных элементов. Первый случай — очевидный, по поводу второго в тексте есть заготовленный пример:

    var three = new[] { 3 };
    var four = new[] { 4 };
    var combination = three.Concat(four);

    Если последовательность — это то, что всегда получается в результате применения моноида конкатенации, значит последовательность и есть моноид конкатенации. Точно так же как с квадратом, алгоритм построения квадарата и есть квадрат.

    Поэтому в тексте они употреблены как синонимы — вероятно, с целью упростить формулировку

    А свобода тут в том, что в комбинации (тип данных + операция + данные), операция — не захардкожена, мы можем ее поменять потом. Паттерн стратегия
  • Моноиды, полугруппы и все-все-все
    +2
    Это еще только начало материала :)
  • О чем болит голова Android DevOps-инженера
    0
    Красиво Барух сказал: «Ответственность — это значит быть в ответе за что-либо, возможность объяснить, разобраться в том деле, которое делаешь.»

    Прикол начинается тогда, когда твой коллега (или целая команда — например, команда мобильных разработчиков из вашего примера) совершенно не хочет разделять эту ответственность. Они понятия не имеют, как работает серверный бэкенд на Java, никогда не видели Java, понятия не имеют что такое стектрейсы, — и более того, понятия иметь не хотят. Вот представьте, это официальный ответ главного руководителя мобильной разработки. Ваши действия дальше?)
  • Как дела у CatBoost? Интервью с разработчиками
    0
    Ну наверное, этот вопрос стоит задать самой Анне. При возможности, задам.

    Судя документации, волшебной фичи, на которую вы надеетесь, нет. Обрабатываемая информация — произвольная, но только в том смысле, в каком произволен входящий текст. Яндексу было важно научить машину работать не только с числами, но и с категориями напрямую, закономерности между которыми она будет выявлять самостоятельно, без нашей низкокачественной ручной помощи. В результате появился CatBoost, одинаково хорошо работающий «из коробки» как с числовыми признаками, так и с категориальными. В этом и есть задекларированная свобода.

    Но можно пофантазировать, если бы ваша магическая фича существовала — как бы для нее выглядел входящий датасет, и каким могло бы быть апи. Наверное, такого эффекта можно достичь самостоятельно, комбинацией разных инструментов — еще одна тема для вопросов к Анне.
  • О чем болит голова Android DevOps-инженера
    0
    Забавно, правда? Ну тут такой вопрос. Например, у программистов тоже есть некое условное деление на «прикладных» и «системных». Прикладной программист может хорошо разбираться в алгоритмах своей предметной области, паттернах проектирования, вот этом всем. Но попробуй заставить его читать ассемблерные листинги, или отчеты системы сборки мусора в его VM, или копаться в ядре Линукса, чтобы починить какой-то малопонятный баг — то все, труба. Как на это обычно реагируют?
  • Как дела у CatBoost? Интервью с разработчиками
    0
    Если бы он жрал набор страниц со смешанным контентом, приведите пример формата датасета и способа обращения с ним в смысле API?

    tech.yandex.com/catboost/doc/dg/concepts/input-data_values-file-docpage
  • О чем болит голова Android DevOps-инженера
    0
    Имхо, мир изменился, и девопс стал совершенно обычной вещью. Как воздух. Это не просто «плотность в последнее время», это свойство реальности, без которой уже нельзя. Все, кто этого еще не осознал, носятся с девопсом как писаной торбой :-) Таких много — большая шумиха.
  • О чем болит голова Android DevOps-инженера
    0
    DevOps — это не «программирующий админ», это культура разработки. Она охватывает совершенно всех как минимум вдоль цепочки разработки-поставки-обслуживания сервисов.

    Что касатеся «скриптов»… Ну как бы, вот у Джинга случилась проблема с необходимостью сверять наборы permissions на андроиде. Он попробовал написать модульные тесты с программным получением прав, попробовал распарсить AndroidManifest.xml и написать свой мерджер, в конце концов дошел до распаковки apk. Результат оформил как законченный продукт на Гитхабе, который может составить конкуренцию современной фиче из AndroidStudio. Это все точно описание «админа» со «скриптами»?
  • Много, быстро, распределенно: как выбирать In-Memory Data Grid-решение
    +1
    Там есть Си? Ну это же всё решает, в современных языках везде есть поддержка вызова Си
  • Перформанс: что в имени тебе моём? — Алексей Шипилёв об оптимизации в крупных проектах
    0
    если бы каждый в комментариях повторил эту фразу, получился бы забавный флешмоб. Например.
  • Перформанс: что в имени тебе моём? — Алексей Шипилёв об оптимизации в крупных проектах
    0
    Один из лучших докладов (если не лучший), что мне довелось видеть на тему производительности.
  • 10 интересных нововведений в JUnit 5
    0
    Я всегда пишу if (42 == x) {… в коде
  • Что «под капотом» у LinkedList?
    +8
    Как давно признался Шипилёву автор LinkedList,



    Рекомендую прочитать весь тред.

    twitter.com/joshbloch/status/583813919019573248
  • Как я браузерный 3D-футбол писала. Часть 1
    +3
    можно подключить этот интерфейс к живым футболистам, тогда оно заимплементится само
  • Concurrency паттерны в Rust из Java
    +1
    Это ленивый класс. Как только он потребуется, тогда и узнаем — зачем
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +1
    в таких случаях принято комментарий целиком заменять на слово «del», и потом писать в правильное место. Их обычно не минусуют, потому что всем и так ясно, откуда пошла такая фигня
  • Готовимся к Java 9. Обзор самых интересных улучшений
    0
    Имхо там слегка сложней.
    Есть договоренность, что если спека всеми принята, то ее делают.
    А тут получилось, что люди прямо перед выпуском напрямую отказались от своих слов, посчитав их глупостью.
    И дело там не только в «переписывать программы», а в том, что изначальную спеку нужно делать куда масштабней и умней.
    Обычная мелкая гражданская война, в которой все правы и неправы одновременно, а страдают вообще другие люди :)
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +1
    Вопрос в том, что стратегический план должен корректировать не только саму форму API, но и способ того, как люди пользуются Java. Направлять мир в правильное русло. Это один из смыслов существования архитектурных советов и выпуска ими рекомендаций. Если бы нужен был просто вспомогательный метод, сделать его не проблема, или уже стащить готовый из Гуавы.

    С точки зрения всеобщей схемы всего, верной практикой считается использование иммутабельных конструкций. Нужно всячески поощрять разработчиков к иммутабельности, а стиль программирования — к функциональной чистоте.

    Если бы существовала мутабельная версия этой конструкции, все говнокодеры мира тут же начали бы ее использовать (не нужно учиться новым вещам, плодить мутабельное всегда проще), а всем остальным пришлось бы смириться с таким положением вещей по причине частоты распространения.

    Имхо, именно поэтому, для создания мутабельной версии выбрана специально переусложненная форма. Именно такая как у тебя в примере — использование копирующего конструктора поверх коллекции, полученной через convenience method.

    Я не чтобы оракул оракла, это чуть ли не открытым текстом сказано в JEP-269 Convenience Factories.

    В дальнейшем эти идеи могут быть развиты с помощью JEP-186 Collection Literals. Предлагается не мусорить с помощью List.of, а сразу писать List list = #[ 1, 2, 3 ];. Но это совершенно отдельный (тоже стратегический) вопрос.
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +2
    Java нужна потому, что это Java. Язык с невероятно долгой совместимостью и неформальными гарантиями что новые фичи будут хорошо работать очень долго (может быть, те же фичи будут использовать наши внуки), с хорошо подогнанными друг другу фичами (проходят годы обсуждений, прежде чем какая-то фича попадает на публику), с поддержкой Oracle, ну и в конце концов — это язык, на котором говорит большинство разработчиков в мире. Котлин — хороший язык, но он не об этом. Тем, кому нужна Java, нужна именно Java.
  • Готовимся к Java 9. Обзор самых интересных улучшений
    0
    public interface HelloWordable {
        public static void hello() {
            System.out.println("Hello World!");
        }
    }

  • Готовимся к Java 9. Обзор самых интересных улучшений
    +1

    уже работает. IntStream.iterate(0, x -> x < 10, x -> x + 1).forEach(System.out::println)

  • Готовимся к Java 9. Обзор самых интересных улучшений
    0

    В смысле, JEP-286? :) Когда-нибудь относительно скоро

  • Готовимся к Java 9. Обзор самых интересных улучшений
    0
    Гёц когда-то об этом говорил. Проблема в том, что проперти можно реализовать по-разному, и никакая из реализаций не подойдет всем желающим (включая желающих совместимости для легаси двадцатилетней давности). А маркетинговый эффект этой фичи будет минимальный, по сравнению с приложенными усилиями (т.е. если запилить что-то важное типа лямбд — это скорей будет стимулом поменять $languagename на Java, а вот введение пропертей — не особо)
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +1
    просто делаешь приватный метод, и он работает. private static тоже.
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +3

    Да, поэтому:
    1) в конпеляторе есть исследование литералов: http://openjdk.java.net/jeps/186 (это именно исследование, а не финальная спека). Она прям напрямую связана, с обсуждаемой здесь фичей convenience methods (http://openjdk.java.net/jeps/269). Фичу курирует Гёц.
    2) уже есть проротипы type values, я писал о них недавно, и буду еще. Фичу курирует Гёц же, и Роуз.


    Короче, всё будет, но не мгновенно. Возможно, ускорение релизного цикла, о котором недавно писал Рейнхольт, позволит выкатить подобные mast-have фичи поперед других, более масштабных, изменений, и мы увидим их в ближайшем будущем.

  • Готовимся к Java 9. Обзор самых интересных улучшений
    +1
    java.util.stream.IntStream.range(1, 10).dropWhile(x -> x < 5).forEach(System.out::println)
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +5
    Борис Бритва, или Борис-Хрен-Попадешь, резкий, как удар серпом по яйцам, и жесткий, как удар молотом. Живой советский герб. Говорят, эту сволочь вообще невозможно убить.

    www.youtube.com/watch?v=n7itx7O3b_k
  • Готовимся к Java 9. Обзор самых интересных улучшений
    +7
    public interface Отрывать {
        AtomicInteger руки = new AtomicInteger(10);
        private static void заТакое() {
            руки.set(11);
        }
    }
    
  • Готовимся к Java 9. Обзор самых интересных улучшений
    –16

    Друзья, внесу немного оффтопика сейчас, т.к. завтра будет поздно. Сегодня (31 августа) — последний день, когда на Joker 2017 всё еще можно купить билеты по вкусной летней стоимости. До конца дня остались считаные часы. Кто хотел определиться — определяйтесь сейчас.

  • Spring MVC — основные принципы
    0
    Подсказываю тему для статьи: можно этот же туториал превратить в совершенно небанальный, если взять альфа-версию спринга и сделать всё на экспериментальных фичах.
  • Эволюция DevOps
    0
    судя по описанию, к работе SRE или process automation scientist aka «человек-девопс» это вакансия вообще никакого отношения не имеет

    либо имеет, но они не смогли выразить свои желания в тексте

    может, стоит оказать им платную консультацию, и объяснить суть проблемы? :)
  • Эволюция DevOps
    +1
    Какие факторы наиболее сильно влияют на экономическую составляющую вопроса? Скорость разработки? Оверхед гиперконвергентной среды? Еще что-то?
  • Minimal Value Types
    +1
    Сорри. Fixed. Руки слегка дрожали и иногда сами писали странные слова :)