Веб-разработка *

Привет, хабр! Уже сегодня на otus.ru стартует курс "Fullstack разработчик JavaScript" и я решил поддержать ребят этой статьей. Я кстати сам преподаю на курсе по React.js.

Есть такой принцип — Don't break the web, который можно раскрыть как "веб всегда старается сохранить максимальную обратную совместимость". В некоторой мере этот принцип применим и к веб сайтам и приложениям — ваш сайт должен работать не только в одном конкретном браузере, но в целом наборе разных браузеров и версий. Но в каких? Однозначно должны быть какие-то разумные пределы и IE 6 и netscape navigator поддерживать не стоит, но два вопроса остаются открытыми: какие браузеры вы поддерживаете и как это обеспечить?

Если есть обратная совместимость значит что-то меняется. Меняются в вебе три вещи: ECMAScript (javascript), CSS и различные Web API. CSS мы сегодня оставим на опушке, а пока, тропинка ведет нас в дебри современной фронтенд разработки

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

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

Аве Кодер!

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

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

Подборка новых статей по фреймворку Laravel. Научимся авторизировать пользователя через Гейты и Политики. Перепишем проект с веб-сокетов на Livewire. Поработаем с аутентификацией через JWT, SPA+Sanctum и Socialite+Facebook. Задеплоим приложение в Kubernetes.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Я никогда не работала профессиональным фронтенд-разработчиком, и хотя уже 15 лет пишу HTML/CSS/JS для небольших побочных проектов, но все проекты были довольно маленькими. Бывает, что я не пишу на Javascript в течение многих лет между этими проектами, и часто не уверена в том, что всё делаю правильно.

Отчасти поэтому я часто использовала библиотеки! Десять лет назад я использовала jQuery, а где-то с 2017 года для моих маленьких проектов много использую vue.js (можете посмотреть небольшую игру типа «сапёр», которую я сделала в качестве вступления к Vue).

Но на прошлой неделе, впервые за долгое время, я написала простой Javascript без библиотеки, и это было весело, поэтому я хотела немного поговорить об этом!

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

Представляю Вашему вниманию перевод статьи «What JavaScript Developers Should Know About Curl» автора Valery Karpov.

Curl — это популярный инструмент командной строки, часто используемый для отправки HTTP-запросов. Curl поддерживает большое количество протоколов, однако как Node.js-разработчик вы, скорее всего, будете использовать его для отпраки http-запросов к RESTful API.

Документация curl представляет собой перечень из 383 флагов командной строки, поэтому в ней очень трудно найти то, что ищешь. В этой статье я хочу поделиться с вами некоторыми часто используемыми мной шаблонами. Для примеров будет использоваться сервис httpbin.org.

А вы знали о том, что то, что вы сейчас читаете, это — данные? Вы видите слова, но на серверах всё это хранится в виде данных. Эти данные можно куда-то скопировать, можно разобраться в их структуре, с ними можно сделать что-то ещё. Собственно говоря, только что мы привели упрощённое описание веб-скрапинга. Скраперы просматривают код, из которого созданы веб-сайты (HTML-код), или работают с базами данных, и вытаскивают отовсюду те данные, которые им нужны. Практически каждый веб-сайт можно подвергнуть скрапингу. На некоторых сайтах применяются особые меры, которые мешают работе веб-скраперов. Но тот, кто достаточно хорошо знает своё дело, способен успешно собрать данные с 99% существующих сайтов.



Если вы не знали о том, что такое веб-скрапер, то теперь вы, в общих чертах, об этом знаете. А это значит, что мы можем заняться тем, ради чего вы, вероятно, начали читать эту статью. Мы сможем приступить к разговору о заработке на скрапинге. Такой заработок, кстати, не так сложен, как может показаться на первый взгляд. На самом деле, все методы и примеры, которые я собираюсь вам показать, укладываются в менее чем 50 строк кода. А изучить всё это можно буквально за несколько часов. Собственно говоря, полагаю, что сейчас вы вполне готовы к тому, чтобы узнать о трёх способах заработка с помощью веб-скрапинга.

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


