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

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

Последнее время только ленивый не хайпанул на теме ChatGPT. Все, как один, бросились к ИИ решать все свои проблемы, от бытовых и философских вопросов до серьезных задач вроде “найди мне работу” или “помоги релоцироваться”.

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

Причины утечек

Для начала перечислим возможные причины утечки памяти:

1) Утечка горутин

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

2) Бесконечная запись в глобальные переменные

Приложение может бесконечно писать в какую-нибудь глобальную мапу, в результате чего память будет утекать. Один раз я пытался найти утечку у приложения, которое использовало gorilla context. Особенность этой библиотеки в том, что при обработке http запроса она сохраняет указатель на запрос в глобальную мапу и не удаляет ключ мапы без явного указания в пользовательском коде. Начиная с Go 1.7, разработчики gorilla рекомендуют использовать http.Request.Context()

Привет!

На связи Ваня Гулаков, DevOps из CloudMTS. Сегодня хочу рассказать про контейнерные ОС и как мы искали для сервиса Managed Kubernetes ту самую.

До недавнего времени мы использовали дедушку CentOS 7, который уже давно отжил свое. Основные причины переезда, соответственно, старое ядро и отсутствие поддержки. 

Раз уж переезд был неизбежен, появилась мысль присмотреться к так называемым Linux For Containers или Container Optimized OS дистрибутивам. 

В предыдущей статье я рассказывал, как можно доучить GPT на собственных взглядах и вкусах. Сегодня попробуем дать GPT возможность поработать программистом по‑настоящему — с запуском кода и отладкой без участия человека. Весь код опубликован в репозитарии.

Как многие уже убедились, ChatGPT хорош, но есть некоторые типы задач, с которыми у него возникают трудности:

1. Он не может получать новые актуальные знания из сети.
2. Он не может выполнить какие‑либо действия.
3. У него сложности с алгоритмическими задачами (перевернуть строку, решить уравнение, произвести вычисления с применением численных методов).

И если задача 1 решается с помощью BingChat, то 2 и 3 мы сегодня будем решать в рамках данного туториала.

Основная идея такая: пусть ChatGPT сам решает, может ли он справиться с задачей «в уме» или же это лучше сделать с помощью написания кода на python, а наш сервер сразу же выполняет этот код и снова отдает результат работы ChatGPT, чтобы он мог его интерпретировать и или выдать пользователю окончательный ответ или исправить ошибку в своей программе и попытаться ещё раз.

Нет, я не буду мучать бедную нейросеть парадоксами или математическими задачками — для этого есть Wolfram Alpha. Я просто расскажу о паре эпизодов из личного опыта прикосновений к этой популярной сейчас теме. И мне также прекрасно известно о том, что ChatGPT нельзя рассматривать как источник достоверной информации. Уж кто только об этом не предупреждал, видать настала моя очередь.

Итак, эпизод первый — глупость.

ГПТ это именно то, как он называется — преобразователь текста. То есть некоторый чёрный ящик у которого есть текстовый вход и текстовый выход, и текст на выходе скорее всего будет иметь какое-то отношение к тексту на входе. И всё, сверх того ничего пользователям не обещано.

Печальная история «Элизы» подсказывает нам, что наделять программу человеческими качествами (например, эмоциями) нельзя. Как и нельзя ожидать от неё того, для чего она не предназначена. Но иногда, вот как в этом случае, очень хочется представить себе, с каким умным и пафосным видом нейросеть генерирует абсолютную чушь.

Аннотация

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

Статья начинается с краткого обзора литературы.

Во второй главе обсуждается разница между автономностью и автоматизацией.

В третьей главе дается определение современного производства и описываются процессы, наиболее подходящие для автоматизации.

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

Сам подход изложен в пятой главе, где также рассматриваются ключевые логические элементы автономных систем управления.

В шестой части приведены программные средства и технологии, использованные при создании автономной фабрики.

В заключении обобщаются представленные идеи и преимущества предлагаемого подхода.

Привет! Меня зовут Владислав Попов, я автор курса «Go-разработчик» Яндекс Практикума. Когда-то я сам был студентом — хотел учиться Go, но такого курса в Практикуме не было, поступил на Python. Прошёл вводную часть — и тут стартовал желанный курс по Go. В тот же вечер оформил возврат и перепоступил. Попал в первый поток, прошёл его, и после сдачи итогового проекта мне предложили стать тестером курса «Продвинутый Go-разработчик».

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

За время работы с Go я понял, что сам язык не очень сложный и подходит даже в качестве первого, но нужно выучить синтаксис и погрузиться в некоторые особенности, которые отличают Go от других языков: например, интерфейсы и особенности встраивания. А ещё важно на старте хорошо знать Git и ориентироваться в работе SQL (причём любого).

