Да, вот такой гибридный, русско-английский заголовок получился… Поэтому давайте сразу кое-что проясним. Итак, если SEO широко известный (в узких кругах) термин, то AMP — ещё не столь. Accelerated Mobile Pages был анонсирован Google в 2015 г. (см. статью в Википедии), как инструмент, позволяющий быстро просматривать веб-страницы на мобильных телефонах. Со временем AMP превратился в фреймворк, позволяющий создавать страницы для любых сайтов (не только для мобильных устройств), и расширил свою «номенклатуру»: собственно сайты (AMP Websites), истории (AMP Stories; тема этой статьи), рекламные блоки (AMP Ads), и электронные письма (AMP email). За всем этим, как было сказано выше, стоит Google, и если вас интересует продвижение сайтов в этой поисковой машине — полезно будет отнестись к теме AMP с должным вниманием. Но давайте сначала посмотрим как выглядят эти самые AMP-истории (UPD: с 1 мая 2020 AMP Stories переименованы в Web Stories, поэтому теперь по-русски их лучше называть Веб-истории), затем решим нужны ли они нам, и, если окажется, что нужны — рассмотрим как это сделать.

У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.



Я буду использовать разговорное «юзкейс» вместо неуклюжей кальки «прецедент использования». Надеюсь, уважаемая публика меня за это простит.

Всем привет!

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

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

Я увидел этот вопрос на Quora и начал писать ответ. Но ответ получился слишком большим, так что я превратил его в эту статью.

Вот часть изменений в случайном порядке, которые я заметил в программировании за последние 20 лет:

• Многие концепции, которые были лишь теоретическими 20 лет назад, сегодня широко применяются на практике. Например, такие функциональные парадигмы как неизменяемость объектов, хвостовая рекурсия, ленивые коллекции, сопоставление с шаблоном, функции первого класса и взгляд свысока на тех, кто всё это не использует.
• «Десктопным приложением» многие неиронично называют упакованный браузер со страницей по умолчанию и без адресной строки.

Автор материала, перевод которого мы публикуем, недавно выпустил своё первое мобильное приложение, написанное на React Native. Так случилось, что это приложение стало и его первым проектом, который он создал как программист-фрилансер. Здесь он расскажет о том, с чем ему пришлось столкнуться в ходе работы — от инициализации проекта до его публикации в App Store и Google Play.

После доклада Юры Лучанинова, я решил для себя попробовать Flutter. Чтобы мозг размять, и чтобы было о чем похоливарить с мужиками на кухне. Дело пошло. Я начал смотреть, потом читать, потом писать. И вроде все получается, приложения запускаются, и то что объясняют — понятно, все просто. Но не без “но” — объясняют не все. А поскольку платформа, ЯП, подходы и даже предметная область для меня новые, то подобное вызывает раздражение, ведь у тебя “не запускается”, а ты даже не знаешь что гуглить: Dart/Flutter/Window/Screen/Route/Widget?

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

Это вторая статья из цикла, где мы проводим сравнение Kivy, Xamarin.Forms и React Native. В ней я постараюсь написать такой же планировщик задач, но с использованием Xamarin.Forms. Посмотрю, как у меня это получится, и с чем мне придется столкнуться.

Повторять ТЗ я не буду, его можно посмотреть в первой статье: Kivy. Xamarin. React Native. Три фреймворка — один эксперемент

Третья часть про React Native: Kivy. Xamarin. React Native. Три фреймворка — один эксперимент (часть 3)

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

Зачем вообще нужно использовать паттерн MVVM? Это ведь лишний код! Написать тоже самое можно гораздо понятнее и прямолинейнее.

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

Привет, Хабр! представляю вашему вниманию перевод статьи «Mastering Vuex — Zero to Hero» автора Sanath Kumar.

Официальная документация Vuex определяет его как паттерн управления состоянием + библиотека для приложений Vue.js. Но что это значит? Что такое паттерн управления состоянием?

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

JavaScript сильно изменился за последние годы. Вот 12 новых возможностей, которые можно начать использовать уже сегодня!

История

Новые добавления в язык называются ECMAScript 6. Или ES6 или ES2015+.

С момента появления в 1995, JavaScript развивался медленно. Новые возможности добавлялись каждые несколько лет. ECMAScript появился в 1997, его целью было направить развитие JavaScript в нужное русло. Выходили новые версии – ES3, ES5, ES6 и так далее.

