JavaScript *

Привет, Хабр. Хочу рассказать об одной своей разработке в области 3D-графики, которую назвал Z-Desk.

Предыстория

Мои родители – инженеры. У нас дома была чертежная доска. Было что-то волшебное, когда на нее закреплялась бумага, а на бумаге с помощью нехитрых инструментов создавался чертеж. Школьное черчение стало моим любимым предметом. В институте появилась вообще срывающая голову дисциплина — начертательная геометрия. С помощью простых правил можно было делать сложнейшие пространственные построения.

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

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

Ряд публикаций Джейсона Орендорфа ES6 In Depth посвящен ES6, который добавили в язык программирования JavaScript в 6 итерации ECMAScript.

Сегодня будем делать такие штуки:



Немного сложно для первого примера. Подробнее объясню позже, пока что посмотрим, что за объект мы создали.

Нет ничего лучше, чем вновь почувствовать себя ребенком. Воспоминания с детства зачастую самые яркие и приятные. Случайно попавшаяся на просторах интернет фотография электронной игры «Ну, погоди!» («Электроника ИМ-02») навеяла массу воспоминаний и… породила желание не просто сыграть, а еще и реализовать её (специфика профессии). Собственно, результатом и хотел бы поделиться с аудиторией хабра. Игра «Ну, погоди!»

Доброго дня, читатели. Сегодня продолжим совершенствовать нашу игрушку и реализуем возможность атаковать карты противника, а так же некий профит в использовании ShadowDOM для админки.
В реализации атаки нам неожиданно поможет наш же способ реализации очереди из прошлой статьи (в противовес сообщению игроков по WebSockets).

Оговорюсь сразу, что развивать будем версию на MatreshkaJS, а не на Angular.

Я написал небольшую, но полезную библиотечку для любителей TypeScript и ASP.NET MVC. Очень хотелось бы про нее рассказать — возможно какому-то разработчику на вышеупомянутой комбинации технологий (а возможно и целой команде) она существенно облегчит жизнь. Писать полноценную документацию на английском пока что времени нет. К ней вообще нужно подходить осмысленно, с чувством, толком и расстановкой. Поэтому я решил написать статью на Хабрахабр, и вот прямо сейчас, под катом, я сделаю краткий обзор и покажу какую магию можно делать этой штукой. Добро пожаловать.

В начале 2014 года к нам в отдел контентных проектов пришла задача унификации дизайна. Дизайнеры хотели единый стиль проектов и принципы работы интерфейсов. Это будет удобно пользователям, облегчит запуск новых проектов и редизайн существующих (более подробно об этом писал Юра Ветров). Команда фронтенда получит возможность использовать схожие компоненты верстки на разных проектах, что уменьшит время разработки и поддержки существующего функционала. Для команды бэкенда задача оказалась нетривиальной: большинство наших проектов написана на Perl (Template Toolkit), Недвижимость на PHP, Дети и Здоровье используют Django. Но от нас требовалось реализовать не только поддержку единого шаблонизатора, но и согласовать единый формат отдаваемых данных в шаблоны. Обилие подгружаемых AJAX-блочков требовало поддержку еще и клиентской шаблонизации.

Таким образом, задача унификации дизайна превратилась в задачу выбора единого шаблонизатора для Perl, Python, PHP и JS.

Предпосылки и философские размышления

Как и у многих моих коллег по программистскому цеху, особенно у тех, кто рано начал пробовать свои силы в области компьютерных технологий, у меня где-то на задворках сознания хранится набор самых тёплых и романтических воспоминаний о первых опытах. Когда-то, в далёком 1987 году, отец впервые взял меня в выходной к себе на работу, где торжественно усадил на стул перед гудящей «Искрой-1030-11». Примерно тогда я твёрдо понял, чем хочу заниматься в своей дальнейшей жизни.

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

Мы рады представить вам наш первый релиз-кандидат версии React 0.14! Мы опубликовали в июле анонс предстоящих изменениях, но сейчас мы еще больше стабилизировали релиз и нам бы хотелось, чтобы вы попробовали его до того, как мы выпустим финальную версию.

