Рубрика «Разработка веб-сайтов» - 92

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

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

bruce lee

Читать полностью »

DartUP 2019: конференция по Dart и Flutter в Петербурге 23 ноября - 1

23 ноября русскоязычное сообщество разработчиков на Dart и Flutter при поддержке Wrike и Google снова проводят DartUP, конференцию, в прошлом году ставшую самой крупной в DART/FLUTTER мире. В этом году постараемся сделать еще ярче, интереснее и многочисленнее.
Читать полностью »

Вот уже несколько лет, как почти каждая статья о передовых подходах к кэшированию рекомендует пользоваться в продакшне следующими методиками:

  • Добавление в имена файлов информации о версии содержащихся в них данных (обычно — в виде хэша данных, находящихся в файлах).
  • Установка HTTP-заголовков Cache-Control: max-age и Expires, управляющих временем кэширования материалов (что позволяет исключить повторную валидацию соответствующих материалов для посетителей, возвращающихся на ресурс).

Каскадная инвалидация кэша. Часть 1 - 1

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

filename: '[name]-[contenthash].js'

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

Прим. перев.: Эта статья рассчитана в основном на тех кто только выбирает фреймворк для веб-разработки. Опытные разработчики на Django вряд ли узнают что-то новое.

Плюсы и минусы Django - 1

Django описывают как «веб-фреймворк для перфекционистов с дедлайнами». Его создали, чтобы переходить от прототипов к готовым сервисам как можно быстрее.

Фреймворк поможет разработать CRUD приложение под ключ. С Django не придется изобретать велосипед. Он работает из коробки и позволит сосредоточиться на бизнес-логике и продуктах для обычных людей.

Плюсы Джанго

Принцип «Всё включено» («Batteries included»)

Фраза «всё включено» означает, что большинство инструментов для создания приложения — часть фреймворка, а не поставляются в виде отдельных библиотек.

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

  • ORM
  • Миграции базы данных
  • Аутентификация пользователя
  • Панель администратора
  • Формы

Читать полностью »

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

Python и быстрые HTTP-клиенты - 1

Существует множество HTTP-клиентов для Python. Самым распространённым среди них, и, к тому же, таким, с которым легко работать, можно назвать requests. Сегодня этот клиент является стандартом де-факто.
Читать полностью »

Разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. Базы данных из универсальных промышленных монстров переродились в узконаправленные. Docker изменил взгляд на деплой. Но изменилось ли наше представление о логах?

Одна из больших проблем в Яндекс.Вертикалях были логи — 18 ТБ в день и 250 000 логов в секунду, все пишется в файлы. Логи разнородные, потому что много языков: Scala, Java, Python, Go. Потом их собирает Fluent Bit, пишет в Kafka, на одной железной машине работают обработчики, собирают из Kafka и пишут всё на диск. При этом это уже третья версия логов.

Логи не нужны? - 1

Как следствие, возникает проблема долгого поиска. По этим логам поиск идет с помощью grep. На некоторых сервисах grep может достигать часов. Если у вас есть проблемы в продакшн, вы не будете часами искать свои логи. Чтобы решить проблему, в Яндекс решили написать свой велосипед доставки логов для поиска. Что из этого получилось, расскажет Алексей Данилов (danevge) — разработчик команды инфраструктуры в Яндекс.Вертикалях. Разрабатывает, пишет и поддерживает проекты auto.ru и Яндекс.Недвижимость.

Дисклеймер. Статья рассказывает о современной разработке и подходит для микросервисной архитектуры. Здесь представлены различные продукты — это инструменты, которые используют в Яндекс.Вертикалях. Под другие условия возможны аналоги удачнее, но они выполняют практически те же функции.Читать полностью »

