Проблема _непрочтения_ ТЗ встает практически каждый раз, когда "написатели" ТЗ и разработчики — люди из разных контор.

Этот пост — о Техническом Задании на разработку интерфейсов [для пользователей].

Разработчики – такие же люди, как и все. Читать талмуд об интерфейсе, написанный канцелярским языком – наверняка не очень приятное времяпровождение. Специалисты по интерфейсам разрабатывают ТЗ и передают их Заказчикам. И просят прочитать техническое задание (или спецификацию) – о том, как разрабатывать и изменять спроектированный интерфейс.

Что включает в себя техническое задание для разработки спроектированного интерфейса?

Добрый вечер, созидающая часть Хабра!

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

Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!



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

В преддверии Дня Дурака (1 апреля), когда вроде бы ничто не предвещало беды, мировые новости забили тревогу глобального масштаба.

Хактивисты движения Anonymous в рамках акции «Глобальное отключение» обещают 31 марта предпринять распределённую атаку на 13 корневых DNS-серверов, что приведет к тому, что пропадет возможность поиска доменных имен в Интернете по всему миру.

Многим владельцам смартфонов от HTC известны сервисы, предоставляемые компанией покупателям своих гаджетов. В частности, есть сервис поиска украденного или потерянного коммуникатора. Есть и облачный сервис архивации всех данных с телефона, включая контакты, журнал звонков, sms|mms и фотографии. Кто-то считает эти сервисы удобными, кто-то не очень. Но если вы работаете с HTCsense.com, то помните — к 30 апрелю сайт будет закрыт, все сервисы прекращают работу.

В данном посте хочу рассказать как предпочитаю реализовывать наследование в объемном JavaScript приложении.

Допустим для проекта необходимо множество родственных и не очень классов.
Если мы попытаемся каждый тип поведения описать в отдельном классе, то классов может стать очень много. И у финальных классов может быть с десяток предков. В таком случае обычного JavaScript наследования через prototype может оказаться не достаточно. Например мне понадобилась возможность из метода вызывать аналогичный метод класса-предка. И захотелось создавать и наследовать некоторые статические свойства и методы класса. Такую функциональность можно добавить, вызывая для каждого класса ниже изложенную ф-ию extend:

Функция extend

