xXNullXx

корпоративные приложения

Поучите голый ADO.NET и какую-нибудь ORM-ку, да хотя бы EF. Еще можете хотя бы начать ASP.NET, вероятность попасть на него на первой работе достаточно высокая.

финансы, банковская сфера

Подтяните теорию по реляционным БД. Ведь какие финансы без транзакций!) Вы должны хотя бы знать о таких понятиях, как изоляция транзакций, представлять в общих чертах как на SQL можно сделать какую-нибудь выборку с агренированием. Никто конечно в здравом уме не даст джуниору непосредственный доступ к сколь-либо значащим данным, отражающим реальные денежные балансы, но ваша осведомленность пойдет вам на пользу, иначе рискуете клепать интерфейсики ближайшие несколько лет. А, ну да, выясните, почему нельзя вот так считать проценты по кредиту:

float interestRate = 0.13 // ставка
float interestSum = interestRate * sum;

геймдев

ну это отдельная история.. Несмотря на обилие высокоуровневых инструментов, не мешало бы знать основы графики (цветовые модели, граф. конвейер, что такое вершинный шейдер), алгоритмы на графах, популярные структуры данных и основы геометрии (без матриц никуда, хоть стреляй).

И еще для всех направлений: станьте более-менее самостоятельным в вопросах деплоя. Вы должны в общих чертах представлять, что находится внутри дотнетовской сборки, как работает версионность и что может пойти не так. Ну и про NuGet я надеюсь вы уже знаете.

Джун должен точно знать что не все в работе программиста - это программирование. Если вы можете легко и связно изъяснятся, понимаете цикл разработки (описание-согласование,разработка, тестирование, интеграция) приложения и умеете читать(!! дада, многое что нужно действительно прочитать и сделать именно так), то у вас уже есть 50% успеха.
По программированию, то что вы можете прям быстро-быстро освоить:
asp.net webforms + EF5+jquery
WebForms -действительно очень старая технология на данный момент, все просто фанатеют и бегают как угорелые за ASP.NET MVC. Но въехать сразу что куда там и как, джуну будет сложно (некоторые мидлы тяжко переваривают, хотя как по мне так все просто там, не зря ж модели основанные на MVC самые распространненные в мире : MVC, MVVM, MVP, MVT).
С EF особо не извращайтесь (например с полной моделью дб). Возьми(те?) EF6 + code first, например, "хау ту" из гугла, и пройдитесь по мануалу. Создав приложение например, которое создает-отображает-модифицирует-удаляет записи из бд, открывайте Management Studio и смотрите что у вас получилось в бд. Напишите запросы на выборку данных соединенных из двух таблиц
Если после проведенных действий вы уже можете написать запросы INSERT, SELECT, UPDATE, DELETE, то уже хорошо, никто не будет от вас ждать глубоких знаний SQL, но и теряться при виде хоть мало мальски сложно запроса нельзя. Плюс как сказал Станислав Макаров, нужно знать что такое транзакции и с чем их есть.
У вас уже не должно вызывать ужас в глазах, приложение которое может это все делать и вы ориентируетесь в его коде. По asp.net'у научились использовать n-ое количество контролов: открываете список всех webforms контролов и прям по списку берете каждый и используете. Если вы будете представлять что есть такие-то и такие-то контролы, то вам будет легче не городить адовые конструкции из таблиц и всяких повторителей.
По самому .NET: один из самых популярных вопросов "что появилось в .net версии %version%?" Поэтому чтобы не потерятся при ответе на такой вопрос, гуглите примерно так

• Что появилось в .NET 2.0
  
• Что появилось в .NET 3.0
  
• Что появилось в .NET 4.0
  
• Что появилось в .NET 4.5
  

Еще очень популярная технология для шарпистов - это WCF. Если скилла написать простенький сервис не хватит, то хотя бы почитайте что это такое и с чем его едят.

Из книжек, которые можно посоветовать одна из моих любимых это Троелсен. Достаточно качественно объясняет и легко чтобы сразу взять и въехать.

Ну и плюс все что выше описали, достаточно хорошие советы. Походите по ссылкам, почитайте статьи, посмотрите курсы. И самое главное если вы еще не начали, то начинайте учить английский. Грамматика в первую очередь. Банально составлять предложения это ОЧЕНЬ ВАЖНО. Вас никто не поймет если вы будете писать по-русски английскими словами, а вы будете если не возьметесь за грамматику сразу, наравне с программированием.

Только что закончили проект на связке ASP.NET MVC + WebApi + AngularJS. Получилось очень клёво. Логика такая: MVC-котнтроллеры возвращают только чистую вьюшку с разметкой для AngularJS, тот обращается к WebApi, получает в JSON данные, ну и мапит на вьюшку. И при изменении данных шлёт их в JSON обратно к WebApi.

Плюсы:
1) Чёткое разделение на слои логики. WebApi-контроллеры покрываются юнит-тестами.
2) Чёткое разделение работы клиентских и серверных разрабов. До разработчика клиентского кода доходят только интерфейсы моделей, причём уже гарантированно работающие, т.к. проверяются тестами.
3) Внешние сервисы (с которыми мы интегрируемся или, в перспективе, мобильное приложение) интегрируются с тем же api, с которым работает сам сайт.

Минусы:
1) Требуется дописать приличное количество клиентской логики для корректного отображения ошибок валидации.
2) Большие страницы (а в нашем конкретном проекте на одной странице отображалось несколько вьюшек с разными api-контроллерами) подгружаются достаточно долго: сначала отображается пустая страница, затем первая часть, спустя пару секунд ещё и т.п. Но это больше вопрос оптимизации чем AngularJS

В настоящий момент С# (asp.net) имеет целый ряд преимуществ над тем, что нам дает Java (в плане удобства и синтаксиса языка). Это правда!

Проблема заключается в том, что Java появился раньше, Java был открытым для использования на Linux. В итоге под сервера на Java написали огромный список уникальных решений, которые сейчас используют топовые команды (посмотри, что такое хадуп, например). В итоге, компании либо не видели смысла переписывать все на C#, так как уже имели билды на Java, либо не хотели тратить время на разработку того, что уже есть на Java.

Именно по этой причине Microsoft сейчас активно начинает спариваться с Linux и везде кричит, что они его любят.

Что касается текущего состояния, то сейчас достаточно много компаний, кто начинает писать свои системы на С# (asp.net) - чаще всего новые компании, например, Додо-Пицца. Но старички с Java уже просто не слезут.

Контейнер хранилище зависимостей. Контейнер служит для разрешения зависимостей, те говорит какую конкретную реализацию подставить. У вас зависимость может быть интерфейс - класс реализация интерфейса, класс - наследник класса, просто класс. Так вот при регистрации вы сопоставляете тип и конкретную его реализацию.
Например

container.Register<IRegisterServer,DbRegisterService>();
container.Register<RegisterVieModel>();
.......
//Конструстор ViewModel
void RegisterViewModel(IRegisterService service)
{
}

Так вот, когда у ioc контейнера вы запрашиваете RegisterViewModel, он смотрит на параметры конструктора и в соответствии с типами в нем зарегистрированными, создаёт и подставляет в конструктор соответствующие типы. Зачем это надо, вы в любой момент можете поменять реализацию или сделать несколько реализаций и регистрировать их в зависимости от параметров запуска или ключей реестра. А вообще инверсия зависимостей служит для избавления кода от связанности. В примере выше, в VM используется не конкретный класс, а некий тип, описанный интерфейсом, если вам надо поменять реализацию, то вы поменяете только строчку реализации, а класс VM останется без изменений. На небольших проектах может и не заметна выгода, но в больших, над которыми несколько человек, даже очень.

у меня на проекте тим лид ставит запятые в начале строки, типа

Method(int a
, int b
, int c)

хочется пристрелить. Я понимаю в SQL там так делают, чтобы по быстрому глянуть там данные, но в С# то чего глядеть?).
А еще никто не парится и пишут строки длиной в столько символов, сколько захочется. Я находил и по 400-500.
В общем я это все правлю когда работаю в методах с чужим кодом, но блин они снова пишут). Я спрашиваю, ребята, у вас мониторы 50 дюймов? Вы, bla, как просматриваете код, маслите мышкой туда-сюда? Смотрят на меня своими филлипинскими глазами в очках и улыбаются...

Для меня очевидно, что это писали бывшие разработчики на C/C++. Это древняя нотация, многие называют ее венгерской, только тут какой-то извращенный вариант (надо сказать, что и саму венгерку правильно применяли единицы в свое время, большинство не понимало до конца ее смысла). Сейчас так не пишут и на самих плюсах, для шарпа же это моветон. Выдает нотацию n перед именем индекса (это значит именно "индекс", а не int, правда обычно пишут nUnit или nEmployee, а не nIndex) и C перед именемами классов.

Если есть нормальная IDE, то венгерская нотация нафиг не нужна, код превращается в рябь из смеси сокращений, которые только раздражают

Совершенно согласен с вами.

Не такие уж опытные ребята писали этот код, и они точно не в ладах с оформлением кода в C#. Вероятно, писали давно, когда C# еще появился, и все C++ программеры начинали писать на нем, сохраняя все свои привычки, многие из которых не нужны или даже вредны.
То, что разные классы по-разному оформлены это не еще не большая беда, далеко не всем проектам удается поддержать одинаковый стиль (хотя оно того стоит конечно).

Почти все классы в основном проекте лежат, никаких папок и соответствия им нэймспэйсов (за редким исключением).

Это тоже из плюсов - нормальные люди конечно пользуются неймспейсами, но там они не настолько вездесущи, как в C#, т.к. технология сборки в принципе иная.

А у вас было подобное? Вы как-то решали эту проблему?

А это кроме вашей команды во главе с тимлидом и даже с привлечением менеджеров никому не решить. Если вы готовы отрефакторить половину продукта - вперед. Не готовы - лучше не трогайте. Пишите новый код в адекватном стиле. Если бы это был C++, я бы даже вам посоветовал новый код оформлять по правилам проекта, но ЭТИ правила в рамках C# неадекватны совершенно.

Резюмирую: если нет ресурсов на переработку кода - терпите. Терпение и способность работать с legacy кодом не самого высокого качества - вероятно самая важная черта "программиста в команде". Старый и не самый симпатичный код - это реальность, это так же реально, как и ветхие здания, которые просто так не перестроишь без серьезных вложений.

Работал в одной организации полтора года, написал сам несколько проектов. код в плане оформления просто чуть ли не идеален. Без всякой чуши типа венгерской нотации и т.д.

Вам везло в плане качества кода. Теперь не очень повезло. Как сказал AtomKrieg, хорошо что не Кобол (хотя б тогда вам платили еще больше).

Над методами простые комментарии, а не XML или их вообще нет

Нормальные XML-комментарии в C# коде это вообще роскошь. Я их вижу только в серьезных библиотеках, а во всяком корпоративном треше так комментятся только самые важные классы в программе (штук 10-15). Радуйтесь, что вообще есть документация. Если есть желание и время - переносите в код, это наверняка будет полезно.

Увеличить вес изображения можно комбинацией из 3 пунктов:

1. использовать неэффективный алгоритм сжатия - тут вы ограничены предлагаемыми форматами, выясните какой из них самый неэффективный;
   
2. использовать как можно больше цветов - опять же всё зависит от конкретного изображения, возможно наложение градиента даст прирост к весу
   
3. увеличить размер изображения - ясен пончик, что чем больше пикселей, тем больше вес
   

Но это, конечно, какое-то извращение...