Недавно Фил Стерджен опубликовал твит, который сильно задел любителей GraphQL. В этом твите речь шла о том, что GraphQL — это, по определению, технология, которая противоречит сущности HTTP/2. О том, что уже вышел стандарт HTTP/3, и о том, что автор твита не очень понимает тех, кто, выбирая GraphQL, идёт путём несовместимости. Для того чтобы лучше понять причины такого отношения Фила к GraphQL — взгляните на этот материал.

Не потерял ли GraphQL актуальности в эпоху HTTP-2? - 1

Примерно в то же самое время было сделано сообщение о появлении проекта Vulcain. В это сообщение входили такие слова: «TL/DR: GraphQL вам больше не нужен!». И наконец — вышла замечательная статья Марка Ноттингема, посвящённая мощным возможностям HTTP/2, и тому, что эти возможности означают для тех, кто проектирует API. Ссылкой на эту статью поделился со своими подписчиками Даррел Миллер.

Происходящее заставило меня задуматься о GraphQL и об HTTP/2. Если всё вокруг начнёт работать с использованием HTTP/2 (и HTTP/3), будет ли это значить, что у нас не останется причин использовать GraphQL? Вот это мне и хотелось бы сегодня выяснить.
Читать полностью »

imageКДПВ взята отсюда

Часто слышу истории вида "пробовал фрилансить — не понравилось" и встречаю много заблуждений по поводу этого типа работ, потому что люди просто начали "не с той стороны". Постараюсь исправить ситуацию этим постом.

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

Читать полностью »

Пробуем preload (PHP 7.4) и RoadRunner - 1

Привет! 

Мы часто пишем и говорим о производительности PHP: как мы ей занимаемся в целом, как мы сэкономили 1 млн долларов при переходе на PHP 7.0, а также переводим разные материалы на эту тему. Это вызвано тем, что аудитория наших продуктов растёт, а масштабирование PHP-бэкенда при помощи железа сопряжено со значительными затратами — у нас 600 серверов с PHP-FPM. Поэтому инвестирование времени в оптимизацию для нас выгодно.

Прежде мы говорили в основном об обычных и уже устоявшихся способах работы с производительностью. Но сообщество PHP не дремлет! В PHP 8 появится JIT, в PHP 7.4 — preload, а за пределами core-разработки PHP развиваются фреймворки, подразумевающие работу PHP как демона. Пора поэкспериментировать с чем-то новым и посмотреть, что это может нам дать.

Так как до релиза PHP 8 ещё далеко, а асинхронные фреймворки плохо подходят для наших задач (почему — расскажу ниже), сегодня остановимся на preload, который появится в PHP 7.4, и фреймворке для демонизации PHP — RoadRunner.

Это текстовая версия моего доклада с Badoo PHP Meetup #3. Видео всех выступлений мы собрали в этом посте.Читать полностью »

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

Десять лет назад очевидно было то, что JavaScript имеет все шансы, так сказать, править миром. За эту честь сражались и другие платформы — такие, как Java, Flash и Silverlight. Всем этим трём платформам нужны, для работы в браузерах, специальные плагины. Все три меняют HTML-подход к формированию интерфейсов на что-то другое. Это позволило им уйти далеко вперёд от JavaScript в плане возможностей. Например — они умели проигрывать видео, выводить анимацию, рисовать что-то на экране. Всё это другие платформы поддерживали задолго до появления стандартного тега <video>, механизмов CSS-анимации и HTML-элемента canvas. Но всё это стало причиной их краха. Так, когда в мире начался бум мобильного интернета, и когда это было учтено в HTML, другие платформы оказались не у дел.

Кто он — убийца JavaScript? - 1

Ирония есть и в том, что происходит сейчас. В то самое время, когда JavaScript царствует в мире веб-разработки, появился один проект, вроде бы не особенно масштабный, который, когда-нибудь в будущем, способен стать убийцей JavaScript. То, о чём мы тут говорим, началось с экспериментальной технологии asm.js. Как это может выглядеть? Прежде чем ответить на этот вопрос — давайте немного притормозим и поговорим о современном положении дел.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js