JavaScript *

Когда я работаю с файлами в Node.js, меня не оставляет мысль, что я пишу очень много однотипного кода. Создание, чтение и запись, перемещение, удаление, обход файлов и подкаталогов, всё это обрастает неимоверным количеством бойлерплейта, который еще усугубляется странными названиями функций модуля fs. Со всем этим можно жить, но меня не оставляла мысль, что можно сделать удобнее. Хотелось, чтобы такие элементарные вещи, как, например, чтение или запись текста (или json) в файл можно было написать в одну строчку.

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

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

Есть несколько способов получить эти цифры:

Лежу я ночью, пытаюсь уснуть. И как обычно тысяча мыслей, и среди них я сумел зацепился за одну. А звучала она так: "почему бы не сделать анализатора футбольных матчей, где нужно будет лишь ввести участников игры и получить выборку из их статистики общей и какие-то описание, чего ждать в грядущем матче". Действительно, почему нет?!

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

Гугл дал свой результат, впрочем как всегда. Я нашел кучу калькуляторов ставок, которые продается за 3-5к рублей, и прочие таблицы расчетов в свободном доступе. Я как бы и так помнил расчеты тоталов голов, но мне нужно было их улучшить и получить на выходе собственно целого "мага/колдуна/вангу" спортивных событий. Или хотя бы формулку, которая выдаст результат после ввода данных.

Среди отзывов, полученных мной после этого доклада, занявшего второе место по полезности по результатам опроса после конференции, был такой: «Краткий пересказ документации Workbox». Что ж, в какой-то степени это действительно так: я рассказал пошаговую историю превращения «обычного» веб-приложения в прогрессивное с помощью этой замечательной библиотеки. Буду очень рад, если доклад и конспект вдохновят вас и помогут начать ваше собственное путешествие в мир сервис-воркеров и PWA.

Всем доброго дня или ночи! Затронутая в статье, тема может показаться настолько избитой до популярности, что при ее прочтении возникнет стойкое желание взять помидор или, не дай бог, кирпич и кинуть в автора. А изложенные мысли будут напоминать повторное изобретение велосипеда с квадратными колесами. Но идея, побудившая приступить к описанию, буквально зудит и проситься ей поделиться, несмотря на угрозу физического или морального наказания.

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

В моем случае она была столь полезной, что я решил перевести ее, чтобы запомнить получше и дебютировать с переводом на Хабре.

Люблю изобретать велосипеды и прочие нужные предметы заново. Получается не всегда хорошо, но процесс интересный. Предлагаю вашему вниманию библиотеку управления стейтом для React, Preact (вес всего 4.8Кб). Библиотека еще находится разработке, но уже можно попробовать.

Начнем с примера всеми любимого TODO органайзера. Исходный код на гитхабе. Для начала создадим основной компонент main.js.

От переводчика: При разработке бэкэнда наличие API для фронт-энда стало практически повсеместным стандартом. Однако можем ли мы называть это "настоящим" API? Предлагаем вашему вниманию интересное пятничное чтение, которое, возможно, повлияет на API, которые мы все разрабатываем.

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

Ценность API — в сокрытии информации

Предоставляя API, системы решают, какая информация должна быть доступна из внешнего мира, а какая будет держаться в секрете (“сокрытие информации”).

Почему это важно? Потому что чем объемнее API, тем дороже его поддерживать. Представьте себе крайний случай — открытие каждой детали реализации. Каждое изменение в системе может сломать код, который используют ваши клиенты. Именно по этой причине мы стремимся разрабатывать компактные API. Я писал статью (перевод на хабре) по этой теме в контексте описания шаблона “Регистрация событий”.

Вне зависимости от размера, API не позволяет менять систему так, как нам хочется. Мы всегда вынуждены детально документировать API и всегда думать о том, как бы не сломать клиентский код. Изменения должны быть обратно совместимы, в противном случае придется согласовывать развертывание всех зависимых систем, что быстро превратится в ад поддержки монолитного приложения.

Эта статья - часть серии статей "Составляя ПО" про функциональное программирование и различные техники создания программ на JavaScript ES6+, начиная с азов. Предыдущая часть: Сочиняя ПО: Введение / Хабр

Забудьте все, что вы знали о JavaScript, и постарайтесь воспринять эту статью так, будто вы начинающий программист. Чтобы помочь вам, мы рассмотрим JavaScipt начиная с самых основ, так, как будто вы никогда не видели JavaScript. Ну а если вы начинающий, то вам повезло. Наконец-то попробуем изучить ES6 и функциональное программирование с нуля! К счастью, все новые концепты будут изучены по ходу дела - но не рассчитывайте слишком уж сильно на это.

Всем привет, я Максим Кравец, CEO команды веб-инженеров Holyweb, адептов JavaScript. И сегодня хочу поговорить о паттернах проектирования.

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

• 75 лекций на русском от Y Combinator (из 172)
• Подборка 143 переводов эссе Пола Грэма (из 184)
• Все статьи Тима Урбана (Wait But Why) на русском [46 из 99]
• 450 бесплатных курсов от Лиги Плюща
• Онтол от DeepMind: самые полезные материалы по искусственному интеллекту от мирового лидера
• Лучшее в мире видео-объяснение нейронных сетей, глубокого обучения, градиентного спуска и обратного распространения
• 70 офигенных видеокурсов от мировых звёзд

React — это библиотека JavaScript для создания пользовательского интерфейса.

Это официальное определение React. Но что если вы не знаете, что такое JavaScript? Что если вы не разработчик? Смогли бы вы тогда понять, что такое React?

Однозначно ДА. Именно поэтому я и написал эту статью на тему: Что такое React на самом деле? Что такое React.js (или ReactJS)? Для чего используется React? Почему React так популярен? Какие проблемы можно решить с его помощью?

Эта статья — введение в React для начинающих. И это первое, с чего стоит начать, прежде чем детально изучить React. Я объясню основные идеи React на пальцах (и с помощью картинок). Нет опыта работы с JavaScript? Не беда! Если у вас есть базовые знания HTML (например, HTML-тегов), эта статья должна вам понравиться.

Это как посмотреть на React с высоты птичьего полета, но я дам вам бинокль. Так что вы не только увидите общую картину того, что делает React таким особенным, но и увеличите изображение, чтобы получить практический опыт написания реального React-компонента. И да, никаких знаний JS не требуется!

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

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

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

Эта статья основана на реальном проекте и реальном коде, который был ускорен с помощью кэша почти в полтора раза. Весь код написан на JavaScript.

Привет, Хабр!

В прошлых моих статьях обсуждая useMemo, мы постоянно упоминали React.memo. Поэтому в этой статье я решил глубоко погрузиться в понятие, что из себя представляет React.memo и конечно же изучим его исходники. (Данная статья является расшифровкой двух видео: React.memo это вам не useMemo и Чем отличается SimpleMemoComponent от MemoComponent?)