В этой статье мы рассмотрим как можно ускорить первоночальную загрузку web-приложения c помощью разделения кода (code splitting). Для реализации задуманного я буду использовать webpack v1, а для демонстрации — React (не обязателен).

В большинстве своих проектов я собираю все javascript файлы (а иногда css и картинки тоже) в ОДИН ОЧЕНЬ БОЛЬШОЙ bundle.js. Возможно ты, дорогой читатель, делаешь точно так же. Это достаточно стандартная практика для современных веб-приложений.

Но этот подход имеет один (и иногда достаточно важный) недостаток: первоночальная загрузка приложения может занимать очень долгое время, так как web-браузер должен (1) загрузить огромный файл и (2) распарсить тонну js-кода. Загрузка файла может занять долгое время, если у пользователя медленный интернет. Так же этот огромный файл может содержать код компонентов, которые пользователь НИКОГДА не увидит (например, пользователь просто не откроет некоторые части вашего приложения).

Что делать?

Зависимости. Дженерики. Они часто звучат в списке проблем в Go сообществе, но есть одна проблема, о которой вспоминают довольно редко — организация кода вашего пакета.

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

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

Хэш-таблицы используются везде, в каждой серьёзной С-программе. По сути, они позволяют программисту хранить значения в «массиве», индексируя его с помощью строк, в то время как в языке С допускаются только целочисленные ключи массива. В хэш-таблице строчные ключи сначала хэшируются, а затем уменьшаются до размеров таблицы. Здесь могут возникать коллизии, поэтому нужен алгоритм их разрешения. Существует несколько подобных алгоритмов, и в РНР используется стратегия связных списков (linked list).

В Сети есть немало замечательных статей, подробно освещающих устройство хэш-таблиц и их реализации. Начать можно с http://preshing.com/. Но имейте в виду, вариантов структуры хэш-таблиц — несметное множество, и ни один из них не совершенен, в каждом есть компромиссы, несмотря на оптимизацию циклов процессора, использования памяти или хорошее масштабирование потокового окружения (threaded environment). Одни варианты лучше при добавлении данных, другие — при поиске и т. д. Выбирайте реализацию в зависимости от того, что для вас важнее.

Хэш-таблицы в РНР 5 подробно рассмотрены в материале phpinternalsbook, который я написал вместе с Nikic, автором хорошей статьи про хэш-таблицы в РНР 7. Возможно, её вы тоже сочтёте интересной. Правда, она писалась до релиза, поэтому некоторые вещи в ней слегка отличаются.

Здесь же мы подробно рассмотрим, как устроены хэш-таблицы в РНР 7, как с ними можно работать с точки зрения языка С и как ими управлять средствами РНР (используя структуры, называемые массивами). Исходный код в основном доступен в zend_hash.c. Не забывайте, что хэш-таблицы мы используем везде (обычно в роли словарей), следовательно, нужно проектировать их так, чтобы они быстро обрабатывались процессором и потребляли мало памяти. Эти структуры решающе влияют на общую производительность РНР, поскольку местные массивы не единственное место, где используются хэш-таблицы.

Этот пост просто шутка и не пытается выставить инструменты, упомянутые здесь, в дурном свете. Я использую их постоянно, они великолепны, и я рекомендую их использовать. По мотивам It's the future @ CircleCI Blog

— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.

— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.

— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?

— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.

— Окей, лады. А что это?

Предлагаю читателям «Хабрахабра» перевод понравившейся мне статьи «After a year of using NodeJS in production» за авторством Gavin Vickery. Это продолжение его статьи «Why I’m switching from Python to Node.js», которую он написал чуть больше года назад в ответ на разочарования при использовании Python и как обоснование перехода на Node.



Год разработки с штатными инструментами командной строки, клиентские проекты и выпуск обновлений для продуктов нашей компании, в двух словах, это то, чему я научился за это время. Я бы хотел поделиться опытом, но речь пойдет не столько про Node, сколько за весь JavaScript в целом.

