ИМХО
Идеальных людей нет. И не будет. В канцелярии так и сказали. Например, умение приходить к 9 и уходить в 18 — обозначает лишь то, что вы умеете приходить к 9 и уходить к 18. Каких-то сверхсил это не дает. Если вы программер, то ваш код от этого лучше явно не станет (если вы конечно, не наиболее эффективны во временном промежутке от 10 до 14). Если вы ПМ, то с некоторыми клиентами могут даже возникнуть серьезные проблемы. Потому что они привыкли работать по другому графику, и их не очень сильно волнует ваш распорядок дня. А постоянно работать по 12 часов в день не просто плохо — это еще и серьезный износ здоровья как физического, так и духовного.
Если смотреть глазами программиста.
То данный ПМ — просто фуфло. Стабильности никакой. Обнадеживает попусту. Постоянно письма пишет и языком молотит. Никакого планирования (так чтобы до минут знать всю будущую неделю). Дисциплина вообще напрочь отсутствует. Вообщем негодяй первой степени.
Но по каким-то причинам ПМ остается ПМ-мом, а программист программистом.
С точки зрения ПМ.
Все выглядит несколько подругому. Мы не берем ПМ на проектах, где все хорошо получается. И заказчик дает собой управлять, и неожиданности укладываются в предполагаемый разброс, и имеющиеся ресурсы практически полностью покрывают необходимости, и вообще погода на улице хорошая. Сразу оговорюсь. Я не подразумеваю того, что описанная мной хорошая ситуация не требует усилий, умений и знаний.
Итак. Есть забугорный заказчик. И его явно не волнует, что исполнитель в россии. Скорее всего это даже по договору прописано. Видно, что его представители достаточно капризные. Плюс заказчик умеет считать деньги, и понимает их ценность. Но самое главное — он оплачивает труд всей команды. А это достаточно неплохая сумма.
Уже из общей ситуации видно, что график 9-18 «фтопку». Умеет считать деньги -> слова «концептуальность», «передовые технологии» и т.д. «фтопку» (потому что перевозить коробку с лекарствами можно и на обычной машине, без функций аля «массажного кресла водителя»). Капризные -> обвинять его в чем-то или идти на прямой конфликт нельзя (очень плохо, когда рассерженный капризный мальчик сидит за пультом управления полетами). Ненормированная ситуация (часто меняются требования, приоритеты и т.д.) -> какой план тут составишь? Только гибкий.
Если смотреть с этой точки зрения, то ПМ хоть и имеет недостатки (а кто без них), но справляется с задачей (сделать проект, если вы забыли).
С точки зрения владельца или директора компании исполнителя.
Почему он оставляет ПМ на месте, а разработчика оставляет разработчиком? Потому что ПМ умеет управлять ситуацией и людьми так как требует ситуация (в том или ином виде), а не так как он видит. Это очень большая разница. И делает он это в ущерб своей личной жизни. Остальное оставим за кадром (а то точно начнутся обиды).
С точки зрения клиента.
Он платит. И вообще-то, ну так между делом, этот проект нужен ему для решения его целей, а не целей кого-либо из исполнителей.
«1. принято, согласен.»
Простите, не удержусь. Ну ооооооочень похоже на «Одобрено РОСКОМСТАТ». :)
З.Ы. Без обид.
«2. всё так. Но нужно помнить»
Я не спорю. А привожу примеры. Просто хочу показать, что Вы делаете «хорошо и в срок», но со своими рюшечками.
А статья на самом деле приводит одно из следствий. Вернее один из примеров, который возник из ситуации и целей. Просто данная ситуация — частая ошибка.
Все происходит из конкретной ситуации и поставленных целей. В случае, если бы представители заказчика были бы «против» (по своим причинам), такой подход бы не подошел. Потому что Вы бы устали искать все возможные подробности. Потому что расчитываете на то, что представители «заинтересованы». А они будут как «террорист на допросе», по лишним поводам молчать. И тут уже надо вести другую игру.
Но суть все равно одна и таже. Вы оцениваете ситуацию и ставите цели. И в зависимости от этого тандема действуете.
P.S. Я ни в коем случае не утверждаю, что статья плохая. И безусловно она полезна. Просто пытаюсь показать, что растет это все немного из другого.
Представители заказчика и инициатор — это легко могут быть разные люди. Поэтому бедную секретаршу никто и не вспоминал. У нее совершенно другие задачи, правда, если Вы не автоматизируете ее работу.
«Чтобы сотрудничество было более эффективным»
Так Вы и пишите о том, что не ждете от заказчика понимания Вашей работы. Соответственно, Вы его сами обучаете, чтобы сделать свою работу «хорошо и в срок». Потому что предвидите ряд возникающих проблем в будущем, которые легко возникнут, если Вы не поймете друг друга на начальных этапах. Хотя достигнуть этого можно по разному. Не обязательно окунаться в обучение. Например, можно самому понять язык заказчика, и общаться на нем.
Я не совсем про то. Это всего лишь один из примеров. При этом даже в этом примере, ни слова не сказано, что проект Вам не нравится. И что Вы считаете заказчика плохим. Просто на стороне заказчика люди. И они могут иметь свою специфику. И далеко не всегда Вы работаете с инициатором, у которого глаза горят от мысли о продукте.
«Сделал, слил, поднял бабла». Хочу Вас расстроить. Вы делаете тоже самое. Вы получаете работу. Вы ее делаете. Заливаете и получаете деньги. Это просто суть. Другое дело, что Вы добавляете к этому. Вы добавляете желание «в этом разобраться и сделать отлично».
Кстати, в Ваших же примерах, Вы тоже делаете по принципу «Ваша задача — сделать».
Логика та же самая. Просто Вы подходите к вопросам «хорошо и сроки» с другой стороны.
Вы не требуете от заказчика чего-то. Каких-то знаний или пониманий процесса разработки. Вы ищите другие способы решения задачи.
Вот смотрите. Вы когда начинаете что-то делать, то представляете себе какие-то цели. И в зависимости от этих целей и результат получается разный. Если вы, например, занимаетесь нудными для вас вещами, то и скорее всего он будет сделан средним образом. Это не плохо или хорошо. Это результат. Потому что в Вашей голове скорее всего будет одна мысль «избавиться побыстрее». Как бы Вы не маскировали эту мысль.
Но вот если Вашей целью будет что-то другое, например, «чудо работа», то и результат будет другим. Но и времени он может затратить больше. Разница видна, просто подставьте любые дела из своей работы.
Т.е. есть цели, и у них соответствующие результаты.
По моему мнению, изначальный плохой вариант ведения дел складывался следующим образом:
Руководитель со стороны исполнителя хочет сделать хорошую вещь. Но, не просто сделать хорошую вещь. Он хочет работать с профессионалами. Чтобы во всех смыслах можно было сказать, что он как руководитель — профессионал. Ничего плохого в желаниях нет.
Соответственно, когда он рассматривает ситуацию, то видет, что заказчик — профессионал (так это или не так — не важно). И ждет от него профессионализма. Но подвох в том, что заказчик может и профи в своем деле. Но, он может быть слепым котенком в других областях. И не факт, что он будет это показывать (пример, «я же профи!»). А так же не факт, что он будет вообще понимать Вас, но будет желать показать это. Поэтому информация будет неполной, искаженной и возможно вообще неверной на корню.
Поэтому получится следующая ситуация:
Вроде как все профи. А хрень на выходе:)
А вот если Ваша задача не содержит дополнительных слов и определений. Т.е. например, выкопать яму 3 на 3. Это значит выкопать яму 3 на 3. А не «выкопать яму 3 на 3 с музыкой в стиле регги на фоне растяжного билборда с изображением Ямайки».
А вот если бы задача изначальна была проще «Хорошо сделать свою работу, и в срок». Уже в этой постановке нет ни единого требования к заказчику. Вы вообще не расчитываете на его уровень квалификации в Вашей области. Это требование Вас к Вам же.
Соответственно, с такой идеей Вы бы начали думать немного другой логикой.
Пример построения:
«Я хочу сделать хорошо и в срок» -> «мне надо убедиться, что потом не будет больших проблем, и заказчик не будет бегать и орать» -> «верна ли логика сейчас?» -> «заказчик несет хрень про шрифты» -> «Получу ка я у него письменное подтверждение по поводу того, что логика работы верная» -> Заказчик: «Ответственность! Емоё. Могут ведь потом дернуть. Посмотрю ка я логику. О! Вот тут не совсем верно. А тут круто!» -> «Ага. Надо изменить то-то и то-то»…
И результат будет другим. Потому что Вы просто хотите сделать.
ИМХ0
Идеального человека нет. И каждый допускает ошибки. И у каждого есть свои тараканы. Кто-то опаздывает. Кто-то материться. Кто-то молчун. Кто-то… И т.д.
Все познается в весах. Если человек приносит намного больше, чем его заморочки, то ничего страшного нет. Ну, ругается он периодически матом, но зато код пишет на высоком уровне.
И плюс, как многие уже здесь говорили, все зависит еще от окружения.
Это как в школе. Если ты не сделал ДЗ. Придешь на урок, то поставят 2. Если прогуляешь, то просто скажут «атата». На все попытки объяснить почему не сделал, но пришел, ставят 2. Отсюда и прогулы:) Двойки ведь отрабатывать надо;)
ИМХ0
В первом случае, простите, но подчиненный ничем не виноват. Ему поставили задачу сделать анализ, он и сделал.
Во втором случае. Вы работаете с родственником. Он хочет вам супер помочь, и поэтому излишне старается, чтобы каждый ресурс был выверен и нужен (то бишь сливки сливками). У меня такое подозрение, что Вы не до конца обрисовали ему чего же хотите. Вы уточняли ему какие именно параметры Вам нужны (например, статистика посещений и все)? Если нет, то он естественно сам добавил ряд параметров, и сидел и честно просматривал их. Вот Вы попробуйте его просто спросить по каким параметрам он пытался подбирать их. Мне кажется, что он Вам скажет кучу разных параметров. Соответственно, когда куча параметров — времени тратиться много.
Никто и не спорит о плюсах учета времени.
Просто в статье список «Но вам это противопоказано, если вы ...» читается так, как будто учет времени не используют только негодяи. Не более того.
«Но вам это противопоказано, если вы ...». А дальше идет список негодяев.
А как же творческие профессии? Тот же самый дизайнер. Или «Я вам нарисую за 1:17»?:)
Плюс никто не отменял махинации с таймлистом.
>> 5. Заверяете его, что будет дано время на рефакторинг.
Если Ваши слова расходятся с делом, то очень быстро Ваш программист перестанет Вам верить. А это файл на ранних стадиях.
ssleptsov
Единственно дополнил бы, что это средство работает только на MSSQL 2008 Enterprise Edition. На Standard это функциональность не поддерживается.
>> очень удобно читать хорошо написанные логи вместо того чтобы глядеть в базу
Дело привычки. Мне удобнее быстро написать несколько запросов в БД, и понять картину.
Кажется, я забыл описать один важный момент. Приложение предназначено для внутреннего использования. Естественно, на нем нет такой нагрузки как на неплохо посещаемом интеренет-ресурсе. Его задача решать внутренние задачи. Поэтому и можно иногда себя побаловать простыми и легкими решениями.
И за DOS-атаку просто оторвут руки пользователю.
apple_fan
Я с Вами согласен — это совсем не подходящее решение для нагрузочных систем. Я бы немного скорректировал Вас. Это применимо лишь для небольших и внутренних решений. Потому как внутреннее решение может быть сложным, но не требовать выдерживать большие нагрузки.
Denisio
Абсолютно с Вами согласен. В случае нагрузочного решения, наличие такого количества запросов к БД на каждый action — это смертоубийство.
Сколько в Вас агрессии.
Вы опять пытаетесь сравнить его с большими и многофункциональными средствами.
Как то Вы странно проектируете приложение, если Вы не можете понять при запросах, что происходило.
Геморрой в чем? В том, что есть хоть какая-то возможность понять, что происходило, нежели ее отсутствие?
Решение развивается постепенно, у него нет тех задания. Да вроде, пока все в рабочем порядке. И уже давно, а что?:)
Я тоже понимаю Вашу точку зрения. Но это не полноценное решение. Это способ получить функциональность до ее нормальной реализации.
Не относитесь так критично к этому. «Либо все, либо ничего». По мне, так лучше иметь хоть какую-то возможность посмотреть что было, и куда копать, нежели играть в слепого котенка.
Идет статья. В ней описывается, что это простой, ни разу не универсальный метод, который минимально и только минимально позволяет прикрыть Вас. Но все же позволяет прикрыть. И реализуется быстро.
И тут же начинается холивар на тему «что это за велосипед?!», «Где броня как у танка?!»
Просто мы с Вами смотрим с разных точек зрения.
Моя задача была быстро сделать минимальное логирование, которое позволит очень быстро разрешить ряд вопросов, если таковые возникнут. Потому что в попыхах выбирать систему логирования — тоже не самый лучший вариант.
Вы же смотрите с точки зрения того, что это должно быть сразу полноценное решение. И понятно, что при такой постановке задач «мое простое решение» — просто грубое вопиющее издевательство!
Это похоже как если бы на «простой способ разжечь костер в лесу» спорить о том, что это не способ для «работы плавильных печей!».
Ну так не нравится, напишите нормально. Так и скажите «он не подойдет как полноценное решение, так как многого нету, да и возможны ошибки при выходе за границы». Но и в тексте ответ, что это «НЕ полноценное решение».
И да, Вам оно не нужно. Так зачем язвить было?
Напоминаю, я сразу говорил, что этот метод не претендует на универсальность.
Вы требуете от него универсальности и сверхпроизводительности. Насчет работоспособности – работает.
1. Exception
2. Будет плохо
3. Безусловно согласен – это плохо
4. Расти будет быстро – как бамбук. Если применить логику, то можно найти.
5. Ничего
6. Не особо
Вы путаете понятия «work around» и конечный метод.
Тогда вопрос. А Вы знаете, почему Ferrari плохая машина? На ней мало картошки можно отвезти:)
Ну, честно. Это простое решение. Оно позволяет получить минимальную, НО функциональность. А это, кстати, больше чем 0. :)
Естественно, когда будет на это время, можно будет уже в спокойной и нормальной обстановке просмотреть имеющиеся решения. И выбрать наиболее подходящее с учетом задач.
Кстати, вопрос. А что Вы будете делать, если политика компании будет запрещать использование сторонних библиотек (ну бывает такое, не в моем случае, но все же)?
Как бы странно это не было, но самое, что, ни наесть, прямое.
Если брать абстрактно, то Вы, безусловно, правы. Но есть такая штука как реальность.
Просто подумайте над этим:
Люди почему-то до сих пор покупают российские машины, хотя есть огромное количество веских поводов этого не делать. Но они покупают, и они оказываются правы.
P.S. Попробуйте сами пообщаться с заказчиками, и не с теми, которые «в теме» передовых технологий. И я Вас уверяю, после некоторого числа, Ваши взгляды сильно изменяться.
ИМХО
Идеальных людей нет. И не будет. В канцелярии так и сказали. Например, умение приходить к 9 и уходить в 18 — обозначает лишь то, что вы умеете приходить к 9 и уходить к 18. Каких-то сверхсил это не дает. Если вы программер, то ваш код от этого лучше явно не станет (если вы конечно, не наиболее эффективны во временном промежутке от 10 до 14). Если вы ПМ, то с некоторыми клиентами могут даже возникнуть серьезные проблемы. Потому что они привыкли работать по другому графику, и их не очень сильно волнует ваш распорядок дня. А постоянно работать по 12 часов в день не просто плохо — это еще и серьезный износ здоровья как физического, так и духовного.
Если смотреть глазами программиста.
То данный ПМ — просто фуфло. Стабильности никакой. Обнадеживает попусту. Постоянно письма пишет и языком молотит. Никакого планирования (так чтобы до минут знать всю будущую неделю). Дисциплина вообще напрочь отсутствует. Вообщем негодяй первой степени.
Но по каким-то причинам ПМ остается ПМ-мом, а программист программистом.
С точки зрения ПМ.
Все выглядит несколько подругому. Мы не берем ПМ на проектах, где все хорошо получается. И заказчик дает собой управлять, и неожиданности укладываются в предполагаемый разброс, и имеющиеся ресурсы практически полностью покрывают необходимости, и вообще погода на улице хорошая. Сразу оговорюсь. Я не подразумеваю того, что описанная мной хорошая ситуация не требует усилий, умений и знаний.
Итак. Есть забугорный заказчик. И его явно не волнует, что исполнитель в россии. Скорее всего это даже по договору прописано. Видно, что его представители достаточно капризные. Плюс заказчик умеет считать деньги, и понимает их ценность. Но самое главное — он оплачивает труд всей команды. А это достаточно неплохая сумма.
Уже из общей ситуации видно, что график 9-18 «фтопку». Умеет считать деньги -> слова «концептуальность», «передовые технологии» и т.д. «фтопку» (потому что перевозить коробку с лекарствами можно и на обычной машине, без функций аля «массажного кресла водителя»). Капризные -> обвинять его в чем-то или идти на прямой конфликт нельзя (очень плохо, когда рассерженный капризный мальчик сидит за пультом управления полетами). Ненормированная ситуация (часто меняются требования, приоритеты и т.д.) -> какой план тут составишь? Только гибкий.
Если смотреть с этой точки зрения, то ПМ хоть и имеет недостатки (а кто без них), но справляется с задачей (сделать проект, если вы забыли).
С точки зрения владельца или директора компании исполнителя.
Почему он оставляет ПМ на месте, а разработчика оставляет разработчиком? Потому что ПМ умеет управлять ситуацией и людьми так как требует ситуация (в том или ином виде), а не так как он видит. Это очень большая разница. И делает он это в ущерб своей личной жизни. Остальное оставим за кадром (а то точно начнутся обиды).
С точки зрения клиента.
Он платит. И вообще-то, ну так между делом, этот проект нужен ему для решения его целей, а не целей кого-либо из исполнителей.
Простите, не удержусь. Ну ооооооочень похоже на «Одобрено РОСКОМСТАТ». :)
З.Ы. Без обид.
«2. всё так. Но нужно помнить»
Я не спорю. А привожу примеры. Просто хочу показать, что Вы делаете «хорошо и в срок», но со своими рюшечками.
А статья на самом деле приводит одно из следствий. Вернее один из примеров, который возник из ситуации и целей. Просто данная ситуация — частая ошибка.
Все происходит из конкретной ситуации и поставленных целей. В случае, если бы представители заказчика были бы «против» (по своим причинам), такой подход бы не подошел. Потому что Вы бы устали искать все возможные подробности. Потому что расчитываете на то, что представители «заинтересованы». А они будут как «террорист на допросе», по лишним поводам молчать. И тут уже надо вести другую игру.
Но суть все равно одна и таже. Вы оцениваете ситуацию и ставите цели. И в зависимости от этого тандема действуете.
P.S. Я ни в коем случае не утверждаю, что статья плохая. И безусловно она полезна. Просто пытаюсь показать, что растет это все немного из другого.
«Чтобы сотрудничество было более эффективным»
Так Вы и пишите о том, что не ждете от заказчика понимания Вашей работы. Соответственно, Вы его сами обучаете, чтобы сделать свою работу «хорошо и в срок». Потому что предвидите ряд возникающих проблем в будущем, которые легко возникнут, если Вы не поймете друг друга на начальных этапах. Хотя достигнуть этого можно по разному. Не обязательно окунаться в обучение. Например, можно самому понять язык заказчика, и общаться на нем.
«Сделал, слил, поднял бабла». Хочу Вас расстроить. Вы делаете тоже самое. Вы получаете работу. Вы ее делаете. Заливаете и получаете деньги. Это просто суть. Другое дело, что Вы добавляете к этому. Вы добавляете желание «в этом разобраться и сделать отлично».
Кстати, в Ваших же примерах, Вы тоже делаете по принципу «Ваша задача — сделать».
Логика та же самая. Просто Вы подходите к вопросам «хорошо и сроки» с другой стороны.
Вы не требуете от заказчика чего-то. Каких-то знаний или пониманий процесса разработки. Вы ищите другие способы решения задачи.
Но вот если Вашей целью будет что-то другое, например, «чудо работа», то и результат будет другим. Но и времени он может затратить больше. Разница видна, просто подставьте любые дела из своей работы.
Т.е. есть цели, и у них соответствующие результаты.
По моему мнению, изначальный плохой вариант ведения дел складывался следующим образом:
Руководитель со стороны исполнителя хочет сделать хорошую вещь. Но, не просто сделать хорошую вещь. Он хочет работать с профессионалами. Чтобы во всех смыслах можно было сказать, что он как руководитель — профессионал. Ничего плохого в желаниях нет.
Соответственно, когда он рассматривает ситуацию, то видет, что заказчик — профессионал (так это или не так — не важно). И ждет от него профессионализма. Но подвох в том, что заказчик может и профи в своем деле. Но, он может быть слепым котенком в других областях. И не факт, что он будет это показывать (пример, «я же профи!»). А так же не факт, что он будет вообще понимать Вас, но будет желать показать это. Поэтому информация будет неполной, искаженной и возможно вообще неверной на корню.
Поэтому получится следующая ситуация:
Вроде как все профи. А хрень на выходе:)
А вот если Ваша задача не содержит дополнительных слов и определений. Т.е. например, выкопать яму 3 на 3. Это значит выкопать яму 3 на 3. А не «выкопать яму 3 на 3 с музыкой в стиле регги на фоне растяжного билборда с изображением Ямайки».
А вот если бы задача изначальна была проще «Хорошо сделать свою работу, и в срок». Уже в этой постановке нет ни единого требования к заказчику. Вы вообще не расчитываете на его уровень квалификации в Вашей области. Это требование Вас к Вам же.
Соответственно, с такой идеей Вы бы начали думать немного другой логикой.
Пример построения:
«Я хочу сделать хорошо и в срок» -> «мне надо убедиться, что потом не будет больших проблем, и заказчик не будет бегать и орать» -> «верна ли логика сейчас?» -> «заказчик несет хрень про шрифты» -> «Получу ка я у него письменное подтверждение по поводу того, что логика работы верная» -> Заказчик: «Ответственность! Емоё. Могут ведь потом дернуть. Посмотрю ка я логику. О! Вот тут не совсем верно. А тут круто!» -> «Ага. Надо изменить то-то и то-то»…
И результат будет другим. Потому что Вы просто хотите сделать.
По всему тексту чувствуется одна мысль «Ваша задача — не сделать все по технологиям. Ваша задача — сделать.»
Идеального человека нет. И каждый допускает ошибки. И у каждого есть свои тараканы. Кто-то опаздывает. Кто-то материться. Кто-то молчун. Кто-то… И т.д.
Все познается в весах. Если человек приносит намного больше, чем его заморочки, то ничего страшного нет. Ну, ругается он периодически матом, но зато код пишет на высоком уровне.
И плюс, как многие уже здесь говорили, все зависит еще от окружения.
Это как в школе. Если ты не сделал ДЗ. Придешь на урок, то поставят 2. Если прогуляешь, то просто скажут «атата». На все попытки объяснить почему не сделал, но пришел, ставят 2. Отсюда и прогулы:) Двойки ведь отрабатывать надо;)
Предать АНАФЕМЕ!!!!
В первом случае, простите, но подчиненный ничем не виноват. Ему поставили задачу сделать анализ, он и сделал.
Во втором случае. Вы работаете с родственником. Он хочет вам супер помочь, и поэтому излишне старается, чтобы каждый ресурс был выверен и нужен (то бишь сливки сливками). У меня такое подозрение, что Вы не до конца обрисовали ему чего же хотите. Вы уточняли ему какие именно параметры Вам нужны (например, статистика посещений и все)? Если нет, то он естественно сам добавил ряд параметров, и сидел и честно просматривал их. Вот Вы попробуйте его просто спросить по каким параметрам он пытался подбирать их. Мне кажется, что он Вам скажет кучу разных параметров. Соответственно, когда куча параметров — времени тратиться много.
Просто в статье список «Но вам это противопоказано, если вы ...» читается так, как будто учет времени не используют только негодяи. Не более того.
А как же творческие профессии? Тот же самый дизайнер. Или «Я вам нарисую за 1:17»?:)
Плюс никто не отменял махинации с таймлистом.
Если Ваши слова расходятся с делом, то очень быстро Ваш программист перестанет Вам верить. А это файл на ранних стадиях.
Единственно дополнил бы, что это средство работает только на MSSQL 2008 Enterprise Edition. На Standard это функциональность не поддерживается.
>> очень удобно читать хорошо написанные логи вместо того чтобы глядеть в базу
Дело привычки. Мне удобнее быстро написать несколько запросов в БД, и понять картину.
И за DOS-атаку просто оторвут руки пользователю.
apple_fan
Я с Вами согласен — это совсем не подходящее решение для нагрузочных систем. Я бы немного скорректировал Вас. Это применимо лишь для небольших и внутренних решений. Потому как внутреннее решение может быть сложным, но не требовать выдерживать большие нагрузки.
Denisio
Абсолютно с Вами согласен. В случае нагрузочного решения, наличие такого количества запросов к БД на каждый action — это смертоубийство.
Вы опять пытаетесь сравнить его с большими и многофункциональными средствами.
Как то Вы странно проектируете приложение, если Вы не можете понять при запросах, что происходило.
Геморрой в чем? В том, что есть хоть какая-то возможность понять, что происходило, нежели ее отсутствие?
Решение развивается постепенно, у него нет тех задания. Да вроде, пока все в рабочем порядке. И уже давно, а что?:)
Ладно, давайте прекратим этот бессмысленный спор.
Не относитесь так критично к этому. «Либо все, либо ничего». По мне, так лучше иметь хоть какую-то возможность посмотреть что было, и куда копать, нежели играть в слепого котенка.
Пожалуйста:)
Если немного пересказать все выше сказанное:
Идет статья. В ней описывается, что это простой, ни разу не универсальный метод, который минимально и только минимально позволяет прикрыть Вас. Но все же позволяет прикрыть. И реализуется быстро.
И тут же начинается холивар на тему «что это за велосипед?!», «Где броня как у танка?!»
Просто мы с Вами смотрим с разных точек зрения.
Моя задача была быстро сделать минимальное логирование, которое позволит очень быстро разрешить ряд вопросов, если таковые возникнут. Потому что в попыхах выбирать систему логирования — тоже не самый лучший вариант.
Вы же смотрите с точки зрения того, что это должно быть сразу полноценное решение. И понятно, что при такой постановке задач «мое простое решение» — просто грубое вопиющее издевательство!
Это похоже как если бы на «простой способ разжечь костер в лесу» спорить о том, что это не способ для «работы плавильных печей!».
Ну так не нравится, напишите нормально. Так и скажите «он не подойдет как полноценное решение, так как многого нету, да и возможны ошибки при выходе за границы». Но и в тексте ответ, что это «НЕ полноценное решение».
И да, Вам оно не нужно. Так зачем язвить было?
Вы требуете от него универсальности и сверхпроизводительности. Насчет работоспособности – работает.
1. Exception
2. Будет плохо
3. Безусловно согласен – это плохо
4. Расти будет быстро – как бамбук. Если применить логику, то можно найти.
5. Ничего
6. Не особо
Вы путаете понятия «work around» и конечный метод.
Тогда вопрос. А Вы знаете, почему Ferrari плохая машина? На ней мало картошки можно отвезти:)
Ну, честно. Это простое решение. Оно позволяет получить минимальную, НО функциональность. А это, кстати, больше чем 0. :)
Естественно, когда будет на это время, можно будет уже в спокойной и нормальной обстановке просмотреть имеющиеся решения. И выбрать наиболее подходящее с учетом задач.
Кстати, вопрос. А что Вы будете делать, если политика компании будет запрещать использование сторонних библиотек (ну бывает такое, не в моем случае, но все же)?
Если брать абстрактно, то Вы, безусловно, правы. Но есть такая штука как реальность.
Просто подумайте над этим:
Люди почему-то до сих пор покупают российские машины, хотя есть огромное количество веских поводов этого не делать. Но они покупают, и они оказываются правы.
P.S. Попробуйте сами пообщаться с заказчиками, и не с теми, которые «в теме» передовых технологий. И я Вас уверяю, после некоторого числа, Ваши взгляды сильно изменяться.