Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

В сети гуляет довольно много решений для эмуляции многопоточности в php. Чаще всего они основываются на форках, но есть и вариации на тему с использованием curl, proc_open и т.п.

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

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

В результате получилась библиотека AzaThread (старое название — CThread).

Вместо предисловия

Давно хотел опубликовать что-то полезное и вот, наконец, решил рассказать об Ext.Direct. Не видел ни одной более-менее обширной статьи на русском по данной теме, то ли это никому не нужно, то ли одно из двух, как бы то ни было начнем.

Что из себя представляет Ext.Direct?

Ext.Direct существует начиная с версии extjs 3.0. Это пакет который позволяет осуществить более тесное взаимодействие между сервером и клиентом. Вспоминая версию 2.0+ понимаю как же мне не хватало «директа».

Client Side

Возможности Ext.Direct реализованы в классах пакета Ext.data (DirectStore, DirectProxy), соответственно DirectStore в качестве ридера использует JsonReader. Так же существует пакет Ext.direct, в частности класс PollingProvider реализует переодический опрос сервера с заданным интервалом. Ну и Ext.Direct, о нем вскользь ниже и Ext.Direct.Transaction, вспомогательный класс, который напрямую не вызывается.

Автор: Jozef Sakalos, aka Saki
Статья в оригинале: Создание сложного приложение в Ext на blog.extjs.eu

Предисловие

Я решил написать эту статью для тех пользователей Ext 2.x, которые уже переросли одну единственную HTML-страницу со встроенными скриптом, создающим простое окно или форму, для тех, которые уже решили, что Ext — это их путь и для тех, которые превозмогая трудности связанные с большими объемами кода, понимают, что нуждаются в его структурировании.
Сколько людей, столько и мнений. И поэтому способ, который я опишу ниже, не является одним единственным возможным. Также хотелось бы отметить, что не каждое приложение, написанное с применением этого подхода, является гарантированно хорошим. Ничего подобного.
Замечу, что описываемый подход является работоспособным, четко структурированным, без труда поддерживаемым и, одним словом: рабочим!

Каркас для кроссбраузерной разработки ExtJS сейчас очень популярен. Это поистине грандиозный (и монструозный) набор компонентов, классов, функций, хелперов и т. п., которые могут как облегчить жизнь разработчика, так и усложнить ее. Говоря вообще, ExtJS (до 4-й версии) не устанавливает никаких «правил игры» для конечного разработчика: формально нет никаких требований и рекомендаций по проектированию и написанию надежных приложений.
Удивительно, что до сих пор качество пособий и туториалов для новичков ExtJS, мягко говоря, оставляет желать лучшего. Как и стандартная справка по ExtJS API, впрочем [1].
Цель данной статьи — показать, как писать приложения на базе ExtJS так, чтобы человеку, который будет поддерживать ваш код, не хотелось рвать волосы, а вам просто не было стыдно. А если серьезно, то в данной статье я предложу простой и короткий набор правил проектирования и написания приложений применительно к данному фреймворку.

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

Этот пост участвует в конкурсе „Умные телефоны за умные посты“

Введение

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

Такими проблемами к примеру, является получение доступа к системной информации, управление и изменение чего-либо в системе. Доступ из HTML5 к контактам, календарю, органайзеру на мобильном устройстве и другие. Опять же, если наше приложение производит какие-то серьёзные вычисления, то их можно перенести с медленного JS на быстрый C++. В данной статье хочу рассмотреть несколько техник взаимодействия Web-приложения и нативного кода на примере модуля QtWebKit, которые могут оказаться полезными.

Связывание между двумя свойствами (property binding) «a» и «b», объявленное как «a: b», обновляет значение «a» всякий раз, когда обновляется «b». Связывание свойств находит практическое применение при управлении размером элемента, управлении положением элемента с помощью якоря, динамическом изменении текста или изображений, управлении цветом элемента или состоянием кнопок.

В самой простой форме «а», связанное с «b», сохраняет то же значение, что и «b», на протяжение всего времени связывания свойств. В более продвинутой форме «a» привязывается к произвольному JavaScript-выражению, которое использует «b» как «a: b + 1».

Связывать можно более двух свойств — «a: b * c + 1». В данном случае выражение будет считаться при каждом изменении «b» или «c».

Методом проб и ошибок я изобрел очередной велосипед, о котором и собираюсь рассказать Вам ниже.Речь пойдет о сборке пакетов из проектов Qt для Debian и Rpm based систем, Windows из под Ubuntu/Debian. В принципе метод весьма прост, поэтому, думаю, что при небольших изменениях он подойдет и для rpb based дистрибтивов, а для Windows систем потребуется установка cygwin.Кроме того эта тема очень мало обсуждается в интернете, хотя я бы не назвал сборку кроссплатформенных приложений в инсталяционные пакеты простой задачей.Кому будет интересен данный материал:

• в первую очередь начинающим разработчикам Qt, которые хотят распространять свои приложения в удобном для пользователей виде;
• разработчикам, использующих другие языки программирования (при небольших изменениях можно получить.

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

Данная статья является вольным переводом. Оригинал тут.

Введение

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

Предлагаю ознакомиться с решением на базе backbone.js, underscore.js и jQuery, которое поможет решить эту проблему.

Постановка задачи

Каким бы мы хотели видеть наше приложение? Вот основные моменты, которые мне кажутся важными:

1. Должен быть удобный способ описать модели нашей предметной области.
2. Любые изменения в модели должны немедленно отражаться в пользовательском интерфейсе, если модель в нем представлена каким-либо образом.
3. Понятная и легко-поддерживаемая структуризация кода в стиле MVC.

Попробуем решить эти задачи на примере простого приложения «Каталог фильмов».

Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

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

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

Константно-переменный дуализм.

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

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

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

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

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

Я попытаюсь просто объяснить, как работают замыкания в Javascript, как работает this, как создавать конструкторы для своих классов и чем различаются различные подходы к их созданию.
Статья не претендует на новаторство, но достаточно доступные объяснения how it works для новичков я не видел, и на мой взгляд — это три самых узких места в Javascript (не привязанному к какому либо контексту, серверу или браузеру, например).

Как-то незаметно для себя, я решил отойти от возни с классами и паттернами, и разобраться с самыми обычными Js функциями. Думал, что будет достаточно скучно, но ошибся — оказалось очень даже интересно.

В этой статье я расскажу об особенностях объявления функций, и некоторых полезных паттернах (кхе-хе, да, они есть и тут)

Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.

По мотивам «JAVA → Java по-русски. Часть первая: Книги» habrahabr.ru/blogs/java/66568

Добрый день, уважаемые хабровчане!
В предыдущем обзоре Java книг, проведенном пользователем Scala, было рассказано о «практических» книгах, вышедших на рынок в последние три года. Я же хочу рассказать об этих и других книгах с несколько иного ракурса: попытаться выделить ценность информации книг.
Я не любитель читать с монитора, и предпочитаю книги покупать в бумажном варианте. Чтобы сделать осознанный выбор, следует отдавать себе отчет в том, что книга несет некие фундаментальные знания, но никак не сборник «последние фишки». Также в данной статье я хочу упомянуть о других известнейших трудах, не касающихся Java напрямую. Посмотрим, что лучше всего выбрать для обучения языку?

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

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

Buffered Streams

//медленно
InputStream is = new FileInputStream(file);
int val;
while ((val = is.read()) != -1) {
}
//быстро
InputStream is = new BufferedInputStream(new FileInputStream(file));
int val;
while ((val = is.read()) != -1) {
}

Казалось бы — очевидная истина, неправда ли? Но как показал чужой код и опыт собеседования кандидатов, часть разработчиков определенно не понимает в чем преимущество буферизованных стримов. Кто до сих пор не разобрался — метод read() класса FileInputStream:

public native int read() throws IOException;

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

System.arraycopy(src, srcPos, dest, destPos, length);

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