Как видите, между версиями ES3, ES5 и ES6 есть пропуски длиной в 10 и 6 лет. Новая модель – делать маленькие изменения каждый год. Вместо того, чтобы накопить огромное количество изменений и выпустить их все за раз, как это было с ES6.

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

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

В публикации рассматриваются следующие темы:

• Наследование VS компоненты
• Сложные иерархии классов юнитов, предметов и прочего
• Машины состояний, деревья поведений
• Абстракции игровых объектов
• Упрощение доступа к другим компонентам в объекте, сцене
• Сложные составные игровые объекты
• Характеристики объектов в игре
• Модификаторы (баффы/дебаффы)
• Сериализация данных

Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.

Давайте, пацаны, проходим в пост.

Цель этой статьи — рассказать о языке программирования Go (Golang) тем разработчикам, которые смотрят в сторону этого языка, но еще не решились взяться за его изучение. Рассказ будет вестись на примере реального приложения, которое представляет из себя RESTful API веб-сервис.

Данный мануал/гайд/etc написан для тех, кому лень собирать по кускам ту или иную информацию об установке «мака» на PC, все понятно и по полочкам.

Мы в Атласе любим, когда все находится под контролем. Это касается и всей серверной инфраструктуры, которая, с годами, превратилась в живой организм из многочисленных виртуальных машин, сервисов и служб. Появилась потребность наблюдать за жизненно важными аспектами IT-составляющей нашей деятельности: мониторить боевой сервер, отслеживать изменения системных ресурсов на виртуалках баз данных, следить за ходом бизнес-процессов и тд. Встал вопрос — как же этого добиться и главное какими инструментами? Стали искать какие-то готовые решения. Перепробовали кучу платных/бесплатных сервисов, которые, якобы, предоставляли бы нам "самую ценную" информацию о состоянии нашей системы. Но, в конечном итоге, все сводилось к каким-то непонятных диаграммам, схемам и цифрам, которые, по сути, для нас не имели никакой ценности.

Так мы пришли к пониманию, что надо собирать что-то самостоятельно. За основу решили взять самую гибкую и продвинутую систему, которую можно настроить для мониторинга чего и как угодно — Nagios. Настроили, поставили, работает — круто! Жаль только интерфейс сего чуда застрял где-то в середине 90-х, а нам хотелось, чтобы еще и визуальная составляющая была на уровне.

Недолгий поиск показал, что лидером среди решений по созданию красивых дашбордов является Grafana. Так и решили выводить весь наш мониторинг из Nagios на мониторах в виде красивых графиков в Grafana. Вопрос остался только в том — как их подружить друг с другом?

Всем привет! Я тимлид проекта Рамблер/топ-100. Это лонгрид о том, как мы проектировали архитектуру обновлённого сервиса веб-аналитики, с какими сложностями столкнулись по пути и как с ними боролись. Если вам интересны такие базворды как Clickhouse, Aerospike, Spark, добро пожаловать под кат.

Использование хранимых функций СУБД для реализации бизнес-логики или её части, всегда было камнем преткновения. С одной стороны баррикад DBA и программисты БД, с другой — разработчики backend.
Рискну навлечь на себя гнев из обоих лагерей, но всё же просуммирую плюсы и минусы и изложу свои соображения о том, когда стоит писать код в хранимых функциях, а когда следует выносить наружу.

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

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

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

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

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

Обновляю 4-летний список бесплатных сервисов для управления доменами

Primary + Secondary

Сервис	Кол-во NS	Кол-во доменов	Типы записей	TTL	Доп. фичи
pdd.yandex.ru	2	50	AAAA и SRV	+	Есть API
cloudflare.com	2	неограниченное	AAAA, SRV, SPF, LOC	+
2ns.info	4	неограниченное	AAAA и SRV	+	Есть экспорт. Показывает регистратора, дату регистрации домена, дату окончания регистрации, тИЦ. By leonid239
dns.he.net	5	50	все	+	NS доступны по IPv6. Свой DDNS-сервис
www.netbreeze.net/dns	3	1	AAAA и SRV	+	Есть API
entrydns.net	3	неограниченное	AAAA и SRV	+	Есть свой DDNS-сервис, REST-api