Я работаю с Реактом на протяжении почти 3 лет, использовал как Redux так и MobX и у меня к текущему моменту возник вопрос. Почему абсолютное большинство front-end разработчиков продолжают свято верить в то, что Redux + Redux Saga + Reselect + 100500 других библиотек «облегчающих» жизнь — это лучшее решение на сегодняшний момент? Я приведу 4 аргумента в пользу того, чтобы в следующем проекте вы использовали MobX вместо Redux.

— Вы ему не говорили?

— А что я могла сказать?! – всплеснула руками Татьяна, искренне возмущаясь. – Как будто я что-то знаю про этот ваш дурацкий квест!

— Почему дурацкий? – Сергей не менее искренно удивился.

— Потому что мы так никогда не найдем себе нового ИТ-директора! – Татьяна, по обыкновению, начала краснеть от возмущения. – Вы как ушли на повышение, так и спускаете на тормозах всех кандидатов!

— А вас это почему беспокоит?

— Я директор по персоналу, вот почему!

— Погодите… Я понял! – Сергей заулыбался, как ребенок. – У вас премия горит, так? Точно, скоро ведь конец года, KPI считать будут, а у вас одна из ключевых позиций пустует – ИТ-директор.

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

— Сергей… — начала было Татьяна.

— Ладно, будет вам ИТ-директор. – серьезно произнес Сергей. – Кандидат приличный?

— Да. – в голосе Татьяны зазвучали нотки надежды. – Вот, я резюме принесла!

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2265 в закладки, 353k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

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

Мы уже перевели 10 (из 30) глав.

Глава 1. Ориентация

(За перевод спасибо Savva Sumin, который откликнулся на мой призыв в «предыдущей главе».) Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

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

Я буду рассматривать, критиковать и демонстрировать различные стили мышления. Для иллюстрации стилевых особенностей я буду использовать технические знания, знакомые большинству из вас, что, опять же, надеюсь, станет для вас полезным повторением основ. Вам следует рассматривать этот курс в качестве дополнения к уже изученным вами техническим курсам. Многим вещам, о которых я буду говорить, не нашлось места в стандартных курсах, однако я глубоко убеждён, что вам необходимо о них знать. Этот курс существует потому, что Отдел Электрической и Компьютерной Разработки Аспирантуры Университета Морской Пехоты осознаёт необходимость общего, широкого образования, наряду со специализированным, технологическим обучением, которого потребует ваше будущее.

Мы это сделали!

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2588 в закладки, 429k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Мы ее переводим, ведь мужик дело говорит.

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

За перевод спасибо Андрею Пахомову.

Теория Информации была разработана К. Э. Шенноном в конце 1940х годов. Руководство Лабораторий Белла настаивало, чтобы он назвал ее «Теория Связи», т.к. это намного более точное название. По очевидным причинам, название «Теория Информации» обладает значительно большим воздействием на публику, поэтому Шеннон выбрал именно его, и именно оно известно нам по сей день. Само название предполагает, что теория имеет дело с информацией, это и делает ее важной, поскольку мы все глубже проникаем в информационную эпоху. В этой главе я затрону несколько основных выводов из этой теории, приведу не строгие, а скорее интуитивно понятные доказательства некоторых отдельных положений этой теории, чтобы вы поняли, чем на самом деле является «Теория Информации», где вы можете ее применять, а где нет.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

В предыдущей статье на тему дизайна таблиц в Фигме мы выяснили, что базовый элемент создания любого data grid — это компонент ячейки, внутри которого спрятано все необходимое для того, чтобы оставаться в одном экземпляре и строить таблицы ячейка-за-ячейкой. Теперь поговорим о её структуре: какие элементы вложены, случаи использования, рассмотрим темификацию таблиц через токены-цвета. И напоследок расскажу о передаче спецификаций разработчикам и интеграцию таблиц в React/Angular фреймворки прямиком из Figma дизайн-системы. Пока руками, ибо будущее всё еще где-то рядом.

Поехали! Начну с демонстрации бесполезных, но прикольных эффектов кастомизации всей таблицы через главную мастер-ячейку:

Вычисление ряда Фибоначчи — это классическая алгоритмическая задача, потому её нередко дают на собеседованиях, когда хотят проверить, что кандидат в принципе хоть как-то умеет в алгоритмы. Предположим, вы тот самый кандидат. Вам дали задание: на языке JavaScript написать функцию fib(n), возвращающую энное число Фибоначчи. Считаем, что нулевое число Фибоначчи — это нуль. Проверка корректности аргумента не требуется. Какие у вас есть варианты?

Снова всех приветствую! Как и обещал, я продолжаю писать о менеджменте в IT. В прошлой статье я рассказал о поиске и найме новых игроков в команду. Но какими бы классными и талантливыми людьми они ни были, они пока не команда. Можно провести параллель с футболом: вы можете купить суперигроков и выпустить их на поле, но они не будут командой и матч скорее всего проиграют, так как у них нет тактики и стратегии.

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

Автор материала, перевод которого мы сегодня публикуем, говорит, что уверен в том, что многие JavaScript-разработчики пользуются, в основном, такими типами данных, как Number, String, Object, Array и Boolean. В большинстве случаев этого вполне достаточно. Но если нужно сделать код как можно более быстрым и масштабируемым, применение этих типов данных не всегда оправдано.



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

Цифры говорят нам о том, что рост объёмов JavaScript-кода плохо влияет на производительность веб-проектов. Если так будет продолжаться и дальше, то уже очень скоро при загрузке средней страницы будет передаваться как минимум 400 Кб JS-кода. И это — всего лишь объём передаваемых данных. Как и другие текстовые ресурсы, JavaScript-код практически всегда передаётся в сжатом виде. Пожалуй, сжатие — это единственное, что обычно делается правильно при передаче кода с сервера на клиент.



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

