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

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

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

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

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

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

В данной статье я предлагаю вам свой взгляд на выбор использования примесей или делегирования в проектах для добавления в класс нового функционала.

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

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

Стили

User Agent

Один из способов включения стилей для мобильного устройства — это использование User Agent, которую получает сервер от клиента.
Этому может помочь набор скриптов: code.google.com/p/mobileesp, а также сервис от яндекса api.yandex.ru/detector
При работе с User Agent только одна проблема — это постоянно появляющиеся новые User Agent.

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

Заметка навеяна постом Помогите, а то я скоро сойду с ума (реальная история, реальной разработки проекта), затем была опубликована как комментарий, а теперь, по просьбам, и как топик.

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

И так, как же разработать стартап лучше?

Пошаговый план эффективного запуска первой версии:

Здравствуйте, хочу сегодня поведать вам об одном некоммерческом проекте.

Для тех, кто не в теме: существует опенсорсный графический редактор, который называется Gimp. Чтобы рассказать о нем, для простых людей был создан сайт, на котором были размещены уроки и описания этого редактора. Но речь пойдет не о самом сайте.

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

В чем плюсы проекта для пользователей:

• Отказ от системы «пакетов кистей». Человек будет скачивать только те кисти, которые ему интересны.
• Подбор кистей по фильтрам и ключевым словам. То, что будет реализовано в GIMP 2.8 мы попытались реализовать на страницах сайта.
• Удобный просмотр кистей. Пользователь видит кисть перед скачиванием. Может изменить цвет кисти и посмотреть ее в полном размере.
• Перед скачиванием пользователь может опробовать кисть в действии. Порисовать ей в специальном графическом редакторе.
• Скачивание со страниц сайта. Никаких тебе турбобитов, летитбитов и других файлообменников.
• Рейтинг кистей. Сортировка кистей по качеству. Мы видим сколько раз кисть просмотрели, сколько раз ее скачали (показатель отказов), сколько раз ей подняли (в будущем и опустили) рейтинг. И в зависимости от этого, сортировать кисти по их качеству, а не дате добавления.

Эта статья предназначена для тех, кого бесят мильён левых служб и драйверов, которые ставят любые виртуалки. Тем, кто будут ставить доп. пакеты Node.js
Все остальные могут скачать скомпилированный Node.js node-js.prcn.co.cc
Или же установить Node.js из-под виртуалки nodejs.ru/25

Прошу под кат

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

Мы делили апельсин, много нас, а он один

В американской традиции стартапов принято брать в долю всех участников проекта, работающих с первого дня его основания. Отличный способ мотивации команды, скажу я вам. Но как делить баснословные доходы, если они таки будут? Самое первое, приходящее на ум — поделить поровну. Таким образом, если над стартапом работало пять человек, то каждому достанется по 20%. Справедливо? Не очень.

У американцев есть отличная поговорка про курицу и свинью «a chicken is involved with breakfast, but a pig is committed»: речь о яичнице с беконом на завтрак, для приготовления которого требуется некоторое усилие от курицы (снести яйцо и жить себе спокойно дальше), в то время как свинье придётся принести куда более существенную жертву. Так же и в бизнесе: некоторые участники проекта выполняют работу достаточно формально и потом наблюдают за результатами, другие же несут принципиально большие риски и вкладываются в дело сильнее.

Frank Demmler, профессор предпринимательства в бизнес-школе при Carnegie Mellon University, предложил следующий метод распределения долей в стартапе.

Scratch — это среда для обучения школьников программированию.

В этой среде можно создавать и играть с различными объектами, видоизменять их вид, перемещать их по экрану, устанавливать формы взаимодействия между ними. Это объектно-ориентированная среда, в основе которой лежит принцип конструктора LEGO и в которой программы собираются из разноцветных блоков-кирпичиков команд точно так же, как собираются из разноцветных кирпичиков конструкторы Лего.

Вступление

Эта статья проведёт вас через базовые шаги для создания вашего первого расширения для Opera. Вы создадите кнопку на панели, при нажатии на которую будет открываться всплывающее окно с сообщением «Hello World!». Расширения для Opera пишутся с помощью общих открытых веб-стандартов, поэтому всё, что вам нужно чтобы начать, это Opera 11 и ваш текстовый редактор или IDE.

Прочитав недавно нововведения PHP 5.3, я обратил внимание на несколько интересных особенностей, скомпоновав которые можно получить реализацию шаблона проектирования Observer, гораздо красивее, чем имеющиеся в pear и symfony, причём вся реализация займёт всего несколько строк кода.

Хочу Вам рассказать о штуке, которую я изобрел сегодня, чтобы ускорить процесс загрузки сайтов. Все вы знаете, что <script src="..."></script> задерживает отрисовку страницы, пока не загрузится этот скрипт. Если их десятки — это может сереьезно замедлить работу сайта — в результате пользователь 20 секунд пялится на пустую (или недорисованную) страницу из-за какого-нибудь тупящего социального виджета (умножить на десяток этих виджетов).

Не правда ли было бы круто, если бы можно было сказать <script extsrc="..."></script> ("extsrc" = "грузи потом"), чтобы скрипты загружались после того как страница отрисована?

Все бы хорошо, но есть document.write… Сегодня я наконец решил его проблему — представляю extsrc.js — скрипт, который запустит все скрипты после отрисовки страницы (даже если они содержат document.write — и правильно отрисуется все).

Результат? Супер-быстрая загрузка страниц, даже если там море всяких внешних скриптов.

Использование:

Заменяем <script src="..."> на <script extsrc="...">.

Итого получается:

<script src="http://whiteposts.com/extsrc_js/extsrc.js"></script>
<script extsrc="..."></script>

Заметка для тех, кто не специалист в NGINX, а проблему нужно решить быстро.

Допустим, у вас на сервере стоит NGINX и вы хотите, чтобы вся статика кешировалась у клиента. В конфиге хоста NGINX пропишите это:

server {
listen 80;
server_name mysite.com;
...
# Задаем правила обработки статического контента (типов файлов можно поставить и больше)
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|pdf|ppt|txt|bmp|rtf|js)$ {
root /path/to/document/root/; # Путь к корню вашего сайта
access_log off; # не пишем логи
expires 3d; # кешируем у клиента на 3 дня
}
}

Проверить можно в FireBug во вкладке NET: обновите страницу 2 раза и посмотрите код ответа. Если 200 ОК, то не работает. Если 304 Not Modified, то работает.

Неплохо ускоряет работу сайта.

В этой заметке расскажу о своем опыте юнит-тестирования JS-кода, опыте использования среды выполнения тестов js-test-driver, ее возможности code coverage и скручивании ежа с ужом, а именно данных о code coverage от js-test-driver и генератора отчетов о покрытии PHP_CodeCоverage. Расскажу и покажу как получить вот такие отчеты о покрытии кода...

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

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

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

За последний месяц, я написал уже два поста с обзорами плагинов jQuery (1 и 2). Надо сказать, что подобные статьи на английском языке появляются все чаще и чаще. Однако их содержание довольно быстро приедается. Галереи картинок, слайдеры, опять галереи картинок, многочисленные динамические меню и опять слайдеры. Мне не хочется описывать очередную порцию подобных плагинов. Поэтому сегодня я расскажу не о двадцати-тридцати как обычно, а только о семи важных на мой взгляд плагинах, о которых очень хотелось рассказать. Лучше меньше, да лучше.