На текущей работе -да, но это не моя инициатива

А если бы была твоя, то на каком фреймворке бы остановился? Или нечто своё бы написал?

У меня сложился свой набор класов которым я доверяю

Knockout + ASP.NET MVC == love

Добрый день! Мы молодая компания, которая собирается выйти на ico с идеей настоящего туманного компьютера для каждого пользователя. Нам сейчас необходимы -back-end -front-end -lead developer Заинтересованным просьба писать в личку

Кроме окна, конечно же ?

Добрый день! Мы молодая компания, которая собирается выйти на ico с идеей настоящего туманного компьютера для каждого пользователя. Нам сейчас необходимы -back-end -front-end -lead developer Заинтересованным просьба писать в личку

Как всегда, ты на позитиве :) Возможно, тебе стоит попробовать роль инвестиционного консультанта? "Вы просрете все свои бабки и пойдёте на органы", как-то так :)

около того, только с распределением среди пользователей

Извините, можно ссылочку?

Возьмем например мввм для увп/впф. Что делать, когда приложение очень сильно разрастается? Становится нужно это, нужно то, и вот это прикрутить, и получается, что с течением времени поддерживать всю полученную лапшу становится очень сложно. Окидываю щас взглядом сильно связные компоненты своего пет-приложения и думаю, ведь зачем-то же Б-г дал нам интерфейсы, DI, IoC-контейнеры. Но как лучше всю эту братию использовать в десктопных/мобильных нативных приложениях? Можно биндить вьюхи не на конкретные классы, а на интерфейсы, это удобно, поскольку в будущем такое приложение можно будет с лёгкостью расширить, написать новые вьюмодели для этих вьюх с другим поведением (например одинаковый интерфейс текстбокса, но с разными вьюмоделями => можно использовать один UI для бокса сообщений, комментов туда, комментов сюда, диалоговых окон обратной связи). Но также Б-г дал нам shared-прожекты, в которых можно хранить вьюмодели и шарить их между разными UI-провайдерами — андроидовским, эппловским, увпшным или каким-нибудь другим. Однако какой подход лучше избрать, когда приложение очень большое? Более ста вьюмоделей хранить в папке ViewModels, как завещал нам Caliburn.Micro, как-то некруто, путано, эти списки файлов листать можно с ума свихнуться и спутаться. То же самое с вьюхами. Получается, следует структуру разбить на модули-неймспейсы и выстроить иерархию типа: - ViewModels [separate project] -- Audio --- AudioCollectionViewModel --- AudioPageViewModel --- AudioItemViewModel -- Video --- <...> - Views [separate project] -- Audio --- AudioView --- AudioShareView -- Video --- <...> С таким подходом становится возможно шарить кодовую базу между разными UI-провайдерами и при этом она довольно проста и очевидна. Но что тогда делать с DI и биндами контролов на интерфейсы? Заметив, что проект может неконтролируемо расширяться, стоит ли делать ещё один проект-схему или же интерфейсы вью-моделей следует складывать вместе вьюхами приложения? Или с вьюмоделями? Пожалуй, этот вариант логичнее всего. Но необходимо ли для каждого класса выделать интерфейс и нигде не использовать прямых биндингов на инстансы? Ведь вдруг нам понадобится использовать несколько реализаций поведения одного и того же элемента управления (а еще один такой же элемент управления нам копипастить лень — и это антипаттерно). Что мы получим, имея ввиду всё вышесказанное? Какова будет структура нашего нового проекта со слабой связностью компонентов? Попробуем разобраться! - ViewModels [shared project] -- Audio --- Implementation ---- AudioCollectionViewModel ---- AudioPageViewModel ---- AudioViewModel --- IAudioCollectionViewModel --- IAudioPageViewModel --- IAudioViewModel Соответственно во всех компонентах реализованных моделек мы обмазываемся выделенными интерфейсами и слабо связываем наши компоненты, ни в коем случае не используя ключевое слово new (конечно же, потому что это антипаттерн). Получилось у нас всё просто, тестируемо и по фен-шую (ну, почти). Некоторые интерфейсы можно явно не описывать (например, IAudioCollectionViewModel), если они являются потомками generic-класса (например, IFetchableCollection<IAudioCollectioViewModel>). Итого мы ещё чуть-чуть упростили себе жизнь. Или такое всё же лучше описать явно, что думаете?

Как через rabitmq (клиент под C#) передавать объекты? На официальном сайте нашел пример только с передачей байтов.

binaryFormatter

Такой вопрос по: SerialPort. Делаю запрос AT командой на свой SerailPort: _port.Write("AT+CUSD=1,\"#102#\"\r");, это отправление USSD запроса на модем, чтобы узнать баланс. Мне приходят каракули. Если подключаюсь через Putty, все норм. В чем проблема?

мб в этом дело? http://www.cyberforum.ru/csharp-net/thread814419.html

Спасибо, но нет. У меня все 7 ком портов заняты

модем не в PDU формате возвращает? как вариант ещё, поиграться с кодировкой

Мне кажется в нем возвращает.

попробуй пример по ссылке

+CUSD: 2,"0412043004480430002004370430044F0432043A04300020043F04400438043D044F0 4420430002E00200414043E043604340438044204350441044C00200053004D0053002D0443043204350434043E043C043B0435043D0438044F0020043E0431002004380441043F043E043B043D0435043D0438043800200437043004 4F0432043A0438002E0020",72

#ban за репосты

Время 6 утра, зачем ты не спишь

тулзовины итд

Есть плагин, который подсвечивает аллокации в куче.

Методы борьбы простые: делаешь побольше структурок, например, если видишь, что какие-то объекты много утекают. Если видишь большие массивы или List<T> (в dotMemory даже есть такая диагностика на листы) — можешь попробовать поиграться с коллекциями, преаллоцируя их сразу правильными размерами или, опять же, переходя на структуры в критически важных местах. Например, мне рассказывали, как существенно снизили мемори трафик, сделав специальную struct-коллекцию для списков из четырёх элементов (а если становилось больше четырёх, то она трансформировалась в List).

но думал делать в критических местах stackalloc