• Создание Dashboard в Kibana для мониторинга логов

    • Tutorial


    Привет, меня зовут Евгений, я тимлид B2B-направления в Ситимобил. Одной из задач нашей команды является поддержка интеграций по заказу такси от партнеров, и для обеспечения стабильного сервиса мы всегда должны понимать, что происходит в наших микросервисах. И для этого надо постоянно следить за логами.

    В Ситимобил для работы с логами мы используем ELK-стек (ElasticSearch, Logstash, Kibana), и объём приходящих туда данных огромен. Найти в этой массе запросов проблемы, которые могут появиться после деплоя нового кода, довольно сложно. И для их наглядного выявления в Kibana есть раздел Dashboard.

    На Хабре есть довольно много статей с примерами, как настроить ELK-стек для получения и хранения данных, но о создании Dashboard актуальных материалов нет. Поэтому я хочу показать, как в Kibana создавать визуальное представление данных на основе приходящих логов.

    Читать дальше →
    • +13
    • 3,7k
    • 3
  • Русский перевод книги «The Rust Programming Language» (TRPL)

      Добрый праздничный день.

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

        Мой список книг, которые мне хочется прочесть, изрядно вырос, спасибо топику “запасаемся на зиму”. Под катом вы обнаружите список книг, составленный по комментариям в том топике.
        Читать дальше →
        • +109
        • 55,1k
        • 88
      • Адаптационный чек-лист как инструмент мягкого введения в должность

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

          Процесс адаптации можно пустить на самотек. Учитывая затраты отдела HR, руководителя отдела, тимлида и других сотрудников на поиск подходящих кадров, это неэффективный подход. Когда новичок поймет, что ему никто не помогает влиться в коллектив, просто уйдет на испытательном сроке. Если останется, то адаптация займет слишком много времени, ее же никто не контролирует.



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

          Настроить систему поможет адаптационный чек-лист. Он содержит в себе ключевые аспекты адаптации на разных этапах введения в должность: зоны адаптации, какие навыки и в какой последовательности должен изучить новичок, система наставничества, аттестация и обратная связь. Подробнее о том, что такое чек-лист и как он работает, расскажет Алексей Петров (pifagor_mc).
          Читать дальше →
        • Реверс-инжиниринг домашнего роутера с помощью binwalk. Доверяете софту своего роутера?

          • Перевод
          • Tutorial


          Несколько дней назад, я решил провести реверс-инжиниринг прошивки своего роутера используя binwalk.


          Я купил себе TP-Link Archer C7 home router. Не самый лучший роутер, но для моих нужд вполне хватает.


          Каждый раз когда я покупаю новый роутер, я устанавливаю OpenWRT. Зачем? Как правило производители не сильно заботятся о поддержке своих роутеров и со временем софт устаревает, появляются уязвимости и так далее, в общем вы поняли. Поэтому я предпочитаю хорошо поддерживаемую сообществом open-source прошивку OpenWRT.


          Скачав себе OpenWRT, я так же скачал последний образ прошивки под мой новый Archer C7 с официального сайта и решил проанализировать его. Чисто ради фана и рассказать о binwalk.

          Читать дальше →
        • Почему Discord переходит с Go на Rust

          • Перевод


          Rust становится первоклассным языком в самых разных областях. Мы в Discord успешно используем его и на серверной, и на клиентской стороне. Например, на стороне клиента в конвейере кодирования видео для Go Live, а на стороне сервера для функций Elixir NIF (Native Implemented Functions).

          Недавно мы резко улучшили производительность одной службы, переписав её с Go на Rust. В этой статье объясним, почему для нас имело смысл переписать службу, как мы это сделали и насколько повысилась производительность.
          Читать дальше →
        • Исследование рынка тимлидов в России



            Две недели назад к нам в New.HR пришел Егор Толстой (YourDestiny) и попросил собрать данные для его доклада на TeamLeadConf.

            Егора интересовало:

            • Сколько вакансий тимлидов есть на рынке.
            • Какое количество вакансий закрывается внешними кандидатами, а какое – внутренними.

            У нас было всего две недели до конференции, желание сделать интересный анализ рынка тимлидов, и вот что мы успели за это время:
            Читать дальше →
          • Какие английские слова IT-лексикона мы неправильно произносим чаще всего

              Пока пара новых статей на технические темы еще в процессе написания, я решил опубликовать небольшой лингвистический материал. Достаточно часто замечаю, что коллеги, у которых английский язык — не родной, неправильно произносят некоторые характерные для IT сферы слова. И дело здесь не в том, насколько аутентично произносятся отдельные звуки, а именно в транскрипции. Регулярно встречал ситуации при общении с носителями, когда неправильно произносимое слово приводило к недопониманиям.

              Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.
              Читать дальше →
            • Короткая шпаргалка по блокировкам при чтении и изменении данных в зависимости от уровня изоляции транзакции в MSSQL

                Read Uncommitted

                • если в одной транзакции поменять данные — селект этих данных (в другой транзакции или без транзакции) не будут ждать окончания первой транзакции и вернут записанные данные незакомиченных транзакций
                • если в одной транзакции считать данные — апдейты этих данных в другой транзакции не будут ждать окончания первой транзакции
                • шаред локи не используются. Что аналогично установке NOLOCK хинта во все селекты в Read Commited
                • эксклюзивные локировки устанавливаются в процессе выполнения стейтмента и снимаются по окончанию транзакции


                Read Committed + read_committed_snapshot off

                (alter database xxx set read_committed_snapshot off)

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


                Дальше
              • У меня нулевая текучка

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

                Из руководителей я был такой один, тем самым привлек к себе внимание. Ну и сам удивился – оказывается, когда от тебя не уходят сотрудники, это странно и необычно.

                В сумме я работал руководителем лет 7-10 (точно не знаю, какие периоды сюда включать), но нулевая текучка сохранилась. Никто никогда от меня не уходил, никого никогда я не выгонял. Только набирал.

                Нулевая текучка, как показатель, никогда не была моей самоцелью. Но я стараюсь делать так, чтобы вложенные в людей усилия не пропадали даром. Сейчас расскажу примерно, как я руковожу так, что люди не уходят – вдруг что полезное для себя найдете. На полноту раскрытия темы не претендую, т.к. основываюсь только на личном опыте. Вполне возможно, что я всё делаю неправильно.
                Читать дальше →
              • Книга «Элегантные объекты. Java Edition»

                  imageПривет, Хаброжители! Эта книга всерьез пересматривает суть и принципы объектно-ориентированного программирования (ООП) и может быть метафорически названа «ООП Лобачевского». Егор Бугаенко, разработчик с 20-летним стажем, критически анализирует догмы ООП и предлагает взглянуть на эту парадигму совершенно по-новому. Так, он клеймит статические методы, геттеры, сеттеры, изменяемые методы, считая, что это — зло. Для начинающего программиста этот томик может стать просветлением или шоком, а для опытного является обязательным чтением.

                  Отрывок «Не используйте статические методы»


                  Ах, статические методы… Одна из моих любимых тем. Мне понадобилось несколько лет, чтобы осознать, насколько важна эта проблема. Теперь я сожалею обо всем том времени, которое потратил на написание процедурного, а не объектно-ориентированного программного обеспечения. Я был слеп, но теперь прозрел. Статические методы — настолько же большая, если не еще большая проблема в ООП, чем наличие константы NULL. Статических методов в принципе не должно было быть в Java, да и в других объектно-ориентированных языках, но, увы, они там есть. Мы не должны знать о таких вещах, как ключевое слово static в Java, но, увы, вынуждены.. Я не знаю, кто именно привнес их в Java, но они — чистейшее зло.. Статические методы, а не авторы этой возможности. Я надеюсь.
                  Читать дальше →
                • Как проводить Code Review по версии Google

                    Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

                    И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.


                    Итак, поехали

                    Читать дальше →
                  • Ближе к земле: как я сменил коворкинг на дом в деревне

                      От редакции блога: наверняка многие помнят историю про поселок программистов в Кировской области — начинание экс-разработчика из Яндекса впечатлило многих. А наш разработчик решил создать свое поселение в братской стране. Передаем ему слово.



                      Привет, меня зовут Георгий Новик, я работаю бэкенд-разработчиком в Skyeng. В основном реализую хотелки операторов, менеджеров и других заинтересованных лиц в отношении нашей большой CRM, а еще подключаю всякие новомодные вещи для customer service — ботов для техподдержки, сервисов автоматического прозвона и пр.

                      Как и многие разработчики, я не привязан к офису. Что делает человек, который не обязан ежедневно ездить в контору? Один отправится жить на Бали. Другой осядет в коворкинге или на родном диване. Я же выбрал совсем другое направление и переехал на хутор в белорусских лесах. И теперь от меня до ближайшего приличного коворкинга 130 километров.
                      Читать дальше →
                    • Сколько стоят тестировщики и от чего зависят их зарплаты? Строим портрет успешного QA-специалиста

                        ЗП тестировщиков

                        В начале 2019 года мы (совместно с порталами Software-testing.ru и Dou.ua) провели исследование уровня оплаты труда QA-специалистов. Теперь мы знаем сколько стоят услуги тестировщиков в разных уголках планеты. А ещё мы знаем какими знаниями и опытом должен владеть QA-специалист, чтобы сменить душный кабинет и скромный оклад, на пляжный шезлонг и толстую пачку валюты. Хотите узнать обо всём подробнее? Читайте нашу статью.
                        Читать дальше →
                      • PhpStorm 2019.1: Отладка шаблонов Twig и Blade, поиск мертвого кода, улучшенное автодополнение и многое другое



                          Привет, Хабр!

                          Рады представить первый мажорный релиз PhpStorm в этом году!
                          Обзор релиза можно посмотреть на странице “What’s new”. А под катом дополненный перевод этой страницы с демонстрацией самых интересных новых возможностей.
                          Читать дальше →
                        • Сезон конференций компании Ontico по традиции открыла московская TeamLead Conf. Она собрала 1137 человек, а это +134% относительно прошлого года. Значит ли это, что тимлидов стало больше? Или вечно занятые управленцы наконец нашли время для вылазки в свет? Эксперимента ради мы решили продолжить репортажи от лица участников и отправились примерять на себя костюм тимлида.
                          Подробности — под катом
                        • Коммуникации как performance-зона работы тимлида

                            Участники Saint TeamLead Conf назвали доклад Александра Зизы одним из лучших вероятно потому, что от навыков коммуникации тимлида зависит многое, а развиты они, как правило, не очень хорошо.

                            Рассказ будет состоять из четырех смысловых блоков:

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

                            1. Высокоэффективные коммуникации: 4 типа позиционной коммуникации. Эта часть посвящена техническим вопросам, связанным с построением высокоэффективной коммуникации. Грубо говоря, что нужно делать в конкретной ситуации, для того чтобы коммуникация была эффективна.

                            1. Мастерство: 4 уровня развития компетентности. Здесь поговорим про личное мастерство руководителя, который осуществляет свое управленческое воздействие через коммуникацию.

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




                            Ниже вы найдете видео и текстовую версию этого выступления, но просто так посмотреть или прочитать его недостаточно. Надо постараться тут же начать применить подходы на практике, и Александр вас в этом убедит. Фактически это часть программы по развитию управленческих компетенций, по прокачке навыков тимлида с подробным руководством к действию и заготовкой для домашнего задания.
                            Читать дальше →
                            • +25
                            • 11,5k
                            • 7
                          • Сюрпризы планировщика запросов в БД PostgreSQL

                              Графики, отчеты и аналитика – все это так или иначе присутствует в back-office любого, даже совсем маленького, предприятия. Когда в обычных таблицах в Excel/Numbers/Libre становится уже тесно, но data все еще не очень big, традиционные решения для внутренних потребностей компании часто строятся с помощью реляционных баз данных, таких как PostgreSQL, MySQL или MariaDB.

                              Эти базы данных бесплатны, благодаря SQL удобно интегрируются с остальными компонентами в системе, они популярны и с ними умеют работать большинство разработчиков и аналитиков. Нагрузку (трафик и объемы) они могут переварить достаточно объемную, чтобы спокойно продержаться до того момента, когда компания сможет позволить себе более сложные (и дорогие) решения для аналитики и отчетов.
                              Однако даже в многократно изученной технологии всегда существуют разные нюансы
                              • +38
                              • 10,8k
                              • 4
                            • Как сделать код-ревью быстрее и эффективнее

                              • Перевод
                              image

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

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

                              Получается, что чем объемнее пул-реквест, тем меньше пользы будет от его проверки.
                              Читать дальше →
                            • Типичные ошибки при работе с PostgreSQL. Часть 1

                                Чуть более месяца назад в Москве состоялась крупнейшая конференция постгресового сообщества PGConf.Russia 2019, собравшая в МГУ свыше 700 человек. Мы решили выложить видео и расшифровку лучших докладов. Выступление Ивана Фролкова с разбором типичных ошибок при работе с PostgreSQL было отмечено лучшим на конференции, поэтому мы начнем с него.

                                Для удобства мы разбили расшифровку на две части. В этой статье речь пойдет о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. Во второй части будут разобраны обработка ошибок, конкурентный доступ, неотменяемые операции, CTE и JSON.



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

                                Главный вывод, который я смог сделать из того, что я видел, довольно неожиданный: фактически любое приложение при должной настойчивости можно заставить работать. Был замечательный проект (я не могу упоминать все компании, с которыми мы работали), в котором еще более замечательное приложение создавало таблицы миллионами. Выглядело это так: в понедельник система работает неплохо, а уже в пятницу она практически не работает. На выходные дни запускают VACUUM FULL, и в понедельник она опять работает хорошо. Оказывается, над PostgreSQL можно вот так издеваться, и всё это довольно долго будет жить и работать. Другой товарищ сделал странную вещь: у него всё было построено на триггерах, процедур не было вообще. То есть большую часть таблиц трогать нельзя, сделать что-либо не получалось, но и эта база жила.
                                Читать дальше →