Станислав Макаров

Джун джуну рознь. Чем больше знаний - тем лучше.
Троелсен и правда очень медленно и педантично повествует. Он удобен как настольная книга джуниора, как справочник - по конкретным задачам копать. Но, ИМХО, Шилдт будет приятнее.

Основные контейнеры - преимущества и недостатки. Сложность алгоритмов поиска и вставки, сортировки. Хэш-таблицы, хэш-код объектов, equality и как это все устроено. Неплохо бы знать про многопоточность и примитивы синхронизации (в общих чертах).
Хорошо бы знать кое-что про платформу .NET - типы-значения и ссылочные типы (про стек и кучу), про GC с поколениями, SOH/LOH, как можно устроить утечку памяти -> IDisposable.
Уметь делать запросы к базе через голый ADO.NET.
По базам данных: владеть основными запросами SQL, писать и вызывать хранимые процедуры. Знать что такое и зачем нужны индексы, нормализация, View, где смотреть query execution plan.
Суметь рассказать о том, что такое MVC, ориентироваться в основных паттернах.

Если курс на веб, то понимать работу HTTP, REST, знать основы фронта (приоритет селекторов в CSS, "всплывающие" объявления переменных в javascript, разницу "==" и "===", чем отличается асинхронность от параллельности и чем это грозит).

Вызовет уважение в глазах интервьюера: понимать и применять IoC/DI, уметь писать тесты, работать с ORM (EntityFramework допустим), async/await и SynchronizationContext.

В идеале второй вариант, если это возможно.

Скажем я на своих проектах пытаюсь делать так насколько это возможно. Перед началом разработки какой-то фичи разработчики просто договариваются между собой как будет организовано взаимодействие с сервером (по сути пишется описание API на каком api blueprint, сейчас будем переходить на raml).

После чего из этого описания разработчик серверной части может спокойно генерить себе тесты, json схемы респонсов и т.д. что бы быть уверенным что он делает так как договаривались, а мобильщики могут поднять себе из описания mock сервер.

Таким образом какие-то проблемы с серверным взаимодействием можно отловить задолго до того как разработчики в принципе реализуют эту часть api. Хотя если разработчики не используют какие-то средства для валидации реализации на предмет соответствию описанию, то в итоге на интеграцию может уйти больше времени.

p.s. этот подход я форсирую еще и потому, что при таком варианте можно легко наладить кодогенерацию как для клиента так и для бэкэнда. Скажем валидация запросов, маршрутизация, мэппинги и т.д. - все можно сгенерировать. RAML в этом плане дает из всех форматов максимальную гибкость, и поэтому я и планирую на него переходить. В очень простых случаях можно сгенерировать код хоть всего бэкэнда, но и так в целом скорость разработки неслабо увеличивается.

Ethereum

Нету никаких проблем.
Если только ваше конкретное используемое для ваших задач ПО нормально работает с Windows.

Например, в моем случае используется Ansible и Docker, который не поддерживается на Windows. Приходится использовать Vagrant. Это достаточно удобно. Но ресурсы все же кушает.

А так - даже Vim хорошо себя чуствует на Windows. Нативный. Не cygwin.

Microsoft это тоже понимает.
И вот уже они встроили подсистему Linux Ubuntu в Windows 10. Это не виртуализация, а именно полноценная подсистема.

И многие вещи, например, те же шрифты - в Windows работают лучше, чем под Linux.

Могут сказать - что лучше использовать для разработки ту же среду что и для production.

Но дело в том, что даже если вы сидите на Ubuntu Desktop, то ваша среда серьезно отличается от среды сервера FreeBSD, CentOS, Debian, Ubutntu Server. И для полноценного CI все равно умные дядьки категорически рекомендуют и на Linux даже использовать Docker для полноценной эмуляции.

Но ведь Docker-то можно использовать и на Windows. Правда, запускается он там подольше.

Где именно вести разработку, где вам удобнее - это ваше личное дело. Вопрос ваших предпочтений. Никаких объективных причин в наше время, когда существуют Docker, Vagrant и виртуальные машины, когда куча приложений изначально сделанных для *nix запускаются в native под Windows - нет никаких причин себя строить. Кроме любопытства - а как оно там на других системах живется.

У тех кто вас троллит есть еще одна причина: им приятно показать себя более умными. Как же - ведь Linux можно сконфигурить руками.

Ага, конечно.

Или используют готовые десктопные дистрибутивы. Не зря Ubuntu так популярна.
Или если освоили ArchLinux - то построили себе совершенно убогое окружение по готовым мануалам.

Чтобы действительно набрать скиллы ручной настройки Linux - нужно огромное количество упроства и времени, чем ваши друзья, которые вас троллят, вряд ли обладают.

На деле 99% твердящих о гибкости Linux - далее чем ставить Apache и MySQL из пакетов - ничего сами и не умеют. Фактически работая в то же настроенной другими людьми десктопной среде. Но разве вы не умеете делать то же самое под Windows?

Другое дело, что разворачивать и тестировать нужно под аутентичным операционным окружением.
Неважно под Ubuntu ты сидишь или под Windows.

Лучшие практики советуют использовать полностью изолированный и независимый от рабочего места разработчика инструментарий - виртуальные машины, Vagrant, Docker, отдельные физические сервера.

В этом случае под твоей любимой ОС работает только текстовый да графический редактор. А все развертывание для тестирования и для продакшн проводится в совсем другой среде.

Используя Docker хоть под Windows ты будешь получать даже больше преимущество повторяемости рабочей среды чем тем кругом, кто советуют тебе просто перейти на Linux. Если на более слабом железе это и было бы существенно (Docker под Linux стартует быстрее), то на твоем - несущественно на чем работать.

Сделал пока через user defined guard functions:
https://github.com/Microsoft/TypeScript/issues/1007

public static isIdentifierNode (node: ITreeNode): node is IIdentifierNode {
    return node.type === 'Identifier';
}

estraverse.replace(catchClauseNode.param, {
    leave: (node: ITreeNode, parentNode: ITreeNode) => {
        if (NodeUtils.isIdentifierNode(node)) {
            this.catchClauseParam.set(node.name, Utils.getRandomVariableName());
            node.name = this.catchClauseParam.get(node.name);

            return;
        }

        return estraverse.VisitorOption.Skip;
    }
});

Никак
Определить код в разные репозитории

ты сломал тостер)

А вы не задумывались, зачем вообще фреймворки нужны?
Чтобы ускорить разработку - срубить больше бабла в те же сроки.
Они запросто могут сами их использовать для создания сайтов по заказу.
Фреймворк может быть разработан прямо в рамках одного из крупных и не срочных заказов, по принципу "долго запрягаем, потом быстро едем".
Напротив, если автор фреймворков не создает сайтов на своем фреймворке, а сам фреймворк написал с бухты-барахты, то очень сомнительно, что фреймворк будет на что-то годиться - у него же нет опыта.

Взять тот же Laravel:
- Как минимум 3 сопутсвующих ПЛАТНЫХ проекта (forge, spark, envoyer).
- Конференции с нехилым ценником.
- Консультации
- Не уверен, но возможно laracasts что-то отстегивает.

И так же у многих крупных OpenSource проектов. Заработок идет на enterprise решениях на основе их проекта. (Та же платная поддержка).

Некоторые (на вскидку не вспомню) OpenSource проекты получают финансированние от крупных организаций (Google, Yahoo, Microsoft, IBM).

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