Evgeny Maltsev

Привет! Обе книги из топика отличные и хорошо переведены. Что касается паттернов - их проблема в том, что многие примеры высосаны из пальца (а иначе никак). Изучая паттерны, у новичков возникает обычно две проблемы: 1) о, я понял как это работает, надо запихнуть этот паттерн тут, здесь, там 2) я не понимаю где вообще это можно использовать. Обе проблемы возникают из-за нехватки реального опыта. Лично я эту книгу изучал раза три с промежутками в год. И с каждым разом вышеописанных проблем становилось меньше и меньше. По поводу Крэга Лармана: я считаю эту книгу надо читать если Вы решили шагнуть на следующий уровень, уже имея как минимум 3+ года опыта. На Вашем месте я бы в фоне конечно изучал всякие абстрактные приёмы, паттерны, но основной упор сделал бы на изучение лучших практик именно в вашей области разработки, ведь именно они в будущем и будут рассеивать непонимание тех же самых паттернов.

Думаю можно разбить на несколько пунктов, чтобы понять "1С или не 1С":

1. Зарплата. По моим ощущениям, сравнивая 1С'еров и остальных программистов в России вообще, у первых средняя зарплата будет выше.
   
2. Вкусовщина. 1С подходит только тем людям, у которых код на русском языке не вызывает отвращения :)
   
3. Специфика. Франчайзинги 1С особо не парятся над распределением обязанностей программиста. Если ты программист, то сможешь и сам заказчику позвонить, и техподдержу по своему продукту оказать, и показать куда жать, и с бубном сплясать. Сужу только по своему городу, может и есть конторы, в которых этот момент организован правильно.
   
4. Комьюнити. 1С преимущественно используется русскоговорящими, а значит и размер сообщества программистов в глобальном масштабе небольшой. То есть на решение каждого вопроса у программиста 1С будет уходить в среднем больше времени, просто потому что в мире не так много людей, способных помочь.
   
5. Перспективы. Если ты знаешь только 1С, то автоматически становишься невыездным, так как найти работу программиста в другой стране будет уже сложно (но это важно не для всех, естественно). А в целом 1С, как и Ленин: жил, жив и будет жить.
   

Привет! Например, так.

public interface IEntity<TId> where TId : struct
{
    TId Id { get; set; }
}

public class Person: IEntity<int>
{
    public int Id { get; set; }
    //другие поля
}

public abstract class GenericRepository<TEntity, TKey>: where TKey : struct where TEntity :  IEntity<TKey>
{
    internal ApplicationDbConext context;
    public GenericRepository(ApplicationDbConext context)
    {
        this.context = context;
    }

    //сделаем глупый метод, чисто для примера	
    public async Task<TEntity> FirstOrDefaultAsync(TKey id)
    {
        return await сontext.Set<TEntity>().FirstOrDefaultAsync(x => x.Id.Equals(id));
    }
}

public class PersonRepository: GenericRepository<Person, int>
{
    //методы для PersonRepository
}

Как уже говорили выше, статические методы относятся к классу в целом, а не к конкретному объекту. Что касается производительности: если сравнивать обычный метод внутри класса и статический, то статический будет работать быстрее из-за того, что не тратятся ресурсы на инициализацию конструктора. Но, сами понимаете, обычно это никакого существенного буста в производительности не даёт.

Это даже не ошибка, а варнинг. Как правило, если установленная версия ангулар выше, чем указанная в варнинге, то обычно это можно игнорировать. А вот если ниже, тогда вероятно лучше обновиться.

Конкретно в этом случае это скорее всего никак не связано с проблемой стилей.

Менять IP-адрес дроплета

Раз 5 менял в надежде, что новый айпишник не попадёт в список заблокированных, но безуспешно. Или я такой невезучий.

Привет! Можешь посмотреть на гибридное решение EF+Dapper.

Я бы на твоём месте задал себе несколько вопросов. Во-первых, нужно ли вообще высшее образование. Учитывая уровень подготовки в типичном ВУЗе, на выходе ты обычно получаешь: общее понимание архитектуры ПК, какие-то знания по сетям, построению систем, проектированию, немного программирования и никаких знаний по конкретным технологиям и практикам, которые нужны на работе. Во-вторых, если всё-таки нужно, то подумай над заочкой. Как правило, нужно быть совсем деревом, чтобы её запороть, потому что преподы занижают требования к заочникам. И совет: отнесись более скептически к понятиям джун/мидл. Работу получают не джуниоры и мидлы, а люди, у которых есть знания в каком-то стеке. Помониторь вакансии, которые нравятся, смотри на требования и работай над собой в этом направлении. Удачи!

Из самого простого можно посоветовать использовать precompile во время публикации и/или фичу auto-start в IIS. Обычно этого бывает достаточно.

Много полезного в самих доках майкрософта, можно посмотреть на блог/курсы/книги Julie Lerman, но тут надо на версию EF смотреть. А из свежего понравилась вот эта книга по EF Core.

Как вариант: ту часть конфига, в которой прописываются всякие path, вынести в отдельный файл. А в основном конфиге просто использовать линк на этот файл. После этого нужно, чтобы каждый из разработчиков исключил этот файл (предположим paths.config) из обновления гита командой git update-index --skip-worktree paths.config. Теперь этот файл можно менять локально и его изменения трекаться не будут.

Хороший туториал есть на metanit по asp.net mvc/core. А если нет проблем с английским, то попробуйте курсы на pluralsight, там можно сделать 3 месяца бесплатной подписки.

Привет! Мне кажется Вы зациклены на производительности. Все перечисленные языки не были бы столь популярны, если бы их производительность в среднем не покрывала требования пользователей и разработчиков. Уверен, что написать движок можно на любом из них.

Строуструп в своей книге «Программирование, принципы и практика с использованием C ++» сказал, что лучше использовать C ++ без готовых решений.

По поводу API и библиотек: они используются почти везде и, скорее всего, в Вашем проекте тоже будут. Не читал Страуструпа, т.к. это не мой профиль, но предполагаю, что он мог сказать подобное в академических целях либо в то время, когда разработка преимущественно была направлена на написание своих решений с нуля. В реальных проектах всё не так, зачем заново открывать африку если уже есть хороший функционал и им можно воспользоваться. Конечно, это не касается тех задач, когда, например, пишутся чистокровные фреймворки. Но Вы уверены, что Вам нужно именно это? Особенно не имея хорошего опыта.

ИМХО, если Вас интересует именно реализация алгоритма, то незачем париться насчёт доступа к памяти и производительности, по крайней мере пока.

C # - хорошее решение для Windows. Но он привязан к NET.

Немного позащищаю здесь c#. Майкрософт сейчас движется в нужном направлении кроссплатформенности, посмотрите на net core.

Не хочу, чтобы казалось будто я топлю только за c# :) Просто хотел развеять некоторые заблуждения и поделиться тем, с чем знаком. Мой совет: попробуйте разбить проект на небольшие части и начните его реализовывать, многие вопросы отпадут.

a.GroupBy(x => x)
	.Where(x => x.Count() > 1)
	.Select(x => x.First())
	.ToList()
	.ForEach(Console.WriteLine);