Статья про то как много людей херашило полгода, а на выходе клипарт, формальные фразы, штампы, ляпы… но гордо, все как в новостях о достижениях отечественного роботостроения. кажись, подставили вы sitecore
мне видятся следующие проблемы:
— вы не достаточно заботитесь о том что модель должна не только определять исполнителя, но и отличать от других. Собственно определение уникальных отличительных черт — самый сложный кусок.
— ну блин нельзя полагаться на магию библиотек. я перемешал и оно заработало — в жизни должны быть очень веские доказательства чтоб так делать. Я не математик, но Марковские цепи в моем понимание учат последовательности. Научите рандому — рандом и будут прогнозировать
— разубедите меня, но я не видел рабочей системы распознавания аудио на mfcc и марковских цепях. Туча академических статей, а прикладных правдоподобных решений — просто нет.
Искренне желаю не унывать и останавливать себя если начинаете «перебирать и пробовать» — это не научно)
Приемуществом Delphi всегда была генерация стабильного нативного кода и конечно же тонны компонент как «из коробки» так и от сообщества. Люди умудрились убить в один момент оба своего приемущества: подкосили совместимость со старыми VCL компонентами и переориентировались на .Net Framework. Имхо, никакие рюшки в синтаксисе и IDE уже не возродит сообщества в былых масштабах. а жаль…
Ну написали б примеры кода, наглядно показали бы как все просто и быстро и этому не надо особо учиться — я б почитал с удовольствием.
А так — не впечатлили.
Ну пардон, опыта ёк :) Просто че-то вспомнилось. Участие в олимпиадах было незабываемым опытом, который ни на какой работе не получишь. И хоть задачи далеки от прикладного использования, смекалку развивают на раз.
Была как-то раз задачка, которая никаким перебором не вкладывалось в ограничения по времени. Точно не помню, но задачка вроде: для входного целого числа посчитать афигеть какое большое, мудреное и сложное другое число. На нашем этапе, все команды кто вообще решал эту задачу, просчитали ее «в фоне» для входных чисел от 1 до 8, а в вариант «на проверку» тоупо захардкодили ифами. Верхний порог входных данныз подбирался методом «прокатит-не прокатит».
Имхо, все зависит от того как вы проектируете/планируете, адекватности заказчика, квалифицированности сотрудников и только в малой степени от средств планирования. Можно и лобзиком по фанерке лишь бы всем было понятно что делать сейчас и когда проект закончится.
Ресурсы. На название ресурса я лично не обижаюсь ) А все перечисленные трудности с соблюдением графика можно избежать- обобщайте задачи так, чтобы каждая задача на графике у вас не была короче, например, 4х часов.
Скоуп проекта
Как правило, диаграмма Гантта с более менее аргументированным разделением задачи и является весьма убедительным основанием для заказчика. Да требования могут меняться, но вам необходимо показать заказчику, что с изменением требований и сроки могут меняться и почему.
Зависимости
Есть масса средств, позволяющих не указывая явно зависимости задач от ресурсов и других задач эффективно планировать. Все зависит от программы в которой вы проектируете, просто думаю стоит капнуть поглубже)
Итеративность
Вы не обязаны делать абсолютно подробный план работ без необходимости. Стоит помнить, что главное не диаграмма, а главное, что все понимали что нужно делать и в какие сроки.
Все это естественно ИМХО. Мне тоже многое не нравится в имеющихся средствах планированияи мне действительно интересно к какой альтернативе пришли Вы.
Никто никогда никому не помогает просто так. Имхо, майкрософту очень выгодна такая «благотворительность». А если это еще выгодно и интересно мне лично, почему не воспользоваться?
Да, есть такие люди. Сам работал с человеком, который писал свой SQL сервер только потому, что не разобрался с имеющимися… При этом парень толковый, просто направить потенциал некому было.
— вы не достаточно заботитесь о том что модель должна не только определять исполнителя, но и отличать от других. Собственно определение уникальных отличительных черт — самый сложный кусок.
— ну блин нельзя полагаться на магию библиотек. я перемешал и оно заработало — в жизни должны быть очень веские доказательства чтоб так делать. Я не математик, но Марковские цепи в моем понимание учат последовательности. Научите рандому — рандом и будут прогнозировать
— разубедите меня, но я не видел рабочей системы распознавания аудио на mfcc и марковских цепях. Туча академических статей, а прикладных правдоподобных решений — просто нет.
Искренне желаю не унывать и останавливать себя если начинаете «перебирать и пробовать» — это не научно)
А так — не впечатлили.
Ресурсы. На название ресурса я лично не обижаюсь ) А все перечисленные трудности с соблюдением графика можно избежать- обобщайте задачи так, чтобы каждая задача на графике у вас не была короче, например, 4х часов.
Скоуп проекта
Как правило, диаграмма Гантта с более менее аргументированным разделением задачи и является весьма убедительным основанием для заказчика. Да требования могут меняться, но вам необходимо показать заказчику, что с изменением требований и сроки могут меняться и почему.
Зависимости
Есть масса средств, позволяющих не указывая явно зависимости задач от ресурсов и других задач эффективно планировать. Все зависит от программы в которой вы проектируете, просто думаю стоит капнуть поглубже)
Итеративность
Вы не обязаны делать абсолютно подробный план работ без необходимости. Стоит помнить, что главное не диаграмма, а главное, что все понимали что нужно делать и в какие сроки.
Все это естественно ИМХО. Мне тоже многое не нравится в имеющихся средствах планированияи мне действительно интересно к какой альтернативе пришли Вы.
Хотелось бы узнать о практиках, к которым вы перешли или собираетесь перейти