Оплата в некотором университете из топ-листа РФ для ассистента - 200р примерно за час. Оплата в физмат школах для преподавателя - 400р за час. Это официальное трудоустройство, но без доп нагрузок типо поработать в деканате / сводить детишек на экскурсию и т.д. Ах, да, это Москва.
Единственное, что вызывало у меня опасение - это код, написанный ChatGPT. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем программисты, использующие ответы от чат-бота. Я знал, что рано или поздно мы перейдем и на эту дрянь ради достижения лучших KPI.
Cloudflare уже часто под блоки попадает, то одна подсеть, то другая. Wikipedia можно сделать зеркало. Youtube сейчас пытаются проксировать. Github можно оставить по талонам для IT-компаний.
Синхронизация данных 1С с помощью флешек и в 2023 чуть ли не самый частый способ в мелких предприятиях. Особенно если учесть, что 1С обычно в локалках сидят, а для связи с другими компами нужно VPN поднимать.
Вполне возможно, что это информация ради информация, чисто воды налить. Так на википедии, например, добавляют ссылки на года. Читаешь предложение: "Карл V пришел к власти в 1835 году". Тыкаешь на "1835" чтобы узнать как это произошло, а там статья со списком никак не связанных между событий, произошедших в этом году. Так и тут, можно было еще знак зодиака добавить.
Это, кстати, не логическая задача, а математическая на знание длины окружности. Непонятно только, зачем это знать синьору-помидору, но вообще обычно L ~= 3 D знают все
Имеет самое прямое. В статье можно наблюдать все проблемы, отсутствие которых считается достоинством нормализованных бд. Собственно, я по заголовку и при постановки проблемы сразу ожидал решения "мы вынесли жанр в отдельную таблицу". Но почему-то вместо этого один костыль заменили другим...
Я торговался минут 30 с ними, но так и не получилось уговорить на 1 месяц за 7к (деньги, на которые я согласился бы поэкспериментировать). Аргумент, что ЯД начинает работать с бюджетов от 600р, а тут я эффективность не знаю и не могу сразу 20к непонятно куда потратить, их как-то не впечатлил. Ну да пофиг, видимо вся бизнес-модель, это разовая покупка бесполезной рекламы.
Забавно, не прошло и два дня, как мне позавчера позвонили из ЯБ и предлагали купить рекламу на 3 месяца за 21к рублей. Отказался, сославшись на вашу статью)
Так интерфейс и передается в конструктор. Только передается с помощью DI. В максимально упрощенном случае DI это и есть глобальный механизм, хранящий в себе объекты с разным временем жизни и подставляющий их в конструкторы сервисов и контроллеров, когда возникает необходимость. Но когда я использую DI из коробки ASP .NET Core, то я знаю, что любой программист с любого другого проекта на ASP.NET Core, увидев services.AddSingleton<IMarketingPolicy, CosmeticMarketingPolicy>(); поймет, что это такое. И, кстати, даже если программист с ASP.NET MVC придет или даже Spring Boot, то он тоже поймет, что это такое, просто наложив знания о эквивалентных фреймворках друг на друга. Если же я вручную буду организовывать глобальные объекты, то он просто будет вынужден идти и смотреть, что там за объекты с каким временем жизни были созданы.
Ну и так далее со всем. Можно использовать такие абстракции как контроллеры, а можно просто накидать кучу методов для обработки тех или иных маршрутов. Можно пакеты грузить из нугета, а можно класть самому длл в папочку. Можно использовать npm, а можно класть руками или скриптом. И пока у вас методов / библиотек / зависимостей - 5-10 штук, то всё ок. Когда их десятки и сотни - уже все равно придется это как-то группировать, выделять по разным файлам. И вот тут придется или выкидывать самокат и пилить заново со всеми этими DI, фреймворками и паттернами, либо это будет звездолет на коленке, в котором любой ногу сломит, так как вместо привычных инструментов и паттернов мы везде имеем своё решение.
Не знаю какие именно 6.5к строк у вас, но звучит это довольно паршиво. Возможно, если выделить часть этого кода в отдельную библиотеку, то новому программисту будет проще сделать фичу в такой проект без необходимости изучать все 6.5к строк.
С DI есть интересное наблюдение. Если убрав DI код стал лучше, то DI тут был не нужен. Я встречал людей, которые пихали DI внутри библиотеки бизнес-логики, не понимая смысла DI. Естественно, такое применение не привносило ничего, кроме дополнительной сложности и лишних проблем с отладкой.
Из нормального применения DI - это обертки над внешними сервисами, когда вы внедряете в бизнес-логику IMessageSender какой-нибудь, а при использовании бизнес-логики на разных проектах в одном проекте подставляется отправка сообщений СМС, в другом Слак, в третьем ТГ.
Или, например, IMarketingPolicy, отвечающий за маркетинговые правила продаж в магазине. При этом основная библиотека отвечает за работу разных частей магазина (корзины, заказов, продаж), которые есть у всех, а ценообразование, разное для разных магазинов, формируются через реализацию и внедрение IMarketingPolicy.
Да, в этих примерах тоже без DI можно обойтись, например, храня глобальные объекты и подставляя их в конструкторы. Но не понятно, зачем так делать, если DI как раз этим и занимается.
Если получилось заменить один проект ASP .NET на проект из одного main.go, то это означает, что у вас был максимум одностраничный лендинг. Все эти депенденси инъекшин, контроллеры и кучу слоев абстракций придумали не для того, чтобы продавать очередной фреймворк. А чтобы делать крупные проекты, и иметь возможность внедрять новые фичи за константное время. Если все напихать в один main.go, или index.php, то начиная с примерно 2-3к строк скорость внедрения фич будет зависеть от объема кода, а также приводить к регрессионным багам.
Короче, заменить все на повершел и велосипеды невозможно, если вы не гугл. А заменять подходы и архитектуры тем более не стоит.
P.S. Но с другой стороны я согласен с тем, что тянуть кучу фреймворков на каждый чих, это тоже антипаттерн. У меня на том же фронте обычно только какой-нибудь фреймворк типо vue.js и стандартный javascript. А другие фреймворки и либы стараюсь не тянуть.
Оплата в некотором университете из топ-листа РФ для ассистента - 200р примерно за час. Оплата в физмат школах для преподавателя - 400р за час. Это официальное трудоустройство, но без доп нагрузок типо поработать в деканате / сводить детишек на экскурсию и т.д. Ах, да, это Москва.
С# LINQ:
collection.Where(i => i % 2 == 0).Select(i => i / 2)
если не нужны ленивые вычисления, то добавим
collection.Where(i => i % 2 == 0).Select(i => i / 2).ToList();
После такой работы со множествами, хочется плакать в других языках.
Как будто заповеди Христовы и скрижали Моисеевы не пошли лесом намного раньше. Чего только "Не ъуъий" стоит.
Единственное, что вызывало у меня опасение - это код, написанный ChatGPT. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем программисты, использующие ответы от чат-бота. Я знал, что рано или поздно мы перейдем и на эту дрянь ради достижения лучших KPI.
Cloudflare уже часто под блоки попадает, то одна подсеть, то другая. Wikipedia можно сделать зеркало. Youtube сейчас пытаются проксировать. Github можно оставить по талонам для IT-компаний.
Синхронизация данных 1С с помощью флешек и в 2023 чуть ли не самый частый способ в мелких предприятиях. Особенно если учесть, что 1С обычно в локалках сидят, а для связи с другими компами нужно VPN поднимать.
Главное, чтобы дрова были подписанные
Дело не зеленых технологиях, а в цене. Разобрать вручную жесткий диск явно дороже, чем на конвейере слепить просто еще один новый корпус.
Насчет корпусов - есть Евромеханика IEC 60297-3-<N> там описаны как раз шкафы, стойки, полки, отдельные планки
А если все сложить в одну яму, так еще и забесплатно ровным слоем по окрестностям раскидает
Это условный Карл Пятый)
как разница между светло-серым и темно-серым
Вполне возможно, что это информация ради информация, чисто воды налить. Так на википедии, например, добавляют ссылки на года. Читаешь предложение: "Карл V пришел к власти в 1835 году". Тыкаешь на "1835" чтобы узнать как это произошло, а там статья со списком никак не связанных между событий, произошедших в этом году. Так и тут, можно было еще знак зодиака добавить.
Это, кстати, не логическая задача, а математическая на знание длины окружности. Непонятно только, зачем это знать синьору-помидору, но вообще обычно L ~= 3 D знают все
Имеет самое прямое. В статье можно наблюдать все проблемы, отсутствие которых считается достоинством нормализованных бд. Собственно, я по заголовку и при постановки проблемы сразу ожидал решения "мы вынесли жанр в отдельную таблицу". Но почему-то вместо этого один костыль заменили другим...
Я торговался минут 30 с ними, но так и не получилось уговорить на 1 месяц за 7к (деньги, на которые я согласился бы поэкспериментировать). Аргумент, что ЯД начинает работать с бюджетов от 600р, а тут я эффективность не знаю и не могу сразу 20к непонятно куда потратить, их как-то не впечатлил. Ну да пофиг, видимо вся бизнес-модель, это разовая покупка бесполезной рекламы.
Прошло 10 лет и все ссылки из комментариев сдохли( Какая печаль...
Забавно, не прошло и два дня, как мне позавчера позвонили из ЯБ и предлагали купить рекламу на 3 месяца за 21к рублей. Отказался, сославшись на вашу статью)
Так интерфейс и передается в конструктор. Только передается с помощью DI. В максимально упрощенном случае DI это и есть глобальный механизм, хранящий в себе объекты с разным временем жизни и подставляющий их в конструкторы сервисов и контроллеров, когда возникает необходимость. Но когда я использую DI из коробки ASP .NET Core, то я знаю, что любой программист с любого другого проекта на ASP.NET Core, увидев
services.AddSingleton<IMarketingPolicy, CosmeticMarketingPolicy>();
поймет, что это такое. И, кстати, даже если программист с ASP.NET MVC придет или даже Spring Boot, то он тоже поймет, что это такое, просто наложив знания о эквивалентных фреймворках друг на друга. Если же я вручную буду организовывать глобальные объекты, то он просто будет вынужден идти и смотреть, что там за объекты с каким временем жизни были созданы.
Ну и так далее со всем. Можно использовать такие абстракции как контроллеры, а можно просто накидать кучу методов для обработки тех или иных маршрутов. Можно пакеты грузить из нугета, а можно класть самому длл в папочку. Можно использовать npm, а можно класть руками или скриптом. И пока у вас методов / библиотек / зависимостей - 5-10 штук, то всё ок. Когда их десятки и сотни - уже все равно придется это как-то группировать, выделять по разным файлам. И вот тут придется или выкидывать самокат и пилить заново со всеми этими DI, фреймворками и паттернами, либо это будет звездолет на коленке, в котором любой ногу сломит, так как вместо привычных инструментов и паттернов мы везде имеем своё решение.
Не знаю какие именно 6.5к строк у вас, но звучит это довольно паршиво. Возможно, если выделить часть этого кода в отдельную библиотеку, то новому программисту будет проще сделать фичу в такой проект без необходимости изучать все 6.5к строк.
С DI есть интересное наблюдение. Если убрав DI код стал лучше, то DI тут был не нужен. Я встречал людей, которые пихали DI внутри библиотеки бизнес-логики, не понимая смысла DI. Естественно, такое применение не привносило ничего, кроме дополнительной сложности и лишних проблем с отладкой.
Из нормального применения DI - это обертки над внешними сервисами, когда вы внедряете в бизнес-логику IMessageSender какой-нибудь, а при использовании бизнес-логики на разных проектах в одном проекте подставляется отправка сообщений СМС, в другом Слак, в третьем ТГ.
Или, например, IMarketingPolicy, отвечающий за маркетинговые правила продаж в магазине. При этом основная библиотека отвечает за работу разных частей магазина (корзины, заказов, продаж), которые есть у всех, а ценообразование, разное для разных магазинов, формируются через реализацию и внедрение IMarketingPolicy.
Да, в этих примерах тоже без DI можно обойтись, например, храня глобальные объекты и подставляя их в конструкторы. Но не понятно, зачем так делать, если DI как раз этим и занимается.
Если получилось заменить один проект ASP .NET на проект из одного main.go, то это означает, что у вас был максимум одностраничный лендинг. Все эти депенденси инъекшин, контроллеры и кучу слоев абстракций придумали не для того, чтобы продавать очередной фреймворк. А чтобы делать крупные проекты, и иметь возможность внедрять новые фичи за константное время. Если все напихать в один main.go, или index.php, то начиная с примерно 2-3к строк скорость внедрения фич будет зависеть от объема кода, а также приводить к регрессионным багам.
Короче, заменить все на повершел и велосипеды невозможно, если вы не гугл. А заменять подходы и архитектуры тем более не стоит.
P.S. Но с другой стороны я согласен с тем, что тянуть кучу фреймворков на каждый чих, это тоже антипаттерн. У меня на том же фронте обычно только какой-нибудь фреймворк типо vue.js и стандартный javascript. А другие фреймворки и либы стараюсь не тянуть.