Имеем сборку armbian для сервера, то есть без какой-либо графической оболочки.

Пусть в наш компьютер пользователь периодически вставляет самые обычные флешки (с файловой системой FAT32). При вставке такой флешки никакого нового локального диска E не появляется. То есть автоматическое монтирование не происходит. Однако нашей программе на компьютере необходимо с этой флешкой работать. Как же её примонтировать?

Рассмотрим Ручной вариант и Автоматический вариант. Также коснёмся темы как сразу получить образ armbian, который умеет в автомонтирование.

Добро пожаловать в волшебный мир программирования, где каждый разработчик – не просто кодер, а настоящий магистр заклинаний и цифровых чар! Перед вами лежит карта неисследованных земель, полных таинственных «кодовых джунглей», где скрывается легендарный кракен «кодовых глубин» и много других заморских чудес.

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

Запаситесь же попкорном из нулей и единиц, устройтесь поудобнее за своими многооконными экранами и готовьтесь к незабываемому путешествию!

За свою карьеру написал больше 100 микросервисов и около 30 брал на сопровождение, рефакторинг и доработку. Среди них были сервисы аутентификации, криптографии, адаптеры, прокси, эмитенты токенов, DataStore/DataMart, калькулирующие измерения к срезам статистики на холодных данных и на потоке, оркестраторы с широким спектром смежных систем (пример на хабре) etc. Писал на таких языках, как С#, Java, Kotlin, Scala, Node.js. И некоторое время проходил "день сурка" в момент проектирования или рефакторинга полученного в наследство кода, когда руки доходят до аспекта логирования, мониторинга, обработки ошибок etc. В этой статье опишу с какими реализациями слоя обработки ошибок я сталкивался или находил в качестве best practice, как обычно ее интегрируют в SLA, метрики и логи, почему стал изобретать велосипед и к чему пришел, а также сравню собирательный образ классических подходов с выбраным в по итогу проб и ошибок.

Привет, Хабр!

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

В 2024 году Rust остается одним из наиболее востребованных и перспективных языков программирования. Вот несколько причин, почему учить Rust может быть полезно:

1. Безопасность: Rust разработан с упором на безопасность, предотвращая многие типичные ошибки программирования, такие как доступ к памяти после ее освобождения или гонки данных. Это особенно важно для разработки критически важных систем, таких как операционные системы или встраиваемые приложения.

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

3. Многопоточность: Rust предоставляет удобные инструменты для разработки многопоточных приложений. Он предлагает безопасные абстракции для работы с потоками и предотвращает гонки данных, что облегчает разработку параллельных программ.

4. Кроссплатформенность: Rust поддерживает различные платформы, включая Windows, Linux, macOS и другие. Это позволяет разрабатывать приложения, которые могут работать на разных операционных системах без необходимости переписывать код.

5. Растущее сообщество: Rust имеет активное и одно из самых быстрорастущих сообщество разработчиков. Это означает, что всегда есть доступ к обновленным библиотекам, учебным материалам и помощи от опытных разработчиков.

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

Новый Год уже совсем на носу, а значит нужен свежий производственный календарь в базе данных PostgreSQL. Но как совершенно обленившийся IT-шник, заводить его руками не хочется. Хочется, чтобы вызовом одной функции он сразу появился. Ну а уж из этой функции можно его сохранить в табличку и спокойно использовать до следующего Нового Года. А тогда опять просто вызвать вызвать функцию и с чистой совестью отрапортовать о выполненной работе. Цель статьи - показать возможности COPY ... FROM PROGRAM и простейшие приемы парсинга XML в PostgreSQL.

«PostgreSQL может заменить Kafka, RabbitMQ, MongoDB, Redis, Elasticsearch, Geospatial Database и даже Сron. Но есть нюансы».

В среду, 13 декабря, в прямом эфире встретились Senior Software Engineer в Avito Tech Виталий Лихачёв и DBA в Altinity Евгений Климов и обсудили PostgreSQL. В компании Виталия любят PostgreSQL, умеют его готовить и используют для множества задач. А вот в компании Евгения предпочитают Clickhouse и считают, что один инструмент для всего — не всегда хорошо. У экспертов получилась интересная и местами остренькая беседа.

Иногда возникает ситуация, когда надо что-то посчитать согласно сложному алгоритму прямо на LapTop PC. При этом сам алгоритм написан на Си.

Это может быть цифровой фильтр, дискретное преобразование Фурье, генератор QR кода, кусок линейной алгебры с векторами, какое-то тригонометрическое вычисление, программный модулятор, статистическая обработка случайной величины.

Да всё, что угодно! То есть Вы хотите использовать язык Си как гибкий и быстрый калькулятор в Windows.

В этом тексте представлено минимальное окружение для сборки Си кода в Windows.

Visual Studio Code — это бесплатный, шустрый (что важно на больших проектах) и глубоко кастомизируемый редактор кода.

