Pull to refresh
23
Karma
0
Rating
Масляев Александр @maslyaev

Пользователь

  • Followers 38
  • Following

Взлом ГПСЧ с помощью машинного обучения

Интересно, а как насчёт посчитать SHA-256 в обратную сторону?

Python микросервисы с Kafka без боли

Шикарный туториал. Спасибо. Обязательно потаскаю что-нибудь в прод.

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

Кроме прекрасного и полезного паттерна "а давайте поставим Кафку" есть ещё и не менее полезный паттерн "а давайте избавимся от Кафки".

Переносим философию Unix в 21 век

Личная просьба. А давайте строго-типизированное двоичное представление будет не в XXI, а в XXII веке, чтобы я гарантированно не дожил до этого счастья.

Катастрофы, с которыми я столкнулся в мире микросервисов

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

Катастрофы, с которыми я столкнулся в мире микросервисов

HDD это не только hard disk drive, но и hype driven development.

Хайп-проект или будущее интернета? Кому и зачем нужна метавселенная Цукерберга

Концерты, шутеры, гонки, платформеры, фитнес-залы, эскейп-румы

Ну то есть едешь в переполненном вагоне, нацепляешь на себя эту хрень, и ты уже эскейпнулся куда-то на Бора-бора? Солнышко, песочек, океан, но блин почему так шумно, так трясёт, и райские птички так больно в бок пихаются?

Бессерверные БД: зачем переводить Stateful-сервис в Serverless

Естественно одинаковые. Всё одинаковое. План исполнения такой, что боженька радуется, глядя на такие планы исполнения.

Бессерверные БД: зачем переводить Stateful-сервис в Serverless

Не надо никого звать. После того, как наши [censored] девопсы полтора месяца кормили меня завтраками и футболили тикет друг другу, я психанул и со словами "горбатого могила исправит" поднял Постгрес на запасной виртуалке в Digital Ocean.

Я предполагаю, что все эти прекрасные Managed заманухи хранят свои данные в облачных же хранилищах, которые по-любому медленнее, чем железная SSDшка, подключённая через железный PCI-Express. Вот и получается, что ты, дорогой клиент, можешь наслаждаться бесконечным объёмом хранимых данных, но всё будет работать нормально и не вставать колом ровно до момента, как база перестанет целиком помещаться в кэш. Для демок и прототипов такое прокатывает, а для настоящего использования... да кому оно нахрен интересно это настоящее использование?

Бессерверные БД: зачем переводить Stateful-сервис в Serverless

Поделюсь опытом использования Managed PostgreSQL в Azure. Всё хорошо, но производительность в 100 (прописью: сто) раз хуже того же Постгреса, поднятого в докер-контейнере на моём ноутбуке. Одна и та же база (восстановленная из бэкапа), один и тот же запрос, идентичный результат, но у меня 1 секунда, а в облаке полторы мать её минуты. В последний раз я видел такую потрясающую производительность в начале 90-х на DBF файлах в 486-м компьютере.

Короче, дурят доверчивых граждан поставщики облачных сервисов.

Почему «теорию всего» следует искать в информатике, и почему следующим Эйнштейном станет программист

Забавно смотреть на то, как народ пытается вывести само время из рассуждений о некоем процессе, который сам происходит во времени. Если это то же самое время, то мы там же, откуда начали. Если это другое время, то мы в дополнение к проблеме нашего родного времени поимели проблему какого-то загадочного дополнительного чужого времени, которую по аналогии будем решать введением третьего, четвёртого и т.д. времён, так что ли?

О мотивации: ЗП. СМ. И далее по списку

ЗП это необходимое условие, но не достаточное. То есть если ЗП хорошая, это вовсе не означает, что я возьмусь за работу. Но означает, что если я взялся за работу, значит ЗП там хорошая.

DevOps для бабушки

Тут девопса точно не перепутали со скрам-мастером?

UML умер, а никто и не заметил?

Нормальный пример. Более того, я даже не могу припомнить пример из своей практики, когда принцип "код сам себе документация" работал на все сто. Ну кроме совсем примитивных случаев, когда и так всё понятно.

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

UML умер, а никто и не заметил?

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

UML умер, а никто и не заметил?

>>Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад

Это потому что у нас сильно облегчилось накопление сложности. То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным. Он так и остаётся простым как валенок, а вся его сумасшедшая сложность на 99.9% является либо издержками техпроцесса, либо просто балластом. Следует ли нам гордиться этой сложностью? Ну, не уверен. Особенно с учётом того, что вместе со сложностью частенько возрастает хрупкость.

>>У нас основная спецификация — это код

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

UML умер, а никто и не заметил?

Я говорил не про крепление глушителя, а про деградацию качества инженерных решений при внедрении agile там, где не нужно.

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

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

UML умер, а никто и не заметил?

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

Что делает дядя Ашот, если нужно внести изменение в крепление глушителя? "Падажди здесь дарагой, щас Петрович докурит и в пять минут тебе всё как надо приварит".

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

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

Хватит везде делать микросервисы

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

Генераторы для самых маленьких

Нормальный путь питониста вглубь этой темы:

  1. Не знать про yield. Спокойно в своём уютненьком юпитер-нотбуке совать пандас в матплотлиб и горя не знать.

  2. Вау, оказывается, можно не один раз отдавать результат из функции, а несколько раз. Или вообще много раз. Или, хе-хе, бесконечность раз. Прикол. Непонятно, правда, зачем оно может быть нужно.

  3. Разобрались зачем это нужно, вошли во вкус, пользуемся. Возможность выстраивать логику программы не от источника данных, а наоборот, от потребителя - действительно иногда удобно. Да что там говорить, почти всегда удобнее.

  4. Оказывается, yield умеет не только отдавать, но ещё и принимать данные. Ой.

  5. Туго, со скрипом, через боль и фрустрацию въезжаем в тему async/await и внезапно обнаруживаем, что теперь у нас каждая мать её функция является этим самым генератором, который где-то там внутри под капотом елдячит на каждом "await".

  6. ... не знаю, я дальше не ходил.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity