JavaScript *

Как сделать сайт, который понравится пользователю? Какой он должен быть: красивый, с удобной навигацией, с запоминающимся URL? Прежде всего, сайт не должен тормозить — у пользователя должно складываться впечатление, что всё летает. Это первично. Всё остальное решается по мере разработки. О том, как воспринимают сайт пользователи, от чего это зависит и когда производительность решает, мы поговорили с Денисом Мишуновым, frontend-разработчиком (в прошлом контрибьютор в CMS Plone в составе Plone UI Team), автором статей про производительность в Smashing Magazine и активным спикером на профессиональных конференциях (среди которых From The Front, JSConf EU, JSConf Budapest, Smashing Conference, а теперь и HolyJS)



— Расскажи о себе. Какой был путь к web-разработке, почему именно она? Чем ты сейчас занимаешься?

— До того, что сейчас называют веб-разработкой, я дошёл быстро, уверенно и предсказуемо: первый компьютер, первый, никому не нужный, сайт, осознание бренности бытия. Дальше было чтение первых страниц «Программирование на Perl» Ларри Уилла и Тома Кристиансен с депрессивным верблюдом на обложке, повторное осознание бренности бытия и, как следствие, откладывание верблюдокниги. А потом я открыл для себя «Designing with Web Standards» Джеффри Зельдмана. Потом было, конечно же, «Ководство» Лебедева и много всего остального. Но книга Зельдмана была переломной. Хотелось бы сказать что-то красивое типа: «мир веба захватил меня после прочтения», но на самом деле я просто понял, что по сравнению с «конструктор электронных аппаратов» (которых из нас тщетно пытались сделать в институте), интернет-разработчик, а именно так это называлось в начале нулевых, звучит откровенно круче.

Пару лет назад я впервые услышал про веб-компоненты (Web Components). Сперва меня это действительно заинтересовало, но как только шумиха вокруг них приутихла, они тут же вылетели у меня из головы. Но, как оказалось, в последнее время прошло интересное движение и поддержка этой технологии значительно выросла. Отзывчивые веб-компоненты, в частности, призваны упростить наш подход к адаптивному дизайну. Как многообещающе звучит!
Вот четыре пункта, с которыми стоит ознакомиться любому разработчику перед началом использования данной технологии:

• Поддержка технологии;
• Кроссбраузерная работа;
• Возможность адаптации в среде удельного проекта;
• Модульный подход.

В этой статье мы рассмотрим каждый из этих пунктов в отдельности…

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

Зачем всё это

Мы — маленькая компания, наш штат составляет порядка 50 человек, 20 из которых разработчики. Сейчас у нас 4 команды разработки, в каждой из которых сидит по 5 fullstack разработчика. Но одно дело называть себя fullstack-разработчиком, а другое — действительно хорошо разбираться в тонкостях работы SQL Server'а, ASP.NET, разработке на C#, OOP, DDD, знать HTML, CSS, JS и уметь этим всем разумно пользоваться. Конечно каждый разработчик тяготеет к чему-то своему, но все мы, так или иначе, специалисты именно в разработке на .NET и 90% кода мы пишем на C#.
Наш продукт — система автоматизации маркетинга, — подразумевает большой объем настроек для каждого конкретного клиента. Для того, чтобы наши менеджеры могли заниматься настройкой продукта под клиентов, есть административный сайт, в котором можно заводить рассылки, создавать триггеры и другие механики, кастомизировать сервисы и многое другое. Этот административный сайт содержит много различного нетривиального UI'а, и чем более тонкие моменты мы даём настраивать, чем большее количество фич мы выпускаем в продакшн, тем более интересным UI становится.

Доброго времени суток, харбачитатель.

В этой статье мне хотелось бы рассказать об одном придуманном когда-то алгоритме (или скорее всего — переизобретённом велосипеде) построения плавного графика по заданным точкам, используя кривые Безье. Статья была написана под влиянием вот этой статьи и очень полезного комментария товарища lany, за что им отдельное спасибо.

