Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

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

Я делаю шаблоны на чистом HTML/CSS уже больше восьми лет. За это время я убедился, что различные соглашения и документирование помогают в работе. Конечно, они не спасают от периодических CSS-кошмаров. Они лишь делают их менее болезненными. Мое решение — следовать определенным принципам в написании стилей. Эти принципы образуют основание, на котором будет строиться все дальнейшее написание стилей, облегчая работу над растущим проектом.

Так получилось, что последние несколько лет мне приходится принимать участие исключительно в распределенных проектах. Руководство проекта в США, business owner во Франции, разработка в России и Бразилии, а тестирование в Китае — это нормальная ситуация. В таких проектах — очень важна грамотная организация коммуникаций. В разных проектах использовались разные системы. Идеала найдено не было, потому то и был написан собственный «неидеал»: EmForge Portal, который я и хочу сегодня представить, надеясь что кому-то он может оказаться полезным

Привет. Данный перевод задумывается как первая (всего будет две) часть документации по компоненту Event Dispatcher. Этот компонент входит в семейство Symfony компонент, но в то же время он независим и его можно использовать не подключая фреймворк, что делает его еще более ценным. Перевод еще можно воспринимать как обзор легковесной реализации паттерна Наблюдатель (Observer) в php, который призван усилить взаимодействие между классами.

Хочу сказать что семейство компонент сейчас активно перерабатывается для совместимости с версией PHP >= 5.3, и планируется использовать с новой версией фреймворка Symfony 2. Код новой версии компоненты можно посмотреть здесь. Названия и суть методов в новой редакции почти не поменялись, так что материал будет полезен и изучающим код компонент под PHP 5.3. Итак начнем.

Event Dispatcher Component — что это?

Symfony Event Dispatcher — это PHP библиотека, представляющая собой легковесную реализацию шаблона проектирования Наблюдатель (Observer). Это хороший путь сделать ваш код гибче. Это также хороший путь сделать код пригодным для расширения сторонними разработчиками (разработка плагинов). Сторонний код прислушивается к специфическим событиям путем создания обратных вызовов (callbacks), а диспетчер делает вызовы когда ваш код извещает эти события.

Привет!

Представляем хабрасообществу новый сервис от онлайн-бухгалтерии "Мое дело".

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

Подробности и скриншоты под катом.

Во время dot com бума мы с друзьями основали стартап, где я был техническим директором. Мы разработали систему управления знаниями. Это была комбинация блогов, wiki, системы управления документами, социальных закладок. Мы начали в 1999, что было несколько рановато для wiki и блогов (Movable Type вышли на рынок в 2001). Социальные закладки, по сути, были точно такими же, как станет впоследствии Delicious. Помимо этих новых и замечательных идей (по крайней мере для 1999 года) у нас было три отличных особенности:

• Всему можно было присвоить метки (tags): навыкам, людям, ссылкам, документам, постам в блогах, страничкам в wiki. Что-то, что теперь называется фолксономия. Метки могли соотноситься с другими метками и формировать онтологии. Метки могли ссылаться на другие документы, посты, людей.
• Всему можно было поставить свою оценку от 1 до 5.
• У нас был умный нечёткий поиск, основанный на метках и оценках. Например, при поиске «люди со знанием Oracle» в выдачу также попадали специалисты по SQL Server'у — например, чтобы укомплектовать команду, если не было свободных гуру Oracle.

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

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

CSS может связываться с HTML элементами используя любые из его атрибутов. Вы наверняка знаете о классах и ID. Проверим это в HTML:

<h2 id="first-title" class="magical" rel="friend">David Walsh</h2>

Этот один элемент имеет три аттрибута: ID, class и rel. Для выбора элемента в CSS вы можете использовать селектор ID (#first-title) и селектор class (.magical). Но знаете ли вы, что можно использовать для выбора атрибут rel? Это так называемый селектор атрибута:

h2[rel=friend] {
  /* woohoo! */
}

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

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

Почему бы не избежать этих неприятностей, прогнав нагрузочный тест?

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

Под катом рассказываю, как с нуля организовать незамысловатый нагрузочный тест сайта при помощи Apache JMeter.

Недавно на просторах интернета был найден графический редактор, причем написанный чисто на HTML5 + JS без Flash и прочего

Материал, скорее, для начинающих верстальщиков, например таких, что работают в Microsoft ;) На тему натолкнула одна картинка с одной популярной странички:



Дело в том, что весит картинка 55 211 байт. А вот она же, но уже размером 1 764 байт. Если вы думаете, что разница в формате (у меня png, а в оригинале gif), то вы правы лишь отчасти. Попробуйте пересохранить исходное изображение в png, врядли у вас получится серьезный выигрыш (у меня размер получился 45 кб). В общем, дело не в формате.

Добрый день!

Продолжаем говорить о визуализации данных в вебе. На сей раз поговорим о Flash / Flex библиотеках и компонентах.

Предыдущие топики:

• Изумительные диаграммы с новым Chart контролом
• Визуализация направленных графов в вебе
• Список Javascript библиотек для рисования графиков и диаграмм — habrahabr.ru/blogs/javascript/79960 (публикация в блоге — msug.vn.ua/blogs/2257.aspx)
• Список Javascript библиотек для рисования графиков и диаграмм 2 — habrahabr.ru/blogs/javascript/80027 (публикация в блоге — msug.vn.ua/blogs/2276.aspx)

Сложность структуры современного информационного общества постоянно растёт. В связи с этим, требования к эффективности алгоритмов обработки информации также увеличиваются. В последнее время наиболее популярными направлениями в этой области являются Data Mining (DM), Knowledge Discovery in Databases (KDD) и Machine Learning (ML). Все они предоставляют теоретическую и методологическую базу для изучения, анализа и понимания огромных объёмов данных.
Однако этих методов не достаточно, если сама структура данных будет настолько плохо пригодной для машинного анализа, как исторически сложилось на сегодняшний момент в Internet.
Для решения данной проблемы предпринята глобальная инициатива реорганизации структуры данных Internet в целях преобразования его в Семантическую Паутину предоставляющую возможности по эффективному поиску и анализу данных как человеком так и программным агентам.
В этой статье рассмотрены основные технологии позволяющие реализовать Semantic WEB.

Пару недель назад разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.
Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
— приложения, следующие стандартам;
— «долгоиграющие» веб-приложения;
— комплексные приложения со множеством различных асинхронных блоков на странице;
— кросс-доменные приложения.

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

Введение

В статье рассматриваются несколько проблем (и полезных возможностей) при работе с mercurial и предлагаются варианты их решения.

Несколько проектов на одном фреймворке

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

Что же делать?

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

Моя версия под катом.

Даже относительно ограниченный набор возможностей CSS дает нам много возможностей в типографике, которые можно реализовать, используя каскадные таблицы стилей. Антиква или гротеск? Большой или маленький шрифт? Интерлиньяж, апрош, размер шрифта и всевозможные отступы… Список можно продолжать до бесконечности.

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

В конечном счете, мы выделили 13 общих проблем и вопросов, имеющих отношение к типографическим проектам, и попробовали найти ответы на них в нашем исследовании:

1. Насколько популярны шрифты с засечками и без засечек в заголовках и основном тексте?
2. Какие шрифты используются наиболее часто?
3. Каков средний кегль для шрифта?
4. Каково, в среднем, соотношение между размером шрифта в заголовке и в основном тексте?
5. Чему равно среднее значение интерлиньяжа для основного текста?
6. Каково усредненное соотношение между значением интерлиньяжа и размером шрифта для основного текста?
7. Чему равно среднее значение соотношения между интерлиньяжем и длиной строки?
8. Каковы, в среднем, отступы между абзацами?
9. Каково усредненное соотношение значений отступа между абзацами и интерлиньяжем?
10. Как выделяются стилистически ссылки?
11. Сколько символов обычно используется в строке?
12. Как часто ссылки выделяются подчеркиванием?
13. Как часто используется замещение шрифтов (sIFR и прочие)?

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

Browsera — сразу определимся что это не ещё один сервис бесплатных скриншотов. Этот сервис позволяет проводить атоматизированнное тестирование кросс-браузерности вашей вёрстки, то есть читается ваш html код, стили, скрипты — и моделируется их отрисовка в соответствии с особенностями того или иного браузера. Впрочем, сервис также генерирует скриншот для каждого браузера: будет что отослать верстальщику.