Многие наверняка сталкивались с необходимостью быстрого создания контролов в мобильном пользовательском интерфейсе. Рассмотрим стандартные кнопки UIButton. Базовый контрол мало устраивает взыскательного заказчика и зачастую стандартное решение, это натягивание на кнопки битмапов состояния. Растянутая ли это картинка или целиком вырезаная кнопка — решение требует дополнительных временных затрат на дизайн пользовательского интерфейса. Хорошо было бы иметь универсальный контрол, с более широкими визуальными возможностями, чем базовый UIButton.

У любого желающего писать программы для продукции фирмы Apple в жизни наступает такой момент, когда ему приходиться изучить новый язык программирования — Objective-C. Когда-то этот счастливый момент постиг и меня. А чтобы лучше запомнить основные особенности этого языка, решил законспектировать свои мысли во время осмысления его документации, которыми и делюсь с вами.

Инструменты системы управления временем, описанные в прошлом посте, дают возможность свести все дела, происходящие в вашей жизни и требующие участия, в одно место. Это, как, наверное, понятно — списки дел, разбитые на категории DAY, LATER, CONTROL. Работой со списками предшествует работа с накопителями.

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

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

В догонку к посту про макет бизнес модели, не менее полезный «самый короткий в мире маркетинговый план» (так его назвал автор, Келли Одел).

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

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

Начнем с пары историй.

История А.

На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?

Умный человек, подумал я, а говорит глупости.

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

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

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

Как обычно строят процесс тестирования непросветлённые тест-менеджеры?

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

Релиз.

Не работает основной функционал.

Почему такое возможно?

1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.

2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.

3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.

4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…

Что просветлённые тест-менеджеры делают по-другому?

Что они поменяют в первую очередь?

Начало здесь.

Накопители

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

1. Вне человека — хаотичная.
2. В накопителе — хаотичная, но собранная в одном месте.
3. В человеке, его записях, файлах — отсортированная.

Чтобы легче понять, как информация вне человека может быть хаотичной (ведь она поступает по упорядоченным каналам: почта, телефон и т.д.) представьте: Вы сидите за столом, а вокруг толпой стоят люди, которые что-то требуют от Вас, толкаются между собой за право получить от Вас ответ раньше другого… Крик, шум, суета.

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

Многие знают, что за такими запросами стоит не действительно срочная потребность, а сумбурность мысли. Человек не всегда может осознать, к какому же сроку ему нужны те или иные данные? Зачастую, они кричат «срочно!» только потому что им хочется , а не потому что они действительно нуждаются.

Чтобы справиться с хаосом, Дэвидом Алленом был придуман простой инструмент — накопитель.

Продолжая тему рассуждений про карьеру, мы с хабраюзером eagleson записали новое видео: «Карьерное плато».



Коротко и по делу (всего 18 минут) обсудили следующие темы:

• Динамика ИТ-специалиста: рост, рост, рост, ЗП, семья, ипотека…
• Почему так, где движение?
• С любого плато можно улететь: нужно строить самолет!

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

Понедельник начинается в субботу.
А. Стругацкий, Б. Стругацкий.

Прошедшее забыто, грядущее сокрыто, настоящее даровано. Поэтому его и зовут настоящим!
Мудрая Черепаха из «Кунг-фу Панда»

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

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

Под катом простая схема, как этого достичь.

Вступление

C системой Аллена меня познакомили около двух лет назад. Начинал пользоваться вариантом Васи Кислого с помощью HTC Touch Pro, но глючность девайса сильно мешала освоить систему, а сам «Успеватель» не давал необходимого уровня понимания. С GTD пришлось на время расстаться.

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

Попытки вести мобильную версию системы в Nokia E63 с помощью «Активных заметок» привели к покупке книги Дэвида Аллена, переработке статьи В. Кислого, приобретению стабильно работающего, хоть и старенького HTC P3400 (а потом и более современного продукта от HTC) и введению бумажной, физически ощутимой части этой системы.

Итогом переработки стала строгая вариация за моим авторством на тему Дэвида Аллена в обработке Васи Кислого. Благодаря ей, работа стала занимать не больше 3-х часов в день. Но за это время я успеваю сделать действительно много.

Следуя этим принципам, я прихожу на работу к 11-12 часам, работаю плотно и не отвлекаясь до 15 часов. В 15 часов ухожу в зал потаскать железки, прихожу в офис к 17-30, прорабатываю за полчаса все накопившееся с 15 часов. И еду домой.

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

Кому интересно, прошу под кат.

О приложении

Привет, Хабр. Я хочу рассказать о моем первом опыте (вообще, тут я немного кривлю душой, но об этом позже) разработки для AppStore и, что, наверное, более интересно, о том, какие уроки из этого я вынес. Приложение называется iAutographer — и само по себе довольно тривиально. Оно предоставят возможность коллекционировать автографы, привязывая их к контактам телефона и набрасывать на общее пано (Sign Board). Затем при просмотре автографа он прорисовывается заново, тем самым создается ощущения, что человек расписывается на ваших глазах. На этом, пожалуй, о приложении и все. Для того чтобы посмотреть на него в деле, привожу 10 промо кодов тут:

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

Не мало было историй о том, как небольшие группы разработчиков добивались успеха. И ещё больше о том, как эти разработки проваливались. Но здесь я хочу рассказать именно об эволюции процесса разработки онлайн игры, опираясь на свой опыт. Оговорюсь заранее: это первый мой опыт разработки массовой онлайн игры.
Всё началось весьма интригующе. Я имел неаккуратность поспорить со знакомой web-программисткой о том, кто быстрее и качественнее из нас сделает web-проект. Чтобы не сильно распыляться и не тратить много времени, решили, что нам будет дана всего одна неделя, а разрабатывать мы будем многопользовательскую игру!

По истечению этого срока проекты были сданы «оценочной комиссии», которой являлись наши общие друзья. И… Мой проект не выиграл. А самым обидным на тот момент казалось то, что, по условиям спора, я должен был выделить ещё одну неделю рабочего времени, чтобы помочь своей оппонентке в развитии её игры. Но спор есть спор!

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

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

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

Итак, в связи с тем, что Apple сняли волшебное ограничение и теперь на Adobe Flash CS5 можно официально делать iPhone/iPad приложения (детали: flash-ripper.com), вашим глазам представляется тутор — как сделать это своими руками.

Что сделаем:
Простенький p2p чат

Что потребуется:
1. Adobe Flash CS 5 (качать с adobe.com)
2. iPhone Certificate (не пугайтесь, расскажу где взять)
3. (по желанию) jailbroken iphone/ipad

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

Основное различие, разумеется, в том, что Integer — это полнофункциональный объект, который занимает место в куче, а в коде вы пользуетесь ссылками на него, которые неявно преобразуются в значения:

int a = 1000; // a - число
Integer b = 1000; // b - ссылка на объект

При присваивании значения переменной типа Integer обычно выделяется память в куче под новый объект, как будто вы написали new Integer(1000) (так называемый autoboxing). Однако иногда переиспользуются старые объекты. Это иллюстрирует следующий код (JDK 1.6):

Integer a1 = 50;
Integer a2 = 50;
Integer b1 = 500;
Integer b2 = 500;
System.out.println(a1==a2);
System.out.println(b1==b2);

Результатом выполнения будет:

true
false

Вы, вероятно, представляли ее себе как целый орган — грандиозное сооружение длиной в пару метров с сотнями и тысячами клавиш. На самом деле, большинство китайцев используют обычную клавиатуру с латинской раскладкой QWERTY. Но как с помощью нее можно набрать такое несметное количество различных иероглифов? Мы попросили рассказать об этом нашу сотрудницу Юлию Дрейзис. Ее с Китаем связывают и давняя любовь, и работа.

История вопроса: печатные машинки

За несколько тысяч лет хитроумные китайцы успели довести количество иероглифов до 50000 с хвостиком. И хотя число нужных в повседневной жизни знаков не измеряется десятками тысяч, все равно, как ни крути, стандартный набор старой типографии — 9000 литер.

Долгое время набор осуществлялся по принципу «на каждый иероглиф — отдельный печатный элемент». Поэтому работать приходилось с машинками-монстрами вроде такой:


Печатная машинка фирмы «Шуангэ», 1947 год (принцип действия придуман японцем Киота Сугимото в 1915 году).

Чтобы не откладывать в долгий ящик сразу порассказываю несколько других примеров для MapReduce, обещанные в топике "MapReduce без зауми". (Если не понимаете полностью что такое MapReduce — прочитайте тот топик сначала! Без него не разберетесь)

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

Однако тема сама по себе сложная и все же напрячь мозги придется. Когда поймете — будет очень просто.

Входящие ссылки

Допустим у нас есть Интернет. В Интернете есть исходящие ссылки.

Допустим на входе у нас есть такие данные об ИСХОДЯЩИХ ссылках, собранные нашим паучком:

habrahabr.ru -> thematicmedia.ru, apple.ru, microsoft.com, ubuntu.com, yandex.ru
thematicmedia.ru -> habrahabr.ru, autokadabra.ru
autokadabra.ru -> habrahabr.ru, yandex.ru

Т.е. мы знаем, что Хабр ссылается на Apple, MS, Ubuntu и Яндекс но кто ссылается на Хабр? Да, вопрос примитивный, но все же разложим на MapReduce. Дальше будет интереснее и этот пример понадобится.