В статье расскажу, какие настройки и плагины VS Code использует наша команда фронтенда в KTS. Материал может быть полезен для JavaScript- и React-разработчиков, а ещё для тех, кто уже давно пользуется VS Code, но не знает о некоторых полезных плагинах и фичах для повседневного использования. 

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

Также я рассмотрел инструменты для оптимизации работы с Git, шаблоны директорий и другие возможные настройки.

При интеграции с нашим приложением, написанном на "классическом" SpringBoot-стэке встал вопрос о предоставлении описания АПИ партнеру. Фактически из коробки SpringBoot позволяет развернуть на стороне приложения тонкий Swagger-клиент и сгенерировать на лету спецификацию в формате Swagger (OpenAPI), которая представляет собой JSON особой структуры (хотя если читатель не знает, что это, наверное нет никакого смысла вообще читать эту статью).

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

В ходе изысканий в google, была найдена статья, и советы на stackoverflow, которые фактически повторяли эту статью. Фактически было найдено 2 варианта решения:

1) Использовать онлайн-конвертер

2) Настроить цепочку из 3 maven-плагинов:

Как мы к этому пришли? Как мы стали вместо решения наших задач, тратить кучи денег на решение проблем, которых у нас нет?

Всем привет! Меня зовут Надя, и сейчас я выступаю в роли ментора на программе Mentor in Tech и помогаю людям «войти» в Data Science. А несколькими годами ранее сама столкнулась с задачей перехода в DS из другой сферы, так что обо всех трудностях знаю не понаслышке.

Порог для входа в профессию очень высокий, так как DS стоит на стыке трех направлений: аналитики, математики и программирования. Но освоить специальность — задача выполнимая (хоть и непростая), даже если ты гуманитарий и списывал математику у соседа по парте.

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

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

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

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

Новое место, новая позиция, новый продукт! Финтех, камунда, ~ 40 (!) микросервисов за которые отвечает наша команда. Первый спринт. Я в роли наблюдателя. В спринте вроде бы обычная задача - нужно вызвать из одного сервиса другой, и обработать результат. Ребята оценивают, начинают работу, и что я вижу в течение следующих дней: один разработчик берёт сервис-сервер, другой сервис-клиент, и каждый начинает реализацию контракта описанного в табличке в confluence. Что-от около десятка полей, если мне не изменяет память. Они уходят на пару дней, возвращаются, начинают тестирование контракта, выясняется что одно или два поля немного различаются в названии, уходят править нейминг, возвращаются, тестируют и только после этого переходят к написанию какой-то логики.

И тут меня понесло. Да, дело не конкретно в этих ребятах или задаче. Или продукте. Или компании. Они просто делают работу как привыкли делать. С точки зрения разработчика - закрыть такую задачу за 3 или 6 дней - нет особой разницы. Над сроками вообще начинаешь заморачиваться только после перехода в роль которая за эти самые сроки хоть как-то отвечает. Но потратить 4 дня силами двух разработчиков только на контрактую обвязку...

Здесь в памяти начали всплывать давние попытки генерации спецификаций по коду. Или документации по коду. Или кода из спецификации. В общем какие-то попытки генерации чего-то связанного с openapi. А дальше мы ушли в углубленное изучение того, как это можно использовать в контексте нашего продукта и большого количества взаимодействий сервисов.

Не секрет, что работа с часовыми поясами — боль, и многие разработчики объяснимо стараются ее избегать. Тем более что в каждом языке программирования / СУБД работа с часовыми поясами реализована по-разному.

Среди тех, кто работает с PostgreSQL, есть очень распространенное заблуждение про типы данных timestamp (который также именуется timestamp without time zone) и timestamptz (или timestamp with time zone). Вкратце его можно сформулировать так:

Мне не нужен тип timestamp with time zone, т.к. у меня все находится в одном часовом поясе — и сервер, и клиенты.

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

Недавно попался на глаза примерно такой кусок запроса, и тут прекрасно примерно все:

• множество чтений из CTE (хоть и единственной записи, но все же);

• извлечение по каждому ключу текста с раскастовкой в jsonb;

• извлечение каждого отдельного json-ключа в каждое отдельное одноименное поле;

• "ручное" преобразование текстового представления массива в json в текстовое представление PostgreSQL.

А как - правильно?

Рассмотрим вариант добавления трейсов в Spring Boot 3 приложение с использованием Kafka в качестве транспорта и Zipkin в качестве инструмента для трассировки.

Функциональность соберем в автоконфигурацию для подключения к Spring Boot приложениям.

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

Стоит заметить, что локальная БД в данном случае будет использоваться для кеширования данных, получаемых с бэкенда, однако взаимодействие с бэком не будет рассматриваться здесь, так как это тема, достойная отдельной статьи.

Меня зовут Ричард, и я младший разработчик в компании Digital Design.

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

Эта статья о том как отправлять и обрабатывать HTTP-запросы непосредственно из/в PostgreSQL. Автор расскажет о том, что такое асинхронное уведомление в PostgreSQL, и наглядно продемонстрирует, как с его помощью можно взаимодействовать с внешними системами из самой СУБД.