Многие студенты, впервые сталкиваясь с описанием какой-нибудь хитроумной штуки, вроде алгоритма Кнута – Морриса – Пратта или красно-чёрных деревьев, тут же задаются вопросами: «К чему такие сложности? И это, кроме авторов учебников, кому-нибудь нужно?». Лучший способ доказать пользу алгоритмов – это примеры из жизни. Причём, в идеале – конкретные примеры применения широко известных алгоритмов в современных, повсеместно используемых, программных продуктах.
Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.
WebRTC – это API, предоставляемое браузером и позволяющее организовать P2P соединение и передачу данных напрямую между браузерами. В Интернете довольно много руководств по написанию собственного видео-чата при помощи WebRTC. Например, вот статья на Хабре. Однако, все они ограничиваются соединением двух клиентов. В этой статье я постараюсь рассказать о том, как при помощи WebRTC организовать подключение и обмен сообщениями между тремя и более пользователями.
Этим постом я бы хотел исправиться и предложить адекватный способ работы с хранилищем, как с объектом. Код из поста «Работа с локальным хранилищем, как с объектом? Легко!» использовать крайне не рекомендую, там всё плохо (минусы изложены внизу). Цель данного — объяснить всем тем, кто добавил статью по ссылке в избранное или поставил плюсик, никогда не использовать этот код.
Сейчас же я хочу продемонстрировать простейшую идею, предложенную Scalar в комментарии.
При загрузке страницы (даже до события готовности DOM дерева) обращаемся к хранилищу (в данном случае, это localStorage и sessionStorage), получить JSON, десериализовать его и положить в какую-нибудь переменную.
В этой статье мы подробно разберем процесс сборки фронтенд проекта, который прижился в моей повседневной работе и очень облегчил рутину.
Статья не претендует на истину в последней инстанции, так как сегодня существует большое количество различных сборщиков и подходов к сборке, и каждый выбирает по вкусу. Я лишь поделюсь своими мыслями по этой теме и покажу свой workflow.
UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS
Для того, чтобы продемонстрировать работу приложения, нам частенько приходится заставлять его работать с выдуманными данными, ведь негоже, чтобы заголовки были пустыми, а таблицы лишь расчерченными, но не заполненными.
Как правило, при создании приложения, мы не очень-то переживаем о том, c какими именно данными в итоге оно будет работать, мы просто выдумываем какой-то пример, которого достаточно для того, чтобы продолжать работать над логикой, и, собственно, продолжаем работать над логикой.
К счастью, Marak создал опрятное средство, которое позволяет нам генерировать фейковые данные на лету: Faker.
Я работаю в команде Онлайн. Мы делаем веб-версию справочника 2ГИС. Это долгоживущий активно развивающийся проект, в котором JavaScript используется как основной язык как на клиенте, так и на сервере.
Важное место в работе занимают инструменты анализа и отладки приложения. Популярные JavaScript фреймворки как правило обладают собственным инструментарием, заточенным под конкретную идеологию. Наша ситуация осложняется тем, что под капотом Онлайна гудит фреймворк собственного производства — Slot — также находящийся в стадии активной доработки.
В этой статье я расскажу, как мы используем стандартные браузерные инструменты разработчика для эффективной отладки и исследования. Эти рецепты направлены в первую очередь на изучение приложения снаружи-внутрь, поэтому подойдут для любого проекта.
Hockey App, не так давно вошедший в состав официальных сервисов компании Microsoft, уже давно известен среди разработчиков, как инструмент для получения своевременной информации о поведении мобильных и desktop-приложений на этапе их бета-тестирования и в режиме распространения приложения в магазине.
В будущем инструментарий HockeyApp будет интегрирован в новый SDK облачного сервиса Application Insights, который на данный момент ориентирован на сбор данных об операциях, производительности и использовании приложений на различных устройствах.
Это отражает планы компании по расширению функционала Visual Studio и сервиса Application Insights для разработчиков iOS и Android.
На данный момент HockeyApp продолжает свою работу, как самостоятельный сервис. И в этой статье мы рассмотрим пример использования его механизмов для приложения Windows Phone 8.1.
Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.
В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.
Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.
Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.
В конце октября в Москве прошла конференция мобильных разработчиков #MBLTDev, на которой я рассказывал про трилатерацию с помощью iBeacon.
В докладе я намеренно опустил все стандартные примеры кода, которые можно найти в интернете, и сосредоточился на том, какие есть конкурирующие технологии, как работает маяк, с какими трудностями приходится сталкиваться. Одним выступлением тему не покрыть, но надеюсь, в рассказе вы найдете для себя новое и уникальное.
Обработка ошибок в JS – та еще головная боль. Не ошибусь, если скажу, что ошибки – самое слабое место всего языка. При чем проблема состоит из двух других: сложности отлова ошибки в асинхронном коде и плохо спроектированного объекта Error. И если первой проблеме посвящено множество статей, то о второй многие незаслуженно забывают. В этом материале я постараюсь восполнить недостаток и рассмотреть объект Error более пристально.
Я —.NET разработчик. Но в последнее время всё чаще сталкиваюсь с JavaScript. Причём, процентах в 50 случаев я что-то на нём пишу, в остальных 50 — разбираюсь с чужим кодом, да ещё и прошедшим через минификацию, а иногда и обфускацию. В этой статье захотелось поделиться теми моментами, которые мне показались важными для понимания языка и эффективной работы с ним. Тут не будет ничего нового или неизвестного для людей, уже имевших дело с языком, и не будет чего-то такого, чего нельзя найти в других источниках. Для меня статья будет полезна как способ лучше разобраться в предмете, для читателей, я надеюсь, — как повод освежить знания.
Брендан Айк упоминал, что JavaScript был создан за 10 дней. Думаю, идея вынашивалась дольше. Как бы то ни было, язык получился и с тех пор только набирает популярность. Особенно после появления AJAX.
JavaScript — язык со слабой динамической неявной типизацией, автоматическим управлением памятью и прототипным наследованием.
JavaScript состоит из трёх обособленных частей:
ядро (ECMAScript),
объектная модель браузера (Browser Object Model или BOM),
объектная модель документа (Document Object Model или DOM).
В статье, в основном, пойдёт речь о ядре. Конечно, в примерах кода будут использоваться элементы DOM и BOM, но заострять на них внимание не буду.
Мне наступили на больную мозоль, сделав некий обзорный пост по нескольким фантастическим сериалам.
А так как субботним вечером делать особенно нечего, давайте-ка я сделаю свой, более полный.
Да, будут спойлеры, имейте в виду.
Да, и очень много картинок! Трафик!
Начнём со Stargate
Целое семейство сериалов, начавшихся с одноимённого фильма.
Это во-первых, конечно,
На конференции SIGGRAPH ASIA 2013 Thomas Geijtenbeek, Michiel van de Panne и Frank van der Stappen представили метод симуляции физики двуногих существ на основе мускульного контроля с оптимизацией перемещения мышц и других контролируемых параметров. В результате был получен метод управления передвижением для множества двуногих существ. Все приводящие в действие силы являются результатом работы симулированных 3D-мускул и модели нейронных задержек, включенных в цепи ответных реакций. Перечисленные контроллеры генерируют вращающие движения, которые учитывают биомеханические ограничения. Контроллеры находят различные походки на основе требуемой скорости, могут учитывать неровные поверхности и внешние возмущения, способны следовать в задаваемом направлении.
Прежде чем начать рассказ про наш очередной opensource-инструмент, давайте я поясню, для чего мы его сделали. Я довольно много общаюсь с коллегами-тестировщиками и разработчиками из разных компаний. И, по моему опыту, автоматизация тестирования ─ один из самых непрозрачных процессов в цикле разработки ПО. Посмотрим на типичный процесс разработки функциональных автотестов: ручные тестировщики пишут тест-кейсы, которые нужно автоматизировать; автоматизаторы что-то делают, дают кнопку для запуска; тесты падают, автоматизаторы разгребают проблемы.
Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.
Однако существуют и прозрачные процессы. Они построены таким образом, что вся необходимая информация доступна в любой момент. Создание таких процессов может потребовать некоторых усилий на старте, но эти затраты быстро окупаются.
Именно поэтому мы разработали Allure — инструмент, позволяющий внести прозрачность в процесс создания и выполнения функциональных тестов. Красивые и понятные отчёты Allure помогают команде решить перечисленные выше проблемы и начать наконец разговаривать на одном языке. Инструмент имеет модульную структуру, позволяющую легко интегрировать его с уже используемыми инструментами автоматизации тестирования.
Бета включает в себя сотни новшеств, изменений и исправлений с релиза альфы.
Далее мы сделаем обзор наиболее важного, но сначала ответим на часто задаваемые вопросы.
Python — красивый и местами загадочный язык. И даже зная его весьма неплохо, рано или поздно находишь для себя нечто такое, что раньше не использовал. Этот пост отражает некоторые детали языка, на которые многие не обращают внимание. Сразу скажу: многие примеры являются непрактичными, но, оттого, не менее интересными. Так же, многие примеры демонстрируют unpythonic стиль, но я и не претендую на новые стандарты — я просто хочу показать, что можно делать вот так.
Привет! Проблема вот в чём. Если зайти на практически любой сайт интернет-магазина или компании с услугами, вы встретите контент. Точнее — отвратительные тексты, которые писали, кажется, маркетологи, воспитанные сеошниками.
Разумеется, можно не делать, как они. Если работать по-умному, то вы поможете и читателям по жизни, и себе в продажах.
По моим примерным подсчётам (усреднение с ряда позиций), конверсии для нас выглядят так:
Только название и картинка — около 1,5%.
С описанием от производителя — чуть более 2%.
С описанием человека, который держал это в руках и знает правила — около 6%.
Ниже — рассказ про то, как мы доводили время на сайте от 3 минут сначала до 6:40, а потом до 20:48. Да-да, двадцати минут сорока восьми секунд для среднего посетителя. Честного среднего, с учётом отказов и по полной выборке.
Вторая часть статьи из цикла «Продающий дизайн интернет-магазина». Для тех, кто пропустил первую, её можно прочитать тут: «Продающий дизайн интернет-магазина. Часть 1. Аналитика». Сегодня я расскажу про разные части интерфейсов магазинов, которые важны для конверсии и продаж. Постараюсь обозначить какие элементы должны быть в шапке и футере сайта, на главной странице, на странице каталога и многое другое.
