Офигеть:) Спасибо. Книжка из серии «на острие атаки».
Сам от Patterns & Practices использую CAB и Unity (движки для десктопных-клиентов). Очень мощные штуки. Когда в них разбираешься, в разработке начинаешь использовать совсем другую семантику.
Есть возможность реализовать систему учета расхода собственных средств и планирования расходов на какой-то период:) Это моя система мучения, но, имхо, в отличие от вашей, у меня есть один клент — моя знакомая и я сам:)
Интерфейсы для сервисов данных я уже прописал. Если в кратце, то мы можем скооперироваться — я останусь со своим клиентом, а вы можете плескаться в данных как вам угодно. Первоначальная схема данных очень простая. Но ее потом можно усложнить.
Какой-то баг, блин. Строку копи-пейстом вставляю, а браузер отправляет комент автоматически:)
Так вот, вы пишете, что указанный метод работает с CollectionViewSource. Я правильно понимаю, что можно будет биндится к свойствам самой коллекции? Или же биндинг может быть осуществлен к объектам, которые находятся в коллекции?
Пример классный, но вот для промышленного использования, имхо, прикольно было бы ввести класс состояния и заимплементить всю бизнес-логику в нем. Процесс аггрегировал бы это состояние и в своих эвент-хэндлерах вызывал бы его методы. Тем самым отделяем процесс от бизнес-логики а саму бизнес-логику юнит-тестируем вдоль и поперек:)
А про нашу работу — только слезы. У нас нет процесса разработки и нам запрещают его ставить. Поэтому мы делаем такую архитектуру, которая позволяет максимально быстро подстроится под изменяющиеся требования:)
Зависит от того, каким образом процесс описывает взаимодействие между разработчиками и как он предусматривает разделение обязанностей. Но имхо, как бы я постарался минимизировать временные убытки — задачи бьются на оптимальные для исполнения куски (с точки зрения алгоритмики и взаимодействия программных компонент), разделяются между разработчиками, разработчики выдают примерные сроки (заодно решаем проблемы с имплементацией). Путем скрама лид или ПМ каждый день актуализируют прогресс и опять же направляют в нужное русло. Обязательным условием является техническое превосходство или как минимум равенство лида над другими разработчиками. Жира не нужна, достаточно Microsoft Project.
То, что описано в топике, это часть процесса, связанная непосредственно с разработкой конечного функционала. Еще взаимодействие с заказчиком, аналитика, и т.п.
Сам от Patterns & Practices использую CAB и Unity (движки для десктопных-клиентов). Очень мощные штуки. Когда в них разбираешься, в разработке начинаешь использовать совсем другую семантику.
Интерфейсы для сервисов данных я уже прописал. Если в кратце, то мы можем скооперироваться — я останусь со своим клиентом, а вы можете плескаться в данных как вам угодно. Первоначальная схема данных очень простая. Но ее потом можно усложнить.
Можно почитать тут:
acerv.livejournal.com/278203.html
Там по ссылкам «тут» можно провалится в самое начало.
Так вот, вы пишете, что указанный метод работает с CollectionViewSource. Я правильно понимаю, что можно будет биндится к свойствам самой коллекции? Или же биндинг может быть осуществлен к объектам, которые находятся в коллекции?
А про нашу работу — только слезы. У нас нет процесса разработки и нам запрещают его ставить. Поэтому мы делаем такую архитектуру, которая позволяет максимально быстро подстроится под изменяющиеся требования:)