Аарон Густафсон недавно отправил твит Indiegogo, в котором было сказано, что при распечатке их страниц с информацией о заказе получается нечто совершенно неприличное. И понеслооось.

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

01. Мондрианизм

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

---

02. Серендипность

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

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

Вы спросите: зачем нужна серендипность? Здесь все просто. С ее помощью можно сделать пользователя счастливее, а сайт/приложение – эффективнее, представляя пользователю возможность потреблять более релевантный контент и чувствовать себя в своей тарелке.

Несколько лет назад довелось мне попробовать свои силы в заманивании пытливых отроков в разработку микроэлектроники. А дальше было, как в известной пословице: «Коготок увяз — птичке пропасть!» Остановиться уже не смог. Хочу поделиться с общественностью этим опытом, возможно, другие инженеры-электронщики тоже захотят устроить что-то подобное. Грамотнее народ – лучше жизнь.

Началось все с того, что мы почти случайно договорились с Межрегиональной компьютерной школой в подмосковной Дубне о проведении для их слушателей чего-то вроде лекции о проектировании микропроцессоров. Тема эта известна мне не понаслышке, два десятка лет в ней варюсь. Довелось поработать и в отечественных, и в зарубежных фирмах. Ну и почему бы подросткам не рассказать, в чем состоит работа инженеров, выдумывающих внутренности «процов». Это не среди таких же зануд на конференции выступать — перед детьми просто оттарабанить текст не получится. Если им будет совсем не интересно, то плевать им на почетные седины, блистательные лысины и надутые щеки. Будут зевать, не стесняясь, и ерзать на стульях в надежде сбежать поскорее. Но есть и плюсы — всякие вольности, шутки, неточности и упрощения не вызовут негодования и требований сжечь еретика-докладчика. В общем, судя по количеству вопросов в процессе общения, первый блин вышел не комом, стало интересно двигаться дальше.

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

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

Когда Алану было одиннадцать лет, он продавал губки, чтобы собрать деньги на строительство клуба для скаутского отряда. Скаут-мастер, мудрый пожилой человек, поделился с Аланом секретом, который был назван Аланом “закон распределения вероятностей”. Это правило дословно:

Удача — это игра, чем дольше играешь, тем больше выигрываешь. И чем больше выигрываешь, тем более успешно играешь.

В этой статье мы рассмотрим распространённые виды утечек памяти в клиентском JavaScript. Также мы узнаем, как их обнаружить с помощью Chrome Development Tools.

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

«Исходный код словно заржавел!» — Джоэл Спольски

Почти два десятилетия назад Джоэл Спольски устроил разнос Netscape за то, что она переписала кодовую базу браузера, в своём эпохальном эссе «Чего никогда нельзя делать». Он пришёл к выводу, что функционирующий софт абсолютно никогда не следует переписывать с нуля. У него было два основных аргумента:

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

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

Ветеран программирования трёхмерной графики Майкл Абраш на примере разработки первого Quake рассказывает о необходимости творческого мышления в программировании.

Много лет назад я работал в теперь уже не существующей компании-производителе видеоадаптеров Video Seven. Там я помогал в разработке клона VGA. Мой коллега Том Уилсон, долгие месяцы круглосуточно работавший над разработкой VGA-чипа Video Seven, стремился сделать VGA как можно более быстрым, и был уверен, что его производительность оптимизирована почти по максимуму. Однако когда Том уже вносил в конструкцию чипа последние штрихи, до нас донеслись слухи, что наш конкурент Paradise достиг ещё большей производительности в своём разрабатываемом клоне, добавив в него FIFO.

На этом слухи заканчивались — мы не знали, ни что это за FIFO, ни насколько он помог, ничего другого. Тем не менее, Том, обычно приветливый и расслабленный человек, превратился в активного, одержимого фанатика со слишком большим процентом кофеина в крови. Исходя из этих крупиц информации, он пытался выяснить, что же удалось сделать Paradise. В конце концов он пришёл к выводу, что Paradise вероятно вставил FIFO-буфер записи между системной шиной и VGA, чтобы когда ЦП выполнял запись в видеопамять, записываемые данные сразу же попадали в FIFO, и это позволяло ЦП продолжать обработку, а не простаивать каждый раз, когда он выполнял запись в память дисплея.

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

CANVAS шаг за шагом:

1. Основы
2. Изображения
3. Понг
4. Пятнашки

Если верить англо-русскому словарю, то можно узнать что canvas переводится как холст, а если верить википедии, то можно узнать что тег canvas, это элемент HTML 5, который предназначен для создания растрового изображения при помощи JavaScript. Тому как создать это растровое изображение и будет посвящен мой небольшой текст. Прежде чем начинать пробовать свои силы в этом не легком деле рекомендуется уже иметь базовые знания о том что такое HTML и с чем едят JavaScript.

Товарищи инженеры, как и было обещано в анонсе, половина лекций (а это 51) уже доступны для просмотра на ютюбе и я продолжу их записывать в 2019 году. Часть из нужно будет перезаписать, потому, что в первых лекциях не самый лучший звук и потому, что очень простые темы у меня пока не очень хорошо получаются. Лучше вышли сложные и актуальные темы, которые мне и самому более интересно рассказывать. Я бы не сказал, что это курс для начинающих, скорее, это курс для тех, кто уже знает синтаксис. За это время поступило множество предложений, как улучшить способ подачи материала: делить на более короткие лекции, подготовить задачи для практического освоения, записывать семинары и ответы на вопросы студентов, добавить в программу разбор целого ряда спорных и холиварных тем. Но не все сразу, я и так посвящаю этому треть жизни.