Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Чуть раньше я поделился с хабравчанами переводом первой статьи, настала очередь второй. Итак, поехали.

Flux для глупых людей

TL;DR Мне, как глупому человеку, как раз не хватало этой статьи, когда я пытался разобраться с Flux. Это было не просто: хорошей документации нет и многие ее части перемещаются.

Это продолжение статьи «ReactJS For Stupid People».

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

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

TL;DR: базовая логика redux помещается в 7 строк JS кода.

О redux вкратце (вольный перевод заголовка на гитхабе):

Redux — библиотека управления состоянием для приложений, написанных на JavaScript.

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

Я склонировал репозиторий redux, открыл в редакторе папку с исходниками (игнорируя docs, examples и прочее) и взялся за ножницы клавишу Delete:

• Удалил все комментарии из кода
  Каждый метод библиотеки задокументирован с помощью JSDoc весьма подробно
  
• Убрал валидацию и логирование ошибок
  В каждом методе жёстко контролируются входные параметры с выведением очень приятных глазу подробных комментариев в консоль
  
• Убрал методы bindActionCreators, subscribe, replaceReducer и observable.
  
  … потому что мог. Ну или потому что поленился писать для них примеры. Но без корнер-кейсов они ещё менее интересны, чем то, что ждёт вас впереди.
  

А теперь давайте разберём то, что осталось

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



В этой статье вы погрузитесь в основы безопасности в iOS. Вы поработаете с некоторыми базовыми криптографическими методами хеширования для надежного хранения полученных данных в Keychain — сохраняя и защищая пользовательские данные в приложении.

Apple имеет несколько API, которые помогут защитить ваши приложения, и вы изучите их при работе с Keychain. Кроме того, вы будете использовать CryptoSwift — хорошо изучите и просмотрите библиотеку с открытым исходным кодом, которая реализует криптографические алгоритмы.

******************* Ну и кто из нас читал «Начала» Ньютона? *****************

Беру в руки журнал “Наука и жизнь” №1 2020. На обложке бросается в глаза вопрос “Почему Эйнштейн самый великий физик?”. Действительно, почему? Открываю статью Евгения Берковича “Трагедия Эйнштейна, или счастливый Сизиф”. Начинается она так: “Кто самый великий физик? Спросите об этом кого угодно, любой вам скажет: Альберт Эйнштейн. Не зря строгий академик Лев Ландау поставил его первым в иерархии физиков”.

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

“Спросите об этом кого угодно…”. Господин Беркович берет на себя смелость отвечать за всех. Ну, кого угодно, так кого угодно — мне угодно взять себя. Беру себя. И отвечаю: самый великий физик это Исаак Ньютон.

Я стар и уже глуп, а у вас всё впереди, уважаемый программист. Но позвольте дать вам один совет, который наверняка поможет в вашей карьере – если, конечно, вы планируете остаться программистом.

Советы типа «писать красивый код», «хорошо комментировать свои доработки», «изучать современные фреймворки» — очень полезные, но, увы, второстепенные. Они идут прицепом к главному качеству программиста, которое надо в себе развивать.

Вот это главное качество: пытливый ум.

Всем привет! Новогодние праздники подошли к концу, а это значит, что мы вновь готовы делиться с вами полезным материалом. Перевод данной статьи подготовлен в преддверии запуска нового потока по курсу «Алгоритмы для разработчиков».

Поехали!

---

Метод обратного распространения ошибки – вероятно самая фундаментальная составляющая нейронной сети. Впервые он был описан в 1960-е и почти 30 лет спустя его популяризировали Румельхарт, Хинтон и Уильямс в статье под названием «Learning representations by back-propagating errors».

В этой статье показывается, как с помощью CSS трансформаций и махинаций с 3d сделать параллакс-эффект на сайте на чистом CSS.

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

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

Парадокс Эйнштейна — Подольского — Розена сейчас активно изучают в многих лабораториях мира и научных институтах. Пишутся тонны научных статей. Поднято много хайпа в около-научных кругах.


Только лишь одна загвоздка, хотя и достаточно парадоксальная. В самой квантовой механике нет ничего парадоксального в парадоксе ЭПР! Ни граммульки!

Так почему же его так пристально изучают?

И да, при чём тут эфир?!

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

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

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

