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

Идея данной статьи родилась после нескольких мучительных недель изучения WebGL. На личном примере выяснилось, что люди, не сталкивающиеся до этого с 3D-графикой, имеют в основном ошибочные представления о работе данной технологии. К тому же была проблема с поиском информации в интернете.

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

Этой статьёй хочется облегчить порог вхождения в чистый WebGL, дать начальное представление и подсказать, куда двигаться дальше.

Недавно в компании Wrike прошла встреча фронтенд-разработчиков. Спикеры из IT-компаний Петербурга и Москвы поделились своими решениями, помогающими облегчить работу со старым кодом, который имеет свойство накапливаться в течение жизненного цикла продукта, отвлекая от новых бизнес-задач. Отдельная часть докладов была посвящена языку Dart, а также причинам, пожиданиям и непосредственно самому процессу перехода с JavaScript на Dart. Делимся видеозаписями и презентациями самых интересных докладов. Часть 1.

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

Всем доброго времени суток!

Началось всё с того, что в качестве тестового задания на собеседованиях, я начал просить соискателей реализовать предзагрузчик картинок на JS. Помимо самой предзагрузки, скрипт должен был уметь подставлять fallback-картинку, если нужная картинка не могла быть загружена. Обязательным условием было — использование ES6 Promise.
Затем я подумал: «А почему бы самому не реализовать такой предзагрузчик и не выложить в общее пользование? Да это же еще и отличный повод написать статью на Хабр!».
Собственно, под катом описание логики работы такого предзагрузчика + ссылка на сам предзагрузчик.

Многие из нас, наверное, уже устали от этой шумихи вокруг последних стандартов ECMAScript. ES6, ES7 ECMAScript Harmony… Кажется, что у каждого свое мнение на счет того, как правильно называть JS. Но даже несмотря на весь этот хайп, то что сейчас происходит с JavaScript — это самое замечательное, что происходило с ним за последние лет 5 минимум. Язык живет, развивается, комьюнити постоянно предлагает новые возможности и синтаксические конструкции. Одной из таких новых конструкций, безусловно заслуживающих внимания, являются декораторы. Занявшись поисками материалов по этой теме, я понял, что в русскоязычном интернете практически ничего нет о декораторах. В то же время Addy Osmani еще в июле 2015 представил прекрасную статью Exploring ES2016 Decorators на Medium. В связи с этим, я хотел бы представить вашему вниманию перевод этой статьи на русский язык и разместить его здесь.

Почему определенные недостатки языка JavaScript в реалиях разработки такого большого проекта, как наш, оказываются критическими? Как решить проблемы JS, когда количество кода превышает 2 млн строк, а команда насчитывает более 20 человек и постоянно растет? Об этом — в докладе фронтенд тимлида Wrike в рамках митапа, проведенного в нашем офисе совместно с сообществом Piter JS.

Предлагаю вашему вниманию перевод статьи "I’m a web developer and I’ve been stuck with the simplest app for the last 10 days".

От переводчика: мнение автора местами частично, или полностью, не совпадает с моим, но вопрос поднимается, как мне кажется, правильный. Рекомендую почитать комментарии в блоге автора.

В основном я занимаюсь full-stack web-разработкой. Периодически пишу бэкенд на Python или Ruby, иногда работаю с C#. Еще я пишу консольные утилиты на C++ и Node.js. Мне нравится Closure, я познакомился с web много лет назад, когда писал на Perl и PHP, а первые годы профессиональной разработки посвятил программированию на Java.

Когда я впервые встретился с Javascript, он в основном использовался для того, чтобы добавить на страничку "Текущее время". Это были девяностые, когда все хотели приправить свои странички так, чтобы пользователи могли оценить, как это клево: текущий день недели выводится динамически. А спустя какое-то время оказывалось, что Javascript может гораздо больше, и мы получаем полностью динамический HTML — DHTML!

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

Десять дней назад я решил сделать небольшое SPA для себя — маленькая утилита, потенциальный pet-project. Работы дня на два-три. А последние полгода я работал над десктопным проектом на C#. Это была довольно скучная программулина для управления рабочими процессами: webservice-бэкенд и winforms на фронте.

Хотел по традиции написать про спикеров, которые будут в этом году на CodeFest 2016. Но в мою имманентную связь с текстовым редактором ворвался Евгений likegroof и предложил добавить внутренней кухни программного комитета да рассказать про домашние заготовки.

CodeFest — это конференция для разработчиков, тестировщиков, менеджеров и дизайнеров. Слушаем доклады, общаемся на квартирниках (специальный дискуссионный формат), веселимся на афтепати. Встречаемся в 1500 касок 26–27 марта в Новосибирске.

О чём речь?

