Блог О пользователеiphonesdk

Регистрация

 
     
ЯнварьФевральМартАпрельМайИюньИюльАвгустСентябрьОктябрьНоябрьДекабрь
            

1 |2 |3
 

Скрипт для автоматического создания архива проекта с датой и временем в имени файла


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

Разумеется, нужно вместо MyProject и MyProjectFolderFullPath подставить полные или корректные относительные пути к вашей папке с проектом и к архиву (zip-файлу)

Предположим, что архив будет создаваться в текущей папке:

#!/bin/sh
echo "Enter comment: "
read comment                                                                        
zipFileName="./MyProject$(date +%Y%m%d_%H-%M)"
echo "compress MyProject to zip archive..."
txtFileName="$zipFileName.txt"
echo $comment > $txtFileName
zip -r $zipFileName MyProjectFolderFullPath

Не забудьте сделать скрипт исполняемым файлом. Теперь в консоли достаточно будет ввести имя файла этого скрипта (проще разместить его в домашней папке) и нажать Enter - и архив папки проекта вместе с одноимённым текстовым файлом комментариев будут выглядеть примерно так:

MyProject20101124_14-20.txt
MyProject20101124_14-20.zip

Очень удобно.

 

Прокрутка и масштабирование в UIScrollView


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

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

Но если размер вложенного в UIScrollView-вид контентного вида (например UIView или его наследника) равен размеру UIScrollView-вида (то есть размеру контейнера для вашего контента) ИЛИ если вы забыли установить у UIScrollView-вида свойство contentSize таким, чтобы размеры контента были явно больше размеров самого UIScrollView-вида, то прокрутка будет невозможна (или возможно, но только после растягивания контента, чтобы он стал больше размера родительского окна, то есть UIScrollView-вида).

Есть 2 способа сделать возможной прокрутку:
1) сделать изначально большим размер контентного окна и не забыть установить таким же размер через свойство contentSize вашего UIScrollView-вида.
2) установить свойство contentInset, которое устанавливает дополнительное пространство слева, справа, сверху и снизу от контентного окна, чтобы дать возможность его прокручивать (если размеры контентного окна совпадают с размерами родительского окна).

Так вот, я проверил лично: 2-й способ лучше именно для тех случаев, если вам не нужно размещать большой контент, а именно такой, который размером совпадает с UIScrollView-видом (даже если вы и будете его потом растягивать пальцами). Этот способ заметно экономит потребляемую девайсом память, а значит уменьшает шансы на недопустимое падение программы без всякого предупреждения и спасения данных.

 

Переполнение памяти из-за больших размеров окон (UIView)


Разрабатываемое iPhone-приложение может начать неожиданно падать и при этом отладчик никак не в состоянии помочь.

После нескольких дней поиска (когда программа перестала падать после закомментирования содержимого функции drawRect класса моего окна, наследующего от UIView) удалось случайно выяснить, что слишком большой размер окна (который можно задать либо в Interface Builder либо через self.bounds.size) требует слишком много памяти (в моём случае - это цена за возможность безтормозной прокрутки такого большого окна, если оно отображает контент для UIScrollView). Размер окна составлял примерно 4000 на 2500 пикселей.

Стоило лишь уменьшить размер окна в половину, как падение программы прекратилось.

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

 

Как вывести в отладочную консоль используемую память в iPhone-приложении


Материал взят из 
http://stackoverflow.com/questions/2786539/iphone-memory-usuage

#import < mach/mach.h >


void report_memory(void) {
 
struct task_basic_info info;
  mach_msg_type_number_t size
= sizeof(info);
  kern_return_t kerr
= task_info(mach_task_self(),
                                 TASK_BASIC_INFO
,
                                 
(task_info_t)&info,
                                 
&size);
 
if( kerr == KERN_SUCCESS ) {
   
NSLog(@"Memory used: %u", info.resident_size); //in bytes
 
} else {
   
NSLog(@"Error: %s", mach_error_string(kerr));
 
}
}

 
 
 

Проблемы с UIScrollView и Landscape ориентацией интерфейса


Обнаружил, что при использовании Interface Builder'а (если в нём создавать окно, содержащее UIScrollView окошко) возникают существенные проблемы при попытке обеспечить поддержку не только Portrait но и Lanscape ориентации интерфейса.

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