Постановка задачи
Есть массив Y-ков точек, расположенных равномерно по оси X. Нужно получить плавный график, который проходит через все заданные точки. Пример на рисунке ниже:



Всех, кому интересно, прошу под кат.

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

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

Основная идея

Состояние (state ориг.) это сердце каждого приложения и нет более быстрого способа создания забагованого, неуправляемого приложения, как отсутствие консистентности состояния. Или состояние, которое несогласованно с локальными переменными вокруг. Поэтому множество решений по управлению состоянием пытаются ограничить способы, которыми можно его изменять, например сделать состояние неизменяемым. Но это порождает новые проблемы, данные нуждаются в нормализации, нет гарантии ссылочной целостности и становится почти невозможно использовать такие мощные концепты как прототипы(prototypes ориг.).

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

Сегодня увидела свет версия 6.0. Изменений много, в том числе за счет обновления версии v8 (до v5.0), при этом некоторые из них могут поломать ваш код. В октябре этого года ветка v6.x станет новой активной LTS версией и её поддержка продлится до апреля 2018 года.

Изменена логика работы Buffer для повышения безопасности приложений. Из коробки будут доступны Proxy, Reflect, расширеная поддержка ES 2015. Основные изменения c примерами под катом.

Часть 1 Часть 2 Часть 3 Часть 4

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

Автор: Александр Трищенко


Я расскажу о своем хобби — организации видеотрансляций в браузере по технологии WebRTC (Web Real-Time Communication — веб-коммуникация в режиме реального времени). Этот проект с открытым исходным кодом Google активно развивает с 2012 г., а первый стабильный релиз появился в 2013 г. Сейчас WebRTC уже хорошо поддерживается самыми распространенными современными браузерами, за исключением Safari.

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

Если мы используем WebRTC, мы решаем следующие проблемы:

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

Компания Hola объявляет начало весеннего конкурса по программированию! Призовой фонд увеличен:

1. Первое место: 3000 USD.
2. Второе место: 2000 USD.
3. Третье место: 1000 USD.
4. Возможно, мы решим отметить чьи-то чрезвычайно оригинальные решения двумя специальными призами в 400 USD.
5. Если Вы отправите кому-то ссылку на этот конкурс, поставив наш адрес в CC, и этот человек займёт призовое место, Вы получите половину суммы приза (разумеется, не в ущерб награде победителя). За одного победителя такую награду может получить только один человек — тот, кто отправил ссылку первым.

Мы ищем талантливых программистов, поэтому авторы интересных решений будут приглашены на собеседования.

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

Правила

На этот раз мы решили попробовать что-то новенькое: для разнообразия, этот конкурс — не на производительность кода.

Условия конкурса на английском языке размещены на GitHub. Ниже — перевод на русский язык.

За работу frontend части приложения в Ruby on Rails отвечает библиотека Sprockets, которая не дотягивает до потребностей современного frontend приложения. В чем именно не дотягивает можно почитать, например, здесь и здесь.

Хотя уже есть достаточно статей на тему связки webpack+rails и даже специальный гем есть, предлагаю посмотреть на еще один велосипед, умеющий также деплой делать.

Hotel – приют для localhost.

Запуск и управление всех ваших веб-проектов с одного адреса.

Больше, разных портов костылей.

Можно держать зоопарк портов для каждого проекта: 9000, 8000, 8080, 3000, 3001…
Или настраивать веб-сервер, править /etc/hosts файл или DNS для каждого проекта.
А еще помнить, как запускать девелоперский веб-сервер для каждого проекта:

• gulp
• gulp serve
• gulp watch
• ionic serve
• browser-sync start --server --no-open --directory --files
• http-server -p 9000
• python -m http.server 8000
• php -S localhost:8000
• и так далее...

Сделать жизнь проще поможет hotel.

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

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

В последнее время все больше моих друзей, коллег и людей из сообщества говорят про работу с асинхронными функциями и в частности про использование async/await на своих проектах. Я решил разобраться для себя, что это за зверь и стоит ли его использоваться при разработке боевых проектов.

Первое что хочется развеять, это распространенное заблуждение о том, что async/await — это фича ES7.

