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

C момента появления Node.js его и критикуют, и превозносят. Споры о достоинствах и недостатках этого инструмента не утихают и, вероятно, не утихнут в ближайшее время. Однако часто мы упускаем из виду, что критика любого языка или платформы основывается на возникающих проблемах, зависящих от того, как мы эти платформы используем. Вне зависимости от того, насколько Node.js усложняет написание безопасного кода и облегчает его распараллеливание, платформа существует уже довольно давно, и на ней создано огромное количество надёжных и сложных веб-сервисов. Все они хорошо масштабируются и на практике доказали свою устойчивость.

Но, как и любая платформа, Node.js не застрахован от ошибок самих разработчиков. В одних случаях падает производительность, в других — система становится практически непригодной к использованию. И в этом посте я хотел бы рассмотреть 10 наиболее частых ошибок, которые делают разработчики с недостаточным опытом работы с Node.js.

Всем привет. Многие знают об этой замечательной игре — LIMBO! Вы даже наверняка покупали ее в Стиме, или качали с торрентов…
Я тоже ее купил когда-то (что и вам советую!), и прошел). Но, как всегда, мне было этого мало, и я, из спортивного интереса, решил изучить ее защиту. Так и появился кейген к игре LIMBO.

В продолжение предыдущей статьи о тестировании интерфейсов в Тинькофф Банке расскажу, как мы пишем unit-тесты на javascript.

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

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

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Обычная скорость чтения на русском языке составляет 120—180 слов в минуту. С помощью долгих тренировок можно повысить её где-то до 600 слов в минуту. Совсем недавно небольшой стартап из Бостона представил новую технологию под названием Spritz.

Мне удалось без подготовки читать со скоростью 500 слов в минуту. Разработчики утверждают, что можно достигнуть 1000; без ущерба для смысла. Более того, утверждается, что использование Spritz также увеличивает скорость чтения обычных текстов.

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

_{давным давно, в очень далёкой галактике…*
*ой, кажется, это уже где-то было…}

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

– В-владимир, – слегка заикаясь представился клиент. – В-вы тут с-сайты р-раз-рабатываете?

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

– Ну да, я. Александр. Чем-то могу быть полезным?

В разработке интерфейсов отдельные фреймворки уже не так важны: когда инструменты доступны, наша задача сводится к выбору нужных. Чтобы сделать правильный выбор, следует начать с общего подхода, с методологии. Большинство методологий, однако, разработаны крупными компаниями. Применимы ли они в маленьких проектах или для успешного использования их нужно переизобретать заново?

Скорее всего, вы уже знаете об одной из таких методологий, разработанной Яндексом, — БЭМ. БЭМ утверждает, что трёх сущностей (блоков, элементов и модификаторов) достаточно для написания HTML и CSS, задания структуры кода и компонентной структуры с последующим масштабированием проекта до самого высокого уровня.

Я проработал в Яндексе достаточно долго и видел, как эта методология работает на больших проектах. В Яндексе БЭМ используют для разработки CSS- и JavaScript-компонент, с помощью этой методологии также пишут шаблоны и задают зависимости между компонентами. Есть БЭМ-инструменты, поощряются различные эксперименты с кодом, исследования. В масштабах большой компании эти трудозатраты окупаются и дают Яндексу возможность быстро и качественно разрабатывать сотни сервисов одновременно.

Могут ли маленькие команды получить от БЭМ то же самое? Я совершенно не был в этом уверен. Всё же БЭМ — абстракция, которая поставляется вместе с инструментами и технологиями. Для маленькой компании польза от переключения на «полный стек» этих технологий — сомнительна, многие из инструментов изначально приспособлены под крупные и сложные задачи. Быть может, тогда полезной окажется сама идея, сама методология?

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

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

Недавно прочитал неплохой пост на тему поиска работы QA и подумал, что похожий пост был бы полезен для JavaScript разработчиков. В конечном счёте, веб движется вперед семимильными шагами, и соискателей на позицию JavaScript программиста хоть отбавляй (разумеется, хороших всегда меньше).

Предисловие

Некоторое время назад на Хабре была новость о Spritz — программной реализации техники скорочтения, основанной на быстрой смене слов в виджете с определенным центрированием самого слова внутри виджета, а чуть позже и другая новость. Так как тема довольно актуальная я, недолго думая, решил реализовать нечто подобное и универсальное, с возможностью встраивания такого виджета для скорочтения в программы на различных платформах (win, linux, mac, android). Исходя из этого условия был выбран Qt фрейморк с его широкой поддержкой различных платформ.

