ведущая роль UML в проекте - это идеалистический бред :)

Есть некоторое количество проектов, которые делаются правильно и по уму. Только вот на практике их исчезающе малое количество... Поэтому и идеализм.

Если моно - это опенсорц, то киньте мне плз ссылку в sourceforge на исходник .net framework 4

>ведущая роль UML в проекте - это идеалистический бред :)

Все правильно.

Как выразился один уважаемый западный разработчик: «Лучше иметь хороший проект при плохом УМЛ, чем наоборот».

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

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

> Когда у тебя будет проект метров на 50 исходников, в которых надо что-то подправить

+inf. Писать на Питоне легко и приятно, но править потом - песец.

4.2

import unittesting

для успешного 1С программирования надо прилагать туеву кучу социальных навыков и навыков общения с десятками тетушек и молодых девушек из бухгалтерии, на что, понятное дело, не способен любой среднестатический замкнутый на себе жабаимбецил

статистика показывает обратное

норкоман шщтоле?

новелу дали патент на реализацию clr

> import unittesting

>>> import unittesting
Traceback (most recent call last):
File «<stdin>», line 1, in <module>
ImportError: No module named unittesting
>>>

>статистика показывает обратное

статистика - это продажная шалава капитализма.

А я говорю о реальных вещах.

почему никто про D не вспомнил? Может где-то уже есть тот самый толчок в который он с шумом сольётся и никто о нём не вспомнит лет уже через 5?

//fixed

Причем тут новел? Я говорю об открытых кодах, а не о чьих-то патентах на использование полуоткрытых исходников. И вообще, я вроде на личности не переходил. А школоло?

Код пишется _разными_ людьми. И рано или поздно (скорее всего очень рано) найдется чловек который забьет на все это и вольет в проект кучу говнокода

ты б не позорился уже со своими «совковскими» понятиями, для этого существует code review

http://mono-project.com/FAQ:_Licensing

утоли свой бугурт уже

>А идеалистический бред

Еще один, блин. Если диаграммы последовательностей или диаграммы конечных автоматов обладают малой долей детализации, то что же обладает большой?

100% документирующую роль ты на UML не возложишь по-определению. Потому что UML — графическая нотация, сделанная на основе многолетнего опыта тех, чьей основной задачей является объяснение сути проекта людям, которые ни бум-бум в ИТ.

Вообще, из UML надо нафиг выкинуть диаграммы классов и сдлеать их отдельной сущностью. Только из-за того, чтобы у людей не возникали дурацкие идеи.

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

TDD, чтобы Вы знали, время работы сокращает

//а не умеете применять - лучше и не начинайте, это да

спасибо

ты б не позорился уже со своими «совковскими» понятиями, для этого существует code review

А ты бы читать сначала фразу до конца научился. И не выдирать куски из контекста.

ты ошибался.

обоснуй

>ты б не позорился уже со своими «совковскими» понятиями, для этого существует code review

ЧТО??!!

Ты вообще знаешь зачем тот кодеревью используется?

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

Каждый дрочит как хочет и всегда в свою сторону.

>>> import unittesting Traceback (most recent call last): File «<stdin>», line 1, in <module> ImportError: No module named unittesting

такая мартышка, честное слово, это тебе в голове unitesting надо подключать, а для python модуль называется unittest

Каким образом? Если у тебя есть функция + и вызывается она только для интов, то откуда рантайму знать, что ты вызываешь её только для интов? Всё равно jit тебе туда вставит проверку типа.

>TDD, чтобы Вы знали, время работы сокращает

Еще один с пропитанным мозгом манной кашей через уши детектед.

Как??111 Обьясни мне как??!?11 Как оно может сократить время на разработку если тебе банально вместо одной хреновины надо написать две???!!!

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

А представляешь, вот если у заказчика семь пятниц на неделю? Ты заманаешься те тесты править, а потом еще и под них код менять.

>статистика показывает обратное

статистика - это продажная шалава капитализма.

А я говорю о реальных вещах.

о каких же, например? что явакодер не сможет осилить работу с 1С? так 4.2 - много таких