По моему мнению, использование терминов ES6 и ES7 само по себе не очень верное и может ввести разработчиков в заблуждение. После удачного релиза спецификации ES2015, называемой ES6, у многих людей сложилось ошибочное мнение, что все в нее не вошло и заполифилено через babel — это фичи ES7. Это не так. Вот список того что появится с релизом спецификации ES2016. Как видите он не такой большой и async/await в нем никак не значится.

Я хочу, чтобы мы говорили правильно. И говоря о той, или иной фиче, ссылались на конкретную спецификацию в рамках которой она описана и реализована, а не мифические ES6, ES7 … ESN.

Желание разработать собственный Angular.js webApi модуль возникло при работе с большим количеством http-запросов в проекте.

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

Задачи, которые должен решать будущий webApi модуль:

1. Предотвратить дублирование http-запросов в проекте.
2. Группировать существующий список запросов по функциональным категориям, чтобы проще вносить правки в конкретные методы.
3. Быть полностью независимой функциональной единицей приложения, которая подключается к любому другому Angular.js проекту простым Dependency Injection'ом.
4. Инкапсулировать внутреннюю реализацию, чтобы избежать проблем при работе с внешними источниками.

Демо

Посмотреть исходный код модуля: github.

Дальше поговорим о каждом из этих пунктов подробнее.

Всем добрый день. Немного с задержкой, но все же выходит третий мини-учебник. На этот раз разобран react-router. А так же две главы посвещены интеграции react-router + redux.

В процессе интеграции rr+redux я не использовал react-router-redux и redux-router. Как указано в самой книге, из-за активного развития библиотек, мне хотелось бы «научить вас рыбачить», а не просто «дать рыбу».

Также, приведенный способ по интеграции основан на личном опыте, плюс ответах разработчика redux (его твиттер) на SO, и изучении различных репозиториев. Он не является «единственно верным». Пожалуйста, укажите ссылки на ваши репозитории, либо предложите свои варианты в комментариях.

Поехали!

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

Привет,

Javascript и Front-end в целом становятся все сложнее и сложнее. На мой взгляд, стандартная поставка Rails не отвечает современным потребностям Front-end разработчика. К тому же использование Sprockets делает ваш код очень Rails-специфичным, что затрудняет он-бординг новых разработчиков, незнакомых с Rails.

В данном видео, на примере простого React.js приложения, я покажу, как можно мигрировать со Sprockets на Browserify.

Этот подход дает следующие бонусы:

• Управление зависимостями Javascript пакетов через npm;
• Лучший туллинг и интеграция с IDE;
• Уменьшение связности фронтенда и бекенда;
• Возможность выделения фронтенда в отдельное приложение и репозиторий. Что может не являться бонусом на первый взгляд, но довольно удобно, когда вы работаете большой командой над большим приложением.

Код приложения доступен на гитхабе: https://github.com/nLight/tutorial-rails-react-browserify

Всем привет!
Хочу представить вам собственную разработку для создания API-документации. Она еще немного «сыровата», поскольку я уделил ей всего неделю, кроме того, я не являюсь веб-разработчиком. Однако на данном этапе, с целью написания API-документации для своего будущего проекта, она меня полностью устраивает.

Сама разработка находится на GitHub: github.com/gatools/restful-visual-editor

Заинтересовавшихся — милости прошу под кат.

1. C чего всё началось

Недавно у меня возникла необходимость написать очередную утилиту, обрабатывающую текстовый файл в формате, похожем на упрощённый BBCode, а именно в формате исходников для словарей ABBYY Lingvo — DSL (Dictionary Specification Language). (Не путать с другим DSL (Domain-specific language) — интересный случай, когда гипоним является омонимом к гиперониму).

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

Одной из задач утилиты было как раз нахождение этих тегов с исключением экранированных сочетаний.

Поскольку в регулярных выражениях JavaScript с недавнего времени можно пользоваться lookbehind assertions (в личных целях), я подумал, нельзя ли реализовать поиск при помощи этого средства, — тем более что в данной разновидности lookbehind можно использовать выражения переменной длины.