— Сергей Бережной veged уже несколько раз поднимал эту тему и рассказывал про тестирование в Поиске. Вот ссылки на доклады в 2016-м и 2017-м. Многое из того, что он тогда рассказывал, де-факто стало стандартом для большинства компаний. Но несмотря на это, все еще остаются вещи, которые пока нигде особо не применяются. Именно на них я и сосредоточусь.

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

Я пишу на Python и на Go, а в последние годы занимаюсь крупномасштабными приложениями. Речь идёт о том, что каждый день мне и моей команде приходится поддерживать системы, ответственные за обеспечение работы примерно двух миллионов пользователей. Это — непростая задача. Здесь я хочу поделиться несколькими ценными идеями, которые встретились мне за годы работы.

Привет, Хабр! Меня зовут Влад, я лид направления Web Performance в Тинькофф.

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

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

Ведущие игроки IT-индустрии продолжают обращать внимание на важность производительности, проводят масштабные исследования и эксперименты, разрабатывают новые концепции, инструменты и API. А в ближайшем будущем Google и вовсе будет учитывать основные показатели производительности в поисковой выдаче.

Пользователям нравятся отзывчивые интерфейсы, а бизнесу — прибыльные проекты. И если производительность играет в этом не последнюю роль, то почему бы не заняться ее оптимизацией?

Благодаря внедрению клиентского мониторинга производительности, мы с полной уверенностью можем диагностировать проблемные места проекта и составить план для дальнейшей оптимизации.

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

Иногда в приложении надо показать модель помещения – допустим, кинотеатра или даже целого стадиона, если вы продаете билеты на концерт Metallica. Если в зале 50-100 тысяч мест, то для их вывода на экран нужно продумать плавный zoom, скроллинг и другие детали. Итак, главный вопрос – как показывать тысячи элементов на экране, чтобы это было удобно для пользователей?

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

Решил я тут своё портфолио сделать на Laravel 7. Чтобы главная страница была лендингом, а всю информацию на ней можно было менять с помощью админки. Не суть. Дело дошло до деплоя. Нашел пару хороших туториалов, как это сделать на полноценном сервере со всеми заморочками. В деплое я не очень силен, я вообще больше фронт, чем фулстек. И, если писать и тестить на PHP я еще могу, то до управления сервером и т.п. я еще не дорос. Но пришлось разбираться.

Сейчас пройдемся по всем шагам, начиная с запуска через SSH и заканчивая рабочим сайтом. Постараемся обойти все подводные камни.

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

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.

Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Как не убить критикой, но и не скатиться в поверхностное ревью? Жирный PR против кучи мержей — что где выгоднее в зависимости от типа и размера проекта? А вот оно вообще правда нужно? Может, ну его — или автоматизируем/заменим статическим анализом?

Тема благодатная — и мы решили посвятить ей совместный стрим с подкастом SDCast.


1 июля в 17 часов по Москве/Киеву/Минску. В эфир придут хорошие люди (о них под катом) — а еще у нас будут свои голосования ;)

Всем привет! Меня зовут Роман Халкечев, я руковожу отделом аналитики в Яндекс.Еде. Одно из ключевых направлений этого сервиса — логистика. Эффективность алгоритмов логистики во многом и определяет само существование сервисов доставки. Сегодня я расскажу читателям Хабра о нашем новом алгоритме, который помог курьерам сократить время простоя. Вы узнаете, из чего складывается время ожидания доставки заказа и зачем мы считали скорость приготовления килограмма условной еды. Но обо всём по порядку.

Яндекс.Еда представляет собой маркетплейс: на сервисе есть спрос и есть предложение. Спрос — это заказы пользователей. Предложение — курьеры. Разумеется, под предложением мы также понимаем рестораны, но в контексте этого поста остановимся именно на курьерах. Главная задача сервиса — поддерживать баланс: тогда будут счастливы и пользователи (они быстро получат еду), и курьерские службы (заказов хватит всем курьерам). Чтобы сохранять баланс и переживать локальный рост или падение спроса, нам необходимо повышать эффективность доставки. Под эффективностью мы понимаем оборачиваемость — среднее число заказов, которые курьер успевает доставить за час. Чем выше этот показатель, тем эффективнее работает доставка в целом.

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

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

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



Но, к сожалению, Python-интерпретатор не выполняет асинхронный код быстрее синхронного.

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