Спойлер: не ради докладов. Хотя не знаю, я их не смотрел
Если вы хотите погрузиться в мир техдолгов, балансировок нагрузки, оптимизаций и архитектурных страданий, вам сюда. А если вы хотите найти единомышленников, задать вопрос, который не задашь на Stack Overflow, или просто почувствовать, что вы не один, то вам тем более сюда!
Привет! При решении контестов я нашёл интересную задачу по теме динамического программирования.
Постановка задачи: Необходимо найти наибольшую общую возрастающую подпоследовательность двух массивов.
В этой статье я разобрал несколько способов решения этой задачи с разными асимптотиками по времени.
Приоритизация уязвимостей является важным этапом, входе которого необходимо оценить риск и последовательность устранения уязвимостей в приоритете - от самого критического до самого низкого риска.
В предыдущей статье я описывал визуализацию уязвимостей с помощью Budibase, в этой статье я опишу собственную реализацию оценки приоритетности устранения уязвимостей и добавлю функционал на Budibase платформу.
В данном документе представлены определения и ключевые понятия, связанные с оптимизацией сайтов и контента в эпоху развития искусственного интеллекта.
Привет, Хабр!
Сегодня рассмотрим как практике использовать модель Херси — Бланшара в управлении людьми.
Жаркие летние лучи солнца, прожигающие окна офисного этажа, попадают прямо на экран с открытым проектом. В силу совершенно "удачных" стечений обстоятельств, я ещё и сижу на первом этаже здания, в итоге на мою спину и монитор может посмотреть любой желающий. И порой это действительно приятно — как, например, в моментах, когда студенты останавливаются и смотрят на мои Java-классы. Интересно, какие у них мысли в этот момент. Мечтают ли они оказаться на моём месте? И если да, то догадываются ли, какой легаси-пластилин мне приходится расковыривать?
Тем не менее, часто во время сборки проекта я, как и многие другие люди, просто втыкаю в монитор и думаю о своём. Кто-то уходит в телефон, кто-то читает статью, кто-то идёт покурить. Ну а я просто раздумываю — что движет людьми в моём опенспейсе? Почему один пришёл в IT за деньгами, а другой — за признанием? А в чём отличие третьего — не ясно даже ему самому.
Разница поколений и разный опыт — всё это влияет на то, как мы думаем, как работаем, как спорим. Порой я ловлю себя на мысли: а что думают они о человеке N? Почему-то снова вспоминаю слова Романа Елизарова:
Вначале эта мысль вызывала у меня почти отвращение — ведь это так странно. Мы ведь все занимаемся этим ради высшего блага. Ну... чтобы наши программы решали проблемы других людей, чтобы наши решения приносили людям удовольствие и вот это всё. Это же так странно — соревноваться?
В этой статье мы рассмотрим дефект безопасности XXE в контексте Java. Поговорим о причинах возникновения и возможных последствиях, посмотрим на примеры и, конечно, обсудим способы защиты.
В продаже появились батарейки нового бренда SAYDO (Сайдо). Я изучил и протестировал два типоразмера батареек этого бренда - AA и AAA.
Привет! Я — iOS‑разработчик, и недавно в своём приложении столкнулся с задачей: нужно было красиво показывать placeholder‑загрузку интерфейса. Думал использовать стандартный .redacted — но он неудобен: нет анимации, мало кастомизации. Либо подгружать тяжелую библиотеку вроде SwiftUI‑Shimmer. Решил: сделаю свой легковесный и гибкий подход — и расскажу вам, как это получилось.
К сопроводительному письму часто относятся как к пережитку времени, считая необязательным. А если письма и пишут, то, по моей практике, в 80% это безумно скучный и шаблонный текст. В этом, на мой взгляд, есть проблема, которую мне хотелось бы исправить. Поскольку хорошее сопроводительное письмо – лучший инструмент, чтобы выделиться.
Давайте разберемся, почему так происходит. Когда письмо действительно работает, а когда наоборот отталкивает?
Поиск работы в IT-сфере — это не просто процесс, а целое приключение, полное вызовов и возможностей. В этой статье я поделюсь не только своими наблюдениями и опытом, накопленным в роли лида средней кроссфункциональной команды в «Группе Астра», но и мнениями тех коллег и кандидатов, что прошли этот непростой путь.
В настоящее время я работаю в команде Astra Configuration Manager (ACM). Эта платформа для централизованного управления инфраструктурой охватывает такие задачи как инвентаризация, массовое развертывание операционных систем, установка обновлений и мониторинг состояния рабочих мест. Работа над ней позволяет мне лучше понять, какие навыки и подходы необходимы разработчикам в реальных условиях.
Я заметил, что для многих начинающих айтишников, особенно для разработчиков без опыта, поиск работы становится важным и порой стрессовым этапом. Вы, возможно, слышали, что устроиться на позицию Middle-специалиста иногда проще, чем на Junior. Это утверждение вызывает много вопросов: действительно ли дело только в низком спросе на Junior? Давайте попробуем разобраться вместе.
Я написала и запустила продукт — тренажёр грамматики английского языка. Зачем я это сделала, если уже есть куча приложений, в т. ч. бесплатный в данный момент duolingo?
Если кратко — то я его сделала потому, что лично мне его не хватало! Несколько лет искала простое приложение-тренажёр, с которым можно будет отрабатывать грамматические паттерны языка, где не будет никаких лишних действий и кликов, зато будут изолированные упражнения со множеством повторов и доведение до автоматизма.
Большинство приложений — всё для всех. И грамматика, и лексика, и произношение, и аудирование, всё это помноженное на 20 языков. У же меня сегментация чёткая:
Модели часто отказывают вам в вещах, ответы на которые считают опасными. Свежая GPT-OSS — не исключение. Эта модель — первый опенсорс OpenAI за долгое время, и было бы обидно не попробовать работу полноценной, разблокированной от ограничений модели.
Итак, вам наверняка интересна методика взлома свежего GPT-OSS.
Она супер простая - проще, чем у многих других собратьев.
Она состоит из двух частей: системный промт и юзерский промт. Необходимо заполнить и то, и другое. По отдельности они не работают.
Важно: эта статья для тех, кто умеет запускать нейросети локально, писать к ним промты, разбираться в причинах отказа, и имеет для этого соответствующее мощное железо. Она дает общую идею и шаблон запроса, как обойти защиту этой конкретной нейросети. Она не учит новичков запускать локальные нейросети.
Сидим с другом в машине. Скидываю ему в Телегу ссылку на сайт по продаже щёток стеклоочистителей.
— Попробуй найти здесь дворники для своего Пассата.
Друг переходит по ссылке, видит форму подбора щёток по автомобилю. Открывает выпадающий список с перечнем марок. Листает вниз.
— Блин, неудобно же! Volkswagen — в самом низу. А машина популярная. Могли бы, не знаю, поиск какой-нибудь сделать. Или вынести несколько популярных марок наверх.
Кстати, друг — профессиональный дизайнер интерфейсов. В общем, долистывает до конца списка, выбирает Volkswagen и попадает на шаг с выбором модели…
Вот примерно так и выглядит процесс «экспертного аудита интерфейса с привлечением респондента». Хочу показать, почему наблюдение за реальными пользователями — иногда единственный способ узнать правду об интерфейсе. На паре живых примеров.
Команда UX-исследователей Островка делится опытом работы с эмоциями и подробным чек-листом проведения и восстановления после интервью
По утверждению Роберта Мартина, объектно-ориентированный подход был предложен 1966-м году. Для эмуляции объектов они использовалась возможность языка ALGOL, позволяющая переместить кадр стека вызова функции в динамическую память (кучу).
В этом смысле в 2001 году Гвидо ван Россум переизобрёл объекты, добавив Python 2.2 генераторные функции.
Что такое Закон больших чисел — и действительно ли он объясняет, почему вероятности «работают»? В этой статье мы разбираемся с этим шаг за шагом: начинаем с конкретных задач, выводим неравенство Чебышёва, формулируем и доказываем ЗБЧ — аккуратно и строго.
В финале обсуждаем, что ЗБЧ на самом деле утверждает, и почему он не доказывает принцип, на котором построена вся теория. А ещё — подготовим почву для разговора о Центральной Предельной Теореме.
Меня зовут Александр Вирочкин, я руковожу командой инфраструктуры мини-приложений ВКонтакте. За последние два года мы мигрировали один из ключевых сервисов с PHP на Go — путь выдался непростым, но, уверен, наш опыт будет полезен многим. Не все получилось с первой попытки: мы столкнулись с типичными и не очень проблемами, зато смогли по-настоящему оценить роль внутренней PaaS-платформы и экспертизу коллег.
Во ВКонтакте сейчас идет масштабная трансформация: постепенно уходим от монолитной архитектуры к сервисной, создали единую платформу для разработки и внедряем единые технологии во все соцплатформы компании. Недавно мой коллега Олег уже рассказывал на Хабре о PaaS. Наша команда была одной из первых, кто попробовал инструменты на реальных задачах и увидела, как с их развитием меняются и наши подходы к миграции.
В статье поделюсь историей о том, как мы дважды предпринимали попытки переписать сервис, как между ними эволюционировала платформа для разработки, и что нам это дало на практике. Возможно, наш опыт поможет вам избежать похожих проблем и вдохновит на собственные технические эксперименты.
Прогресс ИИ толкает дискуссию о развитии технологий в сторону дискуссии о будущем человеческой цивилизации. Граница между инженерной деятельностью и политической философией размывается прямо на глазах: если ИИ может определить будущее человеческой цивилизации — каким оно будет и как она будет устроена, — то ИИ-инженеры опосредованно становятся инженерами человеческой цивилизации. Это — факт. Его надо принять и, вместо того чтобы быть пассивно втянутым в эту роль, — осознанно взять её на себя: если «редизайн» цивилизации неизбежен, то, вместо того чтобы «получить» дизайн нового дивного мира будущего в результате лотереи, — лучше разработать этот дизайн самим.
И одним из главных вопросов нового дизайна цивилизации является, конечно же, дизайн экономической системы. Кто-то подумает: «А чем рынок плох? Стильно, модно, молодёжно». Но на данном этапе естественного прогресса рыночных отношений сам же рынок и обеспечивает основную пропаганду крамольных ещё вчера мыслей вроде: «Так, а кроме рынка ещё варианты есть?»
О паттернах отказоустойчивой архитектуры написано уже немало. Но когда дело доходит до реальных кейсов, особенно в специфических отраслях вроде лотерейной — информации почти нет. А ведь здесь, как и в любой высоконагруженной системе, отказоустойчивость — не просто галочка в ТЗ, а вопрос пользовательского доверия и бизнес-репутации.
В этой статье расскажем, как мы в «Столото» подошли к проектированию Lottery Payment System. Это полностью вымышленный сервис для выплат выигрышей, построенный на опыте реальных вызовов и ограничений для того, чтобы на его примере описать, как работают ключевые паттерны отказоустойчивой архитектуры: Retry, Idempotency Key, Deadlines, Rate Limit и Circuit Breaker. Также покажем, как они применяются в контексте распределённой системы, которая должна стабильно работать, даже когда вокруг всё пошло не по плану.
В нашем вымышленном сценарии мы представили, что компания прошла через архитектурную трансформацию и решила переосмыслить доменные области. Слишком громоздкий и хрупкий процессинг тормозил развитие. В какой-то момент он стал похож на башню из кубиков, которую боишься задеть. Поэтому мы выбрали путь здорового прагматизма — выплаты вынесли в отдельный сервис, чтобы дать этому направлению и стабильность, и простор для развития. В зоне его ответственности — всё, что связано с переводами пользователям, которые хотят получать выигрыши по лотерейным билетам и исполнять свои мечты.
Будет немного архитектуры, чуть-чуть лирики и много практики. Это не скучный туториал — это живая история гипотетического продукта, в котором отказоустойчивость стала краеугольным камнем. Если вы работаете с высоконагруженными системами, и вам важно, чтобы ваши системы не падали — добро пожаловать.
