Рубрика «makefile» - 2

Аннотация статьи.

  • Использование GtkApplication. Каркас приложения. Makefile.
  • Отрисовка библиотекой librsvg.
  • Экспорт изображения в GtkImage и его масшабирование.
  • Масштабирование SVG самописными функциями.
  • Получение полного пути в приложениях.
  • Тесты быстродействия GtkDrawingArea vs GtkImage.

Читать полностью »

laravel-in-docker

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

"А в чём, собственно, сложность?" — можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории:

  • "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
  • "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
  • "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Всё, что ты прочитаешь ниже — является субъективным опытом, который не претендует быть истиной в последней инстанции. Если у тебя будут дополнения или указания на неточности — welcome to comments.

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Читать полностью »

Добрый вечер, хаброчитатели!

В предыдущих статьях (один, два) мы определили понятие символьного устройства и написали простейший пример символьного драйвера. Последняя часть посвещена проверки его работоспособности. На Хабре уже есть примеры как можно протестировать драйвер, например: тык.

Я попытаюсь рассмотреть данный вопрос чуть подробнее, надеюсь, вам понравится.

Как написать свой первый Linux device driver. Часть 3 - 1
Читать полностью »

В июне на конференции РИТ++ мы с коллегой Игорем Должиковым делились опытом автоматизации процесса разработки сервисов на Go — от первого коммита и до релиза в продакшн-окружение Kubernetes (да-да, видео начинается с 07:16, и нам тоже это не нравится). С момента публикации мастер-класса время от времени я получаю вопросы по тем или иным темам, затронутым в нем. Пожалуй, самые горячие вопросы достойны отдельного рассмотрения, и сегодня я хотела бы поговорить о процессе сборки приложения. Затрагиваемые темы актуальны не только при подготовке сервисов, но и вообще для любых приложений, написанных на Go.

Всё, что описано в этой статье, актуально для текущей версии Go — 1.9.
Читать полностью »

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

В среду железячников я попал в 2006 году на 4-м курсе учёбы в университете, когда пошёл на производственную практику в научно-технический центр, где, собственно, и работаю по сей день. В то время в нашей компании мейнстримом было использование Keil uVision2 для МК на базе C51 и ARM. Однако мне подсовывали простые задачи под PIC, вроде контроля и управления одним сигналом (кнопка вкл-выкл), и моей первой средой разработки были блокноты — бумажный и компьютерный, плюс книжки бумажные по PIC. Выглядела моя среда разработки примерно так:

Идеальная среда разработки для PIC — личный опыт

Для компиляции файлов мне выдали экзешник компилятора и bat-файл, который использовался мной совершенно бездумно — даже не знаю, что за компилятор там был. В общем, суровые были времена…
Читать полностью »

image

Аннотация

В статье описывается фреймворк, позволяющий создавать графические кроссплатформенные приложения, написанные на языке Java, но при этом абсолютно не зависящие ни от Oracle JRE, ни от OpenJDK. Основная идеология фреймворка — по возможности снять с разработчика заботы об обеспечении «родного» look and feel для приложения под каждой операционной системой.

Фактически, на выходе вы получите исполняемый файл, опирающийся только на системные API, на котором нигде не будет клейма «написано на Java».

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

Фреймворк находится в стадии публичной alpha-версии, что означает некоторую его работоспособность, но непроверенность. Использование поощряется (я постараюсь прислушаться к жалобам на проблемы и помогу их решить), но работоспособность не гарантируется.

Готовая, собранная версия приложений, демонстрирующих работу фреймворка под всеми платформами, находится здесь.

Всех интересующихся подробностями милости прошу под кат.
Читать полностью »

Во время разработки большого проекта наступает такой момент, когда надо встроить в приложение библиотеку из мира open source с подходящей лицензией. Например, вам захотелось ускорить декодирование картинок, или понадобился sqlite3 с fts4, или нужны какие-то плюшки из libicu, которых нету в системной libicucore.

Для этого библиотеку, которая понадобилась, нужно будет собрать для 5 архитектур: armv7, armv7s, arm64, i386, x86_64. С кросскомпиляцией есть много подводных камней, на которые не хотелось бы наткнуться, когда есть уже проверенные решения. В этом коротком посте я расскажу об автоматизации сборки библиотек на примере protobuf и sqlite3.
Читать полностью »

в 13:12, , рубрики: make, makefile, метки: ,

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

Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом 'пережитке прошлого' (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.
Читать полностью »

Я люблю desktop-приложения. Признаваться в этом нынче, похоже, стыднее, чем в связях с иностранной разведкой, но это так. Нет, это не значит, что я не люблю интернет-технологии. Более того, некоторые я не только уважаю, а даже более-менее знаю. Но, тем не менее, я скучаю по тем временам, когда программа писалась на одном компьютере, потом компилировалась и запускалась на других, разных компьютерах. Тогда везде (почти) была одна система — Windows с одной и той же API, почти не было проблем совместимости на уровне приложений, никто не материл разработчиков браузеров — все берегли нервы на разработчиков WinAPI, которые умудрялись создавать конфликты даже внутри нее одной. Но это я, конечно, иронизирую, а если серьезно — иногда и сейчас хочется написать просто desktop-приложение, да так, чтобы работало оно на всех популярных системах. Трудно? Если подумать и покопать, то не очень.

Еще я люблю языки высокого уровня с аккуратной архитектурой и строгой типизацией. Это — Java и C#. Оба они предоставляют разработчику множество преимуществ по сравнению с C++, оба избавляют от ряда забот. Чем приходится платить? Тем, что таскаешь за собой тяжелую колоду, которая называется Oracle JVM, .NET или mono. Все три колоды весят сотни мегабайт и лицензию имеют такую, что каждый пользователь вынужден качать эту штуку сам, не путая при этом разрядность своего компьютера, а главное — программа на Java не может быть совместима со всеми версиями JVM разом, не так ли? И вот — мы приходим к тому, что просто скинуть программку другу (или миллиону друзей) и не заботиться о том, что она у него не запустится, не выходит. Приходится делать хитрые сетапы, вбивать костыли, и это я еще не упомянул .NET — однажды я видел у друга сразу 3 установленных версии, причем все три были нужны разным приложениям…

Стоп! А давайте напишем программу на Java, но так, чтобы она не требовала установки на машину какой-либо JVM, чтобы одним касанием собиралась под Windows, Linux и OS X и чтобы при этом занимала совсем чуть-чуть; так, чтобы никто даже не понял, что она написана, скажем, не на C. Невозможно? Совсем наоборот! (И нет, я имею в виду не gcj, который лишает Java всех ее прелестей. Рефлексия будет работать и даже сторонние jar вы сможете запускать).
Автономная кроссплатформенная монолитная программа на Java
Читать полностью »

Привет читатель.

Что-то про вступление

Раз уж я все таки уволился с работы и есть свободное время, расскажу немного про сборку скриптов, а так же про свое кустарное решение годичной давности — redjs builder. Статья, наверное, заинтересует js-разработчиков, которые ведут крупные проекты, которые не удобно вести в одном файле.

О чем речь?

Если вы js разработчик и вы в своей жизни писали что-то большее чем плагин слайдера на jquery, то вам наверняка приходила в голову мысль: «а вот как бы было удобно если бы 1-н файл разделить на несколько». И у меня такая идея возникала не однократно, ещё когда активно занимался написанием своей js библиотеки. И тут в свое время я набил себе бока…
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js