Сейчас (истратив десятки часов на е..лю с горячо любимым Xcode) я прихожу к выводу, что бесполезно пытаться программно перестраивать размеры контент-вида (того самого, который можно передвигать пальцем используя UIScrollView). Приложение всё равно игнорирует (во всяком случае при визуальном тестировании на девайсе) весь ваш код, и продолжает упёрто принимать во внимание только тот размер, который вы задавали контент-виду через Interface Builder.

Оказывается, требуется в настройках (см. Inspector в Interface Builder) главного окна (в котором будет расположено окошко UIScrollView) и в настройках самого UIScrollView окошка поставить галочку Autoresize Subviews.

Кроме того, важно выставить правильные настройки (в виде красных отрезков и стрелочек) в разделе Autosizing (см. Inspector в Interface Builder). Мне удалась моя задача, как только я выставил только красные стрелочки и убрал красные отрезки в настройках контент-вида. То есть программное изменение размеров и оффсета контента я в коде тоже оставил и это вероятно работает теперь в совокупности (не стал это выяснять, чтобы не злоупотреблять рабочим временем - главное теперь работает как надо).

Обидно, что для выяснения подобных тонкостей уходят многие часы. Хотя это - цена за бесценный опыт.

ЧЕРЕЗ НЕСКОЛЬКО ЧАСОВ: Теперь после многочасовой возни с отладчиком и отладочной консолью удалось выяснить основную причину всех моих бед.

При повороте девайса можно перехватывать это событие (поворот девайса) как вариант в функции shouldAutorotateToInterfaceOrientation (подробности через Гугл). Так вот, при перехвате этого события размеры Autoresize-окон ещё не поменялись! Если вы будете вызывать при перехвате этого события какие-то функции (меняющие размеры ваших сущностей, в которых вы что-то рисуете), то нельзя ориентироваться на текущие bounds (размеры) ваших окон, которые ещё не успели красиво повернуться, подстроившись под новое положение девайса!

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

 
 
 

CodeFest — конференция разработчиков в Новосибирске 23 сентября


http://codefest.ru/

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

 

Высота стандартных iPhone-контролов по умолчанию


При разработке iPhone-приложений высота контролов по умолчанию:

Status Bar: 20px
Navigation Bar: 44px
Tab Bar: 50px

Если не ошибаюсь, аналогичная высота и у iPad-контролов.

Помнить эти значения приходится каждый раз, когда вы запихиваете в UIView всякие UITableView и прочие окошки.