>Если ключем к решению проблемы для 1С разработчика является плотное общение с людьми и комуникабельность

Не согласен. 1С-нику очень хорошо нужно знать предметную область. А это, пардон, одна из отличительных черт настоящего программиста.

Я не говорю про тех, кто 1С обновляет, ловит косяки исполнителей или стандартных конфигураций. Это действительно зачастую быдлокодеры.

А ты бы читать сначала фразу до конца научился. И не выдирать куски из контекста.

а я ещё раз повторю: для этого существует code review и ни в одной из нормальных контор не делают так как Вы сказали, потому что на последующий разбор каракулей в коде тратится в 10 раз больше времени

> Если у тебя есть функция + и вызывается она только для интов, то откуда рантайму знать, что ты вызываешь её только для интов?

Неоткуда.

Всё равно jit тебе туда вставит проверку типа.

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

> честное слово, это тебе в голове unitesting надо подключать

У тебя очевидный юниттестинг головного мозга. Лечись.

ЧТО??!!

Ты вообще знаешь зачем тот кодеревью используется?

я знаю, а вот Вы, похоже, не очень

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

сэр, если Вы лично применяете code review именно для указанных Вами целей, то я возражений не имею, в нормальных конторах же оно используется для улучшения качества кода

//не панацея, да

>на последующий разбор каракулей в коде тратится в 10 раз больше времени

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

ни в одной из нормальных контор не делают так как Вы сказали

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

Как??111 Обьясни мне как??!?11 Как оно может сократить время на разработку если тебе банально вместо одной хреновины надо написать две???!!!

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

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

1) кто из нас там живёт в волшебной стране? вот ты и спалился, признайся ты ведь к разработке не имеешь никакого отношения

2) ты так и не понял на каком уровне применяется TDD и для чего оно нужно

А представляешь, вот если у заказчика семь пятниц на неделю? Ты заманаешься те тесты править, а потом еще и под них код менять.

1) man agile

2) тесты надо писать правильно

> честное слово, это тебе в голове unitesting надо подключать

У тебя очевидный юниттестинг головного мозга. Лечись.

понятно, сказать по теме нечего - переходим на личности, засчитано

Контрибьютеров? Может авторов, кто писал (С)Vasya Pupkin? Или все контрибьютеры считаются?

> сказать по теме нечего

По теме я уже сказал.

переходим на личности, засчитано

Сам перешел, сам засчитал. Умница.

>на последующий разбор каракулей в коде тратится в 10 раз больше времени

Вот тут я согласен на все сто! Но постой, кого это волнует?

того кто имеет в голове долгосрочную перспективу и умеет считать деньги

//да в этой стране не так часто, но, поверьте, бывает

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

иногда бывает и хуже, например - настрочить отчёт заказчику об успешной разработке, а уж потом кто как хочет пусть так и выкручивается

>ни в одной из нормальных контор не делают так как Вы сказали

Вот как раз так как я описал выше и делается.

ключевое слово - нормальных

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

расскажите об этом в ibm, вот они поржут

Крокодил Солнце проглотил!

Вот думаю, Оракл, этот недоделанный крокодил, пожалел наверное уже что Солнце проглотил.
Жил себе раньше в своем СУБД-болоте, считался порядочным крокодилом, но Бармалей попутал, захотелось ему Sun поглотить. Ну проглотил. А как щас жжот-то суко!!! xD

Выплюнь, дуралей! Выпусти на свободу солнушко! )))

> сказать по теме нечего

По теме я уже сказал.

Вы сказали фигню полную, а затем начали кривляться как мартышка

> переходим на личности, засчитано

Сам перешел, сам засчитал. Умница.

если Вам так удобнее - пусть будет так

Ты еще третью редакцию сделай %)

>1) man agile

2) тесты надо писать правильно

Звучит как: «Посейте деньги ночью на поле Чудес и тогда они прорастут ...».

>>А если кто-нибудь пришлёт патчи, разгоняющие бесплатную JVM, то Оракуль их не примет?

Их право. Так-же как и твоё право сделать форк, если этим недоволен.

И тут же получить иск за нарушение патентов Оракл?
В том и состоит находка Сан/Оракл, что от патентов защищен только тот вариант открытой Жавы, который устраивает корпорацию (1шт).

Жму волосатую руку Ларри и желаю ему таки сесть за неуплату налогов :-|

--
cc:«risrom throat» как бы намекает - Carpe Jugulum

>на исходник .net framework 4

Моно и вендовый дотнет - это разные вещи.

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

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

>За то теперь у заказчиков будет огромный выбор, тормознутый бесплатный пифон, тормознутый бесплатный пэхапэ или тормознутый бесплатный руби

И тормознутая платная джава.

>1) man agile >2) тесты надо писать правильно

Звучит как: «Посейте деньги ночью на поле Чудес и тогда они прорастут ...».

звучит так:

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

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

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

И что это вообще за высер такой на пол экрана? Ты что хотел этим маркетоилдным бредом вообще сказать?

Что гибкость млять - цель номер 1 при создании проекта? Тае любая гибкость ведет к черезмерной усложенности, и опять таки за доп. усложненность кто платить то будет? Ты? Может быть ты заплатишь за ее своим внерабочим временем?

Ну что, пора брать лопаты?

И что это вообще за высер такой на пол экрана? Ты что хотел этим маркетоилдным бредом вообще сказать?

я правильно понимаю что «все вокруг дураки, я - один умный тут, правда у меня почему-то не работает»?

Что гибкость млять - цель номер 1 при создании проекта? Тае любая гибкость ведет к черезмерной усложенности, и опять таки за доп. усложненность кто платить то будет? Ты? Может быть ты заплатишь за ее своим внерабочим временем?

man agile

И что это вообще за высер такой на пол экрана? Ты что хотел этим маркетоилдным бредом вообще сказать?

Да ничего он им сказать не хотел. Очередной красноглазый вьюнош от agile.

Только вот ни один из этих фанатиков так и не смог ответить на вопрос: как при agile модели разработки посчитать стоимость проекта? И как работать, когда проект fix time/fix price.

Да ничего он им сказать не хотел. Очередной красноглазый вьюнош от agile.

Вы, уважаемый, не поняли зачем нужен agile

Только вот ни один из этих фанатиков так и не смог ответить на вопрос: как при agile модели разработки посчитать стоимость проекта?

да точно так же, количество ресурсов-то не меняется, или не согласны?

И как работать, когда проект fix time/fix price.

а тут Вас что смущает? и как этому мешает agile?

Только вот ни один из этих фанатиков так и не смог ответить на вопрос: как при agile модели разработки посчитать стоимость проекта? И как работать, когда проект fix time/fix price.

По-нормальному имхо никак. Заказчика тоже надо убедить, что эджайл это здорово и теперь надо оплачивать тоже по-эджайловски, набыдлокодили что попало, оплатите, и будем думать, как это всё порефакторить (за что тоже надо заплатить).

А, ну да, всё пишется в 3-4 раза медленнее, т.к. тестов больше чем кода, и любое нетривиальное изменение заставляет переписвать в 4-5 раз больше кода. Зато разработчик уверен в своём коде, и волосы у него шёлковые и блестящие.

> Только вот ни один из этих фанатиков так и не смог ответить на вопрос: как при agile модели разработки посчитать стоимость проекта? И как работать, когда проект fix time/fix price.

По-нормальному имхо никак.

обоснуйте

Заказчика тоже надо убедить, что эджайл это здорово и теперь надо оплачивать тоже по-эджайловски, набыдлокодили что попало, оплатите, и будем думать, как это всё порефакторить (за что тоже надо заплатить).

А, ну да, всё пишется в 3-4 раза медленнее, т.к. тестов больше чем кода, и любое нетривиальное изменение заставляет переписвать в 4-5 раз больше кода. Зато разработчик уверен в своём коде, и волосы у него шёлковые и блестящие.

так, ещё один теоретик-неосилятор, глупость говорите

При покупке премиум-версии вы получаете двух индусов прямо изкаропки! А также китайский улучшенный сборщик мусора!

если улучшенный то таджикский же :)