Решил я тут намедни Дотнет с Додиезом и прочими ВПЭФами освоить.
Пенсионер жеж — для собственного удовольствия...
Задачку себе выбрал: система психологического тестирования.
Потом студентам буду показывать процесс эволюционного развития системы и на паттерны показывать.
Чтобы одновременно не заморачиваться всем сразу, отложил работу с базой на попозже, и проектирование оконного интерфейса — тоже.
Тут просится паттерн прокси на место DB.
Основная часть сейчас — написать собственно тестилку.
Практически все тесты обрабатываются однотипно.
Поэтому первое, что автоматом сделал — паттерн Шаблонный метод.
Хотя Боб Мартин еще советует посмотреть в сторону Стратегии. Посмотрим. Пока неясны выгоды того и другого.
Шаблонный метод — очень понятный паттерн и в данном случае применяется просто в лоб.
У каждого теста есть набор вопросов.
И тестов этих много — ну, штук 200-300. Тут просится Фабрика — это понятно.
При писанине возникли некоторые вопросы к знатокам.
1. Список тестов.
Его легко сделать в виде обычного текстового файла.
Это чтобы можно было туда добавлять новые.
За каждой строкой "стоит" тест (объект в программе) и он имеет список своих вопросов.
Можно этот список вопросов запихать в файл и связать его имя со строкой в списке тестов.
Например:
1. Тест Кеттела = Q0001
2. Тест Айзенка = Q0002
Вот этот список тестов — в ресурсы запихать, или оставить как чисто простой текстовый файл?
Есть ли смысл в использовании ресурсов в данном случае?
Это ж тоже изучать в данном случае — Студия дофига кода генерит для ресурсов.
2. А когда тест выбран для работы, метод Initialization() просто читает в List<string> из соответствующего файла.
Или просто в лоб в коде присвоить имя файла?
В связи с этим: пока не совсем понятно, когда использовать свойства.
Вот например, для имени файла с вопросами использовать поле или свойство?
3. Нет опыта использования интерфейсов.
Когда использовать классы, когда интерфейсы (ну, кроме понятных случаев множественного наследования).
Боб Мартин паттерн Стратегия описывает как второй вариант решения одной и той же задачи.
И как раз описывает стратегию с помощью интерфейса.
А потом разные стратегии у него реализуются разными классами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали: LVV>Поэтому первое, что автоматом сделал — паттерн Шаблонный метод.
Стоять ать-два. Вот так делать никогда и ни при каких обстоятельствах не надо, это прямой путь к запороть весь проект.
Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
вы же не думаете в стиле "у меня есть шуруповёрт, значит, мне нужно собрать шкаф, потому что часы им разбирать неудобно"?
Ну так почему для разработки такой способ мышления считается нормальным?
LVV>Хотя Боб Мартин еще советует посмотреть в сторону Стратегии. Посмотрим. Пока неясны выгоды того и другого.
У Боба Мартина всё классно, кроме одного — он не решает проблемы, он творчески натягивает паттерны. В результате получается симпатично
и как-то так
В общем, если вам для дела, а не для заготовок сфероконины в промышленных масштабах, то ни Фаулер, ни тем более Мартин — не авторитет.
LVV>Шаблонный метод — очень понятный паттерн и в данном случае применяется просто в лоб. LVV>У каждого теста есть набор вопросов.
Посмотрите ссылку на обсуждение выше, я там расписывал с примерами, как надо рассуждать при формулировке начального ТЗ.
Будут реальные сценарии — можно будет и конкретные решения обсудить. А то с тем же успехом можно дротики в оглавление Фаулера метать и писать выпавшее. Шансы угадать те же.
LVV>>Поэтому первое, что автоматом сделал — паттерн Шаблонный метод. S>Стоять ать-два. Вот так делать никогда и ни при каких обстоятельствах не надо, это прямой путь к запороть весь проект.
Почему?
Все тесты обрабатываются совершенно одинаково:
— есть несколько десятков вопросов.
— вопросы задаются пользователю.
Обычно чисто последовательно, но это не критично — можно и все сразу показать, а пользователь будет сам выбирать.
— принимается ответ.
После получения всех ответов — расчет показателей теста.
Далее эти результаты сохраняются в каком-то виде в БД.
И можно показать пользователю.
Пока все. S>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод. S>Недавно обсуждалось вот тут
S>вы же не думаете в стиле "у меня есть шуруповёрт, значит, мне нужно собрать шкаф, потому что часы им разбирать неудобно"?
S> Ну так почему для разработки такой способ мышления считается нормальным?
Спасибо, почитаю.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
По жизни. Можно, конечно, забивать гвозди микроскопом. Но может оказаться, что молотком удобнее и эффективнее.
LVV>Все тесты обрабатываются совершенно одинаково: LVV>- есть несколько десятков вопросов. LVV>- вопросы задаются пользователю. LVV>Обычно чисто последовательно, но это не критично — можно и все сразу показать, а пользователь будет сам выбирать. LVV>- принимается ответ. LVV>После получения всех ответов — расчет показателей теста. LVV>Далее эти результаты сохраняются в каком-то виде в БД. LVV>И можно показать пользователю. LVV>Пока все.
И куда в этом описании пихать шаблонный метод? Возможно, он пригодится где-то в процессе реализации каких-то частей этой последовательности, но на таком уровне никакой надобности в нем не наблюдается.
S>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения.
+100500.
LVV>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.
Шаблонный метод — это инструмент. Он не может быть решаемой задачей (кроме случая, когда стоит задача написать шаблонный метод. Но это ведь не тот случай, да?).
Здравствуйте, LaptevVV, Вы писали:
LVV>Его легко сделать в виде обычного текстового файла.
Лучше его сделать в виде обычного XML или обычного JSON файла.
LVV>Это чтобы можно было туда добавлять новые. LVV>За каждой строкой "стоит" тест (объект в программе) и он имеет список своих вопросов. LVV>Можно этот список вопросов запихать в файл и связать его имя со строкой в списке тестов.
Неудобно когда информация о тесте раскидана по нескольким файлам.
LVV>Есть ли смысл в использовании ресурсов в данном случае?
Не особо.
LVV>Это ж тоже изучать в данном случае — Студия дофига кода генерит для ресурсов.
Изучать там нечего. И генерацию можно убрать.
LVV>2. А когда тест выбран для работы, метод Initialization() просто читает в List<string> из соответствующего файла. LVV>Или просто в лоб в коде присвоить имя файла?
Вопрос непонятен.
LVV>Вот например, для имени файла с вопросами использовать поле или свойство?
Код покажи.
LVV>3. Нет опыта использования интерфейсов. LVV>Когда использовать классы, когда интерфейсы (ну, кроме понятных случаев множественного наследования).
В общем случае интерфейсы использовать всегда, когда можно. Абстрактные классы — только когда интерфейсы не подходят.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, LaptevVV, Вы писали:
S>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения. LVV>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод.
Нет, это не задача.
Начни с тестов (nunit-тестов, а не своих). Как бы ты хотел, чтобы выглядел код, использующий эти самые тесты?
Например:
var testManager = TestManager.Create(new TestSourceMock(testXml));
var test = testManager.Get("Kettel");
Assert.AreEqual("Тест Кеттела", test.DisplayName);
Assert.AreEqual(3, test.Questions.Count);
Assert.AreEqual("Вопрос 1 ...", test.Questions[0].Text);
Assert.AreEqual(QuestionType.Exclusive, test.Questions[0].Type);
Assert.AreEqual(2, test.Questions[0].Answers.Count);
Assert.AreEqual("Ответ А", test.Questions[0].Answers[0]);
...
Ну и самое сложно в твоей задаче — понять какие типы тестов ты хочешь покрыть и как эти типы объединить одной моделью. Как вопросы организованы, как результат теста вычисляется, нужен ли rich text в вопросах и ответах и т.п. А все эти рассказы про шаблоны — ненужные подробности на данном этапе.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
LVV>>Все тесты обрабатываются совершенно одинаково: LVV>>- есть несколько десятков вопросов. LVV>>- вопросы задаются пользователю. LVV>>Обычно чисто последовательно, но это не критично — можно и все сразу показать, а пользователь будет сам выбирать. LVV>>- принимается ответ. LVV>>После получения всех ответов — расчет показателей теста. LVV>>Далее эти результаты сохраняются в каком-то виде в БД. LVV>>И можно показать пользователю. LVV>>Пока все. L>И куда в этом описании пихать шаблонный метод? Возможно, он пригодится где-то в процессе реализации каких-то частей этой последовательности, но на таком уровне никакой надобности в нем не наблюдается.
Дык это он и есть.
Абстрактный алгоритм работы теста.
Различия — в деталях: вопросы, ответы, способ обработки. S>>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения. L>+100500. LVV>>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод. L>Шаблонный метод — это инструмент. Он не может быть решаемой задачей (кроме случая, когда стоит задача написать шаблонный метод. Но это ведь не тот случай, да?).
Шаблонный метод — подходящий в данном случае инструмент.
Пока вы меня не убедили, что он здесь не подходит.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
S>>>Код _всегда_ должен писаться от решаемой проблемы, а не от способа решения. LVV>>Так что тут как раз получается, что решаемая задача — оно самое и есть Шаблонный метод. AVK>Нет, это не задача. AVK>Начни с тестов (nunit-тестов, а не своих). Как бы ты хотел, чтобы выглядел код, использующий эти самые тесты? AVK>Например: AVK>
AVK>Ну и самое сложно в твоей задаче — понять какие типы тестов ты хочешь покрыть и как эти типы объединить одной моделью. Как вопросы организованы, как результат теста вычисляется, нужен ли rich text в вопросах и ответах и т.п. А все эти рассказы про шаблоны — ненужные подробности на данном этапе.
1. Спасибо за пример юнит-тестов. А то я думал, как их писать.
2. Покрываются ВСЕ психологические тесты-опросники. Их много — до нескольких сотен.
Схема тестирования у всех одинакова — я приводил. Разница — в наборах вопросов, естественно, ответах и обработке ответов.
Не покрываются тесты другого вида (пока так представляется), например, тест Люшера.
3. Отсюда — вопросы у всех тестов организованы одинаково... Просто последовательность строк.
Пока отставил проектирование диалогового интерфейса — сначала хочу движок состряпать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>3. Отсюда — вопросы у всех тестов организованы одинаково... Просто последовательность строк.
Как минимум, для разных вопросов ответы могут быть только один вариант или возможность выбрать несколько.
LVV>Пока отставил проектирование диалогового интерфейса — сначала хочу движок состряпать.
Подумай еще над тем, где сами тесты хранить, куда сохранять результаты тестирования, как идентифицировать тестируемого и т.п.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
LVV>>3. Отсюда — вопросы у всех тестов организованы одинаково... Просто последовательность строк. AVK>Как минимум, для разных вопросов ответы могут быть только один вариант или возможность выбрать несколько.
Ну, это как раз те конкретные детали, которые просто уточняют общую схему. LVV>>Пока отставил проектирование диалогового интерфейса — сначала хочу движок состряпать. AVK>Подумай еще над тем, где сами тесты хранить, куда сохранять результаты тестирования, как идентифицировать тестируемого и т.п.Ну, это тоже само-собой.
Ибо тут придется проектировать схему БД.
Поэтому пока вместо БД — заглушка.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
AVK>>Как минимум, для разных вопросов ответы могут быть только один вариант или возможность выбрать несколько. LVV>Ну, это как раз те конкретные детали, которые просто уточняют общую схему.
Они так уточняют, что вместо простотекста появляется какой то формат. Так что лучше сразу не лохматить бабушку, а использовать что нибудь более структурированное, нежели простой текст.
AVK>>Подумай еще над тем, где сами тесты хранить, куда сохранять результаты тестирования, как идентифицировать тестируемого и т.п.Ну, это тоже само-собой. LVV>Ибо тут придется проектировать схему БД. LVV>Поэтому пока вместо БД — заглушка.
Да бог с ней, с БД. Ты хотя бы определись — это будет единое хранилище на сервере или локальное.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
LVV>>Ибо тут придется проектировать схему БД. LVV>>Поэтому пока вместо БД — заглушка. AVK>Да бог с ней, с БД. Ты хотя бы определись — это будет единое хранилище на сервере или локальное.
На сервере.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>На сервере.
Вот с этого тогда и надо начинать. Определись хотя бы с базовыми параметрами — в каком виде у тебя будет серверная часть,какой протокол. Или может быть там веб-интерфейс у тестов будет. Как регистрировать и аутентифицировать пользователей. Как на сервер добавлять данные. Как просматривать результаты тестирования.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, LaptevVV, Вы писали:
LVV>3. Нет опыта использования интерфейсов. LVV>Когда использовать классы, когда интерфейсы (ну, кроме понятных случаев множественного наследования). LVV>Боб Мартин паттерн Стратегия описывает как второй вариант решения одной и той же задачи. LVV>И как раз описывает стратегию с помощью интерфейса. LVV>А потом разные стратегии у него реализуются разными классами.
Вообще тут роли напрашиваются. Админ который будет добавлять в систему преподов. Преподы, которые будет добавлять тесты и студентов, ну студенты конечно. А так это как-то "сферично" и "ваккуумно".
Q>Вообще тут роли напрашиваются. Админ который будет добавлять в систему преподов. Преподы, которые будет добавлять тесты и студентов, ну студенты конечно. А так это как-то "сферично" и "ваккуумно".
Не. Админ не нужен.
Препод (например, я) будет добавлять тесты.
А студенты — сами регистрироваться будут.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>На сервере.
Это я так планирую довести до этого. AVK>Вот с этого тогда и надо начинать. Определись хотя бы с базовыми параметрами — в каком виде у тебя будет серверная часть,какой протокол. Или может быть там веб-интерфейс у тестов будет. Как регистрировать и аутентифицировать пользователей. Как на сервер добавлять данные. Как просматривать результаты тестирования.
1. Систему планирую потом использовать только на кафедре.
Пока мыслю — в пределах одного компьютерного класса с базой на локальном кафедральном сервере.
Это примерно 14-15 компов одновременно.
2. Все добавления-модификации информации буду делать сам или знакомый препод.
Прямо на кафедральном компе. Поэтому новых преподов не нужно регистрировать.
3. Студенты будут региться из класса.
В этом деле опыта нет абсолютно.
Наверное, тонкий клиент?
Ибо от пользователя требуется только вводить ответы.
Пока все ответы не получены — ничего считать не надо.
Неужто интерфейс просто ручками в html сваять?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>1. 2. 3.
Воот.. уже прорисовываются сценарии использования с характеристиками окружения. С этого и надо начинать. Дальше немного детализировать до появления схем взаимодействия и можно код начинать писать.
LVV>Наверное, тонкий клиент? LVV>Ибо от пользователя требуется только вводить ответы. LVV>Пока все ответы не получены — ничего считать не надо.
LVV>Неужто интерфейс просто ручками в html сваять?
Вполне возможный вариант
Я бы делал примерно так:
HTML + CSS + JS на клиенте, т.к. функционал простой и сразу решается вопрос обновления версий
REST сервис на сервере (WebAPI, C# .NET 4.5 + там много чего готового есть для авторизации и прочих типовых задач)
Либо, если веб интерфейс не нужен и хочется 100% .NET на клиенте и сервере
WPF приложение на клиенте — тут как раз можно применить всякие MVVM и прочие паттерны
WCF сервис на сервере
Можно вообще не делать сервис а напрямую цепляться к БД из клиентов, но.. советовать такое пожалуй не буду.
A>Я бы делал примерно так: A>HTML + CSS + JS на клиенте, т.к. функционал простой и сразу решается вопрос обновления версий A>REST сервис на сервере (WebAPI, C# .NET 4.5 + там много чего готового есть для авторизации и прочих типовых задач)
Где читать? A>Либо, если веб интерфейс не нужен и хочется 100% .NET на клиенте и сервере A>WPF приложение на клиенте — тут как раз можно применить всякие MVVM и прочие паттерны A>WCF сервис на сервере
Опять же — где читать про взаимодействие клиента и сервера?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Где читать?
Для поверхностного ознакомления и быстрого старта например тут >> http://metanit.com/sharp/aspnet_webapi/
LVV>Опять же — где читать про взаимодействие клиента и сервера?
Ну... например нагуглить какую-нибудь статью по запросу WCF Tutorial для ознакомления, потом какую-нибудь книжку посолиднее . По технологиям там ничего экстраординарного, а вот правильно спроектировать интерфейс сервиса — этому придется подольше учиться.
LVV>Как отлаживать на одной машине? LVV>Сервер на виртуалке поднять?
Вообще да, будет полезно для проверки взаимодействия. Но в процессе разработки при запуске из студии все будет работать на отладочном сервере с возможностью использовать отладчик для сервиса и клиента.
Здравствуйте, LaptevVV, Вы писали:
LVV>Дык это он и есть. LVV>Абстрактный алгоритм работы теста.
А... с таким же успехом можно почти любую программу обозвать шаблонным методом. Вот только, зачем?
Обычно под шаблонным методом понимают переиспользуемый алгоритм, содержащий какие-то точки кастомизации (через оверрайды/стратегии/trait'ы и т.п.). Что планируется переиспользовать на уровне всего приложения?
LVV>Различия — в деталях: вопросы, ответы, способ обработки.
Эти различия прекрасно обрабатываются на уровне блоков, составляющих высокоуровневый алгоритм. Зачем их вытаскивать наверх?
LVV>Шаблонный метод — подходящий в данном случае инструмент.
Из описания этого не видно. Видно только, что имеет место быть попытка бежать впереди паровоза и принимать низкоуровневые архитектурные решения до того, как будут определены бизнес-требования и описана высокоуровневая архитектура.
Здравствуйте, LaptevVV, Вы писали:
LVV>1. Систему планирую потом использовать только на кафедре. LVV>Пока мыслю — в пределах одного компьютерного класса с базой на локальном кафедральном сервере. LVV>Это примерно 14-15 компов одновременно.
На данном этапе развития индустрии это уже не важно. Сейчас решения для интранета и интернета технически уже не отличаются.
LVV>2. Все добавления-модификации информации буду делать сам или знакомый препод. LVV>Прямо на кафедральном компе. Поэтому новых преподов не нужно регистрировать.
Т.е. для тестирования нужно держать включенной персоналку, а аутентификация преподов тупо по localhost? Плохая, ИМХО, идея. Тем более что ты вроде заявил что цель в изучении технологий.
LVV>В этом деле опыта нет абсолютно. LVV>Наверное, тонкий клиент?
Не знаю. Тебе бы чего хотелось? Десктопного клиента или веб-интерфейс?
LVV>Неужто интерфейс просто ручками в html сваять?
Просто — понятие растяжимое, но мейнстрим где то там.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, andrey82, Вы писали:
A>REST сервис на сервере (WebAPI, C# .NET 4.5 + там много чего готового есть для авторизации и прочих типовых задач)
Вот уж не уверен что для этой задачи оно нужно, особенно если учесть предположительно нулевой экспириенс в JS.
A>Можно вообще не делать сервис а напрямую цепляться к БД из клиентов
Не нужно такое. Безопасность от подобного совсем печальна.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, LaptevVV, Вы писали:
A>>REST сервис на сервере (WebAPI, C# .NET 4.5 + там много чего готового есть для авторизации и прочих типовых задач) LVV>Где читать?
A>>WCF сервис на сервере LVV>Опять же — где читать про взаимодействие клиента и сервера?
LVV>>Различия — в деталях: вопросы, ответы, способ обработки. L>Эти различия прекрасно обрабатываются на уровне блоков, составляющих высокоуровневый алгоритм. Зачем их вытаскивать наверх?
Зачем наверх.
Наверху — абстрактный метод. Который реализуется внизу для каждого конкретного теста. LVV>>Шаблонный метод — подходящий в данном случае инструмент. L>Из описания этого не видно. Видно только, что имеет место быть попытка бежать впереди паровоза и принимать низкоуровневые архитектурные решения до того, как будут определены бизнес-требования и описана высокоуровневая архитектура.
Ну, когда разработка через тестирование начинается, ни о какой высокоуровневой архитектуре речи не идет...
Просто пробуем.
Тем более, что пробуем для освоения инструмента.
И кстати, пробуем архитектуру тоже.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Решил я тут намедни Дотнет с Додиезом и прочими ВПЭФами освоить. LVV>Пенсионер жеж — для собственного удовольствия...
Вообще — ужос и кошмар!
System.Data, ADO.NET, ASP.NET, WPF, WCF — чтобы создать ПРОСТОЕ приложение.
А в какой книжке написано, как создать клиент-серверное приложение 2+2 ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вообще — ужос и кошмар! LVV>System.Data, ADO.NET, ASP.NET, WPF, WCF — чтобы создать ПРОСТОЕ приложение.
Ну так вы определитесь, что нужно в итоге.
Готовый продукт, т.е. штука, которая работает в реальном окружении и решает реальные проблемы?
Или заготовка для разобраться, которая дальше написал-проверил-выбросил не пойдёт?
Бюджет (не в деньгах, по усилиям) разный на порядок минимум.
По факту для обоих вариантов достаточно будет asp.net mvc + любого orm-провайдера, всё остальное — это народ уже увлёкся.
Здравствуйте, LaptevVV, Вы писали:
LVV>System.Data, ADO.NET, ASP.NET, WPF, WCF — чтобы создать ПРОСТОЕ приложение.
И конечно вершина технологий — WTF
Издержки многослойности, что поделать.
LVV>А в какой книжке написано, как создать клиент-серверное приложение 2+2 ?
Эээ... точно хочется просто клиент-сервер (2х звенку)? Как этап в изучении в принципе полезно (из программы к БД обращаться в любом случае придется), но для production так делать я бы не советовал (повторяюсь). В этом случае список сокращается до 2 позиций — минимально понадобится средство для пользовательского интерфейса (WPF ну или даже Winforms) и для доступа к БД (чистый ADO.NET или все-же ORM какой-нибудь, скажем linq2db).
LVV>>Вообще — ужос и кошмар! LVV>>System.Data, ADO.NET, ASP.NET, WPF, WCF — чтобы создать ПРОСТОЕ приложение. S>Ну так вы определитесь, что нужно в итоге.
Дык — откуда же я знаю... S>Готовый продукт, т.е. штука, которая работает в реальном окружении и решает реальные проблемы? S>Или заготовка для разобраться, которая дальше написал-проверил-выбросил не пойдёт? S>Бюджет (не в деньгах, по усилиям) разный на порядок минимум.
1. НЕ ПРОМЫШЛЕННЫЙ продукт.
С целью первоначального освоения и по-совместительству — приносящий некую пользу кафедре в виде психологического тестирования студентов.
2. Поскольку время у меня не ограничено сроками сдачи — продукт можно развивать по мере освоения .
Ну, или в некоторый момент — просто переписать... S>По факту для обоих вариантов достаточно будет asp.net mvc + любого orm-провайдера, всё остальное — это народ уже увлёкся.
orm-провайдер — это вот это: https://ru.wikipedia.org/wiki/ORM ?
Я последний раз с БД дело имел голу примерно в 90-м...
Когда на Клиппере писал. С тех пор — в завязке...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>А в какой книжке написано, как создать клиент-серверное приложение 2+2 ? A>Эээ... точно хочется просто клиент-сервер (2х звенку)?
Да больше и не надо. Может быть, потом — когда-нибудь — появится необходимость.
Но пока я ее не вижу.
Продукт-то — для внутреннего употребления... A>Как этап в изучении в принципе полезно (из программы к БД обращаться в любом случае придется), но для production так делать я бы не советовал (повторяюсь). В этом случае список сокращается до 2 позиций — минимально понадобится средство для пользовательского интерфейса (WPF ну или даже Winforms) и для доступа к БД (чистый ADO.NET или все-же ORM какой-нибудь, скажем linq2db).
Как это в одной проге сделать — я еще примерно представляю.
А как в двух ?
Клиент-то тонкий.
Только данные от пользователя берет и отправляет серверу.
А там принимают и все нужное делают.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Как это в одной проге сделать — я еще примерно представляю. LVV>А как в двух ? LVV>Клиент-то тонкий. LVV>Только данные от пользователя берет и отправляет серверу. LVV>А там принимают и все нужное делают.
Тогда это уже 3 звена (Тонкий клиент — сервис — СУБД). Варианты реализации уже выше написали:
1) Web интерфейс (ASP.NET MVC либо чистый HTML + JS) и сервис ASP.NET (либо WebAPI)
2) Настольное приложение (WPF) и сервис WCF (В виде службы Windows либо в том же IIS разместить).
Здравствуйте, LaptevVV, Вы писали:
LVV>1. НЕ ПРОМЫШЛЕННЫЙ продукт. LVV>С целью первоначального освоения и по-совместительству — приносящий некую пользу кафедре в виде психологического тестирования студентов.
Эва как... ну ок. Допустим, у вас будут результаты тестирования. Что дальше с ними будут делать? По ним будут выставляться оценки, проводиться какой-то анализ, ещё что-то?
У вас запросы из разряда "я хочу сделать что-нибудь несложное... ну, например, боинг". И пока не понятно, речь про модельку, или про покупку компании
S>>По факту для обоих вариантов достаточно будет asp.net mvc + любого orm-провайдера, всё остальное — это народ уже увлёкся. LVV>orm-провайдер — это вот это: https://ru.wikipedia.org/wiki/ORM ?
Любой инструмент для работы с данными. В вашем случае я бы просто начал с класса-заглушки, потом прикрутил бы реальный бэкенд, если дело до этого дойдёт
LVV>>1. НЕ ПРОМЫШЛЕННЫЙ продукт. LVV>>С целью первоначального освоения и по-совместительству — приносящий некую пользу кафедре в виде психологического тестирования студентов.
S>Эва как... ну ок. Допустим, у вас будут результаты тестирования. Что дальше с ними будут делать? По ним будут выставляться оценки, проводиться какой-то анализ, ещё что-то?
Вообще цель — определить список профессионально важных качеств (ПВК) программиста.
ПВК — это такой психологический термин.
Удивительно, но мне не удалось обнаружить общепризнанный явный список ПВК программистов.
Все — вокруг да около.
В огромном количестве статей-книжек описываются разнообразные исследования качеств программиста, но все они делаются по принципу:
— программисты должны обладать вот таким качеством, давайте проверим.
А тут надо по-другому: собрали программистов (или студентов) — и протестировали по всем возможным тестам.
А потом смотрим статистику по качествам и сопоставляем с профессионализмом и успехами в изучении программирования. S>У вас запросы из разряда "я хочу сделать что-нибудь несложное... ну, например, боинг". И пока не понятно, речь про модельку, или про покупку компании
Дык, понимаешь, какое дело...
Слепить настольную систему для одного пользователя — я б и не спрашивал никого.
Это максимум неделя даже на Додиезе — без использования БД, просто на файлах.
А клиент-сервер — это для меня абсолютное новье.
Я ж вообще с БД последний раз имел дело 25 примерно лет назад — тут самая для меня засада и есть.
S>>>По факту для обоих вариантов достаточно будет asp.net mvc + любого orm-провайдера, всё остальное — это народ уже увлёкся. LVV>>orm-провайдер — это вот это: https://ru.wikipedia.org/wiki/ORM ? S>Любой инструмент для работы с данными. В вашем случае я бы просто начал с класса-заглушки, потом прикрутил бы реальный бэкенд, если дело до этого дойдёт
Ну дык я в первом посте написал, что вместо БД пока хочу заместителя использовать...
Дойдет. Я — упёртый...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вообще — ужос и кошмар! LVV>System.Data, ADO.NET, ASP.NET, WPF, WCF — чтобы создать ПРОСТОЕ приложение. LVV>А в какой книжке написано, как создать клиент-серверное приложение 2+2 ?
Это всё детали реализации (Боб Мартин согласно кивает), а ядро приложения у тебя не должно явно от этого добра зависеть. Не вижу проблем спокойно проектировать ядро, а потом уже навесить всё остальное по мере необходимости.
Здравствуйте, LaptevVV, Вы писали:
S>>Эва как... ну ок. Допустим, у вас будут результаты тестирования. Что дальше с ними будут делать? По ним будут выставляться оценки, проводиться какой-то анализ, ещё что-то? LVV>Вообще цель — определить список профессионально важных качеств (ПВК) программиста.
Я вам сэкономлю время. Достаточно всего двух, терпения и способности самостоятельно обучаться. Оба обязательные. Необязательные, но очень нужные — чувство юмора с самоиронией и здоровый цинизм. Всё.
Это если по делу.
LVV>А тут надо по-другому: собрали программистов (или студентов) — и протестировали по всем возможным тестам. LVV>А потом смотрим статистику по качествам и сопоставляем с профессионализмом и успехами в изучении программирования.
Не взлетит. Потому что вы собираетесь корелляцию искать, в стиле "британские учёные обнаружили связь между пиратами и потеплением".
Корелляция работает только для оценки всего множества на основе небольшой выборки и не применима к единичным элементам множества.
Это я не говорю про то, насколько "успехи в изучении программирования" соответствуют реальной профпригодности.
Серьёзно, проконсультируйтесь сначала у социологов. Только у нормальных, а не "диплом есть — значит хирург".
.
Серьёзно. Начните с реальной проблемы и с реального способа её решения. Определитесь, что относится к технической части, что потребует работы с людьми. Убедитесь, что требования выполнимы и что у вас есть ресурсы для каждой из частей.
Если всего этого не сделать, то в конце у вас будет какой-то продукт и целевая аудитория в 0 человек.
Здравствуйте, Sinix, Вы писали:
S>Вот за что я люблю хардкор-программистов. В отличие от девелоперов, к моменту, когда выясняется, что сама задача поставлена неверно
Какие-то тесты, сбор и обработка статистики по результатам тестирования, набор качеств на выходе — вот это и есть ядро, вещь в себе. Остальная часть системы общается с ядром в режиме вопрос-ответ и ядро не волнует откуда пришёл вопрос и куда полетит ответ.
Здравствуйте, Vladek, Вы писали:
V>Какие-то тесты, сбор и обработка статистики по результатам тестирования, набор качеств на выходе — вот это и есть ядро, вещь в себе.
Прелесть ситуации в том, что топикстартеру оно никак не поможет, т.к. поставленная задача если и решается, то точно не предложенным способом, в ответе на тот пост расписал кратко.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>А в какой книжке написано, как создать клиент-серверное приложение 2+2 ? A>>Эээ... точно хочется просто клиент-сервер (2х звенку)? LVV>Да больше и не надо. Может быть, потом — когда-нибудь — появится необходимость. LVV>Но пока я ее не вижу. LVV>Продукт-то — для внутреннего употребления...
Если все настолько просто, то можно не морочится со всякими ADO.Net, WCF, ORM.
Достаточно сделать простой класс с простыми паблик проперятми, описывающим вопрос и в 2 строки сериализовать список этих объев в XML по пути на сервере (или другом компьютере) в расшареную папку, права на которые будут заданы на уровне файловой системы. Для знакомства с основами C# этого будет достаточно и не потребует много времени на разработку.
Здравствуйте, LaptevVV, Вы писали:
LVV>Решил я тут намедни Дотнет с Додиезом и прочими ВПЭФами освоить.
LVV>Тут просится паттерн прокси на место DB. LVV>Поэтому первое, что автоматом сделал — паттерн Шаблонный метод. LVV>Хотя Боб Мартин еще советует посмотреть в сторону Стратегии. Пока неясны выгоды того и другого. LVV>Тут просится Фабрика — это понятно.
Я бы предложил новую парадигму: PDD. Pattern Driven Development. Основная идея данной парадигмы — pattern first, т.е. паттерны должны идти до кода и вообще до и отдельно от любого проектирования. В идеальном случае зилот данного подхода о проекте и его сценариях/проблемах не должен знать вообще ничего.
Как это работает: берёте GoF/Clean Code/... и случайным образом выписываете c десяток-два патернов, после чего пишите их реализацию. Потом берёте реальный проект и запихиваете их туда все, не упуская ни одного. Пусть вас не смущает, что поначалу могут быть неясны выгоды. ̶н̶а̶т̶я̶г̶и̶в̶а̶н̶и̶е̶ ̶с̶о̶в̶ы̶ ̶н̶а̶ ̶г̶л̶о̶б̶у̶с̶ обоснование этих выгод — следующий и финальный шаг данной практики, а вопросы "и как теперь с этим взлететь" выходят за границы применимости и должны быть полностью исключены из рассмотрения.
AVK>В общем случае интерфейсы использовать всегда, когда можно. Абстрактные классы — только когда интерфейсы не подходят.
Вообще не хочу раздувать очередной флейм, но это не единственная точка зрения в природе. FremeWork Design Guidlines как бы намекает нам в разделе 4.3. что последующая поддержка классов, наследованных от других классов проще во многих случаях, нежели чем от интерфейсов, поэтому здесь надо подходить к этому вопросу осторожно
Здравствуйте, Yoriсk, Вы писали:
Y>Я бы предложил новую парадигму: PDD. Pattern Driven Development. Основная идея данной парадигмы — pattern first, т.е. паттерны должны идти до кода и вообще до и отдельно от любого проектирования. В идеальном случае зилот данного подхода о проекте и его сценариях/проблемах не должен знать вообще ничего.
LVV>>Продукт-то — для внутреннего употребления...
V>Если все настолько просто, то можно не морочиться со всякими ADO.Net, WCF, ORM. V>Достаточно сделать простой класс с простыми паблик проперятми, описывающим вопрос и в 2 строки сериализовать список этих объев в XML по пути на сервере (или другом компьютере) в расшареную папку, права на которые будут заданы на уровне файловой системы. Для знакомства с основами C# этого будет достаточно и не потребует много времени на разработку.
Все эти основы я и так уже знаю...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Вообще цель — определить список профессионально важных качеств (ПВК) программиста. S>Я вам сэкономлю время. Достаточно всего двух, терпения и способности самостоятельно обучаться. Оба обязательные. Необязательные, но очень нужные — чувство юмора с самоиронией и здоровый цинизм. Всё. S>Это если по делу.
Ну, я тут тоже составлял список из 5 качеств... http://rsdn.ru/?Forum/?fuid=18459
LVV>>А потом смотрим статистику по качествам и сопоставляем с профессионализмом и успехами в изучении программирования. S>Не взлетит. Потому что вы собираетесь корелляцию искать, в стиле "британские учёные обнаружили связь между пиратами и потеплением". S>Корелляция работает только для оценки всего множества на основе небольшой выборки и не применима к единичным элементам множества.
Ну, у нас в Астрахани дофига наших выпускников, работающих программистами... Довольно успешно работающих. S>Это я не говорю про то, насколько "успехи в изучении программирования" соответствуют реальной профпригодности.
По моим неформальным наблюдениям за 20+ лет — довольно хорошо соответствуют. S>Серьёзно, проконсультируйтесь сначала у социологов. Только у нормальных, а не "диплом есть — значит хирург".
Само собой...
А уж с корреляцией и вероятностью мне тут помогает знакомый доктор-математик, который на этом деле собаку съел. http://www.mathnet.ru/php/archive.phtml?wshow=paper&jrnid=vagtu&paperid=285&option_lang=rus http://www.mathnet.ru/php/archive.phtml?wshow=paper&jrnid=vagtu&paperid=351&option_lang=rus
S>В общем, чутьё снова не обмануло — классическая XY-проблема, она же — проблема мангустов в почтовом ящике
. S>Серьёзно. Начните с реальной проблемы и с реального способа её решения. Определитесь, что относится к технической части, что потребует работы с людьми. Убедитесь, что требования выполнимы и что у вас есть ресурсы для каждой из частей. S>Если всего этого не сделать, то в конце у вас будет какой-то продукт и целевая аудитория в 0 человек.
Да хоть бы и так...
Покуда есть компьютер,
Пока мы с ним друзья —
Мы делать что-то будем,
Иначе жить нельзя!
Не светят нам награды
От фирмы Микрософт.
Но делать что-то надо
Рублей хоть за 500!
(с) Мое...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
S>>Это если по делу. LVV>Ну, я тут тоже составлял список из 5 качеств...
Ссылка в никуда
S>>Серьёзно, проконсультируйтесь сначала у социологов. Только у нормальных, а не "диплом есть — значит хирург". LVV>Само собой... LVV>А уж с корреляцией и вероятностью мне тут помогает знакомый доктор-математик, который на этом деле собаку съел.
Ну так сделайте это. Разработка ПО — это не игра в старкрафт, где "туман войны" это обязательная часть геймплея
Всегда сначала протаптывают тропинку пунктиром от "что у меня есть" к "что я хочу получить", выделяют основные этапы, а затем уже уточняют/корректируют их под давлением обстоятельств.
Вы всё равно всё это будете делать. Вся разница: или получится обходить проблемы _до_ того, как они выстрелят, или будете узнавать про них сложным способом.
Выбирайте
Определитесь, какие данные вам нужны, как вы будете приводить эти данные к сравниваемому виду и как будете искать корреляции. Иначе ближе к концу проекта внезапно™ выяснится, что вы сделали всё, кроме того, что вам действительно нужно.
LVV>>Ну, я тут тоже составлял список из 5 качеств... S>Ссылка в никуда
Я ж нажал — получить адрес...
Ну, вот цитата:
А вообще, давно хотел написать о качествах программиста.
1. Программисты — люди повышенной честности. И профессия еще усугубляет это качество. Ибо машину не обманешь: что написал, то и получил...
Более того, за многие годы преподавания убедился: если студень пытается словчить на лабораторных и/или зачете-экзамене — из него программиста не получится... Жизнь подтверждает: такие пацаны уходят в другие области. Часто в предприниматели...
2. Программисты — клинические оптимисты! Без оптимизма невозможно отлаживать программы. Программист всегда уверен, что программа вот сейчас заработает.
Вот уже одна маленькая последняя ошибка осталась...
Пессимисты в нашей профессии плохо приживаются. Собственно, мне и не попадалось таких.
3. Программисты — супернастойчивые люди. Додолбить программу до рабочего состояния — это надо быть очень упертым.
Опять же, если у человека это качество отсутствует, то програмист из него не получится.
4. Программист естественно должен обладать аналитическим складом ума. Ибо требуется много анализировать: и предметную область, и поведение программы.
5. Для программиста внутренняя мотивация важнее внешней. Люди, у которых внешняя мотивация (карьера, заработки...) превалирует — со временем уходят из программирования в манагеры-предприниматели-руководители...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, вот цитата: LVV>А вообще, давно хотел написать о качествах программиста.
А, ну так вы о программистах, они не нужны нынче никому уже, только разработчики. Писал уже.
Без обид, не девяностые как бы. Программисты-кодеры "моя писать код" уже никому не нужны. Нужны разработчики. Разница — тынц. Или, в одно предложение: разработчик — специалист, способный самостоятельно довести идею до реализации в состоянии, готовом для отправки клиенту.
Т.е. как минимум первые ваши два пункта точно не подходят, остальные — с натяжкой. Здесь оффтоп, если есть желание — выделите отдельную тему, продолжим.
. По технологиям там ничего экстраординарного, а вот правильно спроектировать интерфейс сервиса — этому придется подольше учиться.