Всё-таки Interface Builder при некоторых своих косяках даёт экономию времени (создавать контролы руками через код иногда бывает крайне необходимо, но это в любом случае приходится дольше делать, чем делать несколько движений мышкой в Interface Builder'e - ну и кроме того, снимается ряд головняков, например таких как контроль над утечками памяти программно создаваемых контролов). Особенно я люблю Interface Builder за возможность быстро создать взаимосвязи между контролами и функциями-обработчиками (где в качестве возвращаемого типа указываем IBAction).

Так вот - в ряде случаев применение Interface Builder'а позволяет значительно упростить задачу создавать в одном Xcode-проекте приложение сразу и для iPhone и для iPad (просто для разных экранов работаете мышкой с одноимёнными xib-файлами - поверьте, получается быстрее, чем вручную писать каждый раз if-else или #ifdef ТАКОЙ_ТО_ТИП_ДЕВАЙСА).

 

Upgrade Current Target for iPad - проблемы!


Upgrade Current Target for iPad - увы, я не нашёл этот пункт в контекстном меню при использовании iPhone SDK 3.2 beta (включающего в себя Xcode 3.2.2).

Вместо него там стоит пункт Transition - который выполняет вероятно то, что должен был выполнять пункт
Upgrade Current Target for iPad.

Должен отметить, мне нравится, куда располагаются xib-файлы для iPad (в новую папку Resource-iPad), автоматически генерируемые из одноимённых файлов для iPhone. Но я после этого создаю отдельные папки Resource-iPhone (куда перемещаю ресурсы
, специфичные только для iPhone, в том числе и xib-файлы) и Resource-Common (куда перемещаю общие ресурсы). После этого нельзя забыть удалить из проекта потерянные ресурсы (обозначенные красным цветом в дереве Xcode-проекта) и снова присоединить их к проекту уже из их новых папок. Теперь с ресурсами всё выглядит более логично и организованно.

 

Quartz-рисование в отдельном потоке


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

Из основного потока вы можете нажать какой-либо GUI-контрол (например кнопку или слайдер). Если нужно, то можно через изменение некоторых объектов (или даже простых bool переменных) попросить поток рисования изменить параметры рисунка или что-то в этом роде.

Есть одна очень существенная деталь, которую нужно помнить!

Ну само собой, нужно защищать переменные от одновременного изменения их значений из разных потоков одновременно. Для этого существуют различные средства синхронизации, pthread-мютексы (в C/C++), @synchronized-блоки (в Objective C).

Я хотел предупредить о другом. Сейчас я столкнулся с серьёзной проблемой. Оказывается, когда вы захотите сделать контекст (в который вы рисуете что-либо) текущим с помощью вызова функции UIGraphicsPushContext (и потом вернуть всё как было с помощью функции UIGraphicsPopContext) ТО ВАЖНО ЗНАТЬ, ЧТО ЭТИ 2 ФУНКЦИИ МОЖНО ВЫЗЫВАТЬ ТОЛЬКО ИЗ ОСНОВНОГО ПОТОКА ПРОГРАММЫ!

Мне нужно рисовать в контекст (не контекст экрана, а контекст в памяти) текст. Если я не сделаю этот контекст текущим, то текст в результате не нарисуется. Проблема в том, что я должен рисовать текст в отдельном потоке рисования. Из-за этого я вынужден из этого отдельного потока просить главный поток программы делать вызовы этих 2-х функций (UIGraphicsPushContext и UIGraphicsPopContext) и ждать каждый раз пока главный поток не соизволит это сделать (а главный поток может быть занят в это время чем-то важным, как ему кажется). Это приводит к целому ряду проблем, которых можно было бы избежать, если я бы знал об этом заранее (это бы позволило предпринять некоторые меры при предварительном проектировании, ещё до того, как была написана первая строка кода). У меня сейчас даже случаются дедлоки (взаимные блокировки потоков).

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

 

Макрос _T при переносе Win32 проектов на iPhone


Как правило сейчас уже во всех Win32 (MFC) проектах такая строка в коде _T("Я люблю вас, девочки") воспринимается компилятором как L"Я люблю вас, девочки" (то есть как wchar_t строка).

Чтобы не перелопачивать код, который вам нужно портировать из Windows в iPhone, можете добавить в общий заголовочный файл (например, в исходники, где определены все макросы и константы) такое макроопределение:

#ifdef __IPHONE_3_1
#ifndef _T
#define _T(a) L##a
#endif
#endif


После этого вам должно стать хорошо и приятно :)

 

Проблемы с isnan функцией (при портировании кода Win32-приложения для iPhone)


Функции _isnan нет в iPhone OS (там должна быть функция isnan, включенная в math.h или cmath заголовки), поэтому я делаю такой трюк:

// где-то наверху файла
#ifdef __IPHONE_3_1
#include < cmath > // или #include < math.h >
#endif

// где-то в коде
#ifdef _WIN32
if(_isnan(val))
#elif defined(__IPHONE_3_1)
if (isnan(val))
#endif

//////////////////////////////////
// увы, иногда < cmath > или < math.h > бессильны нам помочь (мистика?),
// и тогда делайте так в одном месте, где-нибудь в общем заголовке:

#ifdef __IPHONE_3_1
#define _isnan(x) \
( sizeof (x) == sizeof(float ) ? __inline_isnanf((float)(x)) \
: sizeof (x) == sizeof(double) ? __inline_isnand((double)(x)) \
: __inline_isnan ((long double)(x)))
#endif //__IPHONE_3_1


Если вы хотите, чтобы #ifdef __IPHONE_3_1 условие точно срабатывало, то один из способов гарантировать это - сделать cpp файл типом objcpp (в свойствах файла, если щёлкнуть по имени файла в дереве Xcode-проекта). С заголовочными файлами обстоит немного посложнее, но если заголовочник уже включен в cpp-файл, с которым вы сделали как я советую, то обычно всё в порядке будет и в заголовочном файле.

 

Прошёл сегодня первый тест по C++ на сайте www.odesk.com


Прошёл сегодня свой первый тест по C++ на сайте www.odesk.com. Результаты получил не самые впечатляющие. Но есть надежда, что через месяц я сдам такой же тест лучше. Думаю, что такая система позволяет измерить уровень подготовки программиста в той или иной области. Вот что мне выдала система:

Passing Score: 2.50      Your Score: 2.75      Grade: Pass


Results by Topic

     Topic         Correct Answers(%)
1.     Classes                       57%
2.     Constructors and Destructors                       86%
3.     Exceptions and Exception Handling                       0%
4.     Functions and Virtual Functions                       75%
5.     Inheritance and Object Oriented Concepts                       67%
6.     Miscellaneous                       0%
7.     Operator Overloading                       75%
8.     Pointers and File Handling                       0%
9.     Standard Template Library, Directives and Macros                       50%
10.     Syntax and Language Fundamentals                       40%

Congratulations!!

By passing this test, you have joined the elite league of individuals who have demonstrated a high level of proficiency in their chosen area.

 

В сообществе фанатов Apple решили, что iPad нуждается в улучшениях


Материал взят из http://hitech.newsru.com/article/24may2010/ipadvsapplefans

В сообществе фанатов продукции Apple полагают, что весь потенциал планшетного компьютера iPad может быть раскрыт только с обновлением операционной системы iPhone OS, сообщает СОТОВИК.ру.

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

Основной же проблемой называют слабость базы iPad-приложений: далеко не все готовы удовольствоваться двукратно масштабируемыми на 9,7-дюймовом экране приложениями для iPhone - ну разве что те, у кого зрение не столь остро.

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

Жесткая привязка к iTunes для загрузки приложений и цифрового контента несколько напрягает, хотя всегда есть альтернативные варианты "джейлбрейка", как называют взлом защиты в устройствах Apple.

Планшетник iPad, очевидно, позиционируется Apple как инструмент для потребления контента, а не его создания. Это нашло отражение в приложениях офисного пакета iWork, в котором возможности по вводу данных и их форматирования оказались изрядно урезаны.


 
 
 

Finger Piano Share: 10 пианистов в одном iPhone


Материал взят из http://www.ru-iphone.com/soft

Компания Yamaha совместно с двумя партнерами выпустит приложение для iPhone, которое позволит одновременно 10 пользователям играть на виртуальном пианино. Finger Piano Share, именно так называется этот продукт, разрабатывался под руководством японской компании Densan System. После запуска приложения на экране появятся виртуальные клавиши пианино, а размещенные подсказки будут направлять пользователей в игре на музыкальном инструменте.

Программа может быть подключена к MIDI-клавиатуре Yamaha через Интернет, то есть с помощью iPhone можно удаленно управлять MIDI-синтезатором. Работать с приложением могут одновременно до 10 человек, подчеркнул Ацуко Ито (Atsuko Ito), руководитель центра развития звуковых технологий в Yamaha (Yamaha Center for Advanced Sound Technologies).

Кроме того, Finger Piano Share совместимо с приложением Sekai Camera, разработанным токийской фирмой Tonchidot. Оно определяет местоположение устройства с помощью модуля GPS и предоставляет пользователю информацию, связанную с этой географической точкой во время просмотра через камеру.


 

Аналог Sleep (Win32) функции в Mac OS (iPhone OS)


Материал взят из http://www.gamedev.ru/code/forum/?id=92177

Названия функций я поменял, чтобы уменьшить вероятность конфликта имён.

Спасибо разработчикам QT.



#
ifndef QTSLEEP_H
#define QTSLEEP_H

#include < pthread.h >
#include < sys/time.h >

static void qt_thread_sleep(struct timespec *ti)
{
pthread_mutex_t mtx;
pthread_cond_t cnd;

pthread_mutex_init(&mtx, 0);
pthread_cond_init(&cnd, 0);

pthread_mutex_lock(&mtx);
(void) pthread_cond_timedwait(&cnd, &mtx, ti);
pthread_mutex_unlock(&mtx);

pthread_cond_destroy(&cnd);
pthread_mutex_destroy(&mtx);
}

void qt_sleep(unsigned long secs)
{
struct timeval tv;
gettimeofday(&tv, 0);
struct timespec ti;
ti.tv_sec = tv.tv_sec + secs;
ti.tv_nsec = (tv.tv_usec * 1000);
qt_thread_sleep(&ti);
}

void qt_msleep(unsigned long msecs)
{
struct timeval tv;
gettimeofday(&tv, 0);
struct timespec ti;

ti.tv_nsec = (tv.tv_usec + (msecs % 1000) * 1000) * 1000;
ti.tv_sec = tv.tv_sec + (msecs / 1000) + (ti.tv_nsec / 1000000000);
ti.tv_nsec %= 1000000000;
qt_thread_sleep(&ti);
}

void qt_usleep(unsigned long usecs)
{
struct timeval tv;
gettimeofday(&tv, 0);
struct timespec ti;

ti.tv_nsec = (tv.tv_usec + (usecs % 1000000)) * 1000;
ti.tv_sec = tv.tv_sec + (usecs / 1000000) + (ti.tv_nsec / 1000000000);
ti.tv_nsec %= 1000000000;
qt_thread_sleep(&ti);
}

#endif

 

Дешевые издания приближают конец книги


Материал взят из http://business.ngs.ru/article/64771/

Интервью с издателем и известным специалистом по маркетингу Игорем Манном
Кризис привел к обрушению многих крупных компаний. Как оказалось, наличие средств и даже так называемого «административного ресурса» совсем не гарантирует бизнесу безоблачного будущего. О том, что должен делать отдел маркетинга, чтобы этого не случилось, и почему это ему порой не удается, НГС.БИЗНЕС поговорил с известным специалистом по маркетингу Игорем Манном.

Справка: Игорь Манн — совладелец издательства «Манн, Иванов и Фербер», специализирующегося на бизнес-литературе. Работал руководителем маркетинговых подразделений российских филиалов компаний Konica Corporation, Alcatel-Lucent, Арктел, «МИАН» (ныне Kopernik Group).

Первый вопрос к вам как к издателю. Как долго, по-вашему, проживут привычные бумажные книги?

Думаю, книга умрет тогда, когда школьники перестанут на уроках пользоваться учебниками и тетрадками, а перейдут на ноутбуки, планшетные компьютеры или что-то в этом роде. Но трудно спорить — перспективы этого рынка под угрозой. Даже лицензионная электронная версия книги уже сегодня обойдется дешевле печатной как минимум в 5–7 раз. Устройства для чтения тоже дешевеют. Так что уже скоро покупка «одноразовых» книжек, которые используются, чтобы убить время, потеряет смысл. Но это не значит, что исчезнет книга как таковая — она может перейти в разряд предмета интерьера, дорогой игрушки, как сигара, дорогие часы и т.д. Дорогие издания смогут находить спрос еще довольно долго. Мы к этому готовимся и уже сейчас пытаемся сделать книгу чем-то большим, чем просто источник информации. Это касается и общего дизайна, и каких-то фишек в оформлении.

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

Слову «маркетинг» в русском языке уже больше 20 лет…

Если быть точным, то где-то 40. В 1971 году появилась первая книга со словом «маркетинг» на обложке.

Тем более. Однако до сих пор этим словом называют в разных компаниях очень разные вещи. Что же все такие это такое? У вас есть для него четкое определение?

У меня нет. Может быть, 10 лет назад я и смог бы привести вам какую-то умную цитату известного ученого, но сейчас сказать просто, что такое маркетинг, я уже не смогу. Есть универсальное определение, подходящее для большинства российских компаний, — это приобретение и удержание клиентов.

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

Кто лучший маркетолог — сам бизнесмен или нанятый специалист?

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

Есть очень хорошие слова основателя компании Hewlett Packard о том, что маркетинг слишком важная вещь, чтобы поручать его отделу маркетинга.

Полезно ли для дела, если владелец бизнеса публичная фигура, или это просто следствие тщеславия и бизнес тут не причем?

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

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

Если вы знаете первое лицо бизнеса, вы понимаете к кому нужно обращаться, если у вас возникнут с этим бизнесом какие-то проблемы. У Олега Тинькова, например, есть блог, в который вы всегда можете написать о каких-то претензиях к его банку «Тинькофф Кредитные Системы». Это совершенно иной уровень взаимодействия.

Но почему одни предприниматели не слезают со страниц газет, а из других слова не вытянешь?

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

 

Ещё одно мнение об уровне квалификации программистов


Информация взята из http://anton.shevchuk.name/project-management/developers-rank/

Junior Developer

  • оптимист, всегда недооценивает поставленную задачу
  • постоянно ощущает нехватку времени
  • стесняется показать свое незнание
  • постоянно наступает на грабли
  • с трудом доводит проект до финальной точки
  • тестер – враг – ибо находит баги
  • менеджер – не воспринимается еще всерьез
  • пока не ориентируется по ЗП, но если ему предложат на $50 больше в другом месте – может уйти
  • рутинную работу считает сложной, но должен справляться

Developer

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

Senior Developer

  • реалист, опираясь на свой опыт, видит "узкие" места проекта и закладывается на риски, а так же сообщает об этом менеджерам
  • успевает и делать проект, и посидеть на "митингах", и еще и подсказывать коллегам
  • может помочь ближнему, не стесняется сказать, что он чего-то не знает
  • если и наступает на грабли – то тут два варианта:
    1. "грабли" – легли в риски, и все проходит безболезненно
    2. "грабли" – наносят критический урон по проекту, ибо Senior допустил ошибки при разработки архитектуры (иль еще где, но не менее фатально)
  • удачно завершенный проект – доставляет истинное удовольствие (и психологическое и материальное)
  • тестер – советник в плане юзабилити
  • менеджер – щит, который тоже не любит неадекватного заказчика
  • хорошо знает себе цену, не стесняется требовать повышения ЗП
  • прекрасно понимают, что работа может быть рутинной, но это не должно влиять на качество кода, может ворчать, но работу будет делать

Если Вы располагаете достаточным количеством ресурсов, и при этом в наличии как Junior’ы так и Senior’ы – то судьба проекта может сильно зависеть от состава команды, так что будьте внимательны:

  • не стоит ставить Junior’а к зубрам программирования, если среди них нет человека способного заняться его обучением: и новичок ничему не научиться, и “зубры” будут в бешенстве
  • если проект разрабатывается лишь Junior’ами – держите руку на пульсе такого проекта и купите валерьянку – себе и заказчику ;)
  • не стоит садить Senior’а за проект уровня “для чайников” – проект будет сделан и сдан, вот только разработчик от скуки начнет думать о работе в другом месте

Ну и еще немного информации к размышлению:

Ошибки которые совершают разработчики, когда начинают задумываться о повышении ЗП:

  1. Переоценивают себя – требовать ЗП не соответствующую Вашему уровню – это верный путь остаться без работы
  2. Устраивать сыр-бор за 10% прибавку к ЗП – зачастую такое повышение можно решить без лишнего шума и криков
  3. Узнать, что через дорогу платят на 100$ больше, впасть в депрессию на пару недель, и оказаться на улице, ибо повышать ЗП человеку который последнее время ничего не делает никто не будет – это очень распространенная ошибка, никогда не забивайте на работу, будьте профессионалами.
  4. Считать, что в соседней конторе работа в 100 раз интересней.

 

Сравнение строк вне зависимости от регистра символов


Данную функцию можно использовать для сравнения строк в C++ коде (главное, не забыть в дереве Xcode-проекта выставить тип C++ исходника как cpp.objcpp).

bool InsensitiveCompareStrings
(const char* left, const char* right)
{
NSString *leftTitle =
[NSString stringWithUTF8String:left];
NSString *rightTitle =
[NSString stringWithUTF8String:right];
return (NSOrderedAscending == [leftTitle
localizedCaseInsensitiveCompare:rightTitle]);
}


Функция хороша тем, что класс NSString в отличие от std::toupper позволяет отсортировать в правильном порядке даже символы русского алфавита (то есть маленькая русская а будет стоять раньше большой Я).

1 |2 |3