У меня ушел один месяц на создание своего сервера. Две недели ушло на понимание функционала и сборку прототипа. Одну неделю я писал Ktor-сервер на Kotlin и визуал в приложении на Flutter. И еще одну неделю тестировал. И я хочу, чтобы вы сэкономили две недели, когда решите создать ваш бэкэнд.
Frontend engineer
Как работает mobx изнутри и сравнение его с redux
Читая чат русскоязычного react сообщества в телеграмме (https://t.me/react_js), я вижу как с постоянной регулярностью появляются обсуждения mobx-а, сравнения с redux-ом с аргументациями про магию, сложность и "мутабельность" и у многих есть большое недопонимание что такое mobx и какие задачи он решает. И я решил написать эту статью с "разбором полетов" чтобы можно было собрать всю аргументацию в одном посте. Мы разберем как работает mobx изнутри путем реализации собственной версии mobx-а и сравним с тем как работает redux.
16 простых и эффективных правил дизайна UI
Проектировать пользовательский интерфейс сложно. Здесь есть множество возможных вариаций макета, отступов, типографики и цвета, в которых можно просто запутаться. А если к этому дополнительно прибавить юзабилити, доступность и принципы психологии, то задача становится ещё труднее.
К счастью, дизайн UI не обязательно должен представлять такие сложности. Работая в качестве дизайнера продуктов более двух десятков лет, я понял, что большая часть моих решений в плане визуального представления и реализации взаимодействия определялись системой логических правил. Не художественным чутьём или магической интуицией, а простыми правилами.
Наличие системы логических правил помогает эффективно принимать в дизайне продуманные решения. Без логической системы вы просто используете внутреннее чутьё, меняя компоновку элементов, пока не получится желаемый красивый результат.
Мне нравятся правила и логика, но в дизайне решения редко являются двоичными. Вместо строгих правил, которым вам необходимо следовать, воспримите приведённые далее рекомендации как руководства, которые прекрасно работают во многих случаях.
Самый быстрый способ обучения — это практика, так что приступим!
Полное понимание асинхронности в браузере
- Цикл событий
Задачи, тики и Web API
Очередь задач
16,6 миллисекунды на задачу
Обработка больших задач
Микрозадачи
requestAnimationFrame
requestIdleCallback
Сравнение очередей
Цикл событий в Node.js - Функции обратного вызова
Ад обратных вызовов
Не выпускайте Залго
Жёсткая сцепленность
Проблема доверия - Обещания
Цепочки обещаний и проброс отказа
Неявное поведение
Возвращение нового обещания
Спрятанный try/catch
Thenable-объекты
Статические методы
Promise.all
Promise.race
Promise.any
Promise.allSettled
Промисификация
Обещания или функции обратного вызова?
Корутины - Async/await
Верхнеуровневый await и асинхронные модули
Обработка ошибок
Не все await одинаково полезны - Заключение
Как я написал самую эффективную библиотеку для реактивного состояния
Всем привет, меня зовут Артём Арутюнян, и я уже пять лет изучаю реактивное программирование. Меня задела недавняя статья, Big State Managers Benchmark, в которой моя библиотека Reatom заняла лишь третье место (скорее второе, ну да ладно) и я решил написать самую эффективную реализацию реактивных состояний, убрав лишние фичи, сфокусировавшись на простоте и производительности.
Немного поэкспериментировав я добился удивительных результатов, в сто строк (0.3KB gzip) уместив максимально простое апи, которое позволяет подключаться к React и Svelte без дополнительных адаптеров. Но самое главное, найденный алгоритм фундаментально покрывает любые краевые случаи условных переподписок зависимых вычислений, с которыми подавляющее большинство популярных библиотек не справляется и дают глитчи.
Если вам интересны детали реализации — прошу под кат.
Как новичку разработать опенсорс-библиотеку: опыт фронтенд-разработчика
При разработке собственной опенсорс-библиотеки у многих возникает огромное количество вопросов. Для меня этот опыт также был в новинку — чтобы выпустить свою небольшую библиотеку, я перерыл половину GitHub в поиске наглядного гайда по подготовке репозитория. Поэтому хочу поделиться с вами своим опытом, а также узнать и что-то новое от вас.
Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. В этой статье буду делиться своим выводами, а также прикладывать дополнительные ссылки, чтобы познакомить вас с материалом более подробно.
Docker: заметки веб-разработчика. Итерация первая
Привет, друзья!
Хочу поделиться с вами заметками о Docker
.
Заметки состоят из 4 частей: 2 теоретических и 2 практических.
Если быть более конкретным:
- эта часть посвящена самому
Docker
,Docker CLI
иDockerfile
; - в второй части рассказывается о
Docker Compose
; - в третьей части мы разработаем приложение, состоящее из 3 сервисов (клиента, админки и API) и базы данных (PostgreSQL);
- в четвертой части мы это приложение "контейнеризуем".
Если вам это интересно, прошу под кат.
Советы по разработке игр от создателя Civilization Сида Мейера
В своей книге «Сид Мейер: Жизнь в мире компьютерных игр» знаменитый разработчик рассказывает о ключевых моментах карьеры, много шутит и через всю книгу дает советы и лайфхаки по разработке игр. А в этой статье основные из них — перевод под катом.
Делаем модальные окна для сайта. Заботимся об удобстве и доступности
Я занимаюсь вёрсткой и программированием сайтов. Почти в каждом макете, который я верстал, были модальные окна. Обычно это формы заказа звонка в лендингах, уведомления о завершении каких-то процессов, или сообщения об ошибках.
Вёрстка таких окон сначала кажется простой задачей. Модальные окна можно сделать даже без помощи JS только лишь с помощью CSS, но на практике они оказываются неудобными, и из-за маленьких недочетов модальные окна раздражают посетителей сайта.
В итоге было задумано сделать собственное простое решение.
Alt: City Online. Как я в одиночку создавал «Gta Online» для мобильных устройств. Часть 1
12 советов по внедрению TypeScript в React-приложениях
Эта статья — сборник советов о том, как внедрить и улучшить использование TypeScript. Первая половина советов общая, касающаяся подходов и инфраструктуры. Вторая — несколько особо полезных фишек языка.
Опубликован исходный код Command & Conquer: смотрим, что внутри
Компания Electronic Arts открыла исходный код первой Command & Conquer, а также Command & Conqueror: Red Alert. Скачать его можно с GitHub.
Всё содержимое имеет лицензию GPL v3; кроме того, в исходном коде сохранены все комментарии. Отсутствует только changelog использовавшейся при разработке системы контроля версий. Похоже, всё просто недавно выложили на Git.
Я решил изучить, что же происходит внутри этого игрового движка. Не буду описывать каждую строку кода, но, по крайней мере, будет интересно взглянуть на то, какой была разработка на C++ в начале 1990-х.
Изучать мы будем только исходный код «Command & Conquer: Red Alert», потому что он похож на форк первой игры. В репозитории он находится в папке
REDALERT
.Статистика
- 290 файлов заголовков C++
- 296 файлов реализации на C++
- 14 файлов ассемблера, содержащих инструкции ассемблера x86
- 222090 строк кода на C++
Количество строк кода я получил, подсчитав непустые строки, после чего вычел из них те строки, которые очевидно были комментариями.
Почти все файлы имеют имена в верхнем регистре.
Кроме того, есть файл «RedAlert.vcxproj», поэтому можно предположить, что проект можно собрать в более новых версиях Visual Studio, но этого я не проверял.
Несколько советов о том, как ускорить сборку Docker-образов. Например, до 30 секунд
Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.
Часть этого пути — сборка Docker-образа. Иногда сборка длится минуты, иногда — десятки минут, что сложно назвать нормальным. В данной статье возьмём простое приложение, которое упакуем в образ, применим несколько методов для ускорения сборки и рассмотрим нюансы работы этих методов.
Самый маленький компьютер
Игровой.
Но это не точно
Он, конечно, не претендует на звание «самого», но явно компактнее собратьев.
Представляю вам пошаговую инструкцию +заметки для сборки вполне себе компактного игрового ПК. Сразу говорю, что понятие «игровой» широкое, а я не богатый, так что тут не будет Core i9 и GTX 1080Ti, я собрал довольно скромную систему, впрочем, она мощнее, тише и меньше старой раз в 10.
Вместо вступления
У меня был средненький 7-летний компьютер, и в какой-то момент он перестал мне нравиться, тогда я решил собрать новый. С удивлением обнаружил, что вышли новые камни у обоих производителей и решил: «наконец-то соберу mini-ITX.» И собрал. Немного заморочившись с питанием (относительно, конечно, но по меркам сборки ПК, где «купил и поставил», заморочился) получил очень компактный ПК. Сами посудите: 210*170*95 мм.
Полная домашняя автоматизация в новостройке
Панель управления квартирой в феврале 2020 года (Home Assistant)
В этой статье расскажу о выборе технологий умного дома, используемых в квартире, а также приведу мои схемы разводки, фотографии всего что было сделано, получившиеся электрические щиты и конфигурации всех устройств, дам ссылку на гитхаб.
Строительство нашего дома в процессе — ноябрь 2016 года
Роботаракан Петя за десять баксов
Знакомьтесь с Петей, шестиногом о трёх сервоприводах
Продолжаю публикацию статей из серии "ардуино головного мозга". Петя — это очень дешёвый (примерно десять баксов) гексапод. Он может быть прекрасным проектом на один ненастный выходной, который развлечёт как и взрослых, так и детей. Раз уж мы про развлечения, вот вам видеоролик с Петей, танцующим под фанк-музыку:
Self-driving ГАЗ66 Monster Truck 1/16
Хочу рассказать вам о том, как я делал и сделал самоуправляему машинку :)
Я мог бы рассказать сразу, как делать, сухо прикрепив схемы и bash команды, но так будет скучно. Предлагаю вам интересную (я надеюсь) историю о том, как лично я прошел этот путь, и куда пришел.
Те места, где было что фоткать, с фотками. Там, где про софт — скорее всего без фото.
Это будет действительно история в формате повествования, как я рассказывал бы вам за чашкой кофе. Это не про bash команды, python скрипты, и вот это вот всё.
Начнём с фотки и видео того, что получилось, и дальше вся история под катом.
Как переписать фронтенд нагруженного проекта и не потерять главного
Представим ситуацию. Ваш сервис или сайт был запущен несколько лет назад. Он постоянно развивается, приносит прибыль, его любят пользователи. Кодовая база с каждым годом растёт, инфраструктура усложняется. Сервис ежедневно соревнуется с конкурентами и регулярно пополняется новыми фичами.
Но не всё так радужно. Команда разработки мечтает о модных фреймворках, документации и идеальной архитектуре. Тимлиды честно пытаются ускорить разработку функционала, а новые члены команды неделями изучают велосипеды ваши лучшие практики построения информационных систем. Вы теряете темп в развитии сервиса, а конкуренты начинают догонять.
Знакомо? Если да, то вы в непростой ситуации. Она закономерно возникает в большинстве проектов, которые за годы своего существования накопили достаточный объём legacy.
Доклад «42». Большой конспект
Однако несколько месяцев назад на конференции YaTalks в Екатеринбурге я выступил с новым докладом. В заголовке число 42, и возникает вопрос: «Неужели Макишвили — автор одной темы?» Нет. Самокопания не было. А что было? И можно ли «42» считать продолжением «36»?
Мой рассказ имеет отношение к предыдущей лекции лишь косвенно. В «42» я детально обдумываю тему, которой тогда едва коснулся. Но если кому-то удобнее думать, что «42» — вторая серия, пусть так. Тогда впереди ещё и третья, которая не будет иметь ничего общего ни с первой, ни со второй, ну разве что автор — я, и название тоже окажется каким-то числом.
«42» — точно не про кризис среднего возраста.
— Здравствуйте, друзья. Мне очень много хочется вам рассказать. Так много, что первая версия этого доклада длилась два часа. Но организаторы сказали мне — Макишвили, не наглей. Короче, вы со мной здесь на час. Я постараюсь, чтобы вам не было ни скучно, ни грустно.
Как проектировать большие и сложные веб-таблицы
Представьте, что вы разрабатываете систему для исследования данных. Или приложение для управления энергией. Или дашборд для продавцов кукурузой. Может быть, вы разрабатываете что-то подобное прямо сейчас. Во всех упомянутых случаях люди будут ожидать таблиц. Не те модные из вдохновляющих сайтов, а выглядящие как Excel монстры с сотнями ячеек и сложным взаимодействием.
В этом случае дизайнер сталкивается со многими проблемами. Например, сопоставление дизайна с существующими фронт-енд фреймворками или борьба с «неудобными» данными, которые разрушают макет. Мы преодолеем эти проблемы с помощью следующих шагов: систематизируем потребности, станем атомарными и определим взаимодействие.
Information
- Rating
- Does not participate
- Location
- Симферополь, Республика Крым, Россия
- Date of birth
- Registered
- Activity