cSO = {}; // Просто для отдельного пространства имен.
cSO.extend = function(child, parent, other) {
  if(parent) {
    var F = function() {};
    F.prototype = parent.prototype;
    child.prototype = new F();
    child.prototype.constructor = child;
    child.prototype.proto = function() {
      return parent.prototype;
    }
    // Пока все стандартно.
  } else {
    child.prototype.proto = function() {
      return;
    }
  }
  /*
   * У классов есть параметр stat, предназначенный для статических ф-ий и данных.
   * Он доступен через _class.stat или из объекта(экземпляра) класса через this.stat.
   * Потомки могут обращаться к статическому методу предка, для этого их нужно
   * объявлять так: _class.stat.prototype.myStaticMethod = function() {...

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

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

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

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

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

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

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

Американский инженер Ричард Уардлоу (Richard Wardlow) разработал интересный микроконтроллер pyMCU, который он позиционирует как «простой интерфейс на Python между компьютером и физическим миром».

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

В HTML 5 были введены такие атрибуты тегов, как data-*.
Про них вы наверняка слышали или видели в разных проектах.
Например, их используют такие модные товарищи, как Twitter Bootstrap и jQuery Mobile.

Раньше использовали классы, ради сохранения информации в HTML, с целью последующего использования в js.

Например, для сохранения уникального номера блока часто пишут так:

<div class="items">
  <div class="item1">...</div>
  <div class="item3">...</div>
  <div class="item6">...</div>
  <div class="item1">...</div>
  ...
</div>

А если нам нужно добавить еще один класс для каждого элемента? Или модификатор для отдельных? Да, конечно, можно обрезать регуляркой или другим костыликом на ваш вкус.

Как может показаться, тут можно задействовать id, но у нас могут быть блоки с одинаковым номером.

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

И вот нам на помощь спешат Чип и Дейл атрибуты data-*.

Переадресация- штука интересная и количество сценариев переадресации звонка очень много.
В случае описываемом мной переадресация выполняется безусловно и включатеся по желанию абонента (вообще данный пример очень просто перделывется в условную переадресацию и если дойдут руки я постараюсь раскрыть эту тему), но все осложняется тем, что сервер на котором регистрируется Asterisk с выходом в город не умеет обрабатывать SIP сообщение 302-Moved Temporarily (Используется SIP канал, но диалплан может быть применен и к другим технологиям). Недостаток метода который я опишу здесь в том, что потребуется 2 Trunk'а или 1, но многоканальный (<2 канала). Метод использует собственную базу данных Asterisk astDB, поэтому советую прочитать об этом, поскольку подробно останавливаться на этом моменте я не буду.

Идея делать украшения из электронных компонентов не нова. Особенно приятно, если это не просто красивая кучка деталек, а работающая схема, которая светится, мигает и переливается… Расскажу о своем опыте конструирования подарка на 8 марта.

Привет Хабравчанам!

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

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

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

В позавчерашнем выпуске «Mozilla Hacks Weekly» увидал гиперссылку «Morris.js», пошёл по ней, почитал, порадовался — а теперь и вам поведаю.

Morris — это легковесный джаваскрипт (всего-то 3052 байта после миниатюризации) с открытым исходным кодом (распространяемым по упрощённой лицензии BSD), который для работы требует jQuery и Raphaël и строит с их помощью графики на простой сетке горизонтальных линий, наподобие такого:



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

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

Достоинство скрипта — простота API. Приведённый мною пример создаётся вот таким вызовом:

// поквартальные данные, тонкие линии, цвета их заданы в явном виде
Morris.Line({
  element: 'quarterly',
  data: [
    {q: '2009 Q3', a: 100, b: 75},
    {q: '2010 Q2', a: 75, b: 50},
    {q: '2010 Q3', a: 75, b: 50},
    {q: '2011 Q1', a: 50, b: 25},
    {q: '2011 Q3', a: 50, b: 25},
    {q: '2011 Q4', a: 75, b: 50},
    {q: '2012 Q2', a: 100, b: 75}
  ],
  xkey: 'q',
  ykeys: ['a', 'b'],
  labels: ['Series A', 'Series B'],
  lineColors: ['#167f39','#044c29'],
  lineWidth: 2
});

При разработке мобильных приложений зачастую возникает необходимость хранить настройки приложения (выбранную пользователем цветовую тему, пароль доступа к приложению, параметры синхронизации с сервером и т.д.). Поскольку такие задачи возникают довольно часто, в Google позаботились о разработчиках и создали механизм для быстрой и легкой реализации данного функционала. Этот механизм позволяет легко создавать, сохранять, отображать и производить разные манипуляции с настройками приложения. Мало того он позволяет автоматически создавать пользовательский интерфейс. При описании типа параметра настроек — автоматически генерируется часть пользовательского интерфейса в зависимости от типа параметра (boolean — чекбокс, String — поле ввода, ...) без написания кода. Звучит неплохо для быстрой разработки, не так ли?

Привет, Хабрачитатели.

Большинство (если не все) веб-серверы при ответе на HTTP-запрос по умолчанию заявляют о себе с помощью заголовка Server, сообщая в лучшем случае название используемого ПО, а в хучшем – версию, используемые модули и т.д. Их можно удобно просматривать с помощью таких дополнений, как например Server Spy для Mozilla Firefox.



Но далеко не все из веб-серверов позволяют в явном виде одной директивой отключить такое поведение. На мой взгляд, это потенциальная прореха в безопасности. В данной статье показано, как отключить отсылку заголовка Server или подменить его значение на произвольное для серверов Lighttpd, Nginx, Apache, G-WAN.
Подробнее под катом.

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



Картинка кликабельна.

PS: Оригинал на английском здесь. Переводил на русский — не я.

Эта картинка, если на первый взгляд, выглядит фотографией реального облака в реальных небесах:



Тем не менее на сайте «CSS3D Clouds» объёмное облако вращается, реагируя на движения мыши, и может быть заново (иначе) сгенерировано в любой момент. Ведь на деле оно является итогом применения JavaScript и трёхмерных CSS-преобразований к нескольким копиям одной и той же картинки облака: из них, как из вокселей, формируется более крупное облако.

Привет, Хабраюзер!
Я даже не знаю что хуже, что код для этого секундомера занимает ~ 1100 строк, или то что он работает только в половине браузеров.
Но если же тебе интересно как это работает, прошу под кат.

В данной статье я бы хотел поделиться своим опытом настройки настройки сервиса сбора и визуализации статистики сollectd в связке с graphite. Первый используется как сборщик данных, второй — как хранилище с визуализатором.

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