О, вы рюхаете:) Отлично. Вопрос такой — нужна ли для сэмплера обвязка? Интересует процесс, в ходе которого можно переносить сделанное на сэмплере в обрабатывающую и сводящую программу? Нужно ли в ходе этого процесса другое железо? Если да, то какое?
Да, целиком поддерживаю:) Особенно напрягают высказывания «да я вот во фруктах все сделал».
Это точно так же, как у меня народ кричал — да че ты паришься, забей, играй на Тракторе! Нахера тебе эти деки, то же самое можно на компьютере сделать!
В результате пока сам не почувствовал железо под руками, не понял, как же разительно отличается «комп» от «железа».
Понятно. А против сэмплера (у меня есть предрасположенность к медленным сочным ломанным ритмам) вы что-то имеете? Это ж по сути та же миди клавиатура, только по другому скомпонована.
Да с фрутилупом все неплохо получается, вроде, но меня сковывает отсутствие возможности почувствовать музыку под пальцами плюс зависимость от самой программы. В прошлом неплохо диджействовал и понимаю, чем отличается сводка треков например на железках, например, Pioneer от сводки музыки в Тракторе.
Поэтому хочу сообразить, хватит ли одного сэмплера или надо еще что докупить.
Вопрос — хочу заняться созданием электронной музыки, но не уверен, что есть талант. Хватит ли сэмплера Akai MPC 1000, чтобы убедиться в наличие способностей? Нужно ли дополнительное обрудование?
Дык, удобен, неудобен, это все субьективно. Вы любите компактность, дизайнер Маша — открытость, легкость в обращении и много свободного места между элементами управления. Кто из вас прав? На форуме гиков — вы. На форуме дизайнеров или женской консультации — дизайнер Маша.
В общем, вы сравниваете несравнимое, какие цели преследуете — я так и не понял. Особенно утверждая то, что вы линуксоид (а стало быть, не пользуетесь ни нативным аськиным клиентом, ни кипом). Ладно, не будем спорить, дело хозяйское:)
Если к данным привязываемся через data binding, то методы с атрибутами весьма накладно использовать. Валидировать придется по событию формы, например, нажатию кнопки, после чего вызывать методы. Здесь вилка — или усложняем логику формы и не паримся с валидацией, или упрощаем привязку данных и паримся с валидацией:) Имхо, второе лучше. По-вашему, можно навешать атрибутов на сам класс, потом его инстанс проверять в специальном валидаторе (такое решение в Enterprise Library, кстати). Но это загромождение бизнес-объекта лишними излишествами и не совсем быстро покрывается тестами.
А можно наваять свое, как у автора. Имхо, все прикольно, но я бы не стал валидировать степ-бай-степ. Кусочки валидации надо разделить на простые, и сложные. Простые — это регэкп, например, а сложные — запрос в базу данных на уникальность. Когда пользователь заполнил все что нужно и жмакнул ок, ему вывелся ValidationResult сначала с проверкой на простые условия. Когда выполнил все простые условия, идут проверки на сложные:) Но идея в статье хорошая — соединить flow of control с валидацией:)
Насчет книг — возьмите Троелсена, лучше в оригинале
Самая лучшая книжка для изучения .net с нуля. Пригодится в ваших статьях-выжимках.
Немного непонятен, вы простите меня конечно, смысл ваших статей. Изучать c# по ним, в лучшем случае, нужно с опаской — потому как неясен ни ваш опыт, ни ваши цели. Я так понял, вы хотите написать еще одну книгу по .net c# — это похвально, но хватит ли сил и как вы оцениваете полноту материала?
Вот именно, что не обособленно:) У вас из первого выходит второе. Я сидел некоторое время втыкал, почему из того, что машинные коды не одно и то же следует связка ассемблера с паскалем :D
Очень интересная мысль про скрещивание с# и с. Вот предположим, есть железка — трекер, она программируется на с. Интересно, возможно ли написать управляющий код на c#, который компоновал бы инструкции С таким образом, чтобы получалась полноценная, работающая программа на с? Которую, в конечном итоге, можно было бы залить программатором в железку?
Машинный код .NET и машинный код Native (Не-.NET) приложений это не одно и то же. Соответственно, выходит интересная штука: мы можем взять одно Native приложение, написанное на языке Assembler, и взять другое Native приложение, написанное я языке Pascal, и скрестить их вместе.
Как-то я не понял логический переход:) Можно пояснить?
Хм. Результат выполнения выдает z0. Т.е. опять же, h(x0) = z0 — это следует из определения функции, а сама конструкция определяет юнит-тест. Поэтому в конечном итоге все равно требуется только a(z0). Если честно, я не вижу смысла писать ассерты на код в h(x) — опять, из выведенного в статье h(x) = f(m(x)), а моки — не изменяют данные. Посмотрите в код, шаг 3, определяется мок, выдающий данные через заглушку ITopologyService. Он не изменяет данные, он их выдает в тестируемый класс как результат вызова метода ITopologyService.
Я привел первый случай, потому как важно определить конечный результат. Почему важно? Чтобы не допустить ошибку в логике f(x). $a(h, x_0, z_0)$ — мне, если честно, не совсем понятен смысл этой конструкции. Дополнительные ассерты всего и вся? В том числе и функциональности теста? Чтож, можно и так — добавляется пятый шаг, на котором программист «усиляет» проверки (если они уместны).
Это точно так же, как у меня народ кричал — да че ты паришься, забей, играй на Тракторе! Нахера тебе эти деки, то же самое можно на компьютере сделать!
В результате пока сам не почувствовал железо под руками, не понял, как же разительно отличается «комп» от «железа».
И какой софт посоветуете, кроме фруктов?
Поэтому хочу сообразить, хватит ли одного сэмплера или надо еще что докупить.
Спасибо!
В общем, вы сравниваете несравнимое, какие цели преследуете — я так и не понял. Особенно утверждая то, что вы линуксоид (а стало быть, не пользуетесь ни нативным аськиным клиентом, ни кипом). Ладно, не будем спорить, дело хозяйское:)
А можно наваять свое, как у автора. Имхо, все прикольно, но я бы не стал валидировать степ-бай-степ. Кусочки валидации надо разделить на простые, и сложные. Простые — это регэкп, например, а сложные — запрос в базу данных на уникальность. Когда пользователь заполнил все что нужно и жмакнул ок, ему вывелся ValidationResult сначала с проверкой на простые условия. Когда выполнил все простые условия, идут проверки на сложные:) Но идея в статье хорошая — соединить flow of control с валидацией:)
Самая лучшая книжка для изучения .net с нуля. Пригодится в ваших статьях-выжимках.
Немного непонятен, вы простите меня конечно, смысл ваших статей. Изучать c# по ним, в лучшем случае, нужно с опаской — потому как неясен ни ваш опыт, ни ваши цели. Я так понял, вы хотите написать еще одну книгу по .net c# — это похвально, но хватит ли сил и как вы оцениваете полноту материала?
Как-то я не понял логический переход:) Можно пояснить?