Всё чаще возникает задача научить frontend-приложение работать в автономном режиме. Это значит придать web-приложению свойство mobile- или desktop-программы — функционировать в отсутствии связи с Интернет, а также в случае отказа сервера.

Цель — оградить пользователя от проблем соединения на его устройстве. Как было бы обидно не сохранить созданные в google docs таблицы из-за потери wi-fi в ближайшем фастфуде!

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

Решение задачи заключается в следующем:

Оригинал здесь.

Написав несколько приложений на React, теперь уже довольно скучно каждый раз начинать всё сначала. Мне нужно настроить webpack, webpack-dev-server, Babel с некоторыми пресетами и плагинами, Karma, React, несколько лоадеров для JSON, CSS, картинок и шрифтов – и объединить всё это вместе.

Чуть переведя дыхание после прошедшего события, а именно 2 недели, мы готовы в красках рассказать, как же прошла традиционная конференция Frontend Dev Conf.

16 апреля в Минске состоялась международная конференция Frontend Dev Conf! Уже в четвертый раз нам удалось объединить под ее началом более 300 участников и сделать FDConf громким событием во frontend-тусовке.

Мы создадим простой, но реалистичный модуль комментариев для блога, упрощенный аналог модуля комментариев реального времени, предлагаемый такими ресурсами как Disqus, LiveFyre и Facebook.

Мы обеспечим:

• Представление для отображения всех комментариев
• Форму для ввода и отправки комментариев
• Задел на будущее, для подключения настоящего бэк-енда

Также будут реализованы:

• Optimistic commenting: комментарии появляются на странице раньше чем они сохраняются на сервере, что визуально ускорит наш модуль
• Live updates: комментарии других пользователей появляются на странице в реальном времени
• Markdown formatting: пользователи могут использовать Markdown-разметку для форматирования текста

Финальная версия

Ссылка на GitHub

Клиент-серверная архитектура для разработчиков веб-приложений — это примерно как одна из черепах, на которой стоял мир в воззрениях наших предков. Трудно себе представить иное положение вещей. Однако бесчисленное количество веб-приложений сформировало новую потребность — управление данными на фронтенде. Пока нет единого подхода и реализации, есть только отдельные технологии, позволяющие работать с данными на клиенте. Да и с ними никто особо не заморачивается. А между прочим, пора. О том, что уже есть в плане работы с данными на фронтенде и что будет дальше, мы поговорили с Никитой Прокоповым aka tonsky.

На Хабре уже много писали о методологии БЭМ, выросшей в Яндексе. И мы решили, что пора системно рассказать о том, откуда она появилась и что сделало БЭМ таким, каким мы его знаем. Думаем, это будет интересно не только тем, кто уже использует БЭМ, но и тем, кто считает, что эта методология не подходит для их проектов. Возможно, они увидят, что мы решали проблемы, похожие на их собственные, и найдут что-то полезное для себя.



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

Каждый месяц по всему миру происходят десятки, если не сотни, IT-ориентированных конференций, выставок и других мероприятий.

В очередной раз мы собираем все наиболее интересные международные даты этого месяца для того, чтобы представить читателям «Мегамозга» в одном месте.

Оптимизация кода начинается не столько с изучения особенностей языка программирования, сколько с понимания схемы работы всей «технологической цепочки», задействованной при создании приложения — от алгоритма программы до компилятора.

Мы поговорили с Вячеславом Егоровым aka mraleph, инженером из Google, компиляторщиком до мозга костей, который работал над JavaScript движком под названием V8, встроенным в Chromium (и, как следствие в Chrome, Android версию браузера, облачную операционную систему Chrome OS) и в менее известный Maxthone.
JavaScript-программистам Вячеслав, скорее всего, известен как автор постов про внутренности V8 и как докладчик, увлеченно показывающий машинный код на конференциях для Web-разработчиков.

В настоящее время Вячеслав активно работает в Google над Dart VM.
В этом интервью он рассказал о том, что происходит внутри движка, выполняющего динамический JS-код и поделился примерами, как выполняются некоторые оптимизации и почему важно глубоко понимать работу движка, чтобы обеспечить быстрое выполнение кода.

В апреле этого года мы перезапустили tinkoff.ru. Банк превратился в финансовый супермакет. Теперь не только клиент банка, но и любой посетитель оплатит мобильный, проверит налоги и оформит ипотеку — всё на одной платформе. В этой статье я поделюсь опытом и технологическими решениями, к которым мы пришли за год разработки.

Всем доброго времени суток!
Данная статья начинает цикл публикаций, посвященных basis.js – фреймворку для создания полноценных Single Page Application.

Всем доброго времени суток.
Продолжаю увлекательный цикл статей про создание мощных Single Page Application на basis.js.
В прошлый раз мы немного пофилософствовали, а так же познакомились с токеном — одной из важнейших вещей в basis.js.
Сегодня речь пойдет о работе с данными.