Самое длинное приключение начинается со слов «Я знаю короткую дорогу».

Прежде чем разбираться с реализацией серверного UI (SDUI) от Airbnb, важно понять, что это вообще такое и какие преимущества оно дает относительно традиционного клиентского UI.

Обычно данные обрабатываются серверной частью, а за работу интерфейса отвечает конкретный клиент (веб-браузер, приложения для iOS, Android). В качестве примера возьмем страницу Airbnb со списком предложений. Чтобы отобразить этот список пользователю, клиент может запросить данные у бэкенда, а затем преобразовать их в UI.

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

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

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

А что, если клиент даже не будет знать, что он отображает список предложений? Можно ли передавать клиенту напрямую UI, а не данные для построения интерфейса? Именно это и происходит в случае SDUI: мы передаем UI и данные вместе, а клиент отображает всё это независимо от того, что конкретно там внутри.

Доброго времени суток, друзья!

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

Сначала мы с вами кратко разберем основные виды уязвимостей веб-приложений, а также основные виды атак, основанные на этих уязвимостях. Далее мы рассмотрим все современные заголовки, каждый — по отдельности. Это в теоретической части статьи.

В практической части мы реализуем простое Express-приложение, развернем его на Heroku и оценим безопасность с помощью WebPageTest и Security Headers. Также, учитывая большую популярность сервисов для генерации статических сайтов, мы настроим и развернем приложение с аналогичным функционалом на Netlify.

Исходный код приложений находится здесь.

Демо Heroku-приложения можно посмотреть здесь, а Netlify-приложения — здесь.

Основными источниками истины при подготовке настоящей статьи для меня послужили следующие ресурсы:

• Security headers quick reference — Google Developers
• OWASP Secure Headers Project
• Web security — MDN

У вас бывают в разработке такие периоды, когда что-то в коде идет не так, ты ищешь баг, а потом оказывается, что за ним стоял еще один баг? Мне нравится искать баги. Это создает ощущение словно ты Шерлок Холмс и являешься главным героем в детективе, где кто-то из обширного списка на вид безобидных классов и функций вызывает неожиданное и даже неопределенное поведение программы, а ты своим зорким взглядом и экспериментами пытаешься вычислить этого мерзавца в кратчайшие сроки.

Можно выделить несколько стадий поиска бага:

• удивление (не знаю как вы, но я каждый раз как в первый раз удивляюсь когда что-то вдруг в моем коде работает не так, как ожидается);

• обвинение всех кругом в баге (коллег по проекту, github, сторонние либы, компилятор), но только не себя;

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

• если причина бага найдена быстро, то я хвалю себя за то, что нашел баг, при этом, я не напоминаю себе, что причиной бага стал тоже я, а не коллеги по проекту, не github, не сторонние либы и не компилятор;

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

Приветствую! 

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

Статья рассчитана на тех кто уже знаком с Си, а все примеры ориентированы на ОС Linux. Мои познания Windows закончились на «WinXP», после которой в Windows стало уже очень много политики ("безопасности") и коммерческой составляющей, но я сейчас не об этом и надеюсь, что здесь вы найдёте для себя полезные моменты, а если я в чём-то не прав или заблуждаюсь, то поправите.

Итак, я решил попробовать писать в стиле объектно ориентированного программирования (далее ООП) на Си без плюсов. Многие скажут, что писать в стиле объектно ориентированного программирования (далее ООП) не для Си, и разные приёмы написания это - «псевдо-ООП». Но лично я считаю ООП всего лишь абстрактной парадигмой, определяющей стиль написания ПО и не более чем. А Си очень мощный и самодостаточный язык программирования.

Так сложилось, что изучать традиции ООП я начал с Delphi и Java, являющихся, как считается, на 100% объектно ориентированными языками программирования, а потому аналогия решений у меня ассоциируется именно с ними. И далее в тексте я иногда буду на них ссылаться, что надеюсь не испортит суть полного понимания.

В этой статье мы познакомимся с основными терминами и определениями Теории графов. Каждый термин схематично показан на картинках.

Граф - это топологичекая модель, которая состоит из множества вершин и множества соединяющих их рёбер. При этом значение имеет только сам факт, какая вершина с какой соединена.

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

Наткнулся я на этот способ случайно. К одному из клиентов, на завод, устроился очень толковый парень, программист, выпускник очень уважаемого ВУЗа. Я, зная историю этого завода, понимал, что парень там пропадёт – превратится в 1Сника. Но как ему об этом сказать?

Прямо заявить не получится – уровень отношений не тот, я для него – просто хрен с горы. Если начну лезть со своими советами – сделаю только хуже. К тому же, не хотелось случайно испортить отношения с клиентом – он, в общем-то, перед парнем ни в чём не виноват. Он просто такой, какой есть.

Приводить какие-то аргументы и доказательства смысла не было – не зная истории развития клиента, парень мне просто не поверит. Публикаций от программистов, гибнущих на заводах, тоже мало, да и толку от них – кто поверит чужому опыту? Хочется заиметь свой собственный.

Мне хотелось, чтобы парень увидел себя через несколько лет. И чтобы увиденное его зацепило и заставило задуматься. Как это сделать? Нужен материал, который взывает не к разуму, а к эмоциям. Нужна история. Так я написал свой первый худлит – Requiem for a Dream.

 И о чудо! – сработало. Парень ещё несколько месяцев посидел на заводе, увидел проблески воплощения этой истории, и свалил – туда, где шансы сгинуть намного ниже.

А я стал пользоваться этим методом постоянно.

Всем хочется получать пассивный доход. Поэтому и пришла идея написать правильного бота, способного зарабатывать на бирже. Как это сделать? К вашему вниманию подробный туториал (Часть 2)

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

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

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

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

Продолжение (материалы и рендер)

Всем доброго времени суток. Сегодня хочу рассказать максимум о регулярных выражениях: что они из себя представляют, как их писать, для чего нужны и т.д.

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

#include "Mouse.h" // импортируем библиотеку работы с мышью
void setup(){}            // ничего не настраиваем
void loop()
{
 Mouse.move(10, -15, 3);  // сдвигаем курсор на 10 пикселей вправо, на 15 пикселей вверх и колесо на 3 оборота
}

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

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

Статья небольшая, но важная для понимания!