Мы выясним, как преобразуются 3D-модели и учитываются источники освещения. Также мы подробно объясним разницу между вершинными и геометрическими шейдерами, и вы узнаете, на каком этапе находится место для тесселяции. Чтобы облегчить понимание, мы используем схемы и примеры кода, демонстрирующие, как в игре выполняются вычисления и обрабатываются значения.

На скриншоте в начале поста показана игра GTA V в каркасном (wireframe) режиме отображения. Сравните её с намного менее сложным каркасным отображением Half-Life 2. Изображения созданы thalixte при помощи ReShade.

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

Вопрос, казалось бы, простой на первый взгляд… можно погуглить, и всё станет ясно. Но практически все статейки в сети дают либо «космические» числа — вроде 400-600 мегапикселей (Мп), либо это и вовсе какие-то убогие рассуждения.

Поэтому постараюсь кратко, но последовательно, чтобы никто ничего не упустил, раскрыть эту тему.

Начнём с общей структуры зрительной системы

1. Сетчатка
2. Зрительный нерв.
3. Таламус(ЛКТ).
4. Зрительная кора.

Сетчатка состоит из трёх типов рецепторов: палочки, колбочки, фоторецепторы(ipRGC).

Однажды фронтендеру позвонил дизайнер и попросил сделать «паутинку» за запотевшим стеклом. Но потом оказалось, что это не «паутинка», а гексагональная сетка, и не за стеклом, а она уходит вдаль, и с WebGL фронтендер не знаком, а всей анимации пришлось учиться в процессе рисования. Тем фронтендером был Юрий Артюх (akella).



Юрий давно занимается версткой, а по воскресеньям записывает стримы с разбором реальных проектов. Он не профи в WebGL, не делает на нем карты, не пишет на Web-ассемблере, но ему нравится учиться чему-то новому. На FrontendConf РИТ++ Юрий рассказал, как провести одну анимацию от макета до сдачи клиенту так, чтобы все были довольны, и по дороге изучить WebGL. История идет от первого лица и включает в себя: Three.js, GLSL, Canvas 2D, графы и немного математики.

Всем привет. На связи Омельницкий Сергей. Не так давно я вел стрим по реактивному программированию, где рассказывал про асинхронность в JavaScript. Сегодня я бы хотел законспектировать этот материал.

Но перед тем как начать основной материал нам нужно сделать вводную. Итак, давайте начнем с определений: что такое стек и очередь?

Стек — это коллекция, элементы которой получают по принципу «последний вошел, первый вышел» LIFO

Очередь — это коллекция, элементы которой получают по принципу («первый вошел, первый вышел» FIFO

Окей, продолжим.

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

Стремление уйти от ручного регрессионого тестирования — хороший повод внедрить автотесты. Вопрос, какие именно? Разработчики интерфейсов Наталья Стусь и Алексей Андросов вспомнили, как их команда прошла несколько итераций и построила тестирование фронтенда в Авто.ру на базе Jest и Puppeteer: юнит-тесты, тесты на отдельные React-компоненты, интеграционные тесты. Самое интересное из этого опыта — изолированное тестирование React-компонентов в браузере без Selenium Grid, Java и прочего.



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

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write — подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.

Не смотря на простоту концепции, детали реализации CQRS могут значительно отличаться. И это именно тот случай, когда дьявол кроется в деталях.

Поле

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

Это первая часть серии туториалов, посвящённых созданию простой игры в жанре tower defense. В этой части мы рассмотрим создание игрового поля, поиск пути и размещение конечных тайлов и стен.

Туториал создавался в Unity 2018.3.0f2.


Поле, готовое к использованию в тайловой игре жанра tower defense.

Игра жанра Tower Defense

Tower defense — это жанр, в которой целью игрока является уничтожение толп врагов, пока они не добрались до своей конечной точки. Игрок выполняет свою цель, строя башни, которые атакуют врагов. У этого жанра очень много вариаций. Мы будем создавать игру с тайловым полем. Враги будут двигаться по полю в сторону своей конечной точки, а игрок будет создавать им препятствия.

[Первая, вторая и третья части туториала]

• Поддержка разных типов башен.
• Создание башни-мортиры.
• Вычисление параболических траекторий.
• Запуск взрывающихся снарядов.

Это четвёртая часть туториала, посвящённого созданию простой игры в жанре tower defense. В ней мы добавим башни-мортиры, стреляющие детонирующими при столкновении снарядами.

Туториал создавался в Unity 2018.4.4f1.


Враги подвергаются бомбардировке.

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

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