Pull to refresh
3
Karma
0.2
Rating

Ненастоящий программист

Пора что-то менять! Как определить ту самую «токсичность в команде» + комментарии инженера

Поясните, пожалуйста, а как связанны токсичность коллектива и история Елены?
У Елены, судя по описанию — конфликт исключительно с менеджментом фирмы: невыполненные данные ей (или неправильно понятые?) обещания при устройстве на работу, принуждение к переработкам, «потребительское отношение компании к сотрудникам»…
Какое-либо влияние коллектива из текста не просматривается — ни положительное, ни отрицательное.
А так, да, тема статьи интересная.

Уменьшить размер консольного .NET 5.0 приложения

Да, пардон, забыл про это. И самое обидное, что я про этот параметр в документации некогда читал.

Уменьшить размер консольного .NET 5.0 приложения

С .NET Framework 3.5 все ещё хуже: у него среда выполнения (CLR) своя (.NET 2.0) с CLR от 4.0 (которую используют все последующие версии) она несовместима ни в ту, ни в другую сторону. Поэтому для приложений, сделанных под 3.5, на новых версиях Windows приходится устанавливать отдельно .NET 3.5 из компонентов. А, к примеру, уже в Windows Server 2012 R2 этот компонент физически удален из устанавливаемого образа (осталась только ссылка), и его нужно ставить из другого источника (впрочем, на дистрибутивном диске он лежит, так что далеко ходить не надо).
Так что никакой универсальности с .NET 3.5, чтобы оно работало из коробки начиная с Win7 до наших дней, все равно не получится.

0x7E5 Рассуждения о главном

А что мешает использовать тот же DI, но отказаться от абстракций,

А модульные тесты (unit tests) как под это писать? «Как по книжке» — реализовать интерфейсы имитаторами (mock) и заглушками (stub) — уже не получится.
Нет, способы тестирования и при таком подходе, конечно есть, потому как были времена когда интерфейсов (тех, которые ключевое слово interface) не было, но тестировать все равно надо было: типовой прием — подмена исходного файла с реализацией. Но все ли разработчики такие приемы (без которых нынче легко прожить) знают? И все ли языки и исполняющие системы это дозволяют? И как использовать фреймворки для тестирования под написание таких тестов, буде такое желание возникнет: они ведь «как по книжке» умеют работать, вроде как, все, а вот как по-другому — возможны варианты, неприятные.
Короче, как и при любом отклонении от общепринятой колеи — вопросы, вопросы…

Важно! Внеплановые обновления безопасности Microsoft для Exchange от 2 марта 2021

Из режима администратора (с повышенными привилегиями) ставили?
А то про эту заплатку были сообщения, что если ставить ее из обычного режима (с урезанными UAC привилегиями) то она может поставиться не до конца.

Боль разработчика: «Никогда не давайте пользователям бесплатный тариф»

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

WinUI 3 — Новая эра разработки под Windows

На стартовой картинке кое-чего не хватает, из далекого прошлого.
Если бы разработчикам программ под Windows весь этот срок с 1995 (на самом деле, с 1990, когда началось массовое распространение Windows 3.0) до 2002 пришлось бы плакать, колоться, но продолжать писать программы на голом WinAPI/Win32API «по Петцольду», как они это делали во времена Windows 3.0, то, думаю, Windows бы до наших дней не дожила. Но, даже если брать только продукты для разработчиков самой MS, в 1992 появилась библиотека MFC для C++, потом — Visual Basic и жизнь разработчиков под Windows стала гораздо легче. А если продуктами MS не ограничиваться, то была ещё, к примеру, Borland — сначала с OWL для C++, потом — с Delphi.

WinUI 3 — Новая эра разработки под Windows

Так же, совсем недавно компания прекратила поддержку .NET Core 2

Еще не прекратила
Для .NET Core 2.1 заявлена поддержка до 21.08.21.
PS Вас видимо сбило с толку, что прекращена поддержка более позднего выпуска 2.2. Однако с .NET Core 2 такая вот загогулина вышла.

