В последнее время все чаще требуется максимально быстрая разработка прототипов веб-приложений. Интерфейсы усложняются, требуется отображение огромного количества данных. И вот я озадачился созданием легкого и максимально простого html-шаблонизатора. Кому интересно, что получилось на ~50 строках JS-кода — под кат.

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Ученик спросил: «Программисты встарь использовали только простые компьютеры и программировали без языков, но они делали прекрасные программы. Почему мы используем сложные компьютеры и языки программирования?». Фу-Тзу ответил: «Строители встарь использовали только палки и глину, но они делали прекрасные хижины».

Мастер Юан-Ма, «Книга программирования»

На текущий момент вы учили язык JavaScript и использовали его в единственном окружении: в браузере. В этой и следующей главе мы кратко представим вам Node.js, программу, которая позволяет применять навыки JavaScript вне браузера. С ней вы можете написать всё, от утилит командной строки до динамических HTTP серверов.

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

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

Если вы хотите сразу запускать код из этой главы, начните с установки Node с сайта nodejs.org для вашей операционки. Также на этом сайте вы найдёте документацию по Node и его встроенным модулям.

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

Но врожденные любознательность и энтузиазм довели меня до того, что я стал одним из разработчиков Synaptic — проекта фреймворка для построения нейронных сетей на JS с 3к+ звезд на GitHub. Сейчас мы с автором фреймворка занимаемся созданием Synaptic 2.0 с ускорением на GPU и WebWorker-ах и с поддержкой почти всех основных фич любого приличного NN-фреймворка.

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

Около полутора лет назад мы написали внутренний инструмент для корпоративных анонсов. Изначально в нём использовался Phoenix для бэкенда и React для фронтенда. Тем самым мы получали преимущества Redux и каналов Phoenix при доставки обновлений в браузер в реальном времени.

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

Почему мы решили заменить React

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

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Учтите, что некоторые положения относятся не к самому JavaScript, а к программным интерфейсам веб-приложений (https://developer.mozilla.org/en/docs/Web/API).

Плохая конструкция

• Каждый скрипт исполняется в едином глобальном пространстве имён, доступ в которое возможен в браузерах с оконным объектом.
• Camel-регистр никуда не годится:

XMLHttpRequest
HTMLHRElement

CleverStyle Framework всячески помогает разработчику не только на сервере, но и на фронтенде. Я об этом несколько раз упоминал в прошлых статьях, но никогда не вдавался в подробности того, как именно всё устроено под капотом.

Данная статья будет погружением в подробности работы со статикой для фронтенда, начиная от того как определяются файлы нужные на странице и заканчивая оптимизациями доставки статики вроде HTTP/2 Server Push. Не забудем и о том, почему с использованием CleverStyle Framework можно обойтись без кастомной системы сборки и как при желании интегрировать такую систему сборки в процессы фреймворка.

Данная статья специально упускает из внимания интеграцию Bower/NPM и RequireJS, это будет тема отдельной статьи в недалеком будущем.

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

Традиционно перед коллекцией микросервисов предлагается дополнительный слой – так называемый API gateway, который решает сразу несколько проблем (они будут перечислены позже). На момент написания этой статьи open source реализаций таких gateway почти нет, поэтому я решил написать свой на PHP с использованием микрофреймворка Lumen (часть Laravel).

В этой статье я покажу насколько это простая задача для современного PHP!

Привет, Хабр! Несмотря на давно уже выпущеную Magento 2, Magento первой версии еще живее всех живых и пока еще не собирается нас покидать. Команда Magento будет поддерживать первую версию продукта 3 года с даты выпуска версии 2, т.е. примерно до ноября 2018. Рынок пестрит широчайшим выбором тем, модулей и сервисов заточеных под Magento 1.x версии. И большое количество сайтов, которые сейчас на Magento 1.x, не торопятся обновляться. Работы много — выхлопа мало. А значит, разработка под Magento первых версий еще актуальна и так будет несколько лет.

Но не о перспективах развития e-commerce решений пойдет речь в этой статье. Тут я решил собрать своеобразный гайд по созданию модулей для Magento 1.x (далее просто Magento). Но не простой гайд, в котором надо всего лишь следовать инструкциям, а с небольшими пояснениями «почему пишем так, а не иначе». Я старался найти золотую середину между краткостью и достаточностью. И в первую очередь, гайд несет пользу новичкам в деле разработки модулей для Magento. Но и более опытным пользователям данный материал может принести пользу.

Введение

Добрый день, дорогой %username%! Сегодня мы будем описывать создание каркаса приложение по типу MVC на Node.js с использованием кластеров, Express.js и mongoose.

Задача — поднять сервер который имеет несколько особенностей.

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

Статья написана новичком для новичков. Буду рад любым замечаниям!

Ранее я уже публиковал перевод статьи с таким же названием. И под ней товарищ aTei оставил комментарий:

По-моему кое-чего не хватает в этой статье и в статье в википедие — примера в стиле «Было плохо — стало хорошо». Сразу получается «хорошо» и не достаточно ясно, что это действительно хорошо. Буду благодарен за такой пример.

Ответа на него так никто и не дал до сих пор. За 3 года я набрался опыта смелости и теперь, как ответ на этот комментарий, хочу написать о паттерне Стратегия от своего имени.

Крохи теории встречаются где-то по тексту. Но большая часть статьи посвящена практическим способам применения этого паттерна и вариантам его применения избежать.

В Yii2 и множестве его сторонних расширений используется Bootstrap. Обычно Bootstrap не заменяют чем-то другим, ведь с ним достаточно удобно работать, и на вид он вполне эстетичен. Если захотелось освежить интерфейс приложения, то может быть не очень отрадно переопределять кучи css-свойств. Обиходные «шкурки» из bootswatch предлагать не буду, приятней взять препроцессор и переопределить несколько переменных. Преобразить облик сайта таким способом можно основательно. Покажу на примере с Less, так как актуальный бутстрап написан на нем. При желании можно подменить дефолтный пакет на Sass-овский или Stylus-овский и изменить приведенный далее код соответственно препроцессору.

Доброго времени суток! Разрабатывая сайт я подошел к тому, что мне необходимо добавить функцию добавления аватара для пользователей на десктопе и мобильных устройствах. Долго искал материалы, даже сначала решил добавить библиотеку с готовыми функциями, уже написанную кем-то (не помню как называлась статья, но она точно была на хабре и там были рассмотрены некоторые библиотеки). После тестирования этих подключенных библиотек я решил написать все на JavaScript и PHP (за исключением использования ajax для работы с php) при помощи HTML5. Для демонстрации я создал страницу для хабра: демо для habrahabr.

Что такое панель? Это довольно простой компонент, разбивающий видимую область на 2-3 блока:

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

Не смотря на кажущуюся простоту, реализации обычно не такие уж и простые. Связано это с тем, что вариантов его использования великое множество.

В шапке может быть, а может не быть:

• Заголовок. Дополнительно у него может быть подзаголовок.
• Хлебные крошки. Они могут быть частью заголовка, а могут — подзаголовка.
• Навигационные ссылки. Такие как "назад", "следующий" и тп.
• Кнопки. Такие как "открыть фильтры", "переключить флаг", "закрыть окно" и другие.

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

Получается, что у панели должно быть минимум 3 параметра, которые принимают "сложное содержимое", то есть такое, которое не является плоским текстом, а содержит иерархию вложенных блоков.

Далее идёт обзор тех готовых решений, которые можно найти в гугле. Для каждого указан размер реализации в строках кода (CLOS). Плюс бонус в конце, для тех, кто доберётся ;-)

