• В данной статье мы разберем влияние SSR на SEO оптимизацию приложения.
• Пройдем с вами путь по переносу обычного React приложения на SSR.
• Разберем обработку асинхронных операций в SSR приложениях.
• Посмотрим, как делать SSR в приложениях с Redux Saga.
• Настроим Webpack 5 для работы с SSR приложением.
• А также рассмотрим тонкости работы SSR: Генерация HTML Meta Tags, Dynamic Imports, работа с LocalStorage, debugging и прочее.

Перевод Neural Network Architectures

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


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

Еще недавно Apple была источником положительных новостей – компания стала первым американской организацией, достигшей оценки в $1 трлн. К началу октября акции компании подорожали почти на 40% с начала 2018 года.

Однако затем ситуация изменилась. Акции обвалились на 17%, что принесло серьезные убытки многим акционерам. Согласно подсчетам ресурса Barron's, общие потери в этот период примерно равны $190 млрд.

В сентябре Apple выпустила новые iPhone XS за $999 и iPhone XS Max за $1099, а также более дешевую модель iPhone XR за $749. Многие аналитики предсказывали успех новой линейке устройств, но не все оказалось так гладко.

Алексей Баранцев, вероятно, один из самых известных людей в российском тестировании: его знают и по software-testing.ru, и по selenium2.ru, и по участию в Selenium WebDriver, и не только. При этом он ещё и один из наиболее опытных: в тестировании аж с 1994-го. И когда стало известно, что он выступит на нашей конференции Heisenbug с докладом «Заморочки в Selenium WebDriver», нам захотелось расспросить такого спикера. Начали с вопросов о том, чем тестирование в 90-х отличалось от сегодняшнего, а затем перешли к современным реалиям.

О зарождении видеоигр — как это начиналось

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

1. Старт

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

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

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

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

Примечание от переводчика:

Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).

---

Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.

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



Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.

Мир в 1997 году

Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.

Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Итак, я знаю что ты любишь Todo списки, то есть, что тебе очень нравится писать Todo списки, поэтому мне хочется, чтобы ты создал один из них, используя новый, восхитительный и питательный («nutritious» прим. пер.) Flux фреймворк, Redux! Я желаю тебе только лучшего.

В этой статье ты научишься как сконструировать свое собственное Redux приложение, не ограничиваясь, но так же включая.

• Цельнозерновой рендеринг на сервере
• Расширенный роутинг, богатый Omega-3
• Маслянистая асинхронная загрузка данных
• Гладкое функциональное послевкусие

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