gleb_kudr

Общее решение задачи следующее (в реальной работе):

Подготовка:

1. Разбиваем менеджеров на группы 1,2,3 и т.д. Каждый менеджер может быть и в нескольких группах.
2. К каждой группе применяем фильтр. Например, в группу 1 могут попасть только заявки с бюджетом N, а в группу 2 — только двухкомнатные квартиры. Фишка в том, что фильтры могут пересекаться, ничего страшного в этом нет.
3. Группы выстраиваются в очередь. В начале — та, которая дольше всех не получала заявки.

Теперь алгоритм:
1. Приходит новая заявка.
2. Примеряется к условию попадания в группу, первую по очереди. Если ок — то заявка поступает в группу, а группа уходит в конец очереди. Если нет, то выбирается следующая за ней и так далее. Та группа в которую попала заявка улетает в конец очереди.
3. Если заявка попала в группу, то конкретный менеджер из группы назначается просто по-очереди. Опять же, когда он принял заявку, то попадает в конец (уже в этой группе). Если он не взял заявку в течение определенного времени, то она поступает в пул доступных для свободного взятия. Если менеджер присутствует в разных группах, то он продвигается по очереди в них независимо!

Зачем так сложно? Дело в том, что менеджеры разные по способностям. Нельзя слабых менеджеров сажать на жирных клиентов. В то же время, передвижение в жирные группы — серьезная мотивация работать лучше. Такая система дает хорошую равномерность распределения + оставляет простор для мотивации путем ротации персонала между группами. Ну и абсолютная прозрачность.

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

В iOS для этого используется KeyChain, быстрым гуглом находится аналог и для андроида developer.android.com/reference/android/security/KeyChain.html Насколько он юзабелен и безопасен — не знаю.

Групповая работа эффективнее только в очень маленьких группах. 2-3 человека. Больше начинаются сильные потери на взаимодействии. Главное явно выделить среди них ответственного, за которым будет последнее слово по техническим решениям.
Мобильные проекты обычно небольшие — они могут позволить себе роскошь разрабатывать сверхмалой командой, нужно этим пользоваться.
Одиночек на проекты лучше не ставить — вы до небес увеличиваете риски связанные с уходом/болезнью и т.д. + пара действительно друг друга мотивирует.

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

1. Крыльчатка кулера. Фишка — гнутые тонкие поверхности.
2. Корпус любого устройства. Т.е. тонкостенная коробка с дырками под винты. Попробовать напечатать коробку с пластиковыми защелками (ни разу не видел, возможно ли?).
3. Какой-нибудь набор шестеренок. Например планетарная + 4 внутри (печатать раздельно конечно).

Чертежей нет, к сожалению и моделлер из меня очень хреновый.

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

Языки разработки — нативный Objective-C, C# — Xamarin, PhoneGap (js & html5). Лично я начал сразу с Xamarin и уходить с него не собираюсь.

Стоит начать с того, что есть как минимум два класса таймера для работы в .net — System.Timers.Timer
и System.Threading.Timer. Нужно указать, какой используете вы.

По дизайну я бы завел один таймер на все объекты. Заставил бы его крутиться в фоновом потоке. Каждые N миллисекунд он бы вызывал процедуру обработки массива точек.
На каждом тике проход по всем элементам и проверка, не подошло ли время обработки. Если время обработки подошло — апдейт элемента в UI треде и назначение следующего времени обработки.
Назначение по таймеру на каждый элемент мне не нравится — можно задолбаться потом с тредами и их взаимодействием.

Заинтересовался проблемой и полез гуглить. Информации действительно мало, попробуйте начать отсюда

>http://stackoverflow.com/questions/3901659/how-to-send-data-from-iphone-over-wifi-to-application-to-print-message

Было бы очень полезно, если вы потом поделитесь опытом о том, решили ли задачу (и если решили, то как).

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

Я вот подобный список бы расписал:

1. Недопустимы ошибки, приводящие к нештатному завершению работы программы (вылеты по памяти, всякие критикал рантайм эксепшны). Приписать сценарии, в которых они допустимы (вряд ли это возможно в релизной версии, но в бете может быть).
2. Что будет если все-таки программа нештатно завершила работу, потеряются ли данные. Вообще, что будет с данными, сохранением состояния. Это надо прописать.
3. Работает ли программа везде или только там где есть связь. Какие требования к качеству связи, скорости соединения.
4. Необходимые функции устройства, которые нужны для работы. Акселерометр, камера, etc.

YouTrack (джава, не пхп). Фришная версия до 10 человек.

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

Встречал контролы под WPF. Ну и как вариант — встроить веб браузер и использовать JS контролы.

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

Для хоткеев советую поставить программу Spark www.macupdate.com/app/mac/14352/spark, она бесплатная.
Вот, например, моя раскладка (в системных настройках клавиатуры специальные функции F-клавиш отключены)

www.sqlite.org/backup.html вот доки по методам SQLite для репликации. Самое лучшее решение.
Ну или на уровне файловой системы.

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

Шаблон примерно такой:

1. Бизнес-задача. Человеческим языком объяснить, зачем это нужно.
2. Бизнес-кейсы. «Зачем» облекаем в «как». Сценарии работы.
3. Дизайн, учитывая п. 2

Можно пользоваться методикой «что, где, когда, как». Просто, последовательно раскрываем эти вопросы.

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

У меня 15', та же проблема. Мне кажется, это у них по жизни. Разбирал, собирал (думал, пыль) — ничего подобного.

Могу посоветовать написать техническому директору на ez@megaplan.ru или через фейсбук, он отвечает.