• Как Амплифер использует Logux — инструмент для связи клиента и сервера

      Logux — инструмент для связи клиента и сервера


      Меня зовут Виталий Ризо, я старший фронтенд-разработчик в «Амплифере». Поделюсь, как мы применяем Logux в веб-приложении: организуем обмен данными в реальном времени, уведомления об ошибках без перезагрузки страницы, общение между вкладками браузера и интеграцию с Redux.

      Читать дальше →
    • Как заработать на API Яндекс.Денег


        С вас — идеи монетизации стриминга и реализация на API Яндекс.Денег, с нас — аудитория, реклама и деньги.


        Шестой день рождения API переводов мы решили отпраздновать антихакатоном, на котором любой желающий может попробовать свои силы в борьбе за джекпот. Помимо денежного приза в 100 000 рублей мы поделимся с победителем прибылью от переводов через Яндекс.Деньги.


        Приглашаем под кат всех индивидуальных разработчиков, предпринимателей и команды стартапов.

        Читать дальше →
      • Как я чуть не выкинул 150к на ветер или история установки приточной вентиляции в квартире

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


          Читать дальше →
        • Ускоряем сборку веб-приложения с webpack

          По мере того как ваше приложение развивается и растёт, увеличивается и время его сборки — от нескольких минут при пересборке в development-режиме до десятков минут при «холодной» production-сборке. Это совершенно неприемлемо. Мы, разработчики, не любим переключать контекст в ожидании готовности бандла и хотим получать фидбек от приложения как можно раньше — в идеале за то время, пока переключаемся с IDE на браузер.


          Как этого достичь? Что мы можем сделать, чтобы оптимизировать время сборки?


          Эта статья — обзор существующих в экосистеме webpack инструментов для ускорения сборки, опыт их применения и советы.


          Оптимизации размера бандла и производительности самого приложения в этой статье не рассматриваются.

          Читать дальше →
        • Краткий и бодрый обзор архитектуры компиляторов

          • Translation

          Большинство компиляторов имеют следующую архитектуру:



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

          Целевая аудитория статьи — люди, чье представление о работе компиляторов крайне ограничено (максимум — то, что они занимаются компилированием). Однако я жду, что читатель разбирается в структурах и алгоритмах данных.

          Статья ни в коем случае не посвящена современным производственным компиляторам с миллионами строк кода — нет, это краткий курс «компиляторы для чайников», помогающий разобраться, что такое компилятор.
          Читать дальше →
        • 10 основных ошибок в попытке изменить привычки и как их исправить

            Недавно натолкнулся на хорошую и краткую презентацию по GTD от Persuasive Technology Lab (Stanford). Эта тематика как и любому гику мне близка и интересна, книг было прочтено много, опыт работы есть уже значительный, в итоге выработался некий концепт того, как я считаю правильно не только работать, но менять свои привычки, который сильно пересекается с тем что я прочитал в презентации. Далее перечислены ошибки, которые мы обычно совершаем в попытке изменить свое поведение, привычки и жирным выделено их решение. На мой взгляд этот список полезен и при решении любых других задач.

            1. Опираться на силу воли для долгосрочных изменений.
            Представьте что силы воли просто нет. Это первый шаг к лучшему будущему.

            2. Планировать и предпринимать большие шаги и задачи, вместо маленьких.
            Успешно выполняйте небольшие задачи — одну за другой.
            Читать дальше →
          • Не рычите на собаку

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


              Читать дальше →
            • Как работает Headless Chrome

                Уже из названия понятно, что headless-браузер — это нечто без головы. В контексте фронтенда — это незаменимый инструмент разработчика, с помощью которого можно тестировать код, проверять качество и соответствие верстке. Виталий Слободин на Frontend Conf решил, что необходимо познакомиться с устройством этого инструмента поближе.

                Под катом компоненты и особенности работы Headless Chrome, интересные сценарии использования Headless Chrome. Вторая часть про Puppeteer — удобную Node.js-библиотеку для управления Headless-режимом в Google Chrome и Chromium.


                О спикере: Виталий Слободин — бывший разработчик PhantomJS — тот, кто закрыл его и похоронил. Иногда помогает Константину Токареву ( annulen) в «воскрешенной» версии QtWebKit — том самом QtWebKit, где есть поддержка ES6, Flexbox и многие других современных стандартов.

                Виталий любит исследовать браузеры, в свободное время копаться в WebKit, Chrome и прочее, прочее. Про браузеры сегодня и поговорим, а именно про безголовые браузеры и всю их семейку призраков.
                Читать дальше →
              • Работа большой распределенной команды: преимущества удаленки, решения проблем, полезные инструменты


                  Всем привет! Меня зовут Алексей, я тимлид команды Vimbox (платформа для обучения в Skyeng). Не так давно я выступал на конференции с докладом об удаленной работе и особенностях распределенной команды. Неожиданно темой заинтересовалось много людей, хотя я думал, что хайп уже прошел и никого не удивить. Поэтому я решил поделиться и с вами наработками, полученными за четыре года функционирования в этом формате. Поскольку у нас в компании из 55 разработчиков 51 человек постоянно работает вне офиса, да и сам я живу в Калининграде, думаю, наш опыт многим может пригодиться.

                  Читать дальше →
                • Webpack 4, import() и CommonJS

                  • Translation

                  В JavaScript много забавного. У одного из самых популярных в мире языков программирования до сих пор нет стабильного синтаксиса разбиения кода на части. То есть в стандарте синтаксис ESM с «import» наперевес уже есть, но в браузерах и ноде он спрятан за флагами, а в вебпаке его поддержка появилась совсем недавно во 2-й версии. Добавим к этому миграцию ноды и вебпака с CommonJS «require» на ESM «import» и полмиллиона пакетов NPM, подавляющая часть которых использует CommonJS. Немного разобраться с зоопарком поможет вышедшая на прошлой неделе статья от автора Webpack, адаптированнй перевод которой ждет вас под катом.
                  Читать дальше →
                  • +31
                  • 14.3k
                  • 1
                • Team Leader. Быть или не быть, вот в чем вопрос

                  image


                  Данную статью меня побудил написать тот скрытый и для каждого свой смысл должности/роли Team Leader. Многие хотят им стать, многим интересно что там, "под капотом", работы в этой должности. Поэтому кому интересно узнать еще одно мнение об этом всем безобразии, то прошу под кат.

                  Читать дальше →
                • 44 урока управления технарями

                    Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.

                    Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.

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

                    Источник
                    Читать дальше →
                  • 15 тривиальных фактов о правильной работе с протоколом HTTP

                      Внимание! Реклама! Пост оплачен Капитаном Очевидность!

                      Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



                      Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

                      Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.
                      Читать дальше →
                    • Полное практическое руководство по Docker: с нуля до кластера на AWS

                      • Translation



                      Содержание



                      Вопросы и ответы


                      Что такое Докер?


                      Определение Докера в Википедии звучит так:


                      программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.



                      Ого! Как много информации.

                      Читать дальше →
                    • Полная автоматизация «development» среды с помощью docker-compose

                      • Tutorial

                      В этой статье мы поделимся опытом автоматизации запуска, тестирования и конфигурации больших проектов с использованием docker-compose. Несколько простых изменений могут помочь Вашей команде быть более эффективной и тратить время на важные, а не на рутинные задачи.


                      Docker в 2017


                      На конференции Dockercon 2016 CEO компании Docker рассказал, что количество приложений, которые запускаются в Docker выросло на 3100% за последние два года. Боле 460 тысяч приложений по всему миру запускаются в Docker. Это невероятно!


                      Если вы все еще не используете Docker, я бы посоветовал почитать отличную статью об использовании Docker во всем мире. Docker полностью изменил то, как мы пишем приложения и стал неотъемлемой частью для разработчиков и DevOps команд. В этой статье мы полагаем, что вы уже знакомы с Docker и хотим дать вам еще одну серьезную причину продолжать использовать его.

                      Читать дальше →
                    • Brubeck — быстрый, statsd-совместимый агрегатор метрик от GitHub



                        История появления


                        Одной из главных целей команды разработчиков GitHub всегда была высокая производительность. У них даже существует поговорка: «it's not fully shipped until it's fast» (продукт считается готовым только тогда, когда он работает быстро). А как понять, что что-то работает быстро или медленно? Нужно мерять. Измерять правильно, измерять надёжно, измерять всегда. Нужно следить за измерениями, визуализировать всевозможные метрики, держать руку на пульсе, особенно, когда дело имеешь с высоконагруженными онлайн системами, такими как GitHub. Поэтому метрики — это инструмент, позволяющий команде предоставлять столь быстрые и доступные сервисы, почти без даунтаймов.

                        В своё время GitHub одними из первых внедрили у себя инструмент под названием statsd от разработчиков из Etsy. statsd — это агрегатор метрик, написанный на Node.js. Его суть состояла в том, чтобы собирать всевозможные метрики и агрегировать их в сервере, для последующего сохранения в любом формате, например, в Graphite в виде данных на графике. statsd — это хороший инструмент, построенный на UDP сокетах, удобный в использовании как на основном Rails приложении, так и для сбора простейших метрик, наподобие вызова nc -u. Проблема с ним начала проявляться позже, по мере роста количества серверов и метрик, отправляемых в statsd.
                        Читать дальше →
                      • Что такое хорошо: как мы разрабатывали критерии для оценки качества вёрстки веб-проектов



                          На Хабре уже было немало материалов о том, как проводить качество вёрстки веб-проектов (вот отличная статья на эту тему) — как правило, речь в таких топиках идёт о коммерческих сайтах. В ходе развития образовательного проекта HTML Academy мы также столкнулись с необходимостью выработки критериев для оценки работ учеников.

                          Очевидно, что учить нужно так, чтобы потом люди (не все из которых «технари») могли приходить в компании и работать «правильно» — то есть создавая вёрстку, которая красиво выглядит и не требует больших усилий по поддержке. Процесс создания списка универсальных критериев для оценки занял довольно длительное время и был сопряжён с рядом трудностей. Сегодня мы расскажем о том, что же у нас в итоге получилось.
                          Читать дальше →
                        • Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать

                            Идеальная вёрсткаВы PM. Как узнать – готова ли вёрстка к реальному использованию?
                            Вы заказчик. Как убедиться, что работа выполнена качественно?
                            Как оценить качество вёрстки?

                            Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

                            Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

                            Итак что же это за список?

                            Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

                            История обновлений:
                            • 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
                            • 2015/08/10: актуализирован список исключений для CSSLint
                            • 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
                            • 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
                            • 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
                            • 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
                            • 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
                            • 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
                            • 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
                            • 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.


                            Далее с примерами - как проверить html, даже если вы ничего не понимаете в вёрстке.
                          • Как мы тестируем CSS-регрессии с Gemini. Доклад на BEMup в Яндексе

                              Всем привет! Меня зовут Сергей Татаринцев. В Яндексе я работаю в группе разработки общих интерфейсов. Наша группа занимается созданием интерфейсных библиотек, используемых во многих сервисах, — в том числе в Поиске. Мы поддерживаем четыре библиотеки, которые в общей сложности включают в себя 62 блока.

                              Если посчитать все десктопные и мобильные браузеры всех версий, то получается, что у нас в поддержке их более 15. Около года назад их все мы тестировали вручную. Тестировщик просто брал и прокликивал все это во всех браузерах и смотрел, не поехало ли что-нибудь, работает ли так, как было задумано. Это приводило к тому, что процесс релиза очень затягивался. Вплоть до того что разработка и тестирование занимали приблизительно одинаковое время. Многие баги ускользали от глаз тестировщика или обнаруживались через достаточно продолжительное время.



                              Мы решили, что дальше так жить нельзя и решили процесс тестирования как-то автоматизировать. Начали мы с инструментов статического анализа. Для проверки стиля кода у нас используется инструмент jscs, написанный нашим коллегой Маратом Дулиным. Для статического анализа кода применяется всем известный JSHint. А для отлова регрессий в JS мы пишем юнит-тесты. Это в какой-то мере помогло справиться с проблемой: анализаторы отлавливали совсем уж глупые ошибки, а тесты позволили проверять функциональность блока. А вот с регрессиями в CSS был пробел. Тестирование внешнего вида по-прежнему проводилось руками и глазами тестировщика. Мы стали искать инструменты, которые помогали бы нам в автоматизации.
                              Читать дальше →
                            • .vimrc для фронтендера

                                Привет, я занимаюсь фронтенд разработкой, и как-то так сложилось, что в своей повседневной работе активно использую vim.

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

                                Под катом я опишу основные фишки конфига. Vim использую в связке c iTerm и темой solarized, но конфиг с минимальными изменениями подходит для любого терминала и любой темы. Из-за подробного описания каждой опции он будет очень полезен для тех, кто по каким-то причинам решил перейти на вим недавно.

                                Как ни странно — в статье много картинок ;)
                                Читать дальше →