Самоподписные сертификаты кровавого энтерпрайза против вашего лампового CI/CD

IMHO неточность в заголовке: самоподписанными называют сертификаты, подпись которого сформирована на основе этого же самого сертификата.
А у вас в статье речь идет все же о сертификатах от УЦ.

Все научились программировать. А дальше-то что?

Дык, он же, вроде как, на F# перебрался?

Важно! Внеплановые обновления безопасности Microsoft для Exchange от 2 марта 2021

Я так понимаю, что заломанные экченжи торчали голым задом прямо в белый свет? А иначе как с них попадать с веб-шелла?

Например, прослушивать команды по HTTP на том же 443 порту, но на другом URL: это вполне можно сделать через драйвер http.sys, не мешая работать IIS (например, AD FS, который так делает, вполне себе живет с IIS на одном сервере)

Важно! Внеплановые обновления безопасности Microsoft для Exchange от 2 марта 2021

MS к сожалению, как это у них нынче принято, раскрывает очень мало технических деталей.
Судя по тому, что опубликовано — общие описания и как искать следы взлома (это — единственные технические детали), первая, самая важная, узявимость (удаленная через HTTPS без аутентификации, которая позволяет выполнить любой HTTPS-запрос с учетными данными сервера Exchange) идет в протоколе доступа к общим папкам через EWS, и работает она только в Exch2013 и выше, потому что существенно опирается на его архитектуру веб-доступа Proxy+BackEnd и на его архитектуру общих папок. То есть, Exchange 2010 однозначно ей не подвержен.
Подвержены ли ей организации, в которых общих папок нет — не совсем понятно (скорее всего — подвержены, т.к. этот компонент — необязательный, по умолчанию не активируется, и если бы без него атака была бы невозможной, то это было бы наверняка в Mitigating Factors).
Но самое главное, что неясно — возможна ли атака, если доступ к EWS извне закрыт: вообще-то EWS нужен, в основном, для Outlook, браузерные (OWA) и ActiveSync (классические мобильные) его не используют (но вот Outlook для IOS/Android в гибридном режиме использует именно его). Если OWA и ECP к этой атаке неуязвимы, то это может существенно изменить дело. И, в любом случае, OWA с ECP могут быть штатно опубликованы через Windows Appliction Proxy с преаутентификацией — и тогда эта атака не сработает без аутентификации сработать не должна.
Вторая уязвимость локальная и с использованием Unified messaging — по идее, в Exch2019 работать не должна.
А третья и четвертая узявимости — это, похоже, повышение привилегий с целью распространения по всей организации Exchange после успешной первой или второй атаки.
Как-то так со стороны видится.

Многопоточность на низком уровне

Не видел, но если вдруг найдется ссылка, будет интересно почитать.

Планировщик Windows? Это очень просто
Там об этом мельком.
А вообще информация об этом в книге «Windows Internals» уже давно есть, из изданиия в издание кочует — не помню, была ли она в первом, которое писала Хелен Кастер, но в тех издания, которые Руссинович делал, кажется, была уже сразу.

50 лет Паскаля

Коллеги, поясните мне, пожалуйста — вы тут все ещё Паскаль обсуждаете, или уже на общие темы перешли?
А то в Паскале-то оператор goto был издавна, ещё со времен Вирта: берем книгу Йенсен и Вирта «ПАСКАЛЬ Руководство для пользователя» в переводе Подшивалова (М.«Финансы и статистика», 1989) и на стр. 57 видим рис. 4.15, на котором изображена синтаксическая диаграмма пресловутого оператора goto.

Многопоточность на низком уровне

С вашего позволения немного позанудствую.
При использовании Thread.SpinWait() не происходит переключение контекста потока, текущий поток не передает управление планировщику задач Windows. Вместо этого запускается холостой цикл, который при каждой итерации возвращает поток обратно в очередь ожидания (прямо как Thread.Yield()), передавая управление потоку с таким же приоритетом, но не фоновому потоку.