То, что получилось и как с этим работать описано ниже. Кому интересно, добро пожаловать.

Открытые вакансии на должность разработчика в Яндексе есть всегда. Компания развивается, и хороших программистов не хватает постоянно. И претендентов на эти должности тоже хоть отбавляй. Главная сложность – отобрать действительно подходящих кандидатов. И в этом плане Яндекс мало чем отличается от большинства крупных IT-компаний. Так что базовые принципы, описываемые в этой статье, могут быть применимы не только к Яндексу.

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

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

Недавно я увидел изящный JS сниппет в этом твите.

var bind = Function.prototype.call.bind(Function.prototype.bind); // #fp

Взглянув на него, я смог догадаться, что он делает. Он превращает x.y(z) в y(x, z). Радуясь как ребенок, я показал его своим коллегам. Они спросили меня, что же тут происходит. Я открыл рот, чтобы объяснить и… не смог сказать ни слова. Я развернулся и ушел.

Сегодня утром стартовал очередной, уже четвёртый по счёту набор в школу программистов HeadHunter.
Занятия будут проходить по вечерам, два раза в неделю с октября по апрель в московском офисе технического департамента, недалеко от метро Алексеевская. Преподаватели – наши специалисты, в числе которых blv, mikesub, tum0rc0re и ваш покорный слуга. Во время обучения студентам выплачивается ежемесячная стипендия – 15 тыс. рублей. Лучшим выпускникам будущей весной мы предложим присоединиться к нашей команде.

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

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

Введение

Phaser — это движок для разработки мобильных и десктопных HTML5 игр, базирующийся на библиотеке PIXI.js. Поддерживает рендеринг в Canvas и WebGL, анимированные спрайты, частицы, аудио, разные способы ввода и физику объектов. Исходники доступны как для просмотра, так и для свободной модификации. Он создан Ричардом Дейви (Richard Davey), известному благодаря активному участию в сообществе программистов, использующих Flixel framework. Ричард не скрывает, что вдохновлялся Фликселем, поэтому некоторые вещи в Фазере будут знакомы опытным флешерам. Первая версия нового движка вышла 13 сентября этого года, сейчас ведется не только активное развитие библиотеки, но и написание документации, поэтому в данный момент уроков по ней, мягко говоря, немного. Что, по моему скромному мнению, следует исправлять, и прямо сейчас.

Для всех, кому прохладного дождя за окном в эти дни мало, Marek Brodziak сделал забавное демо на js + canvas (демо #1, демо #2 — и сразу предупреждаю, что заработать может не во всех браузерах), которое имитирует капли дождя на стекле. Своей целью разработчик ставил добиться лучшей плавности анимации капель.

Для достижения наилучшего эффекта погружения смотреть демо рекомендуется предварительно открыв в соседней вкладке raining.fm.

Данная статья отвечает на вопрос, чем он и как должен заниматься, со всеми интимными подробностями. Подразумевается, что есть проект (стартап) с веб-частью, который работал некоторое время без тестирования безопасности, но по каким-либо причинам решили его внедрить. Последние 2 года я работал security в стартапе с очень крупными клиентами (стартап один из лидеров в мире в своей области), и я уверен, мне есть что сказать по этой теме (естественно, вся информация ниже — лишь мои идеи, подходы и размышления, а не гайд howto и ни шагу в сторону). Статья посвящается заинтересованному начальству, PM'ам, а также человеку, который будет именоваться как Security Testing Team Lead и создавать подобный отдел с нуля.

Итак, вы решили создать security отдел…

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

Веб сейчас везде, и предлагает очень мощную среду для создания и распространения приложений. Вместо цикла: написание кода → компиляция → запуск, просто обновите приложение или даже напиши код «на живую» в браузере. Кроме того, это относительно безболезненно позволяет распространять своё приложение на огромном количестве платформ. Интересно, что в последние несколько лет, разработка игр, используя HTML5, стала реальностью.
Элемент canvas был введен вместе с HTML5 и предоставляет API для работы с ним. API — прост, но если Вы никогда не работали с графикой, Вам потребуется время чтобы привыкнуть. Canvas поддерживается большим количество браузеров, что делает веб — хорошей площадкой для создания игр.

Однажды мне было очень скучно. Настолько, что я решил достать все детали своего «конструктора» и собрать что-нибудь.



В закромах нашлось следующее: Arduino совместимая плата, роутер tp-link mr3020, модуль GPS, гироскоп\акселерометр, и куча всякой прочей ерунды.