Доброго времени суток!

Наряду со статьей "iPhone: MiTM атака из кармана", родилась почти аналогичная статья про Android.

Мы уже знаем, на что способен iPhone. Уступает ли ему Android?

Было рассмотрено около 25 боевых приложений. Хочу предоставить вам результат маленького исследования. Многие приложения даже не запустились, некоторые подвесили телефон намертво, но некоторые даже работали!

Весь софт тестировался на телефоне LG Optimus, с версией Android 2.3.

Итак, краткий обзор боевого софта на Android:

В релизе 2.1 было заявлена реализация такой функциональности, как новый фреймворк агрегирования данных. Хотелось бы рассказать о первых впечатлениях от этой весьма интересной штуки. Данный функционал должен позволить в некоторых местах отказаться от Map/Reduce и написания кода на JavaScript в пользу достаточно простых конструкций, предназначенных для группировки полей почти как в SQL.

Распространенное мнение о появлении панка, состоит в том, что панк был реакцией на крайности современного рока, в частности прогрессивного рока того времени. Реальность, безусловно, намного сложнее, но я подозреваю, что доля правды в этом есть. Рок-н-ролл в поздние 60-е и 70-е, похоже, был областью “Золотых Богов”, недоступной простому смертному. Контраст между группами типа Rush и Black Flag был огромен.

Доброго времени суток, друзья!
Хочу поделиться опытом по борьбе с PHPUnit/DbUnit в связке с MySQL. Далее небольшая предыстория.

Краткая предыстория

В процессе написания одного веб-приложения возникла необходимость тестировать код на PHP, интенсивно взаимодействующий с БД MySQL. В проекте в качестве фреймворка модульного тестирования использовался порт xUnit — PHPUnit. В результате было принято решение писать тесты для модулей, непосредственно взаимодействующих с базой, подцепив плагин PHPUnit/DbUnit. Дальше я расскажу о тех трудностях, которые возникли при написании тестов и о том, каким способом я их преодолел. В ответ же хотелось бы получить комментарии знающих людей относительно корректности моих решений.

Ссылки открытия файлов в IDE

Это облегчит вам поиск нужного файла.
Вы сможете создавать ссылки на код прямо на странице ошибки. Или в журнале ошибок.
Сделайте ссылки в dev панели на класс контроллера и файл шаблона (или что там у вас?)
Клик на такую ссылку будет переносить вас в соответствующий файл открытой IDE.

В статье описан функционал, который доступен в PHP (актуально для 5.3.х) для обработки ошибок всех типов, включая ошибки интерпретации кода (E_ERROR, E_PARSE, E_WARNING, etc). Эта обработка поможет вам для управляемого отображения страницы в случае возникновения таких проблем. В статье присутствует множество описаний и рабочих примеров(архитектуры) для того, что бы сразу воспользоваться в своем программном продукте. В конце концов, ну немного сломали сайт, ну надо же, об этом сообщить поисковику с заголовком 4хх или 5хх и повеселить пользователя, вместо возврата белого экрана (или что хуже экрана со священной информацией, для хакеров) с ответом 200 Ok.



Идея написать этот топик возникла, когда я на храбре задал 2 вопроса:

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

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

Если заинтересовались, то подробности под катом…

PHP очень популярный язык программирования, но тестирование в нем, это скорее прерогатива экспертов, а не жизненная необходимость. Неужели это от того, что PHP-разработчики поголовно быдло-кодеры? Я считаю, что нет. Скорее всё от того, что системы тестирования порой излишне усложнены. А тесты, наоборот, должны были предельно просты: легко читаться, писаться, отлаживаться, и конечно же, быстро выполняться. Мое виденье того как это можно воплотить в PHP вылилось в проект под названием Codeception.

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

<?php
$I = new TestGuy($scenario);
$I->wantTo('create new blog post');
$I->amOnPage('/blog/posts');
$I->click('Create new post');
$I->fillField('Title','Codeception, a new way of testing!');
$I->fillField('Text','Codeception is new PHP full-stack testing framework.');
$I->click('Send');
$I->see('Congratulations, your post is successfully created!');

Согласитесь, такой тест понятен без дополнительных комментариев.
А теперь самое интересное: этот код без всяких изменений может быть выполнен как функциональный тест в фреймворках symfony, Symfony2,Zend Framework, а также в браузерном эмуляторе Goutte и даже через Selenium. Таким образом, вам предлагается единый интерфейс для написания функциональных тестов практически для любого сайта.

В данной статье я хочу описать, как создать минимальное приложение, которое что-то опубликует в timeline, а так же рассказать про трудности, которые могут возникнуть на этом пути.
Прежде всего, стоит сказать, что в данный момент facebook timeline находится в beta и доступна только разработчикам, поэтому первое, что необходимо сделать, это активировать timeline для своего аккаунта. На эту тему написано множество инструкций, вот например www.makeuseof.com/tag/enable-facebooks-timeline-profile.
После выполнения всех действий из инструкции, и подождав несколько минут, кликните по своему имени, вместо стены должен открыться долгожданный timeline.

Шаг 1. Настраиваем facebook приложение

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

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

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

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

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

Например, встречались такие варианты:

if ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR){…}

или

if(in_array($error['type'], array(E_ERROR, E_PARSE,  E_COMPILE_ERROR)) {…}

В связи с этим решил написать небольшую статью о битовых операциях с примерами их использования.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

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

Боевая задача.

Предположим нам хочется захостить небольшой проектик где-нибудь в надежном и не особо тормозящем месте. А поскольку сайт небольшой, то не будем заморачиваться и захотим от хостинга что-нибудь самое простое. Для наших целей вполне хватит PHP, MySQL и доступа по FTP.
Для решения этой задачи идеально подходит Веб сервис от Амазона в котором удивительным образом сочетается способность выдерживать большие нагрузки с бесплатным пакетом ресурсов на первый год после регистрации. В бесплатный пакет входит много чего, но в данный момент нас будут интересовать:

• Виртуальный сервер в формате micro на основе Linux с доступом по SSH.
• 30Гб места в Elastic Block Storage плюс 1Гб под бэкапы.
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

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

Привет! Есть такой замечательный JavaScript фреймворк под названием SproutCore. С помощью него можно довольно легко писать веб-приложения с приближенным к десктопному интерфейсом. Штука довольно популярная, используется например Apple в iWork.com. Под катом мы прикрутим SproutCore к последним рельсам.

Сегодня мы предоставим вашему вниманию перевод поста Пета Аллана (Pat Allan), известного разработчика, приверженца Ruby, одного из победителей Ruby Hero Award 2009 года. Что это за награда? Она присуждается победителями прошлого года тем участникам сообщества, которые наиболее проявили себя: создали значимый обучающий контент, разработали плагины и гемы, участвовали в проектах с открытым кодом. Такая награда была создана для того, чтобы отметить наиболее проявивших себя людей и дать им признание, которое они заслуживают.

Пообщаться со Петом можно будет на конференции RubyC в Киеве 5-6 ноября этого года.

Значительную часть прошлого месяца я провел за написанием моего первого Rails engine — тем не менее я не закончил, да и сама работа была для клиента, так, что на деталях останавливаться я не могу.

В процессе разработки довольно быстро стало ясно, что необходим способ тестировать Rails engine. Не беря во внимание простейшие unit-тесты, довольно привычная практика для интеграционного тестирования — хранить копию приложения на рельсах внутри директории spec или test.

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

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



Под катом история нашей компании за год, от основания, первых продаж и привлечения бизнес ангела, до закрытия раунда в $500 тыс. от SoftLineVP. Ну и конечно отчет, ошибки и наш опыт.

Обойдусь без копипастов и даже ссылок о том, что Ruby за зверь такой, ибо написано было уже сполна. В данном посте просто хочу рассказать о пути изучения Ruby (и, впоследствии фреймворка Ruby on Rails) человека далекого от программирования.

1. Любопытство

«Насколько далекого?», спросите вы, а я отвечу — «Чуть менее, чем полностью», так как в десятом классе в школе у меня были уроки программирования, парочка из которых были уделены Паскалю. Признаюсь, впоследствии о html узнал, и даже мог в Dreamweaver-e сверстать страничку или поставить готовый движок, да по инструкции налепить плагинов, но не более.
Хотя компьютеры мне нравились, пошел я учиться на экономиста* — бакалавриат, магистратура по бух. учету и аудиту, аспирантура по финансам, работа в банке, преподавание, страхование. Но не жилось мне спокойно в финансах, — финансовый калькулятор удовлетворял необходимости решения тривиальных задач, но не удовлетворял мой мозг. А ему хотелось посчитать не только будущую и приведенную стоимость актива, но и создать массив данных из исторических стоимостей этого актива за n лет, высчитать среднюю доходность, дисперсию и, в конце-концов построить красивый график!

Как уже многим известно, сегодня вышел релиз Ruby on Rails 3.1 (про это событие на Хабре наверняка еще кто-нибудь напишет).

Я, в свою очередь, к этому событию приурочил выход новой версии сайта Rusrails.ru, на котором публикую свои переводы официального руководства по Rails.

Над новой версией Rusrails я работал где-то с начала лета в свободное от работы время.

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

И захотелось мне посмотреть, как в одном из самых простых классов связаны между собой методы и поля. PhpCallGraph, быстро нагугленный, наладить не удалось (какие-то проблемы с xdebug), и к тому же, судя по примерам, он показывает связи во всём проекте, трассируя его, а мне нужно было исследовать один класс.

Я решил написать собственное решение, и вот что получилось.

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

Создатели проекта The Noun Project поставили целью собрать пиктограммы для всех объектов в мире. Коллекцию по мере сил пополняют десятки дизайнеров из разных стран. Все иконки публикуются в формате SVG, под лицензией Creative Commons Attribution 3.0 (CC BY) или Public Domain, разбиты на тематические категории, есть поиск на русском языке.