• Заблуждения Clean Architecture

      Превращаем круги в блоки

      ­­ 


      На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

      Читать дальше →
    • Взлом Wi-Fi

      • Перевод
      • Tutorial

      Взлом маршрутизаторов WPA/WPA2 Wi-Fi с помощью Airodump-ng и Aircrack-ng/Hashcat


      Это краткое пошаговое руководство, которое демонстрирует способ взлома сетей Wi-Fi, защищённых слабыми паролями. Оно не исчерпывающее, но этой информации должно хватить, чтобы вы протестировали свою собственную сетевую безопасность или взломали кого-нибудь поблизости. Изложенная ниже атака полностью пассивна (только прослушивание, ничего не транслируется с вашего компьютера) и о ней невозможно узнать, если вы только реально не воспользуетесь паролем, который взломали. Необязательную активную атаку с деаутентификацией можно применить для ускорения разведывательного процесса. Она описана в конце статьи.
      Читать дальше →
    • JavaScript как явление



      Сообщество nodejs безумно, и судя по тому что в 2016-2017 годах в различных рейтингах JavaScript брал первое место по популярности вытеснив оттуда с небольшим отрывом Java — безумие в последнее время действительно станосится массовым. Казалось бы — не хочешь не кушай, пиши на своём любимом Elixir / Erlang / Lisp / Haskell / любом другом языкое с хорошим дизайном и в ус не дуй, но в текущей ситуации к сожалению это правило перестаёт работать и приходится прилагать некоторые усилия чтобы его соблюдать.

      В чём причина популярности такого реально хренового языка как JavaScript? В принципе в том же в чём и причина популярности Java, да и вообще почти всех явлений культуры и общества
      Читать дальше →
    • Kubernetes & production — быть или не быть?

        Сотни контейнеров. Миллионы внешних запросов. Миллиарды внутренних транзакций. Мониторинг и нотификации проблем. Простое масштабирование. 99% up time. Деплои и откатывание релизов.


        Kubernetes как решение всех проблем! «Быть или не быть?» — вот в чем вопрос!
        Читать дальше →
      • Доставка миллиардов сообщений строго один раз

        • Перевод
        Единственное требование ко всем системам передачи данных состоит в том, что нельзя потерять данные. Данные обычно могут поступить с опозданием или их можно запросить заново, но их никогда нельзя терять.

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

        Но как пользователю по крайней мере однократная доставка — это не совсем то, что я хочу. Я хочу, чтобы сообщения доставлялись один раз. И только один раз.
        Читать дальше →
      • Тюним память и сетевой стек в Linux: история перевода высоконагруженных серверов на свежий дистрибутив

          image

          До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

          Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.
          Читать дальше →
        • Тюнинг сетевого стека Linux для ленивых

          • Tutorial

          Сетевой стек Linux по умолчанию замечательно работает на десктопах. На серверах с нагрузкой чуть выше средней уже приходится разбираться как всё нужно правильно настраивать. На моей текущей работе этим приходится заниматься едва ли не в промышленных масштабах, так что без автоматизации никуда – объяснять каждому коллеге что и как устроено долго, а заставлять людей читать ≈300 страниц английского текста, перемешанного с кодом на C… Можно и нужно, но результаты будут не через час и не через день. Поэтому я попробовал накидать набор утилит для тюнинга сетевого стека и руководство по их использованию, не уходящее в специфические детали определённых задач, которое при этом остаётся достаточно компактным для того, чтобы его можно было прочитать меньше чем за час и вынести из него хоть какую-то пользу.

          Читать дальше →
        • Как сделать высоконагруженный сервис, не зная количество нагрузки



            На конференции HighLoad++ 2016 Олег Облеухов рассказал о не требующей при росте нагрузки вмешательства администратора архитектуре, которую он спланировал и внедрил в компании InnoGames.

            Всем привет. Буквально пару слов обо мне. Меня зовут Олег, до этого я работал в компании «Яндекс», жил в замечательном городе Санкт-Петербурге. Сейчас я переехал в Германию и работаю в InnoGames. Компания занимается разработкой онлайн-игр. На счету 150 миллионов пользователей — достаточно большая компания, ну поменьше, чем «Яндекс», конечно. И сегодня мы поговорим с вами о том, как сделать высоконагруженный сервис без данных о нагрузке, не зная её количество.

            Прежде чем мы начнем. Теперь вы все знаете обо мне, я хотел бы узнать немножко об аудитории. Поднимите руку те, кто использует Docker на продакшне? Ну треть зала примерно, хорошо. А теперь из тех, кто поднял руку, поднимите те, кто доволен использованием Docker на продакшне? Значительно меньше. А теперь ещё более сложный вопрос. Те, кто доволен использованием Docker на продакшне, поднимите руку те, кто сисадмин или инженер, или еще кто-то не-разработчик. Я вижу троих. Окей.

            На самом деле мы не будем сегодня разговаривать о Docker. Но мы будем разговаривать о CRM. Я вам расскажу, что это такое, зачем нам нужна эта система.
            Читать дальше →
            • +21
            • 16,3k
            • 6
          • 9 причин, которые мешают вам стать тимлидом

              Хах! Кажется, что тимлид только и делает что таскает бумажки, пьет много кофе, шутит какие-то шутки, да и вообще он какой-то странный парень. Почему бы вам не занять его место? У вас большой опыт, вы знаете команду как свои пять пальцев, виртуозно владеете C++, С#, Java да и что там говорить — вы программист от бога!



              Только вот руководство не замечает что «вы тут вообще за всю команду тащите» и проекты вытягиваете за неделю до дедлайна. Короче, вам пора руководить! Вы спите и видите как классно у вас всё выходит, производительность увеличивается, тендеры один за одним, всеобщее признание команды и начальства уже ваше всё. Вот только повышение осталось получить. А теперь к делу. Что же все таки мешает такому крутому спецу как вы вывести все из болота и управлять миром?
              Читать дальше →
            • Стандарты и шаблоны для ТЗ на разработку ПО

                Введение


                Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

                И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

                • ГОСТ 34
                • ГОСТ 19
                • IEEE STD 830-1998
                • ISO/IEC/ IEEE 29148-2011
                • RUP
                • SWEBOK, BABOK и пр.
                Читать дальше →