• Лучшая архитектура на базе Docker и Kubernetes — миф или реальность?

      Как изменился мир разработки ПО в эпоху Docker и Kubernetes? Можно ли построить архитектуру один раз и навсегда на базе этих технологий? Возможно ли унифицировать процессы разработки и интеграции, когда все "упаковано" в контейнеры? Какие требования предъявляются таким решениям? Какие ограничения несут они с собой? Упростят ли они жизнь простым разработчикам или сделают её тяжелее?



      Пришло время ответить на все эти и не только эти вопросы! (В тексте и оригинальных иллюстрациях)

      Читать дальше →
    • Как и почему мы переосмыслили поисковое поле ввода Яндекса

        Мы уже дважды рассказывали про наши поисковые подсказки: первый пост вышел аж в 2012 году, второй же случился совсем недавно.



        Поисковые подсказки — одна из тех штук, которыми компания может гордиться, поэтому нам не кажется зазорным рассказывать о них часто. Сегодня мы поговорим о функциональных изменениях в поисковых подсказках, произошедших в 2017 году. Речь пойдёт не только об изменениях в интерфейсе, но и об интересной статистике и технологических вызовах, которые она поставила перед нами.


        1. «Расширяющееся» поле ввода


        К началу 2017 года многие мессенджеры уже обладали «резиновыми» полями ввода. Человек, пишущий достаточно длинный текст, конечно, хочет иметь возможность увидеть если не текст целиком, то хотя бы значительную его часть.


        Удивительно, что поисковые системы полностью проигнорировали этот тренд. А ведь длинные запросы составляют значительную часть потока. Скажем, запросы, содержащие более семи слов, составляют до 10% всего потока запросов к Яндексу!

        Читать дальше →
      • «Оч.умелые ручки»: делаем Tableau/Qlik из R и «синей изоленты»

          Является продолжением предыдущих публикаций.


          Естественно, что название является потешным, но, как хорошо известно, в каждой шутке есть доля правды. Сама тема возникла, когда в очередной сотый раз пришлось слышать настойчивое пожелание о том, что необходим «гибкий конструктор отчетов/графиков». После определенного момента проще взять и сделать, чем в очередной раз объяснять, что tidyverse покрывает все необходимые потребности.



          Сама постановка задачи предельно проста: обеспечить графический интерфейс для рисования разнообразных графических представлений по произвольным табличным данным. Классическое решение представляет собой две связанные сущности:


          • интерфейс с большим-большим количеством менюшек и кнопочек, с множественными закулисными IF для управления взаимными состояниями этих элементов;
          • «гибкий плоттер» с большим количеством вложенных IF для отрисовки графиков в соотвествии со скормленным данными и положением кнопочек-ползунков, выставленных в UI.

          С одной стороны делать «Yet Another Tableau» совершенно неинтересно. С другой стороны, постановка в стиле «сделать так, чтобы все было, но ничего не надо делать» — типичная задача для ТРИЗ.


          В целом, после непродолжительных размышений было выработано решение, которое почти удовлетворяет последней постановке. Само Shiny приложение пока под NDA, свободно публикуемый прототип приведен на картинке.



          Две ключевых идеи по упрощению задачи следующие (ничего нового, все уже придумано до нас):


          1. вместо статически заданного UI переходим к динамически генерируемому;
          2. используем интерпретатор R не только для исходного кода, но и внутри самого кода.

          Идея 1. Динамический web-интерфейс


          Вариант, когда все управляющие элементы статически заданы и меняется лишь их параметризация (название, состояние, списки, выбранные элементы ...) удобен на этапе дизайна. Все понятно, все очевидно, можно ручками пощупать. Но если допустимые состояния этих элементов очень сильно связано как с исходными данными для анализа (data.frame), так и с состоянием друг друга, мы попадаем в ситуацию весьма большого количества нетривиальных обработчиков событий по каждому элементу. Много-много запутанного кода.


          Сделаем по-другому. Вместо UI элементов со сложным поведением раскидываем с помощью uiOutput placeholder-ы, в которые динамически рассчитываем и генерируем с помощью shiny::renderUI представление этого элемента. Все внешние параметры, требуемые для генерации элемента, трактуем как реактивные элементы (reactive). При этом все такие интерактивные элементы выступают в качестве «автономных агентов», которые смотрят на окружение и подстраиваются под него. Пользователь изменил состояние одного элемента — все зависимые стали пересчитывать по очереди свое состояние (мы явно не обрабатываем события, а используем реактивный подход shiny). При изменении их состояния могут возникнуть новые индуцированные изменения. И так, пока все не стабилизируется.


          В результате, в коде остается только один обработчик (кнопка «Go»)
            observeEvent(input$gen_plot, { # код демонстрирует принцип
          
              escname <- function(x){
                # имена колонок надо закавычить
                # .....
              }
          
              point_code <- ""
              if(input$shape_type!="__NO_MAPPING__") {
                aes <- c("shape"=escname(input$aes_shape_col), "color"=escname(input$aes_color_col))
                point_code <- buildPointCode(fixed=c("shape"=input$shape_type, "color"=glue("'{input$plot_color}'")), aes=aes)
              }
          
              line_code <- ""
              if(input$line_type!="__NO_MAPPING__") {
                aes <- c("linetype"=escname(input$aes_linetype_col), "color"=escname(input$aes_color_col))
                line_code <- buildLineCode(fixed=c("linetype"=input$line_type, "color"=glue("'{input$plot_color}'")), aes=aes)
              }
          
              gcode <- glue("ggplot(data_df(), aes(x=`{input$x_axis_value}`, y=`{input$y_axis_value}`))\\
                            {point_code} {line_code} + xlab('{input$x_axis_label}')") %>%
                style_text(scope="spaces")
          
              plot_Rcode(gcode)
            })  
          Читать дальше →
        • Динамическая идентификация объектов управления

            Введение


            Идентификация объектов управления — совокупность методов для построения математических моделей объекта по данным наблюдений.

            Математическая модель в данном контексте означает математическое описание поведения какого-либо объекта или процесса в частотной или временной области, к примеру, физических процессов (движение механической системы под действием внешней силы [1]), экономического процесса (влияние смены курса валют на потребительские цены на товары [2]).

            В настоящее время эта область теории управления находит широкое применение на практике и поэтому интересна для рассмотрения.

            Область динамической идентификации объектов управления в связи с различной природой самих объектов достаточно обширна, поэтому для начала ограничимся рассмотрением методов обработки так называемой кривой разгона.

            Кривой разгона называют процесс изменения во времени выходной переменной, вызванный ступенчатым входным воздействием. Кривая разгона служит для определения динамических свойств объекта.
            Читать дальше →
          • R и Информационная безопасность. Как устранить противоречие интересов и запустить R на Linux в оффлайн-режиме

              Является продолжением предыдущих публикаций.


              Очень часто попытки применить инструменты DataScience в корпоративной среде встают в полное противоречие с требованиями Службы Информационной Безопасности (СИБ). В мире DataScience рекомендация «поставь с гитхаба» становится практически нерешаемой при полной изоляции аналитической машины от интернета. Тем не менее, задача запуска на linux инфраструктуры R в offline окружении вполне решаемая. Ниже приведу последовательность мантр, которые позволят это исполнить. Если какие-то шаги будут не совсем прозрачными, то скорректирую по мере появления комментариев. Эти же шаги можно использовать и для online инсталляции, пропуская шаги, относящиеся к хитрым трюкам или созданию локальных репозиториев. Собрано по крупицам на основании многократных инсталляций под разнообразные задачи. Практика показала, что тема весьма актуальна.


              Читать дальше →
            • API BIM-системы Renga

                Всем привет! В этой статье я расскажу об API BIM-системы Renga. О самой системе можно почитать тут, здесь же можно запросить версию для некоммерческого использования. Если вкратце, то Renga это трехмерная система автоматизированного проектирования в архитектуре и строительстве. В ней проектировщик/архитектор/конструктор работает с информационной моделью здания, получает ассоциативные чертежи, спецификации, в общем, создает проект.



                Зачем нужно API CAD-системы


                Сначала, как водится, немного водички.

                Разработка расширений для CAD систем довольно распространена, поскольку в любом проектировании существуют различные направления, разделы и стандарты оформления проектной документации, которые требуют разной узкоспециализированной функциональности. Кроме того существуют задачи интеграции с программами расчета, визуализации, документооборота и многими другими. Выход — создание подключаемых модулей, расширяющих функциональность системы.
                Читать дальше →
              • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

                Подробнее
                Реклама
              • Conan: менеджер зависимостей для C/C++

                • Tutorial
                image

                Здравствуйте. Сегодня речь пойдёт про Conan — современный менеджер зависимостей для C/C++. Если Вы уже активно работаете с ним, то навряд ли найдёт что-нибудь новое для себя. Иначе — прошу под кат.
                Читать дальше →
              • Как у нас устроено AB-тестирование. Лекция Яндекса

                  AB-тестирование на сервисах Яндекса проводится постоянно. «Раскатить на такую-то долю аудитории» и посмотреть на реакцию людей — настолько стандартная практика, что ни у кого в команде не возникает вопроса, зачем это нужно. А чтобы не было проблем с самим тестированием, у нас есть специальная инфраструктура для экспериментов. Подробности рассказывают разработчики Сергей Мыц и Данил Валгушев.


                  Сергей:
                  — Я попробую упрощенно описать задачу AB-тестирования. Есть абстрактная система с пользователями, в нее мы вносим какие-то изменения, и нужно уметь измерять в ней пользу. Пока все просто, но слишком абстрактно. Пример. Есть веб-сервис по сравнению пары фотографий котов. Пользователь должен выбрать наиболее понравившуюся фотографию. При этом он может выбрать не только левый или правый снимок, но и «против всех». Значит, мы подобрали картинки не очень хорошо. Наша задача — обоснованно улучшать сервис, доказывая это цифрами.
                  Читать дальше →
                  • +49
                  • 13,2k
                  • 2
                • Шаблон проектирования “минисценарий с проверкой противоречий”

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

                    Последние пару лет я работаю в крупном проекте и наткнулся на некую закономерность, которая приводит к тотальному запутыванию кода. Код, который развивался лет двадцать командой около сотни человек трудно назвать кодом без эпитетов. Скорее это гора на десяток миллионов строк из всяких правильных и неправильных техник, умных идей, ухищрений, заплаток, копипастов на скорую руку и тд тп…

                    image

                    В организации, где я работаю, автоматизируют бизнес процессы, и обычно это связано с ведением базы данных. У нас принято работать по канонам, — сначала проводить бизнес анализ, составлять умное ТЗ, писать код, проводить тестирование и много всякой деятельности при дефиците времени. Первичная мотивация, вроде разумная, — “давайте будем разделять обязанности”, “давайте будем делать так, чтобы было безопасно” и тд и тп. Все эти приемы менеджмента с восторгом преподают на различных курсах, обещая много хайпа и охмурянта. Надеюсь, что читатель уже знаком с некоторыми модными словами, которые зачастую ни потрогать, ни налить нельзя. Но вопрос не об них, а о том, как программисту жить с ними.

                    Далее постараюсь объяснить, в чем разница между “бизнес логикой” и “строгой логикой”, на которую почему-то многие не обращают достаточного внимания. В результате оголтелого использования бизнес логики страдает просто логика, за которую боролись и математики и философы сотни лет. А когда страдает настоящая логика, то вместе с этим страдают сначала исполнители-технари, которые от безысходности могут начать лепить несуразное, чтобы лишь бы начальники отвязались. А потом бумерангом страдания возвращаются на источник “ярких супер бизнес идей”, заставляя их придумывать другие еще более “яркие супер бизнес идеи” или в конце концов надевать накладную бороду и темные очки, чтобы больше никто не узнавал на улице и не показывал пальцем.
                    Читать дальше →
                  • Использование R для «промышленной» разработки

                      Является продолжением предыдущих публикаций. Не секрет, что при упоминании R в числе используемых инструментов вторым по популярности является вопрос о возможности его применения в «промышленной разработке». Пальму первенства в России неизменно держит вопрос «А что такое R?»


                      Попробуем разобраться в аспектах и возможности применения R в «промышленной» разработке.


                      Читать дальше →
                    Самое читаемое