Сообщите нам, если у вас возникли любые проблемы, создав задачу в нашем GitHub репозитории

Не так давно Microsoft объявила о выпуске TypeScript 1.6 Beta, одним из интересных, на мой взгляд, нововведением является поддержка React/JSX, что в совокупности с особенностями TypeScript'а открывает новые возможности.



Я расскажу о личном опыте — как начал использовать связку TypeScript + React, с каким проблемами столкнулся и как их решал. А так же покажу примеры gulp-тасков для того, чтобы это все заработало и продемонстрирую код минимального todo приложения на TypeScript + React (ссылка на Github).

Если вам это интересно — пожалуйста, заходите под кат.

Недавно Роскомнадзор предпринял попытку блокировки доступа с территории РФ к Википедии. Попытка провалилась, и самое время перейти в контрнаступление. В статье под катом я покажу, что, если пользователь Х зашёл на сайт А, то сайт А может определить, заблокирован ли для пользователя другой сайт Б. А дальше, по намечающейся традиции, изложение пойдёт в вопросно-ответной форме.

Для чего это вообще нужно?

При обсуждении блокировки Википедии сообщество заметило два обстоятельства, которые весьма выгодны цензуре. Во-первых, Википедия использует HTTPS и, более того, HSTS. Это означает, что заблокирована энциклопедия может быть только целиком (с точностью до домена), но при этом перенаправить на пресловутую страницу с сообщением о блокировке нельзя. Вместо этого высвечивается сообщение об ошибке установления соединения. Это выглядит как внутренняя проблема Википедии и смягчает недовольство пользователя действиями Роскомнадзора; в то же время для развития правового государства необходима обратная связь. Во-вторых, даже если пользователи узнают о блокировке, многие из них просто не будут знать, что делать. Вешать перманентную плашку «Если заблокировали Википедию — качайте Tor Browser!» на неравнодушных сайтах как минимум странно; в то же время, оповещение пользователей о блокировке Википедии и способах её обхода необходимо. Решение поставленной проблемы и пытается дать настоящая статья.

Делал перевод статьи The land of undocumented react.js: The Context, где сослался на статью Dan Abramov про умные и глупые компоненты, но почему-то думал что она есть на habrahabr. Думаю эта небольшая статья ни для кого лишней не будет.
Перевод статьи Smart and Dumb Components

Есть простой шаблон, который я нахожу чрезвычайно полезным, когда пишу приложения на React. Если Вы работали с React какое-то время, то, вероятно Вы уже поняли это. Это хорошо объяснено в этой статье, но я хочу добавить пару пунктов.

Вы найдете, что Ваши компоненты намного проще в реиспользовании и обсуждении, если Вы поделите их на две категории. Я называю их Умные (Smart) и Глупые (Dumb), но я так же слышал Fat и Skinny, Stateful и Pure, Screens и Components и так далее. Все это не абсолютно тоже самое но идея похожа.

Мои глупые компоненты:

1. не зависят от остальной части приложения, например Flux actions или stores
2. часто содержатся в this.props.children
3. получают данные и колбэки исключительно через props
4. имеют свой css файл
5. изредка имеют свой state
6. могут использовать другие глупые компоненты
7. примеры: Page, Sidebar, Story, UserInfo, List

Мои умные компоненты:

1. оборачивает один или несколько глупых или умных компонентов
2. хранит состояние стора и пробрасывает его как объекты в глупые компоненты
3. вызывает Flux actions и обеспечивает ими глупые компоненты в виде колбэков
4. никогда не имеют собственных стилей
5. редко сами выдают DOM, используйте глупые компоненты для макета
6. примеры: UserPage, FollowersSidebar, StoryContainer, FollowedUserList

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

