30 полезных сервисов для веб-разработчика / Habr
Решил собрать сервисы, которые могут быть полезны веб-разработчикам и дизайнерам. Буду рад, если кто-то найдет для себя полезный сервис. Осторожно, под катом куча картинок!
Blind Text Generator — генератор текста-рыбы
Random User Generator — генератор случайных пользователей
User Inter Faces — генератор аватарок для вашего проекта.
CSS3Ps — конвертер из PSD в CSS
Prepros — компиляция, сжатие, оптимизация и еще куча всего — все возможности смотрите на сайте
Webflow — drag & drop редактор для создания респонсивных сайтов
html2pdf — конвертер веб-страниц в PDF-формат
Less2CSS — конвертер из Less в CSS
Trackduck — рецензирование веб-страниц (полезно для фрилансеров)
NinjaMock — неплохой инструмент для прототипирования
Moqups — еще один инструмент для прототипирования
Sache — коллекция Sass и Compass расширений
Web Developer Checklist — проверьте все пункты чек-листа перед запуском своего проекта
Live Tools — 4 инструмента: генератор кнопок, форм, лент на чистом CSS, а также редактор иконок
Glyphter — создание своего иконочного шрифта
Pics.IO — онлайн фоторедактор
Safarizator — вставка вашего дизайн-макета в окно браузера Safari
PlaceIt — еще один сервис для генерации превью ваших работ
TinyPNG — сжатие изображений в формате PNG
BrowserShots — тестируем сайт в самых различных браузерах
Golden Ratio Typography Calculator — расчет оптимального размера шрифта на основе золотого сечения
CSS Arrow please — генерация блока со стрелкой (тултипа) на чистом CSS
Lavish — генератор цветовых схем для Bootstrap на основе пользовательского изображения
Favicon Generator — генератор кросплатформенной favicon
HTML5 Please — статистика по поддержке фич HTML5 в различных браузерах
Pictaculous — генератор цветовой схемы на основе загруженного изображения
JSON Generator — генератор большого объема нужных данных в json-формате
Codio — онлайн-IDE для полноценной разработки любых проектов, связанных с веб-технологиями
CSS Hexagon Generator генератор CSS-шестиугольника
StyleStats — исчерпывающая статистика о CSS-файле
habr.com
116 инструментов для разработчиков — Лайфхакер
Не обязательно становиться рок-звездой для того, чтобы зарабатывать много денег и быть популярным. Новые рок-звёзды — программисты. Ниже вы найдёте более сотни инструментов, которые облегчат работу разработчику.
Оригинальный пост был опубликован на портале DailyTekk. И хотя появился он достаточно давно, список по-прежнему актуален. Инструменты разделены на разные категории: платформы для разработки, обучение программированию, багтрекинг, API и прочее. Не все инструменты бесплатные, но за удобство и новые функции приходится платить. Надеемся, вы найдёте что-то полезное для себя.
Обучение программированию
Treehouse- Treehouse — обучение дизайну и разработке для веб и iOS.
- Codeacademy — интерактивный и весёлый способ научиться программированию.
- Code School — практические курсы для веб-разработчиков.
- Udacity — обучение посредством решения практических задач от известных преподавателей.
- Coursera — множество компьютерных курсов, причём бесплатных.
- RubyMonk — интерактивные курсы по Ruby.
- Khan Academy — бесплатное образование с огромным множеством курсов по программированию.
- School of Webcraft — наполняемый пользователями ресурс по веб-разработке.
- Google Code University — гайды, курсы и обучающие материалы от Google.
- Orientation to Android Training — официальный курс по разработке на Android.
- Phpacademy — бесплатные видеоуроки по PHP.
- Hexlet — обучение программированию в реальной среде разработки.
Системы контроля версий
GitHub- GitHub — хостинг для IT-проектов.
- Pixelapse — сервис, который показывает, как выглядел код в прошлых версиях.
- Bitbucket — бесплатный хостинг для кода.
- Versions — Mac-клиент для сервиса Subversion.
- SourceTree — бесплатный Mac-клиент для систем Git и Mercurial.
- OFFSCALE — управление версиями баз данных.
- Tower — Git-клиент для Mac.
Разное
AppNeta- AppNeta — облачная APM (Application Performance Management).
- TaskMissile — сервис для получения фидбэка от пользователей.
- Kera — создание встроенных в приложение туториалов для пользователей.
- Flowdock — почтовый клиент и чат для команд.
- Modulus — хостинг для Node.js и MongoDB.
- Metricfire — сервис для отслеживания различных метрик.
- Interstate — позволяет превратить обычных пользователей в лояльных.
- Codenow — совместная работа для программистов. Легко находить код и делиться им.
- Lingohub — локализация софта.
- TranslateKarate — простой онлайн-сервис для перевода и локализации.
- Kickfolio — тестирование, поддержка, маркетинг и реклама. Всё в одном.
- Snippets — сервис для хранения сниппетов.
- Product Hunt — множество идей для новых приложений.
Платформы для разработки
Heroku- Heroku — облачная платформа для создания приложений.
- Compilr — позволяет следить за кодом с любого браузера.
- Kinvey — облачный back-end для мобильных приложений.
- Firebase — back-end для вашего сайта.
- Cloud9 — IDE онлайн.
- Parse — полноценная платформа для мобильных приложений.
- CloudMine — back-end для мобильных и веб-приложений.
- Koding — IDE в браузере. Новый способ работы для разработчиков.
- AppHarbor — облачная платформа .NET.
- dotCloud — помощь в разработке и расширении веб-приложений.
- BrainEngine — облачная платформа для Force.com.
- PHP Fog — облачная платформа для PHP.
- Backrest — лёгкое создание back-end для SaaS.
- Codeanywhere — онлайн-редактор кода.
- NeptuneIDE — облачная IDE для PHP.
- Fusegrid — облако для ColdFusion.
- Cloud IDE — написание кода и дебаггинг в онлайне.
- FriendCode — социальная сеть для программистов.
- ToolsCloud — среда для разработки в онлайне.
Интеграция и развёртывание
- Travis CI — интеграция и развёртывание для мобильных приложений.
- CircleCi — интеграция и развёртывание для веб-приложений.
- Railsonfire — интеграция и развёртывание для софта на Ruby.
- Wercker — платформа для создания и интеграции приложений.
- Hostedci — интеграция и развёртывание для приложений на iOS и OS X.
Обратная связь, мониторинг и багтрекинг
Crashalytics- Crashlytics — система для отслеживания крэшей приложений на iOS и Android.
- Usersnap — делает скриншот багов в приложениях.
- Crittercism — платформа для мониторинга производительности.
- Rollbar — отчёт и трекинг багов в реальном времени.
- New Relic — APM для веб-приложений.
- Exceptional — отслеживание ошибок в веб-приложениях в реальном времени.
- BugSense — система для слежения за крэшами в мобильных приложениях.
- Bugzilla — серверное ПО для управления разработкой приложения.
- Bugify — отслеживание ошибок в PHP-коде для небольших команд.
- BugHerd — простой багтрекер.
- Snowy Evening — отслеживание багов и интеграция с GitHub.
API
- Twilio — API для мессенджеров и VoIP.
- OpenWeatherMap — бесплатные API погоды.
- Stripe — платёжная система для разработчиков.
- Factual — API структурированной информации.
- Filepicker.io — упрощение работы с контентом, созданным пользователями (UGC).
- PubNub — сервис для обмена сообщениями в реальном времени в облаке.
- Mailgun — почта для разработчиков.
- Context.IO — API для почтовых клиентов.
- Semantics3 — API для информации о товарах.
- Redpin — система для навигации в помещении.
- Sent.ly — API для SMS-общения с пользователями.
- Embedly — конвертирование URL в видео, фото и другое.
Разработка игр
Viximo- Viximo — платформа для дистрибуции социальных игр.
- XNA — инструменты для разработки игр от Microsoft.
- Yodo1 — платформа для дистрибуции игр в Китае.
- Game Closure — SDK для игр на JavaScript.
- FTW — синхронизация сохранений, счёта и друзей между устройствами.
- Storybricks — создание собственной MMO.
Разработка мобильных приложений
- Codiqa — быстрое создание прототипа мобильного приложения.
- AppCooker — генератор мокапов для мобильных приложений.
- Apptentive — обратная связь для мобильных приложений.
- AppCod.es — SEO и маркетинг в App Store.
- Chupa Mobile — рынок для компонентов мобильных приложений.
- Appboy — аналитика, CRM и прочее.
- Flurry — аналитика, трафик и монетизация.
- Octopod — платформа для разработки мобильных приложений.
- Little Eye — слежение за потреблением батареи для приложений на Android.
Вне категории
Storyteller- Binpress — рынок для покупки скриптов и компонентов для разработки.
- UploadCare — сервис для загрузки и хранения кода.
- Eden — библиотека PHP для быстрого прототипирования.
- Appbackr — краудфандинговая платформа для мобильных приложений.
- Modkit — программирование для чего угодно.
- TechScratch — сервис помогает сфокусироваться на том, что вы делаете лучше всего, и помогает со всем остальным.
- Storyteller — создание контентных сайтов.
- Feed.Us — CMS для веб-приложений.
- Hosted Graphite — информация в виде понятных графиков и диаграмм.
- Divshot — создание интерфейсов для веб-приложений. Быстрое прототипирование на HTML 5.
- FlyWithMonkey — инструменты для разработчиков на HTML5.
- Expanz — помогает с разработкой приложений для бизнеса.
- Zapstreak — AirPlay для Android.
- RepoDrop — приватный репозиторий для кода.
- CodeWars — тренировка и проверка своей способности к программированию.
- Architexa — помогает понять сложные части кода в Java.
- UserMetrics — аналитика того, как пользователи используют ваше приложение.
- Setapp — находите и делитесь полезными инструментами.
- Coder Bounty — устанавливайте награду за решение проблем в коде.
- Last5 — отслеживание времени и продуктивности для разработчиков.
- XtGem — система для создания сайтов.
- uTest — тестирование приложений.
lifehacker.ru
12 портативных приложений для веб-разработчика / Habr
Любой веб-разработчик всегда должен иметь под рукой свои рабочие инструменты. Конечно, зачастую вы работаете дома или в офисе, со своим рабочим компьютером. Но если вы часто находитесь в разъездах, или же устариваете демонстрации своей работы в офисе у клиентов, то вам на помощь придут портативные версии необходимых программ.
В каких случаях могут пригодиться портативные приложения?
Большинство разработчиков просто всегда берут с собой ноутбук. Правда не всегда есть возможность его использовать, например в тех случаях, когда клиент хочет посмотреть работу сайта или приложения на своем собственном компьюетре.
Кроме того, не стоит исключать возможность поломки ноутбука, с потерей всех данных, без возможности восстановления.
Специально для таких случаев, неплохо было бы иметь запасной вариант, в виде usb-флешки, с набором всех необходимых программ.
Использование портативных приложений
Существует большое количество замечательных приложений для веб-раработчика, которые не требуют установки и отлично подходят для хранения на флешке. А если принять во внимание сегодняшние объемы флеш-накопителей, вы легко сможете хранить всю свою работу на них, и при необходимости использовать для работы любой компьютер, без дополнительного программного обеспечения.
Далее представлен список лучших портативных приложений, которые пригодятся любому веб-разработчику.
1. KompoZer Portable
KopmpzerPortable, (ранее известный как Nvu Portable), это замечательный HTML-редактор, который по своей функциональности напоминает Dreamweaver. Конечно он не такой красивый, однако прекрасно подходит для редактирования кода, и гораздо более удобен, чем обычный блокнот.
2. Firefox Portable Edition
Firefox — наиболее популряный среди веб-разработчиков браузер, со своей впечатляющей коллекцией расширений, также доступен в виде портативной версии. Представляет собой полный аналог обычного браузера, без необходимости установки в систему.
3. XAMPP Portable
XAMPP — это отличный локальный сервер (подробнее можно почтитать здесь), и его портативная версия работает так же хорошо, как и обычная. Так что теперь, независимо от компьютера и наличия интернета, вы легко сможете продемонстрировать работу вашего сайта, загруженного на сервер.
4. GIMP Portable
GIMP — бесплатная альтернатива фотошопу, как нетрудно догадаться из заголовка, тоже имеет портативную версию. Если для работы вы используете фотошоп, то вам поначалу будет трудно привыкнуть к интерфейсу гимпа, однако если вам требуется портативная замена фотошопу, это самая лучшая альтернатива.
5. AMP Font Viewer
Простой, но функциональный менеджер шрифтов, позволяющий узнать какие шрфиты установлены в системе. Кроме того, он также позволяет легко устанавливать и удалять необходимые шрифты.
6. 7-Zip Portable
7zip — это популярный, open source архиватор, понимающий различные типы архивов, включая ZIP, RAR, TAR, GZ и другие. Поскольку веб-разработчикам часто приходится иметь дело с различными типами архива, никогда не помешает иметь под рукой портативную версию этого архиватора.
7. PhotoFiltre
PhotoFiltre — это простой инструмент редактирования изображений, позволяющий редактировать изображения любого формата. Это портативное приложение, большей частью предназначено для быстрого редактирования, является неплохим дополнением к гимпу. Используйте его для простых изменений, вроде обрезки изображений или изменения размеров.
8. Inkscape Portable
Inkscape — это open source векторный редактор, который напоминает внешним видом и работой Corel Draw (если вы когда-нибудь использовали Corel Draw, то поймете о чем я говорю). Этот редактор поддерживает общепринятые стандарты, а его портативная версия является наиболее функциональным приложением из подобных программ.
9. Abiword
Многие люди, включая ваших клиентов, используют Microsoft Word и стандарт .doc, для создания текстовых документов — это общепринятый стандарт. Однако, не так-то просто найти хороший портативный редактор .doc-файлов. Abiword — это легковесная и простая альтернатива портативному OpenOffice.
10. PicPick Tools
Это пакет инструментов для веб-разработчиков, дизайнеров и программистов. Сюда включено большое количество инструментов, от захвата экрана до редактирования изображений.
11. MobaPhoto
MobaPhoto — это open source мендеждер картинок, не требующий установки (иначе самым лучшим выбором конечно была бы Picasa). Не очень презентабельно выглядит, но работает хорошо. Очень удобно использовать, если нужно разобрать большое количество картинок.
12. ToDoList
Если вам необходимо, или просто нравится, планировать свое рабочее время, то это приложение обязательно должно входить в набор ваших программ. ToDoList — это простое приложение для управления задачами и проектами, которые поможет вам качественно и быстро выполнить свою работу.
Конечно, перечисленные портативные приложения далеко не единственные в своем роде, но однозначно весьма полезные. Они используются веб-разработчиками и значительно облегчают их работу.
Если вам известны другие полезные приложения, которые не вошли в список, пожалуйста, расскажите о них в комментариях.
habr.com
Среда веб-разработки на Android / Habr
Прелюдия
Здравствуйте, уважаемые хабраюзеры.
На написание данной статьи меня сподвиг пост хабровчанина ilichme — Десктоп – давай, до свидания!. Поэтому, сегодня более детально поговорим о том есть ли жизнь на Марсе насколько возможно и удобно писать код на устройстве с Android на борту. Сразу оговорюсь — обсуждать буду только планшеты, так как о прелестях кодирования на смартфоне и так все ясно. Хоть и речь не о написании кода, а об организации рабочего пространства, которое будет максимально удобным для разработки в условиях, где нет любимых IDE и т.д.
В свое время, когда покупал планшет, одним из критериев выбора было наличие удобной клавиатуры, так как я тогда знал, зачем покупаю сей девайс. А так как выбор в данном секторе небольшой, то остановился на ASUS Transformer. Это я к тому, что если у вас есть реальная необходимость писать код «на коленке», в условиях, которые не способствуют этому — значит статья для вас. Хотя она совсем не претендует на подробное пособие и решение ваших проблем (так как запросы у всех разные). А если уже говорить о запросах — эта стать скорее всего повод развить тему более подробно и поделиться опытом. Я уверен, что где-то существует еще не один вариант решения таких задач, под разные уровни работы.
Что будем обсуждать?
Собственно, говорить буду о веб-разработке, так так сам именно этим и занимаюсь. Для того и купил планшет — чтобы в любой момент иметь под рукой возможность писать и править код, да и просто не терять время, когда есть идея что-то реализовать, но нет привычного рабочего пространства.
Так вот, некоторое время назад, я осознал, что много полезного времени теряю в дороге. Конечно, можно просто наслаждаться отдыхом, но иногда в голову приходят неожиданные решения разных рабочих проблем, которые нужно отработать прямо сейчас, ибо потом потеряешь мысль. Или просто хочется писать код — часто так бывает. В общем, время терять нельзя. Но, как назло, Android не самая удобная система для веб-разработки. Разработчики почему-то не очень спешат делать удобные редакторы кода или локальные сервера для отладки. Да вы все сами знаете и понимаете.
Техническое задание
Теперь, наконец-то, перейду к описанию непосредственно среды разработки. Оговорюсь, что именно и для выполнения каких задач я искал:
- Удобный редактор кода, с подсветкой синтаксиса, с возможностью просмотра результата в браузере, функциями undo\redo, с выбором кодировки и т.д.
- Локальный веб-сервер (имеется в виду полноценный — с PHP, MySQL). Конечно, можно отдельно поставить PHP как? и руками прикрутить MySQL, но я хотел все и сразу
- Так же хотелось иметь встроенный ftp для работы с удаленным сервером (пока не критично)
В общем, это минимальный набор, который необходим в условиях отсутствия традиционного рабочего места. Конечно, сюда можно добавить еще много пунктов, но это дело вкуса, и, давайте не будем забывать, что это всего лишь планшет, и всего лишь временное решение проблемы. По мере необходимости и роста запросов, я буду искать новые решения, но пока достаточно и этого.
Что я нашел
Итак, потратив некоторое время, я довольно быстро нашел приложения, которые практически полностью меня удовлетворили.
Редактор кода
Как ни странно, но с выбором редактора кода проблем практически не было. Дело в том, что в PlayMarket’е не так уж и много достойных редакторов (по меркам существующих) — на пальцах одной руки можно пересчитать. Некоторые из них были кратко описаны на Хабре раньше — здесь и вот здесь. Поэтому, после коротких тестов и размышлений, я остановился на WebMaster’s HTML Editor — ссылка на PlayMarket. Также есть тема на 4PDA. Всем моим требованиям данная программа отвечает на все 100%, а как бонус даже автозавершение кода есть. Сильно вдаваться в детали не буду, но вот общие моменты:
- Поддерживаемые форматы: .js .htm .html .css .php .php3 .php4 .php5 .txt and .xml;
- Подсветка синтаксиса;
- Встроенные виртуальные клавиши для тэгов и популярных ключевых фраз;
- Undo/Redo
Есть две версии — Pro и стандартная. Pro продают за 5$, в бесплатной версии нет функции предпросмотра в браузере и из списка выпадающих тегов можно выбрать только один. Так что тут придется раскошелиться. Но это для своего же блага и удобства. Вот несколько скриншотов:
Для тех, кому не понравился данный редактор, как альтернативу, могу посоветовать DroidEdit. Он также существует в двух версиях. Но как по мне, он уступает WebMaster’s HTML Editor. Но, это дело вкуса. Все остальные редакторы мне совсем не понравились, так как имеют проблемы или с кодировкой или с работой с большими файлами. А это важно.
FTP-клиент
Для работы с FTP я выбрал программу AndFTP — ссылка на бесплатную версию и на Pro версию. На странице WebMaster’s HTML Editor в PlayMarket разработчики редактора сами рекомендуют использовать данный клиент, да и раньше я встречал неплохие отзывы о нем, так что сразу сделал свой выбор. Относительно ftp я не сильно вдавался в детали, так как мне для работы это не критично, хотя иногда нужно что-то подправить «на лету». Возможно, со временем, эта необходимость станет весомой, и я задумаюсь над лучшей оптимизацией.
Программа позволяет сохранять конфигурации соединений (сервер, логин, пароль), а также предоставляет возможности скачивания/закачивания файлов, синхронизации каталога в сети с каталогом на мобильном устройстве, удаления и переименования файлов, изменения прав доступа. Для защиты ваших данных, программа позволяет использовать SSH RSA/DSA ключи. В общем, стандартный набор нормального ftp-клиента, вот только синхронизация папок, поддержка SCP и импорт настроек из файла доступны в ПРО-версии, которая стоит чуть больше 5$.
Локальный веб-сервер
А теперь поговорим о самом интересно — о локальной среде разработки и отладки написанного кода. Согласитесь, без локального веб-сервера вся идея разработки на планшете ничего бы не стоила. И так приходиться терпеть неудобства с ftp, так если бы еще пришлось работать с удаленным веб-сервером, было бы совсем неудобно. Как для меня, так это очень важный момент.
После некоторого времени поисков, я нашел-таки парочку неплохих решений, таких как kWS — Android Web Server или PAW Server for Android, но они меня не впечатлили.
Я уже было согласился их использовать, но неожиданно наткнулся на очень интересный продукт — KSWEB — server + PHP + MySQL и я сразу понял, что это то, что я так долго искал.
KSWEB — это пакет веб разработчика для платформы Android. В его состав входят: веб сервер, язык программирования PHP версии 5.4 и СУБД MySQL версии 5.1. KSWEB дает возможность организовать на вашем Android устройстве платформу для запуска и отладки веб приложений (сайтов). Все, что вам нужно, это установить приложение. В корне памяти устройства создастся папка htdocs, куда необходимо сохранять ваши файлы. Все, как в любом нормальном веб-сервере. После установки, откроется окно управления сервером.
Первым делом, я установил phpMyAdmin (он не установлен по умолчанию). Необходимо кликнуть на соответствующую кнопку в меню, программа спросит, куда устанавливать (путь оставить по умолчанию, так как он должен установиться в папку веб-сервера). Все файлы сервер скачает и распакует самостоятельно. После этого зайти в phpMyAdmin можно будет через панель управления сервером или через браузер, прописав localhost:8080/phpmyadmin. phpMyAdmin полностью функциональный, версии 3.5.2
Для того, чтобы запустить ваш файл, необходимо в панели управления нажать кнопку GO TO. Сразу откроется браузер по умолчанию, в адресной строке уже будет прописан путь к серверу (localhost:8080/), вам же остается только дописать имя файла. С панели управления также можно перегрузить сервер при необходимости. Кнопка Minimize сворачивает сервер в трей, а кнопка Exit закрывает приложение.
Панель настроек имеет такой вид:
Здесь вы можете указать порт, через который будет работать сервер, можете выбрать другую папку для сервера, заставить сразу грузиться в трей не открывая при запуске главное меню. По умолчанию, KSWEB содержит настроенные конфигурационные файлы сервера, PHP и MySQL. Однако, если вы хотите что-то в них изменить, в опциях сервера кликните на пункт «INI Files». Файлы с настройками будут пернесены на SD-карту вашего устройства по адресу «/mnt/sdcard/ksweb/ini/», если она доступна. Повторно кликнув на пункт настроек «INI Files», будут задействованы внутренние файлы настроек.
В Маркете нет возможности купить платную версию, это вы можете сделать через панель опций программы. Лицензия стоит чуть больше 2$ — смешная цена за столь удобное и полезное приложение.
Вот, собственно, и весь необходимый минимум. Конечно, все это субъективно, и я рад буду услышать дополнения и новые решения. Я же, параллельно с личностным ростом и новыми проблемами, буду искать новые пути и средства решения. Может, в конце-концов, и соберу идеальную среду разработки на Android) Спасибо за внимание.
habr.com
выбери себе приключение / Авито corporate blog / Habr
Привет. Недавно я делал доклад для студентов о том, какие шишки можно набить, занимаясь современной веб-разработкой. Как связаны друг с другом различные решения, которые мы принимаем в процессе разработки, как выбор технологий влияет на размер команды, как размер команды влияет на подходы к тестированию, как подходы к тестированию связаны со структурой всей компании….
Получилось что-то вроде квеста с распределенным выбором: от того, какой язык программирования выбрать и до того, кого лучше нанимать в команду, которая сделает самый полезный продукт ever. Предлагаю вам почитать этот пост, выбрать свои варианты, дополнить квест и обсудить то, что наболело.
upd — немного дополнил текст до ката.
Предположим, что я и мой друг Валерка решили сделать стартап. Uber for X, или там еще что-нибудь в таком духе. Собрались в баре, обсудили эту идею, клёвая тема. Надо сделать. Три месяца не спали, не ели, не выходили из дома. Разрабатывали. Запустили и поняли, что это никому не нужно.
Печаль. Попробуем еще раз. На этот раз мы изучили рынок, посмотрели, какие потребности у пользователей, какие проблемы. Мы сделали какой-то прототип совсем на коленке, быстро и бесплатно за два вечера. Прототип взлетел. Круто, идем дальше.
Теперь мы можем брать и делать из прототипа большое приложение, развивать его. Но для этого надо более серьезно подойти к выбору технологий, которые мы будем использовать.
Язык
По порядку. На каком языке писать? Можно взять модный функциональный: Haskell, Erlang, Lisp (очень модный среди дедушек старше 70). Либо очередного убийцу JS, который очень клевый, компилируется в JS, имеет все нужные фичи. Но скорее всего, нам некого будет нанимать через год, потому что очередной убийца JS не взлетит, и придется переучиваться заново или переписывать проект.
Попытка номер два. Можно взять что-нибудь проверенное временем. Например, PHP. Это неплохой язык, его модно иногда критиковать, у него есть свои минусы, но на нем легко делать бизнес-логику, он достаточно быстрый, неплохо масштабируется, можно нанять людей когда угодно и где угодно. Но он не очень производительный. Поэтому нам нужно либо много железа, либо писать свой компилятор, как сделали Facebook или ВК.
Еще варианты? Можно взять Perl, но тогда будет некого нанимать ещё вчера. Ещё?
Java. Java — норм. Как язык не очень, на мой субъективный взгляд, но JVM — отличная виртуальная машина, все ок, быстро работает, но железа все равно нужно много. А ещё пока мы на Java писали абстрактный билдер фабрики стратегий вместо того, чтобы делать фичи, пользователи ушли к конкурентам.
Ладно, у нас есть еще Python. В принципе, у него всё ок. Но мы запускаем приложение на Python, оно использует одно ядро из 56, в остальном… все ок. Либо можно взять что-то современное: Go, Rust, еще что-то. Но они слишком низкоуровневые, и мы просто долго делаем фичи… Какой-нибудь язык нам всё равно придется выбрать. Пусть в итоге это будет JS, сойдет.
База данных
База. JS без документной базы — деньги на ветер. У документных баз есть свои плюсы. Они позволяют нам быстро разрабатывать прототипы, не париться насчет схемы, колбасить данные туда-сюда. Плюсов много, минус один: каша из данных. Когда коллекций у нас становится десять, двадцать или сорок вместо трёх, когда мы без отсутствия схем пытаемся склеить из них что-то хорошее и удобоваримое, становится это делать все сложнее. Опять долго делаем фичи.
Ок, давайте возьмем реляционную базу. MySQL, PostgreSQL, или Oracle, если денег хватит. С реляционными базами можно однажды прийти на работу и обнаружить себя в аду из транзакций и хранимок. Это не обязательно произойдёт с нашим проектом. Но если произойдет, то эти хитросплетения логики будет невозможно тестировать. А ещё если вдруг мы достигнем вертикального предела нашего большого золотого сервера, на котором мы хостим базу, потом будет довольно сложно их разделять. Долго делаем фичи.
Ладно. Базу взяли какую-нибудь, бахнули перед ней ORM, чтобы проще было с одного SQL на другой переезжать. Когда-нибудь (spoiler: никогда).
Архитектура
Какую взять архитектуру? Ребята на Хабре пишут, что микросервисы – это клёво. Олег Бунин говорит: «берите микросервисы».
Если начать с микросервисов, то с восьмидесятипроцентной вероятностью границы у них будут неправильные, потому что не до конца продумали доменную модель и плохо поняли, где надо резать, а где не надо. Плюс все берут микросервисы, деплоят их пачками по всему своему кластеру, и через месяц возникает вопрос: «а как это всё теперь тестировать?». Сервисы уже работают в продакшене, а мы их не тестируем. Используя привычные методологии (пирамида тестирования, ручные интеграционные тесты, end-to-end тесты), тестировать микросервисы сложно. Поэтому мы долго делаем фичи.
Ок, тогда давайте бахнем монолит. Это самая правильная идея для стартапа. Очень долго можно жить с отличным монолитом и не иметь проблем. Но если мы решим сильно расширить команду, то надо быть осторожнее. Монолит нормально масштабируется, пока разработчиков 20, 30, 50. Дальше скорость доставки фич падает экспоненциально, а мы теряем пользователей.
Где запускать проект?
Это всё надо где-то запускать. 2018 год, самый логичный вариант сделать это в облаке. Запустишь не в облаке — пацаны засмеют. Но, во-первых, есть федеральный закон 152, значительно ограничивающий выбор облачных провайдеров, у которых можно хоститься. Во-вторых, очень легко приватный ключ от своего аккаунта на Amazon случайно закоммитить в Github, и кто-то обязательно придёт и потратит все ваши деньги. А если этого не произойдёт, то в какой-то момент вас разорят облачные тарифы.
Можно арендовать дата-центр. Может, это не так ресурсоэффективно изначально, но в долгосрочной перспективе, вероятно, обойдётся дешевле, чем хоститься в облаке. Но тут нужны люди, которые это будут поддерживать. По моему опыту, те, кто это любят и умеют делать, не очень любят общаться со всеми остальными, поэтому они организуются в отдел. А отдел – это сепаратизм. Я имею в виду то, что внутри команды админов будет легче обмениваться опытом, но в будущем это может работать не очень хорошо. Будут вопросы с приоритезацией задач от других коллег, с синхронизацией. Другие специалисты не будут знать, что происходит внутри отдела, который поддерживает наш дата-центр.
В общем, сепаратизм нам не подходит. Логично переходим к вопросу набора команды.
Разработка
Допустим, мы разобрались с языками, базами и тем, где хостить проект. Настало время набирать команду. Можно взять несколько очень крутых ребят, которые все проблемы решат: стократные разработчики, бэкенд-ниндзи, вы понимаете. Возможно, это прокатит. Но на деле вероятно, что приглашённые звёзды будут:
- токсичными пижонами, которые ничего не будут делать и создадут плохую атмосферу в коллективе,
- либо идеалистами, выстраивающими по крупицам безукоризненную архитектуру, ставящими ORM перед базами, которые никогда менять не придется…
В итоге… да-да, долго делаем фичи. Еще вариант — взять обычных девчонок и ребят, которые просто будут писать код, делать фичи нормально. Но если взять много не очень опытных разработчиков с разным бэкграундом, они могут писать код в разном стиле, делать штуки по-разному, и при достаточном размере команды всем будет тесно, все будут у друг друга фигурные скобочки переставлять в пуллреквестах. Это не очень эффективно. Как это можно решить? Начальник может читать весь код. Я могу читать все пуллреквесты, а мой друг и ко-фаундер Валерка потом второй раз будет перечитывать (на всякий случай, мало ли). Понятно, это не масштабируется и все медленно делают фичи.
Более правильный вариант — определить кодстайл для компании. Для многих языков он уже есть, и можно его просто соблюдать. Либо если кому-то очень хочется, можно взять готовый и подтюнить немного, и потом смотреть на пуллреквестах и говорить, что здесь фигурная скобочка не там стоит, по кодстайлу должна стоять там. С таким аргументом уже не поспоришь, но на деле это не сильно лучше предыдущего варианта, все равно мы медленно делаем фичи. Правильный вариант для всех современных языков — проверять это автоматически.
Ок. Набрали разработчиков, фигачим код. Но мы начали релизить фичи в продакшн, и нам надо как-то убеждаться, что мы без багов их катим, что у нас ничего не падает.
Quality Assurance
Можно сказать, что QA-специалисты нам не нужны. Многие так делают, это иногда работает. Но не все разработчики любят писать тесты. Их можно понять. И стоит их лучше мотивировать, чтобы тесты все-таки писали, но реальность жестока: unit-тесты ловят далеко не все баги. А если какой-то разработчик не любит писать тесты и все-таки начал их писать, то скорее всего это будут unit-тесты.
Плюс еще есть подходы, когда ты минимизируешь mean time between failures вместо mean time to recover. Mean time between failures — это когда QA специалист говорит: «не будем релизить, у меня чутье плохое, баги будут, давайте через две недели выкатим». А mean time to recover — это когда вы катите что-нибудь, сразу видите на метриках, что что-то сломалось, и через две минуты все откатили, пофиксили и все ок. Но чтобы можно было проект через две минуты откатить, надо всё покрыть нормальными метриками, а это не всегда тривиально. А если метрики в плачевном состоянии, и мы выкатим плохой релиз, мы можем узнать об этом после того, как все пользователи уйдут от нас к конкурентам.
Другой вариант: всё-таки сделать отдел QA. Вы помните: отдел — это не очень хорошо, это сепаратизм, это нам не подходит. Сепаратизм можно разрулить с помощью кроссфункциональных команд. Да, они решают проблему того, что у нас админ сидит отдельно, тестировщики отдельно.
Но создают другие проблемы. Так как разработчики, тестировщики и все прочие члены кроссфункциональных команд начинают больше общаться внутри своих команд и решать предыдущие проблемы, они меньше общаются с их коллегами по функции: другими бэкендерами и тестировщиками, они начинают переизобретать велосипеды, делать параллельно одни и те же вещи, наступает изоляция между командами. Шило на мыло: был один сепаратизм, стал другой.
Как это разрулить? Общаться с коллегами в кружках по интересам. Где-то это называют гильдиями, где-то — коммьюнити. Если мы масштабируем команду кроссфункциональными командами, чтобы они не замыкались в себе, мы просто организуем кружок любителей бэкенда, функциональных языков, секьюрити…
На самом деле, не всё так плохо. Из любой ситуации можно найти выход, найти решение. Может быть, не идеальное, но наиболее подходящее в данной ситуации с минимумом проблем. Всегда возможен компромисс.
А ещё — всё это интересно. Интересно решать проблемы, которые уже кто-то решал, новые проблемы еще интереснее решать. Интересно делиться знаниями.
habr.com
Языки программирования для веб-разработки сайтов и приложений
От автора: если ранее вы думали, что за трендами следят только в мире моды, значит, вы не так близко знакомы с разработкой сайтов и приложений. В этой сфере следить за тенденциями развития приходится более тщательно, чем в любой другой. В этом маленьком исследовании мы рассмотрим, насколько востребованы различные языки программирования для веб-разработки и установим, какой из них является наиболее популярным в 2018 году. Оставайтесь с нами, если не хотите остаться за бортом!
Не только для веба!
Почти все PL (здесь и далее — programming language) которые мы вспомним сегодня, не предназначались для потребностей сайтов и веб-приложений. Что уж говорить, если на момент создания самых популярных из них, Интернет был инструментом в руках самых продвинутых, а эпоха динамических страниц была далеким будущим. Но время диктует свои правила, и те средства, что предназначались для разработки программного обеспечения, сегодня обслуживают потребности пользователей сети.
Некоторые ресурсы для разработчиков создают ранжированные списки, но мы не пойдем по этому пути. Ведь то, что мы назовем самым популярным сегодня, может оказаться невостребованным завтра. Для того, чтобы информация всегда была свежей, мы рассмотрим каждый из них объективно, лишь упоминая о рейтингах.
JavaScript для старта!
Как правило, те кто приходят в веб-разработку и успевают быстро освоить разметку и описания внешнего вида, решают, что пришла очередь освоить сценарии. Для машины клиента, они создаются на JavaScript и производных. Характерна стандартизация ECMAScript, благодаря которой применение становится легче.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнееРазработчики создавали язык для веба, чтобы дизайнеры страниц, не обладающие глубокими познаниями в программировании, могли создавать шедевры в сети. Скрипты можно встраивать прямо в HTML-код при помощи специального тега, прописывать внутри документа или просто создавать ссылку на другой документ.
Сегодня с JavaScript могут работать даже те, кто не имеет навыков программирования. Долгий опыт работы веб-мастеров по всему миру позволил создать библиотеки с готовыми решениями: кликами, переходами, интерактивными меню.
Одним из основных преимуществ JavaScript разработчики называют выполнение сценария в браузере пользователя. Таким образом снижается нагрузка на сервер, и экономятся ресурсы хоста. JavaScript уже много лет занимает лидирующие позиции по используемости. Несмотря на «заточенность» под веб-приложения, его применяют и в других сферах. Например, работа банковской системы, которая реализована на JS, отличается скоростью и стабильной работой.
PHP нельзя не вспомнить
Конечно, сегодня все камни летят именно в этот PL, ведь он стал основой для множества некачественных бэкендов. Но «правильные» программисты забывают о том, что сам по себе PHP не может быть в этом виноват.
Среди преимуществ — простота, что означает популярность среди начинающих создателей веб-решений. И именно из-за того, что на нем пишут новички, он получил славу «языка багов». Однако при владении PHP на высоком уровне, можно решать множество разных задач. И хоть скорость у PHP ниже, чем у С-подобных, само создание требует меньше времени и ресурсов.
PHP интенсивно используется в создании веб-приложений, когда нужно разгрузить пользовательский девайс, ведь «гипертекстовый процессор» работает на серверной стороне. Программа, написанная на PHP, отдает пользователю лишь готовый результат. Также, к преимуществам PHP следует отнести непрерывное развитие. Последняя версия PHP 7: 7.2.8 вышла 17 июля 2018 года.
Все, что начинается на С
Один из самых старых PL, если говорить о веб-разработке. Создан еще в 1972 году. Если вы знаете об ассемблере, то код на С покажется вам весьма похожим. Все близко к аппаратному, что делает его не столь применимым в создании веб-решений: большинство специалистов здесь предпочитают более адаптированные варианты.
Большую популярность приобрели потомки: С++, С# и Objective-C. Кстати, JavaScript, о котором мы говорили немного выше, был задуман как упрощенная версия С (Сmm, или С минус минус). Кроме вариантов с похожим названием, С стал прародителем для множества других. Даже самых новых и прогрессивных. С значительно повлиял на Nimrod, который увидел мир в 2004 году.
Objective-C соревнуется с Swift
Эти два стали популярными благодаря тому, что их взяли на вооружение разработчики для платформ Apple. Если говорить о первом, то он является прямым потомком С и Smalltalk.
Objective значительно старше своего соперника, но по-прежнему удерживает позиции. Во многом благодаря тому, что разработчики не хотят переходить на облегченную версию. Прибавляет популярности и то, что программы, написанные на С, работают с Objective-C.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
Оценив, насколько серьезным влиянием обладает Objective-C, компания Apple решила создать свой, более легкий и современный аналог. Как говорят сами создатели, начало разработки было заложено еще в 1989 году, когда начались реализации операционной системы NeXT. Но представлен был только в 2014 и почти сразу обрел популярность.
Swift проще в освоении и устойчив к ошибкам. Подобное вы могли видеть в плохо написанных HTML-разметках: почти все неправильно, но все равно работает. Кстати, Swift работает и с рантаймом Objective-C, что делает переход менее болезненным. Кстати, преимущества Swift признала даже компания Google, заявив о том, что будет использовать в создании своих веб-приложений.
Go-go-go!
Go полностью создан компанией Google и является альтернативой С и другим. Был создан для решения ряда проблем, которые преследовали компанию при создании различных продуктов. Среди них:
отсутствие единого стандарта разработки. Все программисты компании работали на разновидностях С, что провоцировало проблемы с совместимостью;
повторные разработки;
трудности с читабельностью кода.
И это далеко не полный список всего, что хотела исправить компания. Go был презентован в 2009 году и почти сразу получил шквал критики. Дело в том, что, упрощая все на своем пути, разработчики убрали множество полезных функций, которые присутствуют в C-подобных. Создавать веб-приложения на нем оказалось не так уж и легко. Несмотря на утверждения компании о том, что данные функции просто не являются необходимыми, они были реализованы в свежих версиях.
В просторечии, «питон»
Python — яркий пример PL общего назначения, который обрел популярность среди веб-разработчиков. Все потому, что люди это, как правило, творческие. Веб-мастер ищет средство, которое поможет ему создать качественный продукт с наименьшими затратами.
Не был столь известным, пока им не заинтересовалась компания Google, которая и профинансировала дальнейшее развитие и популярность. Сегодня множество веб-сайтов созданы на основе Python, например, Instagram — одна из самых популярных социальных сетей. В то же время, приложения для Android и iOS на нем пишут редко. В целом, это возможно при подключении специальных библиотек, но готовый продукт получается увесистым и медленным. Вместе со стремительным развитием производительности мобильных устройств, ожидается, что Python получит еще большую популярность.
Существует реализация, которая адаптирована специально под разработку веб-приложений. Так как сам по себе CPython (основная реализация) довольно медленный в выполнении, было придумано несколько более легких вариантов:
Brython — написан на JavaScript. Создан для того, чтобы писать сценарии для браузера на Python. Встраивать так же легко, как и JavaScript: «type=»text/python»»;
QPython — вариант для Android. Пока еще на тестируется, но основными библиотеками уже наделен. Это вариант для тех, кто хочет создавать Android-приложения, избегая той медлительности, которая характерна для оригинальной реализации.
Java: 30 лет в топе популярных
Несмотря на то, что был создан в 1990 году, до сих пор является одним из самых используемых в веб-разработке. Несмотря на сходство в названии, имеет мало общего с JavaScript («скриптовому» дали такое название, чтобы сделать узнаваемым). Полностью объектно-ориентирован.
Взирая на сложность и большие возможности, программисты Java востребованы на рынке. Также, преимуществом является кроссплатформенность. Написав на нем программу, вы можете быть уверены в запуске на всех основных операционных системах. Интерес к Java подогревается тем, что является основным в плане разработок приложений для Android.
Так быстро подошел к концу наш обзор! Без внимания осталось еще множество достойных, но для рассказа обо всех нужна книга. Если вы размышляете о том, какой из них выбрать для карьеры веб-разработчика, помните, что любой принесет вам успех, если овладеть программированием в совершенстве.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
Хотите узнать, что необходимо для создания сайта?
Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!
Смотреть видеоwebformyself.com
Семь принципов создания современных веб-приложений / Habr
Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.
JavaScript бесспорно стал незаменимым инструментом для разработчиков фронтенда. Сейчас сфера его применения расширяется на другие области, такие как серверы и микроконтроллеры. Этот язык программирования выбрали престижные университеты, чтобы обучать студентов основам информатики.
В то же время существует ряд вопросов относительно его роли и конкретного использования, на которые многие затрудняются ответить, в том числе авторы фреймворков и библиотек.
- Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
- Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
- Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
- Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
- Нужно ли использовать техники вроде PJAX или TurboLinks?
- Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?
Далее последуют мои попытки ответить на эти вопросы. Я попытался исследовать, как использовать JavaScript с точки зрения пользователя (UX). В частности, уделил особое внимание идее минимизации времени, которое требуется пользователю для получения интересующих его данных. Начиная с основ сетевых технологий и заканчивая предсказанием будущего поведения юзера.
1. Рендеринг страниц на сервере
tl;DR: Рендеринг на сервере осуществляется не ради SEO, а для производительности. Принимайте в расчёт дополнительные запросы для получения скриптов, стилей и последующие запросы к API. В будущем, принимайте в расчёт использование метода HTTP 2.0 Push.
Прежде всего, я вынужден обратить внимание на общепринятую ошибку разделять «приложения с рендерингом на сервере» и «одностраничные приложения». Если мы хотим добиться наилучшего восприятия с точки зрения пользователя, то не должны ограничивать себя такими рамками и отказываться от одной альтернативы в пользу другой.
Причины вполне очевидны. Страницы передаются по интернету, у которого есть физические ограничения, что незабвенно проиллюстрировал Стюарт Чешир в знаменитом эссе «Это latency, дурачок»:
Расстояние между Стэнфордом и Бостоном 4320 км.
Скорость света в вакууме 300 x 10^6 м/с.
Скорость света в оптоволокне составляет примерно 66% скорости света в вакууме.
Скорость света в оптоволокне 300 x 10^6 м/c * 0,66 = 200 x 10^6 м/c.
Односторонняя задержка при передаче в Бостон 4320 км / 200 x 10^6 м/c = 21,6 мc.
Задержка при передаче туда и обратно 43,2 мc.
Пинг из Стэнфорда в Бостон в интернете современного образца около 85 мс (…)
Итак, современное оборудование интернета передаёт сигнал со скоростью 0,5 от скорости света.
Указанный результат 85 мс можно улучшить (и уже сейчас он чуть лучше), но важно понять, что существует физическое ограничение на задержку при передаче информации через интернет, как бы не увеличивалась полоса пропускания на компьютерах пользователей.
Это особенно важно в связи с ростом популярности JavaScript-приложений, которые обычно содержат только разметку <script> и <link> рядом с пустым полем <body>. Так называемые одностраничные приложения (Single Page Applications, SPA) — сервер возвращает одну страницу, а всё остальное вызывается кодом на клиентской стороне.
Представьте сценарий, когда пользователь напрямую заходит по адресу аpp.com/orders. К моменту, когда ваше приложение получает и обрабатывает этот запрос, у него уже есть важная информация о том, что нужно показывать на странице. Оно может, например, подгрузить заказ из базы данных и добавить его в ответ. А вот большинство SPA в такой ситуации возвращает пустую страницу и тег <script>. Потом придётся ещё раз обменяться запросами для получения содержимого скрипта, и ещё раз — для получения контента.
Анализ HTML, отправляемого сервером для каждой страницы SPA
Многие разработчики сознательно идут на такую жертву. Они стараются гарантировать, что дополнительные сетевые хопы для пользователя произойдут только один раз, отправляя правильные заголовки для кеширования в ответах со скриптами и CSS. Общепринятое мнение состоит в том, что это приемлемая сделка, потому что после загрузки всех файлов на компьютер большинство действий пользователя (как переходы в другие разделы) осуществляются без запросов дополнительных страниц или скриптов.
Однако, даже с учётом кеша, имеется определённый проигрыш в производительности, если учесть время на парсинг и выполнение скрипта. В статье «jQuery слишком большой для мобильника?» говорится, как один только jQuery может тормозить некоторые мобильные браузеры на сотни миллисекунд.
Что ещё хуже, обычно пользователь не получает никакого фидбека в то время, как загружаются скрипты. Результат — чистая страница на экране, которая потом внезапно превращается в полностью загруженную страницу.
Самое главное, мы обычно забываем, что наиболее распространённые транспорт для передачи интернет-данных (TCP) стартует медленно. Это почти наверняка гарантирует, что большинство комплектов со скриптами не будут переданы за один раз, делая вышеописанную ситуацию ещё хуже.
TCP-соединение начинается с обмена пакетами для рукопожатия. Если вы используете SSL, что важно для безопасной передачи скриптов, происходит два дополнительных обмена пакетами (один, если клиент восстанавливает сессию). Только после этого сервер может начать отправку данных, но практика показывает, что он делает это медленно и порционно.
Механизм контроля заторов под названием Slow Start встроен в протокол TCP, чтобы отправлять данные, постепенно наращивая количество сегментов. Это имеет два серьёзных вывода для SPA:
1. Большие скрипты загружаются гораздо дольше, чем кажется. Как объясняется в книге «High Performance Browser Networking» Ильи Григорика, требуется «четыре обмена пакетами (…) и сотни миллисекунд задержки, чтобы выйти на 64 КБ обмена данными между клиентом и сервером». Например, в случае быстрого интернет-соединения между Лондоном и Нью-Йорком, требуется 225 мс, прежде чем TCP сможет выйти на максимальный размер пакета.
2. Поскольку это правило действует также для первоначальной загрузки страницы, то очень важно, какой контент грузится для рендеринга на странице в первую очередь. Как заключает Пол Ириш в своей презентации «Доставка товаров», критически важны первые 14 КБ. Это понятно, если посмотреть на график с указанием объёмов передачи между клиентом и сервером на первых этапах установки соединения.
Сколько КБ сервер может отправить на каждом этапе соединения, по сегментам
Веб-сайты, которым удаётся доставить контент (пусть даже базовую разметку без данных) в этом окне, кажутся исключительно отзывчивыми. На самом деле, многие авторы быстрых серверных приложений воспринимают JavaScript как нечто ненужное или что нужно использовать с большой осторожностью. Такое отношение ещё больше усиливается, если у приложения быстрые бэкенд и база данных, а его серверы находятся возле пользователей (CDN).
Роль сервера в ускорении представления контента напрямую зависит от веб-приложения. Решение не всегда сводится к «рендерингу целых страниц на сервере».
В некоторых случаях, неактуальную в данный момент для пользователя часть страницы лучше исключить из первоначального ответа и оставить на потом. Некоторые приложения, например, предпочитают осуществить рендеринг только «ядра» страницы для обеспечения немедленного отклика. Затем они запрашивают разные части страницы параллельно. Это обеспечивает лучшую отзывчивость даже в ситуации с медленным устаревшим бэкендом. Для некоторых страниц хорошим вариантом будет рендеринг только видимой части страницы.
Исключительно важна качественная оценка скриптов и стилей с учётом информации, которая у сервера есть о сессии, клиенте и URL. Скрипты, которые осуществляют сортировку заказов, очевидно будут важнее для /orders, чем логика страницы настроек. Может быть, не настолько очевидная, но есть разница в загрузке «структурного CSS» и «CSS для оформления». Первый может понадобиться для кода JavaScript, так что требуется блокировка, а второй загружается асинхронно.
Хороший пример SPA, которое не приводит к излишнему обмену пакетами, — концептуальный клон StackOverflow в 4096 байтах, он теоретически может загружаться с первым же пакетом после рукопожатия на TCP-соединении! Автор умудрился добиться такого за счёт отказа от кеширования, используя inline для всех ресурсов в ответе с сервера. Применив SPDY или HTTP/2 server push, теоретически возможно передать весь кешируемый клиентский код за один хоп. Ну а в настоящее время, рендеринг частей или всей страницы на стороне сервера остаётся самым популярным способом избавиться от лишних раундов обмена пакетами.
Proof-of-concept SPA с использованием inline для CSS и JS, чтобы избавиться от лишних roundtrip’ов
Достаточно гибкая система, которая разделяет рендеринг между браузером и сервером и предоставляет инструменты для постепенной загрузки скриптов и стилей, вполне может стереть грань между веб-сайтами и веб-приложениями. И то, и другое использует URL’ы, навигацию, демонстрирует данные пользователю. Даже приложение с электронными таблицами, которое традиционно полагается на функциональность с клиентской стороны, сначала должно показать клиенту информацию, которую требуется редактировать. И сделать это за наименьшее количество roundtrip’ов первостепенно важно.
С моей точки зрения, самый большой недостаток производительности во многих популярных системах в наше время объясняется прогрессивным накоплением сложности в стеке. Со временем добавлялись технологии вроде JavaScript и CSS. Их популярность тоже постепенно росла. Только сейчас мы можем оценить, как их можно использовать по-другому. Речь идёт и об улучшении протоколов (это показывает нынешний прогресс SPDY и QUIC), но наибольшую выгоду несёт всё-таки оптимизация приложений.
Полезно будет вспомнить некоторые исторические дискуссии вокруг дизайна ранних версий HTML и WWW. Например, этот список рассылки от 1997 года предлагает добавить тег <img> в HTML. Марк Андрессен повторяет, насколько важно быстро доставлять информацию:
«Если документ нужно составлять в единое целое на лету, то это может быть сколь угодно сложным, и даже если сложность ограничить, у нас всё равно возникнут крупные проблемы с производительностью из-за структуризации документов подобным способом. Прежде всего, это сразу нарушает принцип одного хопа в WWW (ну, IMG тоже его нарушает, но по очень специфической причине и в очень ограниченном смысле) — уверены ли мы, что хотим этого?»
2. Немедленный ответ на действия пользователя
tl;DR: JavaScript позволяет вообще спрятать сетевую задержку. Используя это как принцип дизайна, мы можем даже убрать из приложения почти все индикаторы загрузки и сообщения “loading”. PJAX или TurboLinks упускают возможности по увеличению субъективной скорости интерфейса.
Наша задача состоит в максимальном ускорении реакции на действия пользователя. Сколько бы усилий мы не вкладывали в уменьшение числа хопов при работе с веб-приложением, но есть вещи вне нашего контроля. Это теоретический предел скорости света и минимальный пинг между клиентом и сервером.
Важный фактор — непредсказуемое качество связи между клиентом и сервером. Если качество связи плохое, то будет происходить повторная передача пакетов. Там, где контент должен загружаться за пару roundtrip’ов, может понадобиться гораздо больше.
В этом главное преимущество JavaScript для улучшения UX. Если на клиентской стороне интерфейс управляется с помощью скриптов, мы можем спрятать сетевую задержку. Мы можем создать впечатление высокой скорости. Мы можем искусственно достигнуть нулевой задержки.
Предположим снова, что перед нами обычный HTML. Документы соединяются гиперссылками или тегами <a>. Если нажать на любой из них, то браузер осуществит сетевой запрос, что занимает непредсказуемо долгое время, потом получает и обрабатывает полученные данные и наконец переходит в новое состояние.
JavaScript позволяет реагировать немедленно и оптимистично на действия пользователя. Нажатие на ссылку или кнопку приводит к немедленной реакции, без обращения в Сеть. Известный пример — это интерфейс Gmail (или Google Inbox), в котором архивация почтового сообщения происходит немедленно, тогда как соответствующий запрос к серверу отправляется и обрабатывается асинхронно.
В случае с формой, вместо ожидания какого-то кода HTML в качестве ответа на её заполнение, мы можем реагировать сразу, как только пользователь нажал “Enter”. Или даже лучше, как делает поиск Google, мы можем реагировать ещё раньше, готовя разметку для новой страницы заблаговременно.
Такое поведение — пример того, что я называю адаптацией разметки. Основная идея состоит в том, что страница «знает» свою будущую разметку, так что может переключиться на неё тогда, когда ещё нет данных для указания на это. Это «оптимистичное» поведение, потому что всё ещё остаётся риск, что данные никогда не поступят, и придётся выводить сообщение об ошибке, но это, очевидно, случается редко.
Заглавная страница Google вполне подходит в качестве примера, потому что она очень чётко демонстрирует первые два принципа из нашей статьи.
Во-первых, пакетный дамп TCP-соединения с www.google.com показывает, что они специально стараются отправить всю страницу целиком сразу после получения запроса. Весь обмен пакетами, включая закрытие соединения, занимает 64 мс для меня в Сан-Франциско. Вероятно, это было актуально для них с самого начала.
В конце 2004 года, компания Google стала пионером в использовании JavaScript для выдачи подсказок в реальном времени в процессе набора поискового запроса (интересно, что эту функцию сотрудник разработал в свободные от основной работы 20% времени, так же как и Gmail). Это даже стало фундаментом для появления Ajax:
Посмотрите на Google Suggest. Наблюдайте, как обновляются поисковые термины по мере набора текста, практически мгновенно… без задержки на перезагрузку страницы. Google Suggest и Google Maps — это два примера нового подхода к созданию веб-приложений, которые мы в Adaptive Path назвали “Ajax”
И в 2010 они представили Instant Search, в котором JS играет центральную роль, вообще исключая обновление страницы вручную и переключаясь на разметку «поисковые результаты» при первом же нажатии клавиши, как видно на иллюстрации вверху.
Другой видный пример адаптации разметки, возможно, лежит у вас в кармане. С первых же дней iPhone OS требовала от авторов приложений предоставить картинку default.png, которое можно сразу вывести на экран во время загрузки самого приложения.
iPhone OS принудительно загружает default.png перед запуском приложения
В этом случае операционная система компенсирует не сетевую задержку, а CPU. Это было важно, учитывая производительность раннего оборудования. Правда, в некоторых случаях такой подход давал сбой. Например, если картинка не соответствовала экрану ввода пароля. Подробный анализ результатов публиковал Марко Армент в 2010 году.
Другим типом действий, кроме кликов и отправки форм, которые отлично улучшаются с помощью JavaScript, является рендеринг загрузки файла.
Мы можем зарегистрировать попытку пользователя загрузить файл разными способами: drag-n-drop, вставка из буфера, выбор файла. Затем, благодаря новым HTML5 APIs, мы можем отобразить контент, как будто он уже загружен. Пример такого рода интерфейса — наша работа с загрузками в Cloudup. Обратите внимание, как миниатюра изображения генерируется и рендерится мгновенно:
Изображение рендерится и отображается до окончания загрузки
Во всех этих случаях мы улучшаем восприятие скорости. К счастью, существует много доказательств полезности такого подхода. Взять хотя бы пример, как увеличение расстояния до багажного конвейера в Хьюстонском аэропорту уменьшило количество жалоб на потерянный багаж, без необходимости ускорять обработку багажа.
Эта идея должна серьёзно повлиять на UI наших приложений. Я считаю, что индикаторы загрузки должны стать редкостью, особенно если мы переходим на приложения с информацией в реальном времени, которые описываются в следующем разделе.
Есть ситуации, когда иллюзия мгновенного действия в реальности оказывает вредный эффект на UX. Это может быть форма платежа или окончания сессии на сайте. Применяя здесь оптимистичный подход, де-факто обманывая пользователя, мы рискуем вызвать у него раздражение.
Но даже в этих случаях, отображение на экране спиннеров или индикаторов загрузки следует прекратить. Их нужно отображать только после того, как пользователь считатиает отклик не мгновенным. В соответствии с часто цитируемым исследованием Nielsen:
Базовый совет по времени отклика остаётся неизменным уже тридцать лет Miller 1968; Card et al. 1991:
* 0,1 секундs является лимитом, чтобы пользователь воспринимал отклик как немедленный, здесь не требуется отображение никакой дополнительной информации, кроме результата операции.
* 1,0 секунды является лимитом на непрерывность потока мысли у пользователя, даже хотя он заметит задержку. Обычно, не требуется никакой дополнительной индикации при задержки более 0,1 секунды, но менее 1,0 секунды, но у пользователя пропадает ощущение прямой работы с данными.
* 10 секунд является лимитом удерживания внимания пользователя на диалоге. При большей задержке пользователи захотят выполнить другую задачу, ожидая отклика от компьютера.
Техники вроде PJAX или TurboLinks, к сожалению, упускают большинство возможностей, описанных в данном разделе. Код на клиентской стороне не «знает» о будущем состоянии страницы до тех пор, пока не состоится обмен данными с сервером.
3. Реакция на изменение данных
tl;DR: Когда на сервере обновляются данные, клиента следует уведомлять без задержки. Это такая форма повышения производительности, когда пользователя освобождают от необходимости совершать дополнительные действия (нажимать F5, обновлять страницу). Новые проблемы: управление (повторным) соединением, восстановление состояния.
Третий принцип относится к реагированию UI на изменение данных в источнике, обычно, в одном или нескольких серверах баз данных.
Уходит в прошлое модель передачи по HTML данных, которые остаются статичными до тех пор, пока пользователь не обновит страницу (традиционные веб-сайты) или не взаимодействует с ней (Ajax).
Ваш UI должен обновляться автоматически.
Это критически важно в мире с нарастающим потоком информации из разных источников, включая часы, телефоны, планшеты и носимые устройства, которые появятся в будущем.
Представьте новостную ленту Facebook сразу после её появления, когда информацию публиковали, в основном, с персональных компьютеров пользователей. Статичный рендеринг нельзя было назвать оптимальным, но он имел смысл для людей, которые обновляли ленту, скажем, раз в день.
Сейчас мы живём в мире, когда ты загружаешь фотографию — и почти немедленно получаешь лайки и комментарии от друзей и знакомых. Необходимость в мгновенном отклике стала естественной необходимостью в конкурентном окружении других приложений.
Было бы неверным, однако, предположить, что преимущества мгновенного обновления UI ограничиваются только многопользовательскими приложениями. Вот почему я люблю говорить о согласованных дата-поинтах, вместо пользователей. Возьмём типичный сценарий синхронизации фотографии между телефоном и ваши собственным ноутбуком:
Однопользовательское приложение тоже может получить пользу от «реактивности»
Полезно представлять всю информацию, которая отправляется пользователю как «реактивную». Синхронизация сессии и состояния авторизации — один из примеров универсального подхода. Если у пользователей вашего приложения одновременно открыто несколько вкладок, то окончание рабочей сессии на одной из них должно сразу деактивировать авторизацию на всех остальных. Это неизбежно ведёт к улучшению безопасности и лучшей защите конфиденциальной информации, особенно в ситуациях, когда несколько человек имеют доступ к одному устройству.
Каждая страница реагирует на состоянии сессии и статус авторизации
Как только вы установили правило, что информация на экране обновляется автоматически, важно поработать над новой задачей: восстановление состояния.
При отправке запросов и получении атомарных обновлений легко забыть, что ваше приложение должно нормально обновляться даже после долгого отсутствия связи. Представьте, что вы закрываете крышку ноутбука и открываете её через несколько дней. Как будет вести себя приложение?
Пример того, что происходит в случае некорректного обновления связи
Способность приложения нормально восстанавливать связь взаимодействует с принципом № 1. Если вы выбрали отправлять данные при первой же загрузке страницы, вы должны учитывать и время, которое прошло перед загрузкой скриптов. Это время, по существу, эквивалентно времени дисконнекта, так что первоначальное подключение ваших скриптов является возобновлением сессии.
4. Контроль обмена данными с сервером
tl;DR: Теперь мы можем тонко настраивать обмен данными с сервером. Убедитесь в обработке ошибок, повторных запросах в пользу клиента, синхронизации данных в фоновом режиме и сохранении кеша в офлайне.
Когда появился веб, обмен данными между клиентом и сервером был ограничен несколькими способами:
- Нажатие на ссылку отправит
GETдля получения новой страницы и её рендеринга. - Отправка формы отправит POST или GET с последующим рендерингом новой страницы.
- Внедрение изображения или объекта отправит GET асинхронно с последующим рендерингом.
Простота такой модели очень привлекательна, и сейчас всё определённо усложнилось, когда речь идёт о понимании, как получать и отправлять информацию.
Главные ограничения касаются второго пункта. Невозможность отправить данные без обязательной загрузки новой страницы было недостатком с точки зрения производительности. Но самое главное, что это полностью ломало кнопку «Назад»:
Вероятно, самый раздражающий артефакт старого веба
Именно поэтому веб как платформа для приложений оставался неполноценным без JavaScript. Ajax представлял собой огромный скачок вперед с точки зрения удобства в части публикации информации пользователем.
Сейчас у нас есть множество API (XMLHttpRequest, WebSocket, EventSource, это лишь некоторые из них), которые дают полный и чёткий контроль над потоком данных. Кроме возможности публиковать пользовательские данные через форму, у нас появились новые возможности по улучшению UX.
Прямое отношение к предыдущему принципу имеет показ состояния соединения. Если мы ожидаем, что данные будут обновляться автоматически, то обязаны информировать пользователя о фактах потери связи и попытках её восстановления.
При обнаружении дисконнекта, полезно сохранить данные в памяти (а ещё лучше, в localStorage), так что их можно отправить позднее. Это особенно важно в свете будущего использования ServiceWorker, который позволяет приложениям JavaScript работать в фоновом режиме. Если ваше приложение не открыто, вы всё ещё можете продолжать попытки синхронизировать данные с сервером в фоновом режиме.
Учитывайте возможность таймаутов и ошибок при отправке данных, такие ситуации должны решаться в пользу клиента. Если соединение восстановлено, пробуйте отправить данные снова. В случае постоянной ошибки, сообщите об этом пользователю.
Некоторые ошибки нужно обрабатывать особенно внимательно. Например, неожиданная 403 может означать, что пользовательская сессия признана недействительной. В таких случаях, есть возможность восстановить сеанс, если показать пользователю окно для ввода логина и пароля.
Важно ещё убедиться, что пользователь случайно не прервёт поток данных. Это может случиться в двух ситуациях. Первый и самый очевидный случай — закрытие браузера или вкладки, что мы пытаемся предотвратить обработчиком beforeunload.
Предупреждение beforeunload
Другой (и менее очевидный) случай — попытка перехода на другую страницу, например, нажатие на ссылку. В этом случае приложение может остановить юзера иными методами, на усмотрение разработчика.
5. Не ломай историю, улучшай её
tl;DR: Если браузер не будет управлять URL’ами и историей, у нас возникнут новые проблемы. Убедитесь, что вы соответствуете ожидаемому поведению в отношении прокрутки. Сохраняйте собственный кеш для быстрого фидбека.
Если не считать отправки форм, то при использовании в веб-приложении одних только гиперссылок у нас будет полностью функциональная навигация «Вперёд/Назад» в браузере.
К примеру, типичную «бесконечную» страницу обычно делают с помощью кнопки на JavaScript, которая запрашивает дополнительные данные/HTML и вставляет их. К сожалению, немногие при этом помнят о необходимости вызова history.pushState или replaceState как обязательного шага.
Вот почему я использую слово «ломать». С простой моделью первоначального веба такая ситуация была невозможна. Каждое изменение состояния основывалось на изменении URL.
Но есть и обратная сторона медали — возможность улучшать историю сёрфинга, которую мы теперь контролируем средствами JavaScript.
Одну такую возможность Дэниел Пипиус назвал Fast Back:
Кнопка «Назад» должна работать быстро; пользователи не ожидают слишком большого изменения данных.
Это как рассматривать кнопку «Назад» в качестве кнопки из веб-приложения и применить к ней принцип № 2: немедленно реагировать на действие пользователя. Главное, что у вас есть возможность решить, как организовать кеширование предыдущей страницы и мгновенно вывести её на экран. Вы можете затем применить принцип № 3, а потом информировать пользователя о поступлении новых данных на эту страницу.
Всё ещё остаётся несколько ситуаций, когда вы не можете контролировать поведение кеша. Например, если вы отрендерили страницу, затем ушли на сторонний сайт, а потом пользователь нажал «Назад». Этому маленькому багу особенно подвержены приложения, которые рендерят HTML на стороне сервера, а потом модифицируют его на стороне клиента:
Некорректная работа кнопки «Назад»
Ещё один способ сломать навигацию — игнорирование памяти о состоянии прокрутки. Ещё раз, страницы, которые не используют JS и ручное управление историей, скорее всего, не будут иметь тут проблем. Но динамические страницы будут. Я протестировал две самые популярные новостные ленты на основе JavaScript в интернете: Twitter и Facebook. У обоих обнаружилась амнезия на прокрутку.
Бесконечное листание страниц — обычно, признак скроллинг-амнезии
В конце концов, опасайтесь таких изменений состояния, которые релевантны только при просмотре истории. Например, этот случай с изменением состояния поддеревьев с комментариями.
Изменение вида комментариев нужно сохранять в истории
Если страница была заново отрисована после нажатия ссылки внутри приложения, пользователь может ожидать, что все комментарии будут развёрнуты. При изменении состояния его нужно сохранить в истории.
6. Обновление кода через push-сообщения
tl;DR: Недостаточно отправлять через push-сообщения только данные, нужно ещё и код. Избегайте ошибок API и повышайте производительность. Используйте stateless DOM для безболезненной перелицовки приложения.
Исключительно важно, чтобы ваше приложение реагировало на изменения в коде.
Во-первых, это уменьшает количество возможных ошибок и повышает надёжность. Если вы сделали важное изменение в API бэкенда, то должны обновить код клиентских программ. В противном случае, клиенты могут не воспринять новые данные или могут прислать данные в несовместимом формате.
Не менее важной причиной является соблюдение принципа № 3. Если ваш интерфейс обновляется сам, то у пользователей мало причин обращаться к ручной перезагрузке страницы.
Имейте в виду, что у обычного сайта обновление страницы инициирует две вещи: перезагрузка данных и перезагрузка кода. Организация системы с push-обновлениями данных без push-обновлений кода неполноценна, особенно в мире, где одна вкладка (сессия) может оставаться открытой очень долгое время.
Если серверный push-канал работает, то пользователю можно выслать уведомление о доступности нового кода. Если нет, то номер версии можно добавить в заголовок исходящих HTTP-запросов. Сервер может сравнить его с последней известной версией, согласиться на обработку запроса или нет, и выдать задание для клиента.
После этого некоторые веб-приложения принудительно перезагружают страницу от имени пользователя. Например, если страница не находится в видимой области экрана и на ней нет заполненных форм для ввода.
Ещё лучший подход — «горячая» замена кода. Это значит, что не придётся осуществлять полную перезагрузку страницы. Вместо этого, определённые модули заменяются на лету, а их код повторно отправляется на выполнение.
Во многих существующих приложениях довольно сложно осуществить «горячую» замену кода. Для этого нужно изначально придерживаться архитектуры, которая разделяет поведение (код) от данных (состояние). Такое разделение позволит нам довольно быстро накатывать много разных патчей.
Например, в нашем веб-приложении есть модуль, который устанавливает шину для передачи event’ов (как socket.io). Когда событие наступает, состояние определённого компонента меняется и это отражается в DOM. Затем вы изменяете поведение этого компонента, например, так, что он генерирует разные разметки DOM для существующего и нового состояний.
В идеале у нас должна быть возможность менять код помодульно. Не нужно будет заново устанавливать соединение с сокетом, например, если есть возможность просто обновить код нужного компонента. Идеальная архитектура для push-обновлений кода, таким образом, является модульной.
Но сразу возникает проблема с тем, как оценить модули без нежелательных побочных эффектов. Здесь лучше всего подходит архитектура вроде той, которую предлагает React. Если код компонента обновляется, его логика может быть просто повторно исполнена, и DOM обновляется. Объяснение этой концепции от Дэна Абрамова читай здесь.
По существу, идея заключается в том, что вы обновляете DOM (или перекрашиваете его), что существенно помогает в замене кода. Если состояние сохранено в DOM или обработчики event’ов установлены приложением, то обновление кода может стать намного более сложной задачей.
7. Предсказание поведения
tl;DR: Отрицательная задержка.
У современного JavaScript-приложения могут быть механизмы для предсказания действий пользователя.
Наиболее очевидным применением этой идеи является заблаговременное скачивание данных с сервера, прежде чем пользователь их запросил. Скачивать веб-страницу, когда над ней появился курсор мыши, так что по нажатию на ссылки она отображается мгновенно, — это простой пример.
Немного более продвинутый метод мониторинга отслеживания движения мыши анализирует её траекторию на предмет будущего «столкновения» с интерактивными элементами, как кнопки. Пример на jQuery:
Плагин jQuery предугадывает траекторию мыши
Заключение
Веб остаётся самой многогранной средой передачи информации. Мы продолжаем добавлять динамику на наши страницы и перед их внедрением должны убедиться, что сохраним важные принципы веба, доставшиеся нам в наследство.
Страницы, связанные между собой гиперссылками, — хорошие строительные блоки для любого приложения. Поступательная загрузка кода, стилей и разметки по мере действий пользователя гарантирует отличную производительность без отказа от интерактивности.
Новые уникальные возможности предоставляет JavaScript. Если эти технологии будут повсеместно использоваться, то обеспечат наилучший опыт работы для пользователей самой свободной платформы из существующих — WWW.
habr.com