Если вы хотите создать собственное десктопное приложение на основе веб-технологий, то мир опенсорса предлагает два основных варианта: NW.js (ранее известный как node-webkit) и Electron (atom-shell). Выбор между ними не так очевиден, поэтому я решил создать сравнительную таблицу и остановиться на самых важных отличиях.

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

FastClick.js

Nota Bene. Практически всегда страница в браузере на вашем тач устройстве реагирует недостаточно быстро. Все из-за задержки в 300ms, чтобы убедиться, что это не double tap. FastClick.js — это полифил, который избавляет пользователей вашего сайта от этой задержки.

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

Что такое иммутабельность

Неизменяемым (англ. immutable) называется объект, состояние которого не может быть изменено после создания. Результатом любой модификации такого объекта всегда будет новый объект, при этом старый объект не изменится.

NeDB (Node.js Embedded Database) — встраиваемая база данных для NodeJS, реализующая подмножество MongoDB API. Эта легкая NoSQL СУБД написана на чистом JavaScript, не имеет бинарных зависимостей и, помимо NodeJS, может использоваться в NW.js, Electron или прямо в браузере.

Вторая часть заметок об объектной системе python'a (первая часть тут). В этой статье рассказывается, что такое классы, метаклассы, type, object и как происходит поиск атрибутов в классе.

В стандартной библиотеке Python 3.4 в своё время появился модуль asyncio, позволивший удобно и быстро писать асинхронный код. А уже к Python 3.5 в синтаксис были добавлены конструкции async/await, окончательно оформившие асинхронность «из коробки» как красивую и гармоничную часть языка.



Хотя asyncio сам по себе и позволяет писать высоконагруженные веб-приложения, оптимизация производительности не была приоритетом при создании модуля.

Один из авторов упомянутого PEP-492 (async/await) Юрий Селиванов (на Хабре — 1st1, его твиттер) взялся за разработку альтернативной реализации цикла событий для asyncio — uvloop. Вчера вышла первая альфа-версия модуля, о чём автор написал развёрнутый пост.

Если вкратце, то uvloop работает примерно в 2 раза быстрее Node.js и практически не уступает программам на Go.

Один из аспектов понятия «производительность Web» заключается в том, чтобы уменьшить наблюдаемые пользователем задержки; получить готовую к работе страницу как можно быстрее. В отношении протокола HTTP это подразумевает, что идеальный протокол связи выглядит как-то так:



Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправки\приёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.

Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?

Привет всем!

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

Сортировка массива данных – задача, которой далеко уже не первый год. Она преследует нас с первых курсов технических вузов, а кому особенно повезло, то и со школьной скамьи. Обычно это методы сортировки “пузырьком”, “делением”, “быстрая”, “вставками” и прочие.


Вот, к примеру, подобной реализации метода сортировки “пузырьком” меня учили в одной крупной IT-компании. Этот метод использовался матёрыми программистами там повсеместно.

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

JavaScript quality guide

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

От переводчика

Всем привет, с вами Максим Иванов, и сегодня мы поговорим о правилах оформления кода на языке JavaScript. Николя Бэвакуа (Nicolás Bevacqua), автор книги «Дизайн JavaScript-приложений» (JavaScript Application Design), разработчик из Аргентины, опубликовал данное руководство достаточно давно, первая запись появилась еще в 2014 году, многое написано по стандарту ES5, однако, в наши дни это все равно актуально, сейчас, когда ES6 еще нигде полноценно не работает без babel и прочих транспайлеров. Хотя мы видим прогресс в топовых десктопных браузерах (Google Crhome, Firefox), где уже реализовано 70-90% задуманного, мы видим, что они стремятся поддерживать новый стандарт, но, к сожалению, ещё нет браузеров, которые полностью могли бы поддерживать ES6. К слову, я буду очень рад вашим комментариям. В общем, удачи и давайте начнем.