Сотрудники Node.js и члены Node.js Foundation с гордостью представляют 4.0.0 версию продукта. В этот релиз включены бесчисленные часы совместной работы проектов Node.js и io.js, которые были успешно объедены в одну кодовую базу. Проект Node.js управляется командой из 44 человек, 15 из которых формируют Technical Steering Committee (TSC). Кроме того, более 100 участников были добавлены в список людей, способных влиять на развитие ядра, по сравнению с числом участников версии v0.12.7.

Node.js v4.0.0 содержит V8 v4.5, это та же версия V8, которая поставляется вместе с веб браузером Chrome сегодня. Это привносит с собой множество бонусов для пользователей Node.js, наиболее важные из которых, это поддержка ES6 стандарта, который включен по умолчанию, включая блочную область видимости, классы, типизированные массивы (Node's Buffer теперь работает поверх Uint8Array), генераторы, Promises, Symbols, строковые шаблоны, коллекции (Map, Set, и так далее) и, новая возможность для V8 v4.5 — стрелочные функции.

Началось все с тестового задания на вакансию «js-developer, Node.js-developer», и тут я выпал в осадок: задача на счастливые билетики.

Посчитать количество счастливых билетиков для 2, 4, 6, 8 и 10 цифрового значения.

Уверен, многие уже не раз делали эту банальную задачку, но, как правило, для 6-ти цифр (для тех, кто не понимает о чем пойдет речь).

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

• AngularJS
• DataBoom

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

Ну а во второй части с помощью DataBoom создадим замечательную очередь событий, как в оригинальной игре (напоминаю, что делаем по образу и подобию HeartStone). Забегая вперед скажу, что в следующий раз мы вообще избавимся от php сервера, и полностью перейдем на Databoom, но это уже совсем другая статья…

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

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

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

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?

Предлагаю читателям «Хабрахабра» перевод статьи «The land of undocumented react.js: The Context».

Если мы взглянем на React компонент то мы можем увидеть некоторые свойства.

State

Да, каждый React компонент имеет state. Это что-то внутри компонента. Только сам компонент может читать и писать в свой собственный state и как видно из названия — state используется для хранения состояния компонента (Привет, Кэп). Не интересно, давайте дальше.

Props

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

Context

Встречайте context, причину, по которой я написал этот пост. Context — это недокументированная особенность React и похожа на props, но разница в том, что props передается исключительно от родительского компонента к дочернему и они не распространяются вниз по иерархии, в то время как context просто может быть запрошен в дочернем элементе.

«Свобода — это возможность сказать, что дважды два – четыре. Если дозволено это, всё остальное отсюда следует.»
Джордж Оруэлл — «1984»

В современном мире активно развиваются различные распределенные технологии. Уже не первый год успешно функционируеют такие проекты как пиринговая платежная система Bitcoin, распределенные микроблоги (Twister), распределенные мессенджеры (например, Tox). Дошло дело и до полноценных распределенных сайтов.

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

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

Про Firebase уже не раз писали на хабре. Ключевым преимуществом этой системы является то, что в некоторых случаях на ней можно построить завершенное веб-приложение работающее с данными в реальном времени. Располагая возможностью редактирования правил доступа к базе данных и тем что эти правила можно устроить на основе пользователей (которых сюда тоже завезли), в принципе можно обойтись и без какого-либо backend'a. Но обычно возникают такие проблемы, которые лучше решить «со стороны» чем плодить велосипеды в правилах (например).

В середине мая разработчики объявили о выходе firebase-queue. Это javascript-библиотека с помощью которой можно организовать работу с данными в базе, как с задачами. Работает это следующим образом: определяем ячейку задач, используя Queue() на сервере устанавливаем связь. Теперь, когда в этой ячейке появится новый элемент, сервер сделает необходимые действия, если нужно оповестит о прогрессе и ошибках, и по завершению удалит задачу. В итоге мы получаем возможность покрыть много проблем возникающих в разработке с Firebase — согласовать данные, провести их дополнительную валидацию (например проверить на спам и мат) отправить их в другое место (например загрузить картинку на хостинг) и другое.