EvgMul: хороший код является хорошим по какой-то причине. Код с хорошо названными переменными легче читается, поэтому он хороший; код, в котором методы изменяют передаваемые параметры - плохой, потому что при чтении эти изменения неявные. Код без перехвата исключений - плохой, потому что программа падает. Код без волшебных констант хорош, потому что читается и изменяется проще. Хороший код - следствие.
Еще один момент: нельзя оценить всю прелесть IoC-контейнеров, если не оценил DI, которое трудно оценить не познав модульное тестирование (либо не прозанимавшись развитием проекта в течении пары лет). Всему свое время.
Еще момент: читая код, мы иногда видим следствие, но не видим причин. В итоге мы не знаем, хороший код перед нами, или нет.
Еще момент: то, что подходит в одном случае, не подойдет в другом. Для больших проектов со многими связями в предметной области может подойти BDD. Для небольшой консольки это будет лишь неоправданное усложнение.
Еще момент: часто нужен код не красивый, а рабочий, и быстро написанный. Красота требует жертв, в нашем случае времени. Как-то на хабре один товарищ пропагандировал "Модульно-костыльную разработку", когда интерфейсы делают грамотными, а реализацию - костыльную. Этот товарищ явно ценил время.
Короче, сама идея "почитать красивый код" не слишком удачна. Лучше почитай "Совершенный код" Макконнелла. Классическая книга про хороший\красивый код, с пояснением, почему именно код красивый. А перед этим "Рефакторинг" Фаулера (который чуть проще).
EvgMul: Чтобы писать свой код хватит редактора и компилятора (хотя с IDE удобнее). Код не обязан быть красивым, первое время. Чужой код частенько непонятен, и красоту его вы один фиг не оцените. Некоторые моменты крайне тяжело понять, не зная мотивов. Некоторые лучшие практики иногда используются по привычке в проектах, не совсем для этого предназначенных.
Станислав Макаров : Создал игру в героев, выскочили окошки винды с требованием разрешить приложению доступ к сети и т.д.
После разрешения сетевая игра доступна.
Однако, в героях режим tcp\ip, и при запуске моих приложений подобных сообщений не показывается.
Станислав Макаров: другой сервис - это какой? Написать еще один тестовый сервис, или сетевую игру для героев создать?
Firewalls have been disabled.
Пинг проходит.
"не для моего уровня". Дурак. Ты всерьез думаешь, что языки программирования для нормальной разработки делают на подростковом уровне? Или что есть язык, изучаемый за 21 день? Есть такие, Delphi 7 и PHP. (Как зачеркивать слова в комментариях?)
Паскаль создавался как раз для обучения. Можешь юзать. Изучать до тех пор, пока не будет понятна "большая часть", а не "что-то". Если чего-то не понимаешь - донимай препода, пускай объясняет. Или дает задачи (на циклы, функции, условия, процедуры, и т.д.), и через неделю помогает разбирать. Решив сто однотипных задач, начнешь тему понимать.
Итого: подходишь к преподу, берешь у него 4 задачи, пытаешься решить. Если не получается за неделю - подходишь, просишь показать и объяснить решение, берешь еще 4 задачи, пытаешься решить. Если не получается за неделю... ну, ты понял.
Обязательно попроси препода или другого знающего человека показать тебе что такое дебаг. Дебаж решения, свои и чужие. Обязательно с просмотром текущих значений переменных (полей\свойств).
Язык - любой. Тот, который известен преподу.
Забудь о том, что ты подросток. В программировании это не важно. Не называй себя чайником. Чайник - это не смыслящий в теме человек, и это навсегда. Называй себя падаваном. Тоже не особо соображает, но работает, чтобы стать мастером.
Если не идет программирование - изучай HTML\CSS. Потом попробуй JavaScript.
Станислав Макаров в обоих конфигах стоит адрес 192.168.0.101. Использование http://+:8733/ вызывает ошибку во время запуска: + не может использоваться в качестве базового адреса, только абсолютный адрес.
Mrrl Не уверен, что размер листа меняется автоматом. Если память мне не изменяет, у листа массив лежит под капотом (при условии, что мы говорим о шарпе). Плюс, можно, задать "ожидаемое количество элементов" в конструкторе листа (capacity?).
Agrigattor в моей текущей работе практически не нужны знания из университета. Два исключения: английский, и психология. При всем при этом, я не могу вспомнить предмет, который был для меня полностью бесполезным. Учи все. Не обязательно все на "отлично", достаточно уверенного трояка на нелюбимых предметах. Просто знай, какие темы есть, и, в общих чертах, как они решаются.
Кроме того, посмотри\почитай-таки речь Джобса перед выпускниками.
Удачи.
Антон Папин: Не. Вариант типа public class WrapperForAllFreeWithouSMS{ public T Item; }: в сериализованном виде получим ... . Можно повесить атрибут на Item, но его значения должны быть константой времени компиляции. Даже если я буду изменять ElementName во время (де)сериализации - это тоже самое, что удалять\добавлять теги, только чуток сложнее.
В теории, в VS 15 с nameof() могло бы прокатить (не уверен, что nameof() работает с типами).
Антон Папин: Да, обертка вполне подошла. По большому счету, производительность дело десятое. Проблема в том, что придется добавить 60 классов оберток. Или один класс наследник, наследники которого отличаются лишь значением атрибута. В принципе, это можно было автоматизировать, в билд-сценарий добавить инструкций, или T4, но сложность решения не оправдана.
Идеального решения (короткого, читаемого, легко поддерживаемого) не нашел. :(
Антон Папин: Удобство важнее.
Я создаю обертку над API, чтоб коллегам не нужно было задумываться о деталях коммуникации. В принципе, сейчас обхожусь обертками (дольше вырезки\врезки тэгов в сериализаторе, но проще для чтения\понимания).
Дмитрий Ковальский: "clr via c#" - это далеко не примерный уровень понимания .net. Да и джуниоров бояться - в лидЫ не ходить. :) В конце концов, через пару недель\месяц работы уже видно, на что способен новичек. А дальше либо увольняют его, либо на другое место (консультант, тестировщик, еще куда) переводят, либо на конкретные задачки.
прочитанная и понятая "CLR via C#" - это слишком для новичка. Вполне можно джуниорить с первой половиной Шилдта, SQL запросами на уровне JOIN-ов, и без знания целевой платформы.
Еще один момент: нельзя оценить всю прелесть IoC-контейнеров, если не оценил DI, которое трудно оценить не познав модульное тестирование (либо не прозанимавшись развитием проекта в течении пары лет). Всему свое время.
Еще момент: читая код, мы иногда видим следствие, но не видим причин. В итоге мы не знаем, хороший код перед нами, или нет.
Еще момент: то, что подходит в одном случае, не подойдет в другом. Для больших проектов со многими связями в предметной области может подойти BDD. Для небольшой консольки это будет лишь неоправданное усложнение.
Еще момент: часто нужен код не красивый, а рабочий, и быстро написанный. Красота требует жертв, в нашем случае времени. Как-то на хабре один товарищ пропагандировал "Модульно-костыльную разработку", когда интерфейсы делают грамотными, а реализацию - костыльную. Этот товарищ явно ценил время.
Короче, сама идея "почитать красивый код" не слишком удачна. Лучше почитай "Совершенный код" Макконнелла. Классическая книга про хороший\красивый код, с пояснением, почему именно код красивый. А перед этим "Рефакторинг" Фаулера (который чуть проще).