JavaScript *

Недавно читал топип о красоте кода. В комментариях, набрала популярность тема переноса скобочек при записи условного оператора. В одном из вариантов пример из статьи выглядел так:

if (typeof a ! == "undefined"
&& typeof b ! == "undefined"
&& typeof c === "string")
{ 
    call_function(a, b, c);
    // ...
}

Задумался над самими условиями: они немного странные, хотя и часто встречаются. Внутри «call_function» будет проверяться тип «a» и тип «b», но не тип «с». С другой стороны, количество поддерживаемых сочетаний типов «a» и «b», поддерживаемых функцией конечно, и, скорее всего, фиксировано, а, значит, было бы полезно эти сочетания увидеть. А этот пост натолкнул на мысль, что можно вообще обойтись без условных операторов. Так и зародилась идея отказаться от условных операторов в пользу индексов. Несмотря на то, подход рассматривается в рамках Javascript, он с успехом может быть применен во многих других языках после учета их синтаксических особенностей.

Не надейтесь увидеть тут картины Рембранта мира программирования. Код в статье — произведение Дали. Впрочем, как и сама статья.

По роду своей деятельности мне часто приходится заниматься разработкой разнообразных crm-систем. Клиентскую часть уже очень давно собираю на Extjs (начинал еще со 2-й версии). На сервере пару лет назад прочно обосновался Nodejs, заменив привычный PHP.

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

Хочу поделиться историей моего знакомства с gulp и как я решал некоторые проблемы при разработке. Материал ориентирован на тех, кто знаком с nodejs и только начинает знакомиться с gulp, а также на тех, кто ищет решение схожей проблемы. Как следует из названия, статья состоит из трех глав.

Лига! Сегодня наш мир может стать чуточку спокойнее.

Новое оружие против сил зла ждёт проверки Советом. Оружие — BrowserSync Angular Template (bsAt) призвано ускорить каждого из нас, конечно не до скорости Флеша, но кто откажется быть хоть на секунду быстрее врага?

_{Предисловием мне хотелось бы поздравить одного хабраюзера с днём рождения. Расти большим, будь умным, и допили уже наконец свой canvas-фреймворк Graphics2D до того состояния, которое считаешь приемлемым.
С днём рождения, я. :P}

Этим летом мне пришла в голову интересная мысль: если бы я писал микробиблиотеку для canvas в 100 строк, что бы я туда уместил?.. Самый развёрнутый ответ можно написать за 1 вечер. А потом пришла и идея этой статьи.

Предлагаю реализовать ООП, события и анимацию на canvas — самые часто нужные (имхо) вещи… и всё это в 100 строк. Часть первая.

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

Мир javascript развивается с невероятной скоростью: новые стандарты языка, новые фреймворки, и в браузере, и на сервере и в десктопных приложениях и так далее… Но иногда хочется вместо изучения новой супер-фичи погрузиться в какую-то более базовую тему. И погрузиться глубоко, до самых исходников.

И в этот момент под моим пристальным взглядом оказалась незаметная строчка «native code», которая так или иначе появляется перед глазами любого JS разработчика в консоли Chrome или Node.js:

[].sort.toString();
"function sort() { [native code] }"

Итак, кому интересно, какая реализация сортировки скрывается в V8 за надписью [native code] — добро пожаловать под кат.

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

Вы несколько лет писали свой проект и теперь хотите привлечь пользователей? У меня есть простой, как холостяцкая яичница с беконом, рецепт специально для вас.

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

• репозиторий на GitHub — 1 штука
• готовый html шаблон, для придания приятного вида — 1 штука
• кусочек свежего компилирущегося C++ кода — минимум 1 строка кода
• готовые javascript соусы из магазина — ~500Kb
• картинки и анимашки по вкусу

Меняйте любые компоненты, экспериментируйте и готовьте свои сайты для любимого языка!

Кто я

Я — Александр Кашеверов. По образованию — магистр радиофизики. По профессии — веб-разработчик, работаю в компании DataArt с 2011 года, с 2009 увлекаюсь IT и веб-технологиями.

О чем статья, коротко

Рассмотрим, что такое веб-компоненты и polymer. Немного поразмышляем на тему развития веба. Посмотрим на технические детали, примеры, поддержку браузерами, тестирование. Коротко, понятно, по делу. С картинками.

Вступление

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

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

Для уменьшения головной боли хорошо бы, если в контексте веб:

• CSS не пересекался.
• Области видимости JS не пересекались.
• HTML был понятным и читаемым, никаких лишних элементов.

Допустим моя компания кому-то звонит и что-то продаёт и мне нужна простая CRM, которая позволит вести справочник контактов и наглядно отслеживать их состояние в плане продажи.