PHP имеет всего одну структуру данных для управления всем. array — сложный, гибкий, гибридный, сочетает в себе поведение list и linked map. Но мы используем его для всего, потому что PHP придерживается прагматичного подхода: иметь предельно правильный, здравый и реалистичный способ решения проблемы, исходящий из практических, а не теоретических рассуждений. array позволяет делать работу, хотя о нем и так много рассказывают на лекциях по информатике. Но, к сожалению, с гибкостью приходит и сложность.

Последний релиз PHP вызвал большое оживление в сообществе. Мы не могли дождаться того, чтобы начать использовать новые возможности и почувствовать вкус ~2х прироста производительности. Одна из причин, почему это случилось — структура array была переработана. Но массивы все также придерживаются принципа «оптимизировано для всего; оптимизировано для ничего», еще не все идеально, есть возможности для совершенствования.

А что насчет структур данных SPL?

К сожалению… они ужасны. Раньше, до PHP7, они предлагали _некоторые_ преимущества, но сейчас мы дошли до точки, когда использование SPL не имеет практического смысла.

Почему мы не можем просто поправить и улучшить их?

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

«SPL data structures are horribly designed.»
— Anthony Ferrara

---

Введение: php-ds — расширение для PHP7, добавляющее структуры данных. Этот пост кратко охватывает поведение, производительность и преимущества каждой из них. Также в конце вы найдете список ответов на ожидаемые вопросы.

Github: https://github.com/php-ds
Пространство имен: Ds\
Интерфейсы: Collection, Sequence, Hashable
Классы: Vector, Deque, Stack, Queue, PriorityQueue, Map, Set

В этой статье рассматриваются 4 подхода к управлению приватными данными классов ES6:

1. Хранение данных в конструкторе класса.
2. Маркировка приватных свойств через соглашение об именовании (например, префиксное подчеркивание).
3. Хранение приватных данных в WeakMaps.
4. Использование символов в виде ключей для приватных свойств.

Первый и второй подходы широко использовались в ES5, а третий и четвертый – появились только в ES6. Давайте поочередно рассмотрим каждый на одном примере.

К концу 2015 года в распоряжении JavaScript разработчиков образовалось огромное количество инструментов. В этой экосистеме легко потеряться, поэтому успешные команды следуют выработанным правилам, которые позволяют не терять время и сохранять здоровье проектов. Под катом перевод статьи 2016 года от команды Heroku, в которой они рассказывают о десяти привычках веб разработчиков, у которых все работает и ничего не болит. Скорее всего 80% написанного вы уже знаете – тем интереснее вам будет прочитать об оставшихся двух приемах!

От переводчика:

Данная публикация является третьей и последней статьей цикла, стихийно возникшего после публикации перевода статьи "How to C in 2016" в блоге Inoventica Services. Тут критикуются некоторые изложенные в оригинале тезисы и окончательно формируется законченная "картина" мнений о поднимаемых автором первой публикации вопросах и методах написания кода на С. Наводку на англоязычный оригинал предоставил пользователь ImpureThought, за что ему отдельное спасибо. Со второй публикацией, наводку на текст которой дал, как я думаю, знакомый многим, пользователь CodeRush, можно ознакомиться здесь.

Мэтт (на сайте которого не указана фамилия автора, по крайней мере, насколько мне известно) опубликовал статью «Программирование на С в 2016 году», которая позже появилась на Reddit и Hacker News, именно на последнем ресурсе я ее и обнаружил.

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

Я не цитирую всю публикацию Мэтта. В частности, решил опустил некоторые пункты, с которыми согласен. Начнем.

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

В этой статье вы узнаете:

• в чем отличие от интерфейсов в Java
• важные и неочевидные последствия этих отличий
• как устроены интерфейсы под капотом
• вспомним про пустой интерфейс (interface{})
• затронем сакральную тему про дженерики
• разберемся, кто и зачем должен создавать интерфейс
• и постараемся научиться не абьюзить интерфейсы и начать жить

(artwork by Svitlana Agudova)