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

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



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

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

Эти советы, возможно, не все найдут полезными. Они адресованы тем, кому на работе бывает скучно. Так скучно, что уныние немного скрашивают лишь утренний контактик и послеобеденный ютубчик. Вот именно от них вам придется отказаться. Зачем? Сейчас узнаете.

Прим. перев.: Сотрудники всемирно известного сервиса Tinder недавно поделились некоторыми техническими деталями миграции своей инфраструктуры на Kubernetes. Процесс занял почти два года и вылился в запуск на K8s весьма масштабной платформы, состоящей из 200 сервисов, размещённых на 48 тысячах контейнеров. С какими интересными сложностями столкнулись инженеры Tinder и к каким результатам пришли — читайте в этом переводе.

После нахождения уязвимостей в мобайл-банкинге украинского банка (пост) я захотел немного сменить направление и перейти от финансовых сервисов к другим.

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

Здесь инструменты те же: ПК, Fiddler, Android-смартфон – устанавливаем приложение и отслеживаем его запросы.

Я специально не рассматривал запросы и ответы при регистрации или логине (например, не стал проверять возможность перебора пароля), а перешёл к функциям, доступным после регистрации.

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

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

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

Сеть подов в кластере – аккуратный материал, но сам по себе он недостаточен для создания долгосрочных систем, поскольку поды в Kubernetes эфемерны. В качестве конечной точки можно использовать IP-адрес пода, но нет гарантии, что при следующем воссоздании пода адрес останется прежним. Его смена может произойти по любой причине.

Когда речь заходит об open source проектах, развиваемых компанией Cisco в области кибербезопасности, то большинство специалистов вспоминает только популярный Snort, возможно еще ClamAV, да описанный на страницах Хабра инструмент OpenSOC. На самом деле Cisco, являясь достаточно открытой компаний (у нас куча API для работы с нашими решениями по ИБ), очень активно работает в сообществе open source и предлагает пользователям несколько десятков проектов, из которых немалое количество посвящено кибербезопасности. В этой заметке мне бы хотелось собрать воедино все open source проекты компании Cisco, которые имеют отношение именно к этой теме.

Сегодня в России очень модной стала тема SOC и SIEM. Все их строят и пишут. Вы знали, что в России уже около десятка собственных систем мониторинга событий безопасности (SIEM)? Эту цифру перевалило и число коммерческих SOCов, предлагающих свои услуги заказчикам, которые попадут под требования 187-ФЗ о безопасности критической информационной инфраструктуры и вынуждены будут оперативно отдавать данные об инцидентах в ГосСОПКУ. Но какую бы цель не преследовали создатели SIEM и SOC, и на каком бы уровне зрелости они не находились, они все равно сталкиваются с базовой задачей — сбора событий безопасности и журналов регистрации от разрозненных средств защиты информации.

Согласно данным компании Canalys (а она единственная кто продолжает оценивать российский рынок решений по ИБ), лидером отечественного рынка продолжает оставаться компания Cisco. Поэтому вполне разумно предположить, что одной из первых задач, которая должна стоять перед разработчиками SIEM/SOC, — это интеграция с решениями нашей компании. Но вокруг такой интеграции бытует множество мифов и заблуждений, которые можно описать диалогом, который у меня недавно случился с одним из отечественных производителей SIEM:

— А почему вы не интегрируетесь с решениями Cisco?
— Так у вас уже все проприетарное?
— Нет, это не так!
— Да? А мне говорили, что у вас закрытые API и доступ к ним стоит денег.
— Нет, и это не так!

Вокруг нас достаточно разработчиков, которые хотели бы заняться своим проектом. Зачастую эти идеи так и пылятся в головах людей по самым различным причинам. Истории Вадима Смирнова из 2ГИС ( zloypakimon ) — как раз о том, как претворить их в жизнь. Потратив несколько выходных за год, он смог сделать пять разных проектов, не заработал миллионы, но при этом не разочаровался и не прекращает работать над pet-project'ами.

В основе публикации — доклад Вадима на AppConf 2017.

Пока мозг ещё не окончательно превратился в оливье, самое время немного заставить его поработать. Новая подборка логических и алгоритмических задач, предлагаемых на собеседованиях в известные IT-компании.



В нашу первую в новом году подборку попали вопросы и задачи, задаваемые в Alcatel-Lucent (Nokia).
Задачи мы постарись подобрать с различным уровнем сложности. На некоторые (а, может быть, и на все) вопросы можно найти ответ на просторах интернета, но это ведь не наш путь, верно?
Предлагаем интеллектуально размяться и попробовать самостоятельно решить приведённые задачи.

Здравствуйте, меня зовут Александр Зеленин, и я веб-разработчик.
Многократно я слышал мнение, что верстка — удел начинающих frontend’еров. Хотя фактически это важнейшая часть любого (почти) веб-проекта. Это то, что пользователи видят в первую очередь. На текущий момент качественная вёрстка (особенно проектирование блоков) в крупном проекте требует большого количества различных навыков.

В данной статье представляю схему развития верстальщика

[большая по клику]
Само собой, это не всеобъемлющая и единственно верная схема. Есть ещё целая гора связанных навыков, релевантных технологий и так далее. Градация является субъективной.

Об авторе. Джеймс Рутли — бэкенд-разработчик в компании Monzo.

В этой статье мы изучим двочиный формат сообщений Domain Name Service (DNS) и напишем вручную одно сообщение. Это больше, чем вам нужно для использования DNS, но я подумал, что для развлечения и в образовательных целях интересно посмотреть, что находится под капотом.

Мы узнаем, как:

• Написать запросы DNS в двоичном формате
• Отправить сообщение в теле датаграммы UDP с помощью Python
• Прочитать ответ от DNS-сервера

Писать в двоичном формате кажется сложным, но в реальности я обнаружил, что это вполне доступно. Документация DNS хорошо написана и понятна, а писать мы будем маленькое сообщение — всего 29 байт.

Многие разработчики знают, или должны знать, что Java-процессы, исполняемые внутри контейнеров Linux (среди них — docker, rkt, runC, lxcfs, и другие), ведут себя не так, как ожидается. Происходит это тогда, когда механизму JVM ergonomics позволяют самостоятельно задавать параметры сборщика мусора и компилятора, управлять размером кучи. Когда Java-приложение запускают без ключа, указывающего на необходимость настройки параметров, скажем, командой java -jar myapplication-fat.jar, JVM самостоятельно настроит некоторые параметры, стремясь обеспечить наилучшую производительность приложения.

В этом материале мы поговорим о том, что необходимо знать разработчику перед тем, как он займётся упаковкой своих приложений, написанных на Java, в контейнеры Linux.

Мне необходимо было настроить и запустить Tomcat на Mac OS X (Mountain Lion) и зарегистрировать данный сервер приложений (контейнер сервлетов) в NetBeans.
Для того чтобы это сделать, я выполнил следующие пункты.