Рассказываю что можно сделать на одном только голом JDK. Это старое и ныне почти забытое искусство разработки без внешних библиотек и фреймворков. Работать будем «как в былинные времена» — киркой и лопатой голыми руками и немного мозгом.

Большинство программистов отлично разбираются в работе процессоров и последовательном программировании, поскольку с самого начала пишут код для CPU. Однако многие из них меньше знают о том, как устроены графические процессоры (GPU) и в чем заключается их уникальность. За последнее десятилетие GPU стали чрезвычайно важны благодаря широкому применению в глубоком обучении, и сегодня каждому разработчику необходимо обладать базовыми знаниями о том, как они работают. Цель этой статьи — дать вам это понимание. 

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

Данную статью я написал после того, как сделал собственную библиотеку, генерирующую сообщения протокола Kerberos, а также после того, как я протестировал «стандартный клиент» Kerberos в Windows — набор функций SSPI. Я научился тестировать произвольные конфигурации сервисов при всех возможных видах делегирования. Я нашёл способ, как выполнять пре‑аутентификацию в Windows как с применением имени пользователя и пароля, так и с помощью PKINIT. Я также сделал библиотеку, которая умещает «стандартный» код для запроса к SSPI в 3–5 строк вместо, скажем, 50-ти.

Хотя в названии статьи фигурирует «простыми словами» однако эта статья предполагает, что читатель уже имеет какое‑то представление о Kerberos.

Spark Connect — это, пожалуй, самая ожидаемая фича Apache Spark 3.4.0. Она была анонсирована на конференции Data+AI Summit 2022 и сейчас широко освещается в социальных сетях. Вот и я решил приобщиться и внести свой небольшой вклад в это дело, продемонстрировав вам несколько интересных деталей реализации.

Кто такой FastAPI?

FastAPI — это фреймворк для создания лаконичных и довольно быстрых HTTP API-серверов со встроенными валидацией, сериализацией и асинхронностью,
что называется, из коробки. Стоит он на плечах двух других фреймворков: работой с web в FastAPI занимается Starlette, а за валидацию отвечает Pydantic.

Комбайн получился легким, неперегруженным и более, чем достаточным по функционалу.

Облик самолёта с фюзеляжем и расположенными сзади килем и стабилизатором утвердился быстро и прочно – его называют даже не «классической», а «нормальной» аэродинамической схемой. Но всегда находились чудаки, создававшие разного рода «ненормальные» аэропланы. Самые «чудачные» из них размышляли так: чтобы подняться в небо, самолёту не нужно ничего, кроме крыла, остальное только мешает своим весом и сопротивлением. Так почему бы не избавиться от всего лишнего? Тогда моторы, топливо, экипаж, полезная нагрузка разместятся внутри несущей поверхности. Такая схема получила название «летающее крыло», а сто лет назад её познакомил с небом Борис Черановский – авиаконструктор и мечтатель.

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

Наш сегодняшний рассказ — о человеке, который приложил руку к созданию ИС, получил прозвище «мэр Кремниевой долины» и вдобавок основал крупнейшую в мире компанию по производству процессоров.

Военная история изобилует примерами удивительных событий, на первый взгляд, не поддающихся логике и здравому смыслу. Один из них будет описан в этой статье. Сегодня мы рассмотрим события утра 10 мая 1940 года, когда в ходе плана «Гельб» небольшая группа немецких десантников высадилась на крышу бельгийского форта Эбен-Эмаль — крепости, спроектированной по последнему слову тогдашней фортификации, с гарнизоном численностью более 1200 человек, расположенную в идеальной для обороны местности и считавшуюся неприступной.

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

Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.

Дай думаю поделюсь инфой, чтобы наше с вами будущее не было наполнено болью, страданием и борьбой с последствиями тех дурацких решений, которые можно напринимать прямо сейчас с той кашей в голове, которую я вижу у людей по этой теме.

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

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.

Представьте: вот вы пилот, летите, никого не трогаете, примус починяете, и решаете набрать высоту. Для этого надо немного ускориться и параллельно чуть увеличить тангаж, что вы, собственно, и делаете. Увеличивая тягу РУДом, вы параллельно немного тянете рычаг управления на себя. Все идёт хорошо первые несколько минут, но тут рычаг полностью самостоятельно и с огромной силой уходит в положение "на себя" до упора и там замирает. Поздравляю вас, вы познакомились с явлением, именуемым "перекомпенсация руля высоты". Пока вы лихорадочно пытаетесь оттолкнуть рычаг в нормальное положение, а ваш самолёт переходит в устойчивый штопор, у как раз вас есть несколько минут падения до земли, так что давайте познакомимся с этим явлением поближе.