Эта подборка составлена менторами нашего курса по Go-разработке для практикующих программистов. Она родилась благодаря коллективному разуму наших наставников, которые занимают позиции синьор-разработчиков на Go в разных компаниях.

Предположим у вас есть сайт на котором вы хотите в автоматическом режиме консультировать посетителей. Само собой сейчас это уже хочется делать с использованием chatGPT.

В этой статье мы разберем новые удивительные способности последней языковой модели из семейства GPT (от понимания мемов до программирования), немного покопаемся у нее под капотом, а также попробуем понять – насколько близко искусственный интеллект подошел к черте его безопасного применения?

На текущем месте работы столкнулся с необходимости собирать Docker образы для сервисов написанных на Rust. Обычно в таком случае пишется Dockerfile, который внутри докера просто собирает контейнер и все. Но все оказалось не так однозначно: такая схема довольно неплохо работает, когда у тебя есть x86_64 Linux машина, но любой шаг в сторону и начинаются большие проблемы.

Все довольно неприятно уже на Intel MacBook машинах, докер поедает довольно много ресурсов с хоста, а еще возникают всякие странные приколы с монтированием файловой системы и правами доступа. Но настоящий ужас начинается на Макбуках с Apple Silicon процессорами, где обычной виртуализацией уже не обойдешься и можно часами ждать сборки простого сервиса через qemu. Можно решать эту проблему через сборку контейнеров в CI, но когда разработчиков много, а им надо часто что-то пересобирать, то там образовывалась очередь.

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

Инструменты покрытия кода помогают понять, какая часть кодовой базы выполняется (или, как еще говорят, покрывается) при выполнении данного набора тестов. Какое-то время Go поддерживал измерение покрытия кода на уровне пакета, введенное в Go 1.2, она включалась флагом команды go test -cover.

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

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

Двоичные файлы интеграционных тестов создаются командой go build, а не go test, поэтому инструментарий Go до сих пор не предоставлял простого способа сбора профиля покрытия этих тестов.

С версии Go 1.20 программы с инструментированием покрытия можно создавать командой go build -cover, а затем, чтобы расширить область покрытия, передавать эти инструментированные двоичные файлы в интеграционный тест.

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

Agon light — это 8-разрядный микрокомпьютер с полностью открытым исходным кодом и микроконтроллер на одной небольшой плате, построенный по последнему слову техники 21 века. Текущая цена очередного инженерного чуда — 50 евро.

Введение

Согласно статистике, большинство всех атак совершается с использованием вредоносного программного обеспечения, а половина от всех атак проводится с использованием методов социальной инженерии.

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

Мы, Маргарита Белоусова, аналитик аналитического центра и Анастасия Прядко, специалист по анализу защищенности компании УЦСБ написали пошаговую инструкцию, как сделать фишинговый документ: детали и примеры кода. Кроме того, мы кратко рассмотрели структуру PDF-файла, как и куда в него внедрять JavaScript, а также способы маскировки факта внедрения скрипта. Наш опыт пригодится безопасникам, системным администраторам и всем, кто связан с ИБ.

Структура PDF

Организация данных в памяти

PDF способен на большее, чем просто отображать текст. Он может также включать в себя изображения и другие мультимедийные элементы, может быть защищён паролем, выполнять JavaScript и многое другое. Вне зависимости от версии структура PDF документа неизменна:

Сейчас в IT-сфере набирают популярность так называемые low-code и no-code системы. Разработчики таких систем твердят, что с помощью их продуктов бизнес может создавать прикладное ПО без профессиональных разработчиков. Еще и весь интернет набит статьями, которые преподносят low-code и no-code как что-то кардинально новое и очень крутое для людей, которые не умеют программировать. Так ли это на самом деле?

На протяжении более чем 10 лет работы с PostgreSQL, периодически наблюдаю, как команды на начальном этапе, зачастую, не уделяют внимание ролевой модели базы, или как вся команда работает под суперпользователем postgres и забывает про версионирование схемы.

В процессе общения с различными командами в НЛМК у меня появилась идея предложить им «преднастроенный PostgreSQL». Как в итоге сделали — под катом.

PostgreSQL и MySQL — это надежные, безопасные и масштабируемые базы данных, которые существуют уже много лет. Каждая из них имеет уникальные сильные и слабые стороны, что делает какую‑либо из них более подходящей для конкретных нужд. В этой статье мы проведем их сравнение, чтобы помочь с принятием обоснованного решения в 2023 году.

Язык программирования Rust был разработан компанией Mozilla и впервые представлен в 2010 году. Он считается одним из самых безопасных и производительных языков программирования на сегодняшний день. В данной статье мы рассмотрим основные преимущества Rust, и почему он становится все более популярным в системном программировании.