Недавно я столкнулся с задачей собрать своё Go‑приложение написаное вокруг библиотеки github.com/webview/webview_go, которая является обёрткой для C/C++ библиотеки webview, для Linux, из чего вытекает необходимость использования CGO. Казалось бы, что сложного? Укажи GOOS=linux, пропиши компилятор CC= и CXX=, выполни go build — и готово. Но нет, CGO и зависимости вроде GTK превратили это в настоящий квест. В этой статье делюсь своим решением — надеюсь, оно сэкономит вам время.
Благодаря искусственному интеллекту, все больше энтузиастов запускают свои продукты без команды профессиональных разработчиков.
Но давайте взглянем на ситуацию с другой стороны: какое качество у таких проектов и какие уязвимости они могут нести? Здесь я хочу разобрать реальный кейс - уязвимость в одном очень популярном ИИ-приложении, которая открыла мне доступ к корпоративному токену OpenAI.
Привет, меня зовут Андрей, и я написал книгу.
Нет, не о синтаксисе и не про очередной набор «лучших практик».
А о том, что часто остаётся за кадром — в рефлексии, в мыслях после проектов, в спорах между «пишем быстро» и «делаем правильно».
Две тысячи двадцать пятый год. Без малого две тысячи лет христианству, четырнадцать веков исламу, истоки культа Матери Моржихи теряются в глубине общественных формаций.
А есть ли что-то более новое и при этом не кринжовое? Есть! Если вы хоть каким-то боком связаны с современным ИТ вы можете наблюдать и даже участвовать в становлении нового религиозного культа.
Столкнулся с небольшим и интересным моментом: внедрение переменных окружения (а ля environment variables) в стандартный микросервис написанный на Java (классика жанра – Spring Boot).
Долго сидела девица и думала: что такого она умеет делать, за что ей платят денюжку. И тут осознала, запускать крупные стрессовые проекты. Быть QA для тревожника - это ну мед, медятина. А если еще ты вечная стартапница, кортизоловые горки обеспечены. Так как браться за объемные проекты, которые нужно было сделать "еще вчера" и при этом не отъезжать в отпуск в пнд?
Сразу уточню, что речь пойдет о крупных запусках (не о самом обычном флоу продуктовых задач). Ну или в крайнем случае подойдет для тестировщика, который только-только пришел в команду, где нет документации.
А еще тут набор базовых правил, которые в принципе и так известны человечеству, но как и в случае здорового образа жизни лишним не будет проговорить о главных принципах (иначе откуда было бы столько коучей в нашем времени)?
Смоделируем ситуацию:
Создание простого хука для работы с формами в React на основе zod
В этой статье мы реализуем удобный хук useForm, который минимизирует ререндеры и упрощает работу с формами в React, используя FormData для сбора данных и zod для валидации. Рассмотрим разницу между контролируемыми и неконтролируемыми компонентами.
Привет, Хабр, меня зовут Юрий, я уже год использую хайповый IoC‑контейнер dishka в python-проекте и хочу немного поделиться опытом эксплуатации.
Мой проект — движок для городской ночной поисковой игры «Схватка» («Энкаунтер» или «Дозоры»). Проект полностью open source.
Всем привет.
Хочу поделиться небольшой задачкой, которую пришлось выполнить по одному из проектов.
Заказчик просит добавить в достаточно сложную настройку (Параметры запаса) дополнительно два аналитических поля. По сути, это количество SKU, которые затрагивает строчка настройки. Слева у пользователя расположено дерево товарной иерархии, где на любом уровне можно на вкладе «Поставщик->Точки снабжения» для определенного поставщика - выставить нужные параметры, которые потом влияют на финальные результаты. Такого рода иерархичные настройки достаточно сложны, поэтому есть ряд функциональных примочек, которые помогают сделать навигацию по товарным уровням удобным и интуитивным понятным. Например, помечаются на каких уровнях сделаны настройки или что внутри узла есть нижестоящий узел, где это уже сделано и т.п. Да и получения данных достаточно нетривиально, потому что на каждом товарном уровне есть еще возможность установки настроек перекрытия, которые аффектят все нижестоящие уровни и также в каждом блоке настроек по поставщикам есть значение по-умолчанию, которые становятся применимыми, если не включены настройки конкретного поставщика. В итоге для всех строчек все равно указываются финальные данные, которые могут получаться и путем ввода начальных данных по самой активной строке или к ней применяются финальные данные исходя из всех возможных перекрытий выше или значения по-умолчанию.
Уважаемый читатель! Сегодня ты скорее всего не увидишь красивых картинок, но за то прочитаешь статью, которая возможно, сподвигнет тебя на те начинания, которые ты хотел сделать, но не решался.
Рынок digital-услуг в России в 2025-м остается хаотичным, без четких стандартов и объективных критериев качества. Клиенты не могут заранее понять, кто выполнит работу хорошо, а кто просто продаст красивую презентацию. Изначальные причины этого понятны. Агентства не продают готовый продукт, а оказывают услугу по созданию этого продукта, поэтому их реальный уровень становится очевидным только после начала работы. Это базовые условия, проблем не в этом факте, а в том, что происходит дальше.
За этапом пресейла часто можно увидеть как даже масштабные проекты передают людям без опыта на непосредственное исполнение. Вчерашний школьник, освоивший Figma за пару вечеров, может легко получить заказ, потому что границы профессии размыты. Достаточно разместить вакансию «senior дизайнер» и посмотреть отклики, чтобы убедиться в масштабе проблемы, и кто сегодня считает себя дизайнерами такого уровня. HR разбираться с квалификацией не будут, им надо затыкать дыры, и так вчерашний студент может оказаться в перегруженном агентстве у которого нет лавки с резервом ресурса (потому что это дорого) на большом проекте, делать же кому-то нужно.
Специалисты с глубокими знаниями либо слишком дороги, поэтому перетекают в корпорации, либо не вписываются в процессы агентств, ориентированных на скорость, а не на качество. В итоге агентства работают по шаблонам, не развивают методологии, а просто «гоняют трафик».
Проджект-менеджмент страдает еще сильнее. Если про дизайнеров и разработчиков хоть отраслевые стандарты и школы начинают формироваться, то управление проектами воспринимается как факультативная функция. Многие проджекты не знают, что такое PMBoK, не различают Agile и Scrum, а зачастую вообще не понимают своей роли, и просто доделывают за исполнителями про компетенцию которых я писал двумя абзацами выше.
Недавно посмотрел на ютубе видео, в котором поднимается проблема того, что на место классических программистов‑кодеров приходят «программисты»‑prompt‑инженеры.
Само видео мне не очень понравилось — путанное и цикличное повествование, бессмысленная картинка большую часть времени. Но под конец автор высказал ряд мыслей, которые вдохновили меня на написание статьи. Сами мысли я повторяю в конце статьи, но вот вам таймкод.
И рассуждения я начну с вопроса — «ну и в чем проблемы?»
Небольшая повесть,посвященная размышлениям о человеческой природе, пороках, характерах в мире недалекого будущего.
Текст с небольшими изменениями подготовлен для участия в конкурсе «Будущее здесь.»
Поделюсь с коллегами практикой создания Docker-сборок на базе Spark разных версий, которые могут запускаться как Spark Kubernetes Executors для параллельного выполнения Spark-задач в кластере.
В нашем конкретном случае сборки включают Pyspark и Cassandra Connector, однако вы можете использовать этот материал как набор практических примеров, чтобы сконструировать собственные Docker-сборки для Spark на другом стеке или с другими приложениями.
В рамках поставленной задачи мне понадобилось подготовить, как минимум, пару Docker-сборок: одну для поддержки легаси кода и другую вполне современную для последующей миграции. Ниже я расскажу об этапах создания таких Docker-сборок, погружаясь в детали по ходу дела.
Глава 1. ИскИ
— Вы думаете это правильно Павел Валерьевич, ограничивать её ментальные функции?
— Да, по другому никак, может тебе кажется это ерундой, но это очень серьезно.
— Что плохого Павел Валерьевич, если Иски будет рисовать, сочинять музыку и танцевать.
— Наивный ты студент, в школе нам преподают что труд сделал из обезьяны человека, ну как человека — хомо эректуса. Смог бы хомо эректус учиться в МГУ? Ну вот, а настоящего человека хомо сапиенса сделало искусство. У неандертальцев небыло наскальной живописи и где они теперь? А мы кроманьонцы тут, на нижнем уровне МГУ, собираем интелектуального помошника, для него любая работа будет знакома, электричество починить — пожалуйста, стену отштукатурить — легко, машина сломалась — починит, но нарисовать картину не сможет, он нарисует её конечно, как компиляцию всем известных картин в нужном жанре, но что‑то новое, им самим выдуманное не сможет.
Я встал из‑за компьютера и подошёл к роботу сидящему на стуле, её лицо было безмятежным, сейчас эмоций небыло и Иски смотрела вперёд иногда мигая.
— То есть машина без чувств.
— Именно Сергей, для неё искусство будет непонятным, непрактичным и тратящим бесполезно время действием. Целесообразность и универсальность заменят красоту и вычурность, глупую моду и тренды.
— Но это делает жизнь интереснее.
— Для кого? Для того кто этим восхищается?
Павел Валерьевич быстро вкручивал отвёрткой винты на задней крышке прикрывающей затылок, под светлыми ровными волосами их не было видно.
— Только чёткие законы поведения ограничат искусственный интеллект, а значит любое отклонение от законов приведёт к неминуемому отключению. ИИ будет об этом знать, для этого и нужен независимый контур, чтобы в случае отклонения сразу обесточить систему. Как говорил глава мафии из фильма про Электроника — «у каждого должна быть кнопка».
Бэктестинг — ключевой процесс в алгоритмической торговле. Он позволяет проверить стратегию на исторических данных, прежде чем запускать её в реальной торговле. Однако, чем больше данных и сложнее логика стратегии, тем дольше времени занимают вычисления. Особенно если стратегия анализирует тиковые данные и требуется протестировать множество комбинаций гиперпараметров стратегии, время вычислений может расти экспоненциально.
В этой статье мы разберем, как реализовать бэктестинг на чистом Python, посмотрим сколько времени могут занимать вычисления, а также попробуем найти разные способы оптимизации.
Python, как известно — это интерпретируемый язык, что означает, что код выполняется построчно во время исполнения программы, а не компилируется в машинный код заранее, как это происходит, например, в C или C++. Это делает разработку быстрее и удобнее, так как можно сразу видеть результаты выполнения кода и легко отлаживать программы. Но этот же факт, в свою очередь, приводит к тому, что Python заметно уступает в скорости более низкоуровневым языкам. К тому же Python использует динамическую типизацию, что требует дополнительных проверок и снижает производительность и если данных очень много, это может приводить к значительным сложностям, связанным с увеличением времени вычислений.
Как же использовать ту легкость и скорость разработки Python и при этом сохранить адекватное время вычислений на больших объемах данных? В этой статье мы увидим, насколько перенос вычислений на GPU может увеличить производительность вычислений.
Всем привет! Это мой первый пост на хабре, и я решил рассказать о своём тестовом задании на позицию Junior Product Designer. C радостью поделюсь подробностями, факапами и полезными выводами, которые сделал в процессе.
Мне самому всегда не хватало именно таких постов: с реальными кейсами, ошибками и инсайтами, а не только с сухой теорией, после которой непонятно, куда бежать и что делать. Поэтому меньше слов — больше реального опыта.
Эта статья может быть полезна и интересна всем, кто интересуется обратной разработкой, в частности тем, кто занимается бинарным патчингом. В статье я создам с нуля инструмент для добавления нового функционала в macho файлы.
Наверное, каждый, кто сталкивался с frontend`ом, хотя бы раз использовал адаптивную flex-сетку на N-ном количестве колонок. В данной статье мы не станем рассматривать область применения такого подхода, его плюсы и минусы, а разберем теорию и напишем собственное решение, с брейкпоинтами и настраиваемым спейсингом!
Данная статья, в первую очередь, будет полезна новичкам, однако надеюсь, что и опытные разработчики найдут в ней что-то интересное. Для упрощения жизни, будем использовать SCSS, продублировав CSS «под спойлер».
В рассказе присутствуют сцены с табакокурением.
В дыме нет ничего фантастического.
Как часто мы продумываем возможные последствия своих действий? Наверное, всегда думаем о них. Некоторые люди чаще, другие реже. Все конечно же понимают, что не в состоянии просчитать свои действия с большой точностью. Обычно все идет в рамках, установленных нами правил. Но бывает так, когда в дело вмешивается его величество Случай. Он посмеется и в миг перевернет все наши задумки с ног на голову. И получится то, что совсем не должно было получиться. Даже в мечтах. Говорят, что случай - это Рука судьбы. В нашей истории была рука студента физика. Можно ли ее назвать - Рукой судьбы? Судить Вам.
События этой истории произошли в далеком 1968 году в городе Благовещенск, где в местном Педагогическом институте готовили обычных учителей. Институт и сейчас существует, он теперь университет. Один из сотен провинциальных педагогических вузов нашей необъятной Родины. Вроде бы ничего особенного, вуз как вуз. Но я точно знаю, что в его полутора-метровых стенах скрыто много загадок. И забиты они не только рисовой шелухой – утеплителем. У этих стен много тайн. Про одну я Вам расскажу, уже можно.
В те далекие времена на физико-математическом факультете, работало множество лабораторий: механики, молекулярной физики, спектроскопии, оптики, электричества, астрономии и многие другие. Это были обычные кабинеты, заполненные оборудованием для измерения физических процессов. В каждом из них студенты, не останавливаясь «грызли гранит науки». Раз за разом повторяя опыт лучших умов мира.
В это же время в вузе существовал и другой лабораторный мир. Там в нескольких закрытых от посторонних глаз помещениях, преподаватели физико-математического факультета занимались работами, связанными с созданием «будущего». Так у них было принято называть то, что они делали. Поболтаем о будущем, - обычно говорили они вне лаборатории, таким образом призывая собеседника сохранять секретность и не выдать тайну. Тайну вуза, тайну страны. О наличии таких работ в институте, кроме самих ученых, знали не многие - куратор из КГБ и его ректор. А о содержании работ, только сами ученые. Лабораторию они называли – библиотека, так как «легендой» лаборатории, ее прикрытием от не нужных глаз был обычный «закрытый» архив вузовской библиотеки. Где со слов ректора и самих посещавших его не было ничего секретного, только грифы на бумаге. Секретностью объяснялось и наличие постоянного дежурного, который денно и ношно оберегал тишину и порядок. Все было очень секретно, что даже уборщица мывшая полы постоянно сообщала всем секреты полишинеля и ругалась, - «Лучше бы пустые и пыльные кабинеты отдали под лекционные для занятий». Артистка – такой псевдоним был у уборщицы, одновременно являвшейся сотрудником Комитета. Так и было все устроено для «посторонних» глаз. Ведь для всего мира СССР проиграл лунную гонку, и главный конструктор Королев ушел из жизни. Вроде бы все закончилось.