Сейчас мы с вами сделаем такую систему с нуля за считанные минуты. Для этого мы будем использовать фрэймворк Allcountjs.

Самые нетерпеливые могут сразу же посмотреть на результат.

Какими CSS обладает особенностями, которые приносят боль на больших проектах?

• глобальное пространство имен
• разрешение зависимостей
• поиск «мертвого» кода
• отсутствие констант
• неоднозначный результат (каскад)

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

Возьмем простой пример: кнопка и ее состояния.

Способы «общения» компонентов

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

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



Это чем-то напоминает WI-FI в кафе, когда все могут обмениваться сообщениями со всеми, но при этом есть роутер (диспетчер), который обеспечивает существование «эфира» и отдает сообщения только тем, кому они адресованы.

Такая организация позволяет, например, «бесплатно» получить слабое связывание компонентов. Недостаток ее в том, что при росте числа компонентов и соответственно числа событий становится сложно уследить за именами событий и за тем, кому какие события нужны для правильной работы. Появляются пространства имен и имена событий из чего-то типа «Событие1» превращаются в «Состояние_приложения1.Компонент2.Событие1». И что совсем невозможно делать при такой организации это компоновать события. Например требование «сделай что-то когда событие Б возникнет после двух событий A» выливается в тонну локальных переменных, хранящих последние данные из событий и счетчики самих событий.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

На прошлой неделе состоялся релиз Nodejs v5. Эта ветка включает в себя порцию новых возможностей и будет развиваться параллельно c веткой Node v4.x, которая является стабильной LTS веткой с длительным сроком поддержки в 30 месяцев. Релизы Node v5.x будут осуществляться раз в 8 месяцев.

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

Подробности под катом.

Пару недель назад (статья написана в августе — прим. перев.) мы описывали новую систему классов в ES6 в тривиальных случаях создания конструктора объекта. Мы показали, как можно писать код типа такого:

class Circle {
    constructor(radius) {
        this.radius = radius;
        Circle.circlesMade++;
    };

    static draw(circle, canvas) {
        // Canvas drawing code
    };

    static get circlesMade() {
        return !this._count ? 0 : this._count;
    };
    static set circlesMade(val) {
        this._count = val;
    };

    area() {
        return Math.pow(this.radius, 2) * Math.PI;
    };

    get radius() {
        return this._radius;
    };
    set radius(radius) {
        if (!Number.isInteger(radius))
            throw new Error("Circle radius must be an integer.");
        this._radius = radius;
    };
}

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

Хотя мы еще продолжаем работу над внедрением поддержки ES6/2015, команда Chackra также смотрит за пределы ES2016 и, в частности, на асинхронные функции. Мы рады объявить об экспериментальной поддержке async-функций в Microsoft Edge, начиная со сборки Microsoft Edge (EdgeHTML 13.10547).

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

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

Даже самый примитивный игровой персонаж должен обладать хоть какими-нибудь “мозгами”. Рыбки априори не блещут интеллектом, но кое-что они все же должны уметь — передвигаться, “смотреть”, убегать или нападать. От них не требуется искать укрытия или “морщить лоб” для умной ответной фразы. Выглядит просто, но легко ли сделать?

Разговор пойдет о реализации AI силами JavaScript и Blend4Web. Поставленные задачи, способы их решения или вынужденные пути обхода — все это на примере разрабатываемого живого, игрового проекта.

Прошло полгода с последней новости о TARS на хабре.

Напомню, что TARS — это сборщик html-верстки, основанный на gulp, в помощь любому frontend-разработчику (или даже целой команде), для создания проектов любой сложности. За последние шесть месяцев было закрыто 88 issue, выпущено 7 версий, появился CLI, так вышло, что с yeoman’ом отношения не сложились, поэтому появилась своя версия. TARS переехал в свой новый дом на github, обзавелся командой из 4 разработчиков + небольшой армией фанатов. Кстати, огромное вам спасибо за мгновенные фидбеки после релизов и не только. TARS был внедрен в нескольких вебстудиях России и за рубежом. Сборщик научил компонентному подходу не один десяток разработчиков, привлек в ряды frontend’еров тех, кто боялся всей рутины верстки. В общем, появилось много всего нового, и об этом хотелось бы рассказать.

Недавно я увидел статью на Хабре и очень удивился, что она вообще находиться на ресурсе для IT-специалистов. Но ещё больше меня шокировало то, что никто в комментариях не указал на очевидные грубые ошибки описанные в той статье. Хабр, что с тобой случилось? Когда всё пошло не так?


Эх вы, горе-IT-специалисты.