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

Предисловие

Случается, что навязчивая идея так прочно заседает в голове, что ты возвращаешься к ней снова и снова на протяжении многих лет. Пытаешься подойти к проблеме с другой стороны, воспользоваться новыми знаниями, или же просто начать все еще раз с чистого листа — и так до тех пор, пока вопрос не будет исчерпан раз и навсегда. Для меня такой идеей-фикс стали языки программирования. Сам факт того, что одна программа позволяет создавать другие программы, в моих глазах наделял ее непостижимой фрактальной красотой. Написание такой программы самому стало лишь вопросом времени.

Несколько недель назад на конференции Teched North America 2013 был сделан анонс Visual Studio 2013, и было рассказано о некоторых новых возможностях этой среды. Вчера, на конференции Build 2013 было объявлено о доступности предварительной версии Visual Studio 2013, Net Framework 4.5.1 и Team Foundation Server 2013 которые вы можете загрузить уже сейчас.

Так уж получилось, что даже на Хабре многие имеют очень смутное представление о семействе OS Linux.

Цель данной статьи – максимально популярным языком рассказать про особенности и отличия Linux от Windows для тех, кто вообще не имел с ним дела.

Я уже не один год свободно пользуюсь Archlinux, загружая винду лишь «на поиграться». Данная статья рассказывает о вещах, которые я выяснил эмпирическим путем, тыкаясь словно слепой котенок. Если бы в свое время мне попалась бы именно такая информация именно в такой форме — это сэкономило бы мне как минимум 2 года, в течение которых я переходил с Windows на Linux.

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

Visual Studio 2012 & SharePoint

• Разработка приложений с использованием пакета Visual Studio 3D Starter Kit. Часть 1 из 3
• Клонирование планов тестирования с использованием Microsoft Test Manager
• Разработка приложений, учитывающих географическое положение, с использованием функций геолокации и карт Bing Maps
• Анонс Visual Studio 2013
• Обзор Visual Studio 2012 Update2
• Новые возможности в средствах разработчика Microsoft Office Developer Tools для Visual Studio 2012
• Разработка, подключение и публикация с помощью Visual Studio и Git
• Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходима повторно используемая (повторяемая) архитектура
• Руководство по инструментам архитектуры Visual Studio. Сценарий – Мне необходимо начать разработку новой системы
• Руководство по инструментам архитектуры Visual Studio. Сценарий – мне нужно изучить существующую систему
• Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходимо обеспечить трассировку
• Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходимо выполнить валидацию архитектуры системы
• Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходимо настроить графы DGML
• Управляемая тестами разработка с использованием инструмента NUnit в Visual Studio 2012
• Модульные тесты Windows Phone в Visual Studio 2012 Update 2
• Coding4Fun: создание игры типа «Тетрис» с помощью макета сетки CSS и Blend 5Coding4Fun
• Использование списков SharePoint в качестве объектов LightSwitch с помощью CSOM
• Разработка рабочих процессов SharePoint с помощью средств разработчика Office Developer Tools для Visual Studio 2012

Windows Azure & Mobile Services

• 1 часть: Введение в WAMS
• Windows Azure Mobile Services – краткое руководство по использованию. Часть 2
• Windows Azure Mobile Services – краткое руководство по использованию. Часть 3

Haskell — пока еще единственный язык программирования, в котором есть оператор «фтопку» (>>=)

Абсурдопедия

Планировал начать с описания того, как ошибаются люди, полагающие Haskell бесполезным с практической точки зрения, сферическим языком в вакууме и т.д. Но, боюсь, за меня все уже сделали авторы Real World Haskell. Была идея рассказать о том, насколько красив и могуч этот язык программирования — но подвел тяжелый слог и неумение придумать захватывающий сюжет с неожиданной развязкой. Поэтому отброшу все лишнее и расскажу о своих злоключениях веб-разработки на Haskell.

Awesomium — это библиотека, для интеграции браузера на базе Chromium в своё приложение. Вся прелесть Awesomium состоит в том, что его можно интегрировать в приложение практически любого типа (есть примеры интеграции в 3D игры на базе Unity3D), он обладает широким набором возможностей для разработчика и, честно говоря, с ним просто приятно работать.

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

И вот накопив некоторые знания я решил ими поделится. Уверен, что я не первый и не последний, кто будет проходить этот путь.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Навигация на основе представлений (View-Based Navigation)

Несмотря на то, что навигация на основе состояний может быть полезна в сценариях, описанных ранее, тем не менее, навигация в приложении часто требует замены одного представления на другое. В Prism, такой вид навигации называется «навигация на основе представлений (view-based navigation)».

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

• Цель навигации — контейнер для добавляемых, или удаляемых представлений — может обрабатывать навигацию разными способами при добавлении и удалении представлений, или может визуализировать процесс навигации по-разному. Во многих случаях, целью навигации является обычный Frame, или ContentControl, и представления просто отображаются внутри этих элементов управления. Однако существует множество сценариев, когда целью навигации является другой вид элементов управления, таких как TabControl, или ListBox. В таких случаях, навигация может потребовать активации или выделения уже существующего представления, или добавление нового представления.
• Приложению часто будет требоваться, каким-либо образом идентифицировать представление, к которому должна быть выполнена навигация. Для примера, в web-приложениях, страница, к которой выполняется навигация, напрямую идентифицируется по URI. В клиентских приложениях, представление может быть идентифицировано по имени его типа, по расположению файла ресурсов, или множеством других способов. В составных приложениях, состоящих из слабо связанных модулей, представления зачастую определены в раздельных модулях. Отдельные представления, в таких случаях, должны иметь возможность быть идентифицированы без создания дополнительных зависимостей между модулями.
• После идентификации представления, процесс его создания и инициализации должен быть тщательно скоординирован. Это особенно важно при использовании паттерна MVVM. В таком случае, представления и соответствующая модель представления должны быть созданы и ассоциированы друг с другом во время совершения навигации. В случае использования контейнера внедрения зависимостей, такого как Unity, или MEF, при создании модели представления и/или представления может потребоваться использование особого механизма конструирования.
• MVVM паттерн позволяет отделить UI приложения от его логики взаимодействия с пользователем и бизнес-логики. Однако процесс навигации может охватывать как UI, так и логику приложения. Пользователь может начать навигацию внутри представления, в результате чего представление будет обновлено. Но часто будет требоваться возможность инициировать и скоординировать навигацию из модели представления. Важным аспектом для рассмотрения, является способность чётко разделить навигационное поведение между представлением и моделью представления.
• Приложению часто может потребоваться передавать параметры, или контекст, представлению для его корректной инициализации. Для примера, если пользователь производит навигацию к представлению для редактирования информации о выбранном клиенте, ID этого клиента, или его данные, должны быть переданы в представление, для отображения в нем корректной информации.
• Многим приложениям необходимо тщательно координировать навигацию для уверенности, что будут выполнены определённые бизнес-требования. К примеру, пользователю может быть показано всплывающее сообщение о некорректности введённых им данных, во время попытки навигации к другому представлению. Этот процесс требует координации между предыдущим и новым представлениями.
• Наконец, большинство современных приложений позволяют пользователю производить навигацию к предыдущему, или к следующему представлению. Аналогично, некоторые приложения реализуют свой рабочий процесс, используя последовательность представлений, или форм и позволяют пользователю производить по ним навигацию вперёд или назад, добавляя или редактируя данные, перед тем, как завершить задачу и отправить все сделанные изменения одним пакетом. Такие сценарии требуют некоторого механизма журналирования, для того, чтобы последовательность навигации могла быть сохранена, повторена, или предопределена.

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

Концепция

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

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

Основная идея feature branch заключается в создании нового брэнча, когда вы начинаете работать над какой-то функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

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


Начать сие увлекательное путешествие можно под катом.

Всем привет!
На данный момент очень трендово использовать node.js. Однако не всем он нравится. В данном обзоре, я бы хотел рассказать немного о конкуренте, который был написан под влиянием node.js
Vert.x это асинхронный, event-driven фреймворк, цели которого пересекаются с популярным node.js. Высокая производительность, простая асинхронность и конфигурирование — это все по vert.x.
Первая версия фрейворка, была выпущена в 2012 году, в то время как node.js был выпущен в 2009. Однако, уже поддерживается VMware и может запускаться на CloudFoundry.
Основные характеристики продукта под катом:

С ростом популярности node.js он становится всё более привлекательным для разработки приложений. По крайней мере я в последнее время очень часто использую эту технологию для быстрой разработки оных. И на данный момент, технологически нет никаких препятствий для разработки кроссплатформенных приложений на одном языке. И не только классических Web-приложений (клиент-сервер) но и десктопных.

Архитектура USB содержит несколько уровней. На самом низком уровне специально обученное железо, называемое хост-контроллером (host controller), общается с USB-устройством специальными сигналами. Сигналы кодируют биты, биты складываются в пакеты, пакеты образуют транзакции, транзакции составляют передачи (transfers).

Я рассказываю о программной поддержке USB, поэтому уровни ниже передач почти неинтересны: за них отвечает хост-контроллер. Зато важно, какой интерфейс представляет хост-контроллер софту. Сейчас распространены три интерфейса, и постепенно распространяется четвёртый:

Аббр.	Название интерфейса	Версия	Код поддержки контроллера в KolibriOS
UHCI	Universal Host Controller Interface	USB 1.1	kernel/trunk/bus/usb/uhci.inc
OHCI	Open Host Controller Interface	USB 1.1	kernel/trunk/bus/usb/ohci.inc
EHCI	Enhanced Host Controller Interface	USB 2.0	kernel/trunk/bus/usb/ehci.inc
XHCI	eXtensible Host Controller Interface (новый)	USB 3.0	В KolibriOS ещё не поддерживается

На этом же уровне взаимодействия с контроллерами находятся файлы kernel/trunk/bus/usb/hccommon.inc, где реализованы некоторые функции, общие для всех контроллеров, и kernel/trunk/bus/usb/init.inc, который запускает всю подсистему. Впрочем, не торопитесь пока лезть в код — во-первых, я ещё не рассказала про то, чего же ожидают от него более высокие уровни, а во-вторых, после демонстрации общей схемы я вернусь к отдельным компонентам с подробностями.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

Модули или подобные структуры это неотъемлемая часть любого взрослого языка программирования. Просто иначе никак. Модули позволяют ограничить область видимости, позволяют реиспользовать части приложения, делают приложение более структурированным, отделяют ресурсы от шума и вообще делают код нагляднее.

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

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

Несколько дней назад, 15 мая, в ScummVM, известный кроссплатформенный набор игровых движков для point-and-click adventure, была добавлена ветка кода с движком, который поддерживает классику квестового жанра, игру The Neverhood.

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

Чем доступнее информация, тем больше её вокруг. Чем быстрее она распространяется, тем меньше остаётся времени на то, чтобы её проверить. Постепенно информационная среда превращается в некое подобие «белого шума». Всё труднее строить внутри себя новые информационные фильтры, чтобы отсеять лишнее: убрать в сторону лозунги, агитацию, пропаганду, а оставить только то, что на самом деле кроется за ними. А манипулировать нашими мыслями пытаются постоянно, и я говорю не о 25-ом кадре (он не работает), а о более земных вещах — приёмах пропаганды, которые так умело (а зачастую — очень топорно) используют политики, рекламщики и вообще, все, кому не лень. Об этих приёмах и пойдёт речь в статье.

Хвост виляет собакой. ("Wag the dog") — чтобы избежать большого скандала или «замять», оставить незамеченным какое-нибудь важное, но неприятное событие, часто используется простой, но хитрый и ловкий приём, который англоязычные политтехнологи называют «Wag the dog», а русскоязычные — «Хвост виляет собакой». Он заключается в том, чтобы вовремя поднять волну обсуждения вокруг вопроса второстепенной важности, на фоне которой другое, более важное событие или действие пройдёт незаметно.
Примеры таких вопросов: Отмена перехода на зимнее время, российское гражданство Депардье, поездка Путина или Саши Грей на Ладе Калине по России, полёты со стерхами и т.д.
Своё название этот приём получил в честь английского выражения tail wagging the dog, который, в свою очередь, появился из следующего народного пассажа:

— Почему собака виляет хвостом?
— Потому, что собака умнее, чем хвост. Если бы хвост был умнее, он вилял бы собакой.