Вы все еще отдаете поисковикам HTML-версию своего SPA приложения? 2016 год на дворе, времена изменились.

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

Такие вопросы, помимо нервного тика, приводят и к другим последствиям: у программистов не остается другого выхода кроме как соврать. Потому что дать человеку, далекому от программирования, экспресс-курс «Как писать код» за несколько минут, задача не из легких.

Итак, встречайте топ-7 фраз менеджеров, которые не оставляют выбора программистам.

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

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

Мне не нова магия Flexbox, но я не часто ее использую, и поэтому после паузы в использовании мне приходится открывать вот этот пост на CSS-Tricks чтобы освежить память.

Я решила создать краткую визуальную шпаргалку по Flexbox для тех случаев освежения памяти после паузы в будущем. Думаю, что у меня получилась шпаргалка, основанная на… шпаргалках.

В этом эссе описана схема работы Git. Предполагается, что вы знакомы с Git достаточно, чтобы использовать его для контроля версий своих проектов.

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

Текст разбит на серии команд, работающих с единым проектом. Иногда встречаются наблюдения по поводу структуры данных графа, лежащего в основе Git. Наблюдения иллюстрируют свойство графа и поведение, основанное на нём.

После прочтения для ещё более глубокого погружения можно обратиться к обильно комментируемому исходному коду моей реализации Git на JavaScript.

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

Олег Царёв ( zabivator )

Есть мастер, мастер неожиданно упал, но система продолжает работать. Клиенты мигрируют на вторую базу. Нужно делать резервные копии базы. Если делать резервные копии на основной базе, мы можем получить какие-то проблемы производительности, увеличение времени отклика. Это плохо. Поэтому достаточно распространенный пример асинхронной репликации — это снятие резервной копии со слэйва. Другой пример — это миграция тяжелых запросов с мастера на слэйв, с основной базы на вторую. Например, построение отчетов.

Иногда бывает необходимо, чтобы приложение могло получать все обновления из базы и желательно в режиме реального времени. Этим занимается оpen source библиотека, которая называется libslave.