Если вы интересовались разработкой приложений в metro-стиле под Windows 8, вы, наверное, уже знаете, что жизненный цикл этих приложений ближе к жизненному циклу приложений на Windows Phone. Это означает, что приложение, фактически не исполняется, когда пользователь его не видит. Таким образом, возникает вопрос, как приложения могут взаимодействовать друг с другом и системой.

В Windows 8 для приложений в metro-стиле для взаимодействия приложений друг с другом используются контракты, а для взаимодействия с системой – расширения.

Разнообразных контрактов и расширений достаточно много. Написать пост про то, какие контракты и расширения доступны разработчику, меня натолкнула статья Windows 8. Контракт «поиск» в деталях, после которой я решил систематизировать свои знания и собрать в одном месте краткие, буквально в несколько строчек, «how to» по большинству контрактов и расширений, с примерами из Windows SDK Samples.

1 спасибо всем, кто комментировал предыдущую статью на эту тему. Новая статья — для тех, кто задавал вопросы, и для тех, кто чувствует себя опытным докладчиком. Как и раньше, все советы здесь — это мой опыт. У кого-то сработает то, что сработало у меня, у кого-то — что-то иное. Волшебных таблеток и истин в последней инстанции в тексте нет.

Особое спасибо karellen за ссылку на книгу Pitch Anything. У karellen безусловно стоит поучиться: написав в комментарии к моей предыдущей статье, что в этой книге «автор очень убедительно опровергает почти все эти «истины»», он заинтриговал меня. Интересно же: кто-то опровергает то, что у меня отлично работает. Я, конечно, полез на Амазон, купил kindle-версию книги и читал ее с большим удовольствием. Книга на самом деле ничего не опровергает: я рассказывал, что именно я делал, чтобы выступать интересно, а в книге рассказано, почему надо делать именно так. Книгу безусловно стоит прочесть, тем более, что написана она на довольно простом английском.

Кстати: в начале доклада смело благодарите аудиторию, если есть за что — например, за дельные советы и хорошие вопросы на прошлой встрече.

Перед тем, как благодарить, посмотрите habrahabr.ru/post/57913 — я не со всем согласен, но интересно все равно. Там как раз товарищ возмущается дурацкими началами докладов.
Налаживайте контакт, вовлекайте аудиторию в разговор, если она спит. Хороший способ для больших залов (человек двести и больше) — заставить одну половину аудитории кричать один короткий слоган или слово, а другую — другой. А потом — все вместе что-то общее. Работает на слоганах, хорошо разбираемых на части, и вызывающих энтузиазм у значимой части аудитории, например: «Россия — вперед!», «Уралмаш — чемпион!», «PHP — рулит!» и т.п.

Эта статья открывает серию статей — если окажется, что Хабраколлеги сочтут ее интересной, ибо первое правило публичных выступлений гласит: рассказывай людям о том, что им интересно!

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

В сегодняшней статье я пишу о том, как выступать, и очень мало пишу о содержании доклада. Если из комментариев станет понятно, что надо еще рассказать о композиции доклада (постановка задачи -> варианты решений -> процесс выбора -> выбранное решение -> результат) или об основах публичной речи (не «экать», не «мыкать», не говорить через слово «т-скыть» и не заканчивать фразы ненормативными междометиями) — расскажу в следующий раз.

Историческая справка: на Хабре по этой теме уже было небольшое обсуждение год назад.

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

Для тех кто не в курсе, Knockout.js — это популярная JavaScript библиотека, позволяющая реализовать Model-View-View Model (MVVM) паттерн на клиенте. На Хабре уже много писали про него (раз, два, три, четыре, пять, видео). Освоить Knockout.js можно очень быстро — ведь есть система интерактивного обучения, куча живых примеров (можно потыкать и посмотреть исходный код) и прекрасная документация.

Очень часто Knockout.js используют в связке с ASP.NET MVC — ведь библиотека существенно упрощает написание клиентской логики. Однако, возникает много типичных проблем для клиент-серверной разработки: основную модель и часть логики её обработки приходится описывать как на клиенте (JavaScript), так и на сервере (C#/VB). Кроме того, есть рутинная часть, связанная с обращением клиента к серверным методам и передачи им модели для обработки. Но не стоит печалиться! Теперь у нас есть Knockout MVC — это .NET оболочка для Knockout.js, которая генерирует весь нужный JavaScript-код за нас. Нам остаётся только описать нашу модель на C# и в MVVM-стиле указать для каждого нужного html-элемента к какому свойству модели нужно привязаться (а можно указать и целые выражения — они будут транслированы в js). Таким образом, можно получить полноценное кроссбраузерное клиентское веб-приложение без единой строчки JavaScript!

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

Как вы, наверняка, уже знаете, 29 февраля вышла Windows 8 Consumer Preview, а вместе с ней и 5-я platform preview версия Internet Explorer 10. В этой статье я расскажу о том, как подготовиться к новой версии IE. И хотя повествование будет вестись преимущественно вокруг IE10, многие из этих советов применимы и к другим браузерам, в том числе на других платформах.

1. Используете <!doctype html>

Первое, самое-самое-самое первое, с чего надо начать, — это убедиться, что все страницы вы отдаете с правильным doctype. В мире html5 это одна небольшая и очень простая строчка:

<!doctype html>

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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

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

Раз уж нам с вами предстоит пройти некоторый путь вместе, позвольте представиться. Меня зовут Алексей. По специальности я инженер-системотехник, профессиональный сисадмин. Окончил профильный ВУЗ в 1999 году, 6 лет работал системным инженером, потом 3 года специализировался в менеджменте в области ИТ, а потом нашел себя в роли бизнес-аналитика.

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

Надо сказать, коллеги, что эта работа — просто рай для любителей игры Sim City и Transport Tycoon. Где еще вам представиться возможность построить транспортную систему целого города? И не на экране компьютера, а живьем.

Конечно, не все в этой отрасли радужно и прекрасно. Особенно в нашей стране. Далее о проблемах.

Введение

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

Как бы то ни было, неплохо бы разобраться в том, что же собой представляют ИТС и для чего они предназначены. Опустим транспортную и политическую составляющие и сосредоточимся на «Айтишной». Разберем на самом высоком уровне архитектуру ИТС и коротко пробежимся по основным ее блокам. Заодно системным архитекторам будет любопытно узнать, как вообще строится архитектура систем масштаба страны.

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

Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

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

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

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

Сегодня мы посмотрим на дорожное «железо», устанавливаемое на магистралях.

В прошлый раз в статье "АСУДД: Что висит над дорогой?" мы бегло прошлись по «железу», которое устанавливается на транспортных магистралях: по типам детекторов транспортного потока, светодиодным табло и дорожным контроллерам.

Сегодня мы продолжим говорить об управлении трафиком, но уже в городе. Рассмотрим из чего состоит цикл светофорного регулирования, чем именно «рулят» управляющие системы и с чего это все, собственно, началось.

Я долго не решался начать писать этот пост, так как тема управления трафиком на городских улицах настолько объемная и разносторонняя, что рассуждая о ней постоянно рискуешь оказаться в роли «ламера» в смежных областях. Но я все же рискну и попробую.

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

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

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

Большинство разумных веб-разработчиков уже давно знают, что принудительная регистрация — зло. Но некоторые до сих пор без лишней необходимости закрывают контент от пользователей или не дают им купить товар до тех пор, пока они не зарегистрируются. Такой подход оправдан в случае платных услуг или сервисов вроде РуТрекера. Но в большинстве своём является для ресурса крайне вредным или даже губительным.

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

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

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

1. Отображайте нажатия кнопок и кнопкоподобных ссылок

Мой излюбленный совет. Когда стиль кнопки задаётся в CSS, или когда для отображения необычной кнопки используется рисунок (либо как фон, либо как элемент <img />), то кнопка не реагирует на нажатие во всех или в некоторых браузерах (зависит от ситуации). Вот какой простой уловкою вы можете дать знать посетителю сайта, что он и впрямь нажал на нечто нажимаемое:

.mybutton:active {
   position: relative;
   top: 1px;
   left: 1px;
}

Этим кодом кнопка смещается на 1 пиксел направо и на 1 пиксел вниз, когда её нажимают. Испробуйте: выглядит весьма убедительно.

Есть другие, не менее быстрые варианты: придать границе свойство inset, указать свойству text-indent значение 1px, изменить направление градиентного фона (что можно сделать быстро, если для этого не придётся прибегнуть ко графическому редактору, то есть если где-то ещё на сайте используется готовый перевёрнутый градиент), или комбинация нескольких из них.

2. Плавные переходы (CSS3 transitions)

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

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

Проблема очевидна. Нужен способ облегчить работу с префиксами.

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

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

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

Здравствуй, дорогой хабрадруг! Сегодня мы научимся создавать объемные кнопки CSS3! Они основаны на популярной PSD фриби от Orman Clark для его веб-сайта Premium Pixels. Мы постараемся создать копию этих кнопок с помощью CSS с минимальным количеством кода HTML.