На самом деле, Евегений, да. Потому что, к примеру, напоминатель привязанный к БС я пока не видел, только та программеха с профилями. А это было бы гораздо интереснее. Кстати, может кто из присутвующих подскажет, есть в какой из версий (JSR i mean) J2ME возможность получения CellId?
«мобильные телефоны с поддержкой Java (J2ME), например Sony Ericsson (в ближайшее время).»
так что в «ближайшее время» 3тр за телефон c BT + 3тр за BT-GPS )) где то -так, а пока нокиа с симбианом + bt-gps
тут правильно сказали, в основном «Все эти системы пользы не приносят» основной плюс для вас — снижение оплаты по КАСКО (а иногда это просто требование — установка такоих систем), какой процент имеют страховые от компаний-операторов систем «гугль молчит» )))
>Как директор ит компании и пм с 5+ летним опытом согласен с вами что «опытный» пм в 26 лет это нонсенс.
кстати, 5 лет — это уже хороший опыт, но тогда я вам сочувствую, потому, что руководить в 21 — после института, без реального опыта работы, это наверняка было весьма тяжело
основная проблема (не Ваша, а вообще )) к сожалению), что люди что то слышали про эжайл, пытаются применить какие -то методологии, а потом говорят «ничего не работает»
я поэтому спрашивал по конкретную реализацию.
К примеру, нельзя применять XP частично, потому что осутствие документации заменяет общение в одной комнате, а доп тестрование — парное программирование. Отмените одно — все посыпится. В Вашем случае хорошо мог работать, вероятно, FDD. Он представляет собой иерархическую схему отвтевенности, в отличии от сетвой в XP (что у Вас вообще не могло работать в распределенной команде) или Scrum.
Многие беды происходят от путаницы в терминах. Ваши hi-level идеи меня вообще слегка шокируют. Я Вам привел основные постулаты Aglie — т.н. Манифест Гибкой Разработки, в котором черным по белому написано о важности команды, Вы в статье пишете о том, что люди «не понимали и не принмали» и после этого удивляетесь провалу.
Agile — это не анархия.
>«быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»
А что, в RUP по-другому???? Это основа всех итеративных процессов разработки.
На хабре существует тайное общество моих поклонников, минусующих все мои комментарии ))), очевидно, им претит идея профессионализма как такового, которую я пытаюсь отстаивать, но тем не менее, прежде чем все смешивать в одно и делить на две неравные кучи «эжайл» и «уотефол» может стоит разобраться в сущности подходов. Почему они такие, что решают и где нужны?
habrahabr.ru/blogs/pm/51929/#comment_1377660
это кстати не вполне верно
«принципы agile»
Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им — они выполнят работу.
Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром — непосредственное общение.
Работающее ПО — главный индикатор продвижения проекта.
Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
Важна простота — искусство увеличения объема работ, которых удалось избежать.
Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.
основной признаки мотивированная самоорганизующаяся команда. положа руку на сердце — она у вас была? и это эжайл? или все-таки путаница в терминах?
может в этом проблема? вообще говоря, как директор it компании могу сказать, что «опытный пм» в 26 лет это нонсенс. так что, в целом, ничего удивительного.
о! нашел ru.wikipedia.org/wiki/Лампа_накаливания «Современные лампы заполняются буферным газом (кроме ламп малой мощности, которые по-прежнему делают вакуумными)» — дело в том, что в книге идет речь об использовании именно маломощной ламны — 25Вт
или лампочки были другие или не мешает.
вообще, да, интересный вопрос. меня терзают смутные сомнения, что они и в самом деле были вакуумные, но технологию сменили и сейчас заполняют инертным газом, для уменьшения испарения с вольфрамовой нити. если так, что насос все -таки понадобится. или можно приспособить радиолампу — там точно вакуум.
так. ладно. вернемся к исходой точке.
статьи о режимах дня, написанные непрофессионалами, без реального опыта использования (полгода максимум) могут быть по-настоящему опасны.
собственно, весь трэд комментариев вызван скорее ими, а не нашим милейшим доктором и аппаратом Рентгена.
www.google.com/search?rls=ru&q=pda+gps+reminder&ie=utf-8&oe=utf-8
:-)))
б) есть приложения для смартфонов, переключающх профиль в зависмости от привязки к БС (пришел на работу --звук выключился). не совсем то но похоже
так что в «ближайшее время» 3тр за телефон c BT + 3тр за BT-GPS )) где то -так, а пока нокиа с симбианом + bt-gps
кстати, 5 лет — это уже хороший опыт, но тогда я вам сочувствую, потому, что руководить в 21 — после института, без реального опыта работы, это наверняка было весьма тяжело
посмотрел ваш жж.
вы же все это прекрасно и сами знаете )) на личном опыте.
Мне, кстати, нравятся Ваши посты. Еще раз, спасибо.
я поэтому спрашивал по конкретную реализацию.
К примеру, нельзя применять XP частично, потому что осутствие документации заменяет общение в одной комнате, а доп тестрование — парное программирование. Отмените одно — все посыпится. В Вашем случае хорошо мог работать, вероятно, FDD. Он представляет собой иерархическую схему отвтевенности, в отличии от сетвой в XP (что у Вас вообще не могло работать в распределенной команде) или Scrum.
Многие беды происходят от путаницы в терминах. Ваши hi-level идеи меня вообще слегка шокируют. Я Вам привел основные постулаты Aglie — т.н. Манифест Гибкой Разработки, в котором черным по белому написано о важности команды, Вы в статье пишете о том, что люди «не понимали и не принмали» и после этого удивляетесь провалу.
Agile — это не анархия.
>«быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»
А что, в RUP по-другому???? Это основа всех итеративных процессов разработки.
На хабре существует тайное общество моих поклонников, минусующих все мои комментарии ))), очевидно, им претит идея профессионализма как такового, которую я пытаюсь отстаивать, но тем не менее, прежде чем все смешивать в одно и делить на две неравные кучи «эжайл» и «уотефол» может стоит разобраться в сущности подходов. Почему они такие, что решают и где нужны?
это кстати не вполне верно
«принципы agile»
Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им — они выполнят работу.
Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром — непосредственное общение.
Работающее ПО — главный индикатор продвижения проекта.
Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
Важна простота — искусство увеличения объема работ, которых удалось избежать.
Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.
основной признаки мотивированная самоорганизующаяся команда. положа руку на сердце — она у вас была? и это эжайл? или все-таки путаница в терминах?
может в этом проблема? вообще говоря, как директор it компании могу сказать, что «опытный пм» в 26 лет это нонсенс. так что, в целом, ничего удивительного.
:-)
«Современные лампы заполняются буферным газом (кроме ламп малой мощности, которые по-прежнему делают вакуумными)» — дело в том, что в книге идет речь об использовании именно маломощной ламны — 25Вт
вообще, да, интересный вопрос. меня терзают смутные сомнения, что они и в самом деле были вакуумные, но технологию сменили и сейчас заполняют инертным газом, для уменьшения испарения с вольфрамовой нити. если так, что насос все -таки понадобится. или можно приспособить радиолампу — там точно вакуум.
__
Только Agile и Waterfall? RUP с кучей модификаций совсем не катит?
статьи о режимах дня, написанные непрофессионалами, без реального опыта использования (полгода максимум) могут быть по-настоящему опасны.
собственно, весь трэд комментариев вызван скорее ими, а не нашим милейшим доктором и аппаратом Рентгена.