Доброго времени суток! Это мой первый пост на форуме, так что прошу строго не судить.
Коротко обо мне: студент, увлекаюсь электроникой, микроконтроллерами, и программированием. Однако, моя специальность ни коим образом не связана с It. Со мной покончено, переходим к сути.
Дано:
конвейер CI/CD, реализованный, к примеру, в GitLab. Для корректной работы ему требуются, как это очень часто бывает, некие секреты - API-токены, пары логи/пароль, приватные SSH-ключи - да всё, о чём только можно подумать;
работает этот сборочный конвейер, как это тоже часто бывает, на базе контейнеров. Соответственно, чем меньше по размеру образы - тем лучше, чем меньше в них всякой всячины - тем лучше.
Требуется консольная утилита, которая:
занимает минимум места;
умеет расшифровывать секреты, зашифрованные ansible-vault;
не требует никаких внешних зависимостей;
Писать игровой AI очень интересно и увлекательно - не раз убеждался в этом на личном опыте. Недавно, случайно наткнувшись на код своего старого проекта шахматной программы, решил его немного доработать и выложить на GitHub. А заодно рассказать о том, как он создавался и какие уроки преподал мне в процессе работы.
При программировании на телефоне программ под DOS или под Windows в эмуляторах существует проблема ввода русского текста - клавиатура, которой вы только что набирали русский текст в обычных андроид программах, не будет вводить никакой текст в эмуляторы. Эмуляторы, как правило, принимают на вход только обычные англоязычные коды и код других клавиш английской раскладки. А уже поставленный в DOS русификатор или настроенная языковая панель Windows на лету превратят эти англоязычные коды в русские символы при вводе (если вы предварительно переключитесь на RU язык).
Это моя первая статья, постараюсь быть интересным. Много лет назад (о ужас) когда я был супер энергичен, молод и глаза горели я хотел автоматизировать все что движется и не движется. Я чувствовал бескрайние свои возможности и был уверен в себе на 100% и более, передо мной не было не одной не решаемой задачи и все горело в руках. Однако с годами трэкбар от молодости к мудрости все двигался в сторону второго. Так со временем приходил опыт, который сын ошибок трудных и увы, там же гений парадоксов друг.
Сразу забегая вперед скажу что многие процессы на государственной службе, где работал и работает ваш верный слуга автоматизировал, разрабатывал и пускал в эксплуатацию системы которые существенно (в 4 чаза!) сокращали сложность и время обработки информации в разных государственных ведомствах.
На дворе был 2012 год…
Читать полностью »
“Его пример другим наука”
Это грустная история о неуспехе проекта, который я считал потенциально успешным на все 100 процентов. И почему все кончилось обломом, я до сих пор толком не понимаю.
Читать полностью »
Поставили как-то передо мной задачу написать несколько юнитов на Delphi, обеспечивающих доступ к следующим возможностям Windows:
Говорят, что успех того или иного языка программирования или компилятора во многом зависит от его умения взаимодействовать со сторонним кодом. Конечно, «успех» любительского компилятора нужно понимать с известной долей условности и даже иронии. Однако и здесь интеграция с внешними библиотеками, написанными на С, может стать неплохой школой жизни.
О моём компиляторе XD Pascal уже было несколько постов на Хабре. Компилятор написан предельно просто и целиком вручную, при этом язык имеет весьма нетипичные расширения — методы и интерфейсы, позаимствованные из Go. На сегодняшний день базовый язык реализован полностью, работает самокомпиляция, введены простейшие оптимизации. Тут и возникло естественное желание наладить взаимодействие компилятора с какой-нибудь несложной игровой библиотекой. Выбор пал на Raylib — но никогда бы он на неё не пал, если бы я сразу предвидел её подводные камни. Невинная затея превратилась в борьбу с соглашениями о вызове.
Читать полностью »
В этой статье я расскажу о том, зачем, почему и как я начал делать сайты на паскале: Delphi / FPC.
Вероятно, «сайт на паскале» ассоццируется с чем-то вроде:
writeln('Content-type: text/html');
Но нет, всё гораздо интереснее! Впрочем, исходный код реального сайта (почти весь) доступен на GitHub.
Читать полностью »
Я довольно часто сталкивался с тем, что разработчики на Delphi (можно сказать традиционно) компилируют свои приложения "ручками", что далеко не production-решение, а со стороны выглядит кустарщиной и "делаем на-коленке", хотя продукты бывают весьма серьёзными и продаваемыми. Вероятно, это пошло ещё с тех пор, когда для автоматизации нужно было придумывать свои батнички, которые запускали компилятор командной строки dcc32 с нужными параметрами. Некоторые даже сделали свой "Публикатор" — Delphi-expert, который делает работу сервера сборок: компилирует (правда, открытый в IDE) проект, выставляя ему взятый из какой-то БД инкрементированный номер версии, записывает некий changelog и копирует это куда-то в сетевой каталог.
Я не буду вдаваться в исторический экскурс как было раньше. Я расскажу как есть/можно сейчас, и как это использовать для повышения эффективности своей работы.
Файл проекта современной версии Delphi — это .dproj-файл (здесь и далее я буду ориентироваться на Delphi 10 Rio, но с небольшими отличиями это верно для всех более ранних версий Delphi, начиная с 2007). В нём хранятся все настройки проекта, которые обычно изменяют в IDE (меню Project - Options (Ctrl+Shift+F11)). В рамках данной статьи я сконцентрируюсь на "основных", которые понадобятся для демонстрации общих принципов: это Config — конфигурация, Platform — платформа, OutputDirectory — путь выходного файла и ConditionalDefines (директивы условной компиляции). Остальные настройки, если таковые нужно менять при сборке, я предлагаю выявить самостоятельно. Этот же .dproj-файл, если в него заглянуть обычным текстовым редактором, является ничем иным как скриптом сборки MSBuild (давайте создадим простое консольное приложение и назовём его DelphiAutomatedBuild):