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

В стародавние времена в конце прошлого века компания Борланд ворвалась на рынок с принципом RAD и библиотекой VCL. Принцип готовки приложений на их основе был прост – кидаем на форму компоненты, связываем их, дописываем код, …, profit. Для сложных приложений с заранее продуманной системой классов, в которых интерфейс играл факультативное приложение с точки зрения трудозатрат, этот прием не сыграл значительной роли – ну да, быстрее можно было видеть как кнопочки ведут к каким-то действиям, но это не отменяло того кода, что должен быть написан.
Подробнее »»

Мир не идеален, чего уж говорить про программы, которые пишутся одними людьми для других. Редко бывает так, чтобы все работало хорошо и гладко, и виной тому – не злобные программисты, а сочетания множества факторов, начиная от состояния аппаратного обеспечения, заканчивая сложностью программирования как таковой. Увы, наш уважаемый iPhone – не исключение. Доводилось ли вам наблюдать, как программы на нем перестают работать, реагировать на действия пользователя, выдавать несообразные данные или вообще отказываются запускаться? Думаю да, и не раз. Эмоциональный пользователь, скрипя зубами, удалит раздражающее приложение с телефона, поставит ему минимальную оценку, напишет гневный отзыв и с десяток раз пожалеет о потраченном времени и деньгах. Пользователь же дотошный напишет гневное письмо, где во всех подробностях и не стесняясь в выражениях перечислит все найденные ошибки. Чем, конечно, непомерно поможет разработчику и обяжет его устранить неполадки, дабы сохранить свое лицо. Но, увы, часто пользовательское описание внешнего проявления ошибки ничем не поможет разработчику – именно в силу сложности предметной области и множества факторов, влияющих на возникновения сбоя. Поэтому, наилучший способ предоставить разработчику информацию об ошибки и заставить его отработать потраченные на приложение $0.99 – это послать ему отчет о сбое (т.н. крэш-репорт), который волею компании Apple и ее системных программистов сохраняется на телефоне. Этот отчет содержит подробную техническою информацию об инциденте (состояние стека всех выполняющихся потоков и т.п.) и не содержит никаких персональных данных владельца, за исключением, пожалуй, ТТХ устройства. Эта информация гораздо более полезна для программиста и позволит понять суть ошибки и локализовать ее гораздо быстрее, нежели благодаря описанию «не запускается и все тут».

Когда пользователь синхронизирует своё устройство с помощью iTunes, крэш-репорты автоматически копируются в директорию на диске на пользовательском компьютере. Если приложение было скачано из App Store и пользователь включил отправку крэш-репортов в Apple, то крэш-логи будут автоматически отправлены iTunes в Apple и разработчик сможет скачать их через iTunes Connect. В этом случае дотошным пользователям беспокоится не стоит – автор приложения и так все увидит.

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

* Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/
* Windows XP: C:\Documents and Settings\\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\
* Windows Vista: C:\Users\\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\

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

Если же ваше устройство было взломано (jailbrake) и синхронизации с настольным компьютером не было и не предвидится, то крэш-репорты можно найти на самом аппарате в папке /private/var/logs mobile/CrashReporter/. В этом случае достаточно просто скопировать эти файлы при помощи scp или любого файлового менеджера, поддерживающего передачу данных поверх защищенного протокола SSH.

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

Специально для ru_iphonedev, совместно с Романом Бусыгиным.

Работаю над собственным западно-ориентированным сайтом DevImpress.com, реализовал такую простую дизайнерскую идейку:

В общем, полный Web 2.0…

В процессе пришел к мысли, что дорос писать deployment-сценарии (сценарии развертывания на рабочем сервере) для PHP-приложений. Пока, процедура выглядит так:

1. распаковка сценариев бизнес-логики;
2. компрессия JavaScript-сценариев (JavaScript Compressor) и CSS (YUI Compressor) с модификацией шаблонов приложения (у меня XSL, но на этом многообразие не исчерпывается);
3. развертывание БД и модификация параметров в конфигурационном файле;
4. создание точки для восстановления (commit в систему контроля версий с определенным тэгом, архивация или клонирование контейнера).

В идеале еще между пунктом 2 и 3 запустить какой-нибудь мета-компилятор, который унифицировал и сократил до нужного размера названия CSS-классов, например, из mainBigTable сделал что-то вроде mbt. Байтики-байтиками, а курочка по зернышку клюет. В Gmail так, наверное, и сделано.

… будем посмотреть, что из этого получится.