Что-то странное тут написано: «который при каждой итерации возвращает поток обратно в очередь ожидания» — это про Thread.Sleep(0), а не про SpinWait, который, судя по документации, просто крутит холостой цикл на указанное число итераций, безо всяких вызовов ядра в этом цикле. (UPD: пока писал, про это уже выше написали)
Без SpinWait цикл может выполняться бесконечно, потому что если нулевой процессор запустится как фоновый поток, то первый процессор заблокирует этот фоновый поток, до тех пор пока поток на первом процессоре не будет прерван.

Это — не про Windows, точнее — не про потоки обычных пользовательских программ, которые работают с приоритетами в диапазоне динамических приоритетов (1-15). Для этого диапазона планировщик в Windows, если видит, что какой-то поток вообще не получает управление, динамически повышает его приоритет на один или несколько квантов, чтобы поток имел шанс выполниться (как раз вот для подобных случаев).
Тут, кстати, на Хабре была не так давно статья (может, помните), где автор как раз модифицировал планировщик в WinXP, чтобы избежать этого динамического повышения приоритетов — оно у него работу программы для real-time нарушало.

Почему линукс использует swap-файл

Смотреть — вот этим, в 64-битных системах я предпочитаю использовать 64-битную версию poolmon64.exe.

Почему линукс использует swap-файл

Интересная картинка, однако. Это был не кэш файловой системы: застрявшая память находилась в страничном пуле памяти ядра системы, которым пользуются драйверы (и некоторые другие компоненты ядра). А судя по тому, что память была освобождена при возникновении (имитации) потребности в ней, это, похоже, был собственный личный кэш драйвера.
Какой именно драйвер держал память — это можно было бы посмотреть с помощью poolmon64, по четырехсимвольному тегу элементов пула, но сейчас уже, понятно, это не скажешь.
А в принципе, при таком хорошем поведении дравера на эту забираемую им под кэш память можно обращать не больше внимания, чем на кэш файловой системы.
PS Хотя вы пишете, что у вас подкачка отключена, но система в дополнение к физическим 64ГБ видит где-то ещё 16.

50 лет Паскаля

Если уж ностальгировать, и вспоминать слово Паскаль…
Интересно, сколько народу не видело этот древний текст: "Настоящие программисты не используют Паскаль"

Еще один фреймворк…

На заборе тоже пишут. А в реальности… Что декларативного в записи orders.Select(o => o.Amount > 100)?

М-м, а вы точно знаете, как это будет выполнено? В частности, если orders реализует IQueryable<тип-о>, то для получения результата вместо банального перебора провайдером данных может быть выполнен эквивалентный запрос на другом языке запросов (например — на SQL): лямбда в C# может, как известно, быть преобразована в дерево выражения, а оно, в свою очередь — транслировано провайдером на нужный язык запросов. И выполнять ваш запрос будет, к примеру, SQL сервер, спрятавшийся за orders — а вы получите только результат. По-моему, это весьма декларативно: вы написали на C#, что вы хотели получить, а результат вам (внезапно) предоставил своим, более эффективным, способом понятливый ORM с SQL Server'ом на пару — хотя вы в момент написания лямбды, возможно, даже не задумывались об их существовании.
И, кстати, вы, наверное, имели в виду orders.Where(o => o.Amount > 100)? Иначе мне трудно предположить, зачем вам этот результат — IEnumerable<Boolean>, т.е., последовательность непонятных true и false. ;-)
Эмм. Вы считаете, что операция Add на коллекции — это декларация, да?
В контексте стадии конфигурирования ASP.NET смысл вызова Add обычно — роль разделителя, типа перевода строки и пробелов в ней: так здесь принято оформлять строку конфигурации, операция Add самостоятельного смысла не несет, это boilerplate.
Это просто операции над коллекцией. Что в ней — уже не важно. Они императивны по самое не знаю что.

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

Операция императивная, но мы эту операцию не выполняем. Она выполняется библиотекой где-то там за сценой, хотя и по нашей общей команде (которая тоже входит в ритуал). А прикладной программист на ASP.NET может даже не подозревать о существовании этой операции и, при этом, вполне успешно работать: он просто следует ритуалу — описывает конфигурацию, создает хост для веб-приложения командой Build и дальше запускает его одним из предусмотренных для этого способов. Короче, то, что надо программировать императивно — все уже запрограммировано до нас, и потому я предлагаю ограничиваться рассмотрением только тех операции, которые делает прикладной программист.
Расширить — это когда мне предлагают что-то в дополнение. А тут мне предлагают отказаться от конфигурации через код, которая обладает определенными достоинствами, в обмен на конфигурацию через YAML, которая никакими объективными достоинствами в данной реализации не обладает.

Я когда это писал, предполагал не ограничиваться рассмотрением фреймворка idewavecore (автор просит называть его так, см. ниже), а обсудить и принципиально возможные гипотетичекие решения на базе DSL-фреймворков: как я понял, вы от них принципиально откзывались. Но если вы отказываетесь от них не принципиально, а чисто в виду отсутсвия подходящих, и даже если вы вообще не верите в возможность существования подходящих, то тут дальше обсуждать нечего, за неимением предмета обсуждения.
Это не MVC, а роутинг.

Нет, это именно MVC. Не знаю, как точно это реализовано в Core (полагаю, что сходным образом), но в Framework вся магия (там есть много точек, в которые можно вмешаться) выбора класса контроллера, создания его экземпляра и последующего выбором метода действия начинается в обработчике маршрутов из состава MVC — MvcRouteHandler: именно его надо указывать при ручном создании объекта маршрута для приложения MVC.
А роутинг — это общий компонент, в контексте работы MVC он только разбирает путь в URL и выбирает обрабочик маршрутов.

Еще один фреймворк…

А где вы там нашли декларативный подход?
Там прямо в документации по LINQ написано: «Query expressions are written in a declarative query syntax.»
Я, в таком случае, не понимаю, как вы отделяете декларацию от инструкции.
Хороший вопрос, с решения которого надо было бы, вообще-то, было начинать. Декларация, в моем понимании — это описание того, что нужно сделать, без детализации как сделать. И мне нравится определение декларативного программирования из английской Википедии: «a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow»
В данном случае это практически так и control flow в AddOptions() является чисто вспомогательным: он состоит в занесении отдельных деклараций (о том, какие сервисы будут доступны через IServiceProvider) в список этих деклараций (IServiceCollection), и нужен он там только из-за особенностей языка: иначе в C# сложно сделать создаваемый в несколько приемов список деклараций.
У нас с вами терминологическая разница.

Спасибо, что обратили внимание. Дальше, во избежание путаницы, буду использовать названия интерфейсов.
Но суть от этого не меняется. (Прямые) операции над IServiceCollection выполняются сразу же, а не отложено.

Операции над IServiceCollection — это операции над списком деклараций. В основном — простое линейное занесение в список, семантически это — полный аналог написания списка в файле. Кое-где — условное включение в список, но средства типичного декларативного языка сделать такое условное включение тоже обычно позволяют. То есть результатом всех этих операций является список деклараций. И особенные возможности императивного языка тут не используются, согласны?
Когда предоставят, тогда и снимет возражение.

ОК, значит вы не отвергаете возможность получния пользы от такого рода инструментов.
«Нарваться» можно на что угодно. Это не повод пренебрегать существующими инструментами.

Никто не предлагает вам пренебрегать. Наоборот, вам предлагают расширить круг инструментов. Возьмем тот же MVC — в его лице вы получили новый инструмент: динамическое определение вызываемой подпрограммы обработки запроса по соглашению об именах.

Information

Rating
2,049-th
Registered
Activity