Одна из особенностей языка Go, которая мне очень нравится – стандартизация практические всего и вся с предоставлением инструментов для валидации и максимальной автоматизации применения. Так все программы на Go выглядят более-менее одинаково как за счет единого стандарта к разработке (да,я не люблю кучу соплей с проверкой результатов возврата, но тем не менее это единообразие) так и за счет единого форматирования. Благодаря этому не приходится испытывать какого-то серьезного дискомфорта разбирая новый кусок кода – каким бы (не)качественным он ни был, выглядеть и как следствие восприниматься он будет как родной. Кроме того, основная масса редакторов Go поддерживает переформатирование текста при сохранении, так как за формат отвечает косольное приложение, то появляется возможность поставить триггеры в VCS и отклонять не удовлетворяющие условиям коммиты. С одной стороны, все это может казаться мелочами. Но только до тех пор, пока ты не работаешь в довольно сильно распределенной команде с крайне разными уровнями у разработчиков.
Continue reading
Post Category → Tooling
Мелкие пакости: время жизни переменной в Rust
Допустим, хочется получить текстовое представление типа переменной в Rust. При этом в язык входит такая замечательная функция как
fn type_of<'a, T>(_: T) -> &'a str {
unsafe { std::intrinsics::type_name::<T>() }
}
unsafe { std::intrinsics::type_name::<T>() }
}
Но тут возникнет довольно занятная проблема, так как переменная становится недоступной после (с некоторыми ньюансами в зависимости от типа) получения её имени:
error: use of moved value: `*variable_name` [E0382]
После небольшой фрустрации понимаешь, что в принципе это ж фича и компилятор не должен догадываться о моих намерениях только лишь получить тип, а не реально использовать значение. Но делать что-то нужно. Единственным подходящим решением оказывается передача по ссылке (ссылке в понимании Rust, а не C++), что ожидаемо, но немного странно для C++ разработчика.
fn type_of<'a, T>(_: &T) -> &'a str {
unsafe { std::intrinsics::type_name::<T>() }
}
unsafe { std::intrinsics::type_name::<T>() }
}
Вообще, все эти мелкие пакости модели памяти постоянно преследуют при программировании на Rust. Никак не могу понять, это реально зло или я просто еще не привык и просто мыслю моделью памяти C++?
Генератор CMakeLists.txt файлов
Довольно часто возникает необходимость быстренько написать тестовое приложение на C++ и опробовать в нем что-то. IDE я не слишком люблю, а каждый раз где-то выискивать завалявшийся шаблон к CMake-у довольно лениво. После очередных поисков запилил небольшой вспомогательный скриптик (само собой на Python) для генерации CMakeLists.txt.
На данный момент поддерживается только генерация приложений, как надоест конвертировать приложения в библиотеки, так будут и они генериться
Сам скриптик с руководством по использованию тут: https://github.com/astavonin/gen-cmake
C++XX в CMake
Вообще я очень люблю использовать CMake для создания различных небольших тестов. Собирается везде, ручной работы ощутимо меньше, чем если писать правила для Make, генерируется поддержка для любой IDE (если тестик в что-то более крупное перерастет и т.д). И как-то меня угораздило “проспать” как CMake 3.x так и довольно полезную фифу в нем – простое и понятное подключение поддержки C++11. Я всегда подключал C++11 по старинке:
list( APPEND CMAKE_CXX_FLAGS "-std=c++11")
Но, оказывается-то, прогресс шагнул далеко вперед! так что для тех кого так же как и меня “заморозили” сообщаю – все стало проще и понятнее:
cmake_minimum_required(VERSION 3.1 FATAL_ERROR) # (1)
project(cpp11_test)
add_executable(cpp11_test main.cpp)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11) # (2)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD_REQUIRED ON) # (3)
project(cpp11_test)
add_executable(cpp11_test main.cpp)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11) # (2)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD_REQUIRED ON) # (3)
Прекрасная фича доступна начиная с CMake 3.1
Релиз Rust 1.0. Возможности и сомнения
Разработчики Rust прошли долгий путь и 15 мая ожидается выпуск первой версии языка с вечеринкой по случаю новорожденного. Лично я долго ждал этого события, хотя и вызывает оно довольно смешанные чувства. Вроде что-то и родилось, но хочу ли я это что-то использовать и стоит ли оно того? Вот в чем вопрос. Дело в том, что в процессе развития Rust претерпел довольно сильные изменения и теперь это далеко не тот же язык, о котором я писал в 2013.
Continue reading
Браузер в песочнице
По не совсем понятным мне причинам, ряд критичных к наличию уязвимость приложений, например широко распространенный браузер Firefix, игнорируют использование встроенной в OS X песочницы. Казалось бы, много какие приложения могут игнорировать песочницу, но никак не те, которые скачивают и так или иначе исполняют произвольный контент из интернета. Возмущаться, конечно, можно долго, а можно просто взять и запустить этот самый Firefox в песочнице. Безопасно, интересно и познавательно
Для начала, какой тип песочницы лучше всего подойдет для интернет-браузера? Я решил остановиться на варианте с белым списком, т.е. приложению запрещено все кроме того, что разрешено. Дальне возникает вопрос как получить список разрешенных действий и тут есть варианты:
- Запустить генератор профайла и выкинуть все лишнее;
- Запускать приложение и отслеживать все, что выводится в консоль с тегом
sandbox .
Swift – это изумительно!
Давно ничего не писал по программированию, т.к. у меня возрадилось старое хобби – фотография. Но про такое я просто не могу молчать! Язык Swift просто покорил меня с первого взгляда! Я долго откладывал знакомство с ним, воспринимая язык как улучшенную версию Objective-C в чем был сильно не прав. Первые впечатления которые оставляет язык – это как Python, только лучше и со статической типизацией. Основная крайне досадная проблема связанная с языком – поддержка исключительно OSX. Хотя, насколько я помню, было обещание Apple выпустить язык под какой-то свободной лицензией, что меня сильно обнадеживает.
На данный же момент мы получили просто мечту OSX/iOS разработчика.
Continue reading
Приближение выхода Rust 1.0
Судя по записи в официальном блоге Rust, ожидать выхода Rust 1.0 осталось всего ничего:
We plan to ship the 1.0 beta around the end of the year.
Что на мой взгляд просто отличная новость! А дальше еще интереснее:
After 1.0 is released, future 1.x releases will be backwards compatible
Что недвусмысленно намекает на то, что разработчики языка Rust куда более вменяемые по сравнению с разработчиками D. Как следствие, возлагаемые на язык надежды в плане использования в промышленной среде становятся все более и более оправданными.
А вот заключительное утверждение:
In many ways, Rust 1.0 is not so much an endpoint as it is a starting point.
Напоминает мне шутку о том, что C++ разработчики скоро разделятся на две группы: те кто успел выучить язык до выхода C++17 и те кто уже не выучит %)
На что бы заменить Python?
На прошлой неделе интегрировал наши замечательные автотесты не только нам, но и команде тестирования и задумался. А правильно ли я изначально сделал выбрав Python в качестве языка для реализации системы? Мне видится ряд плюсов и минусов, ну и некоторые дополнительные мысли созрели.
Плюсы
В качестве главного плюса этого выбора выступает простота самого языка и, как следствие, требованию к уровню разработчика необходимого для вхождения в проект очень низкие.
Динамическая природа языка способствует экспериментам в REPL и облегчает поиск оптимального решения.
Язык очень емкий, что сильно сокращает объем код и позволяет в пару строк написать очень не тривиальные для многих других языков вещи.
Огромное количество библиотек на все случаи жизни позволяет сосредоточиться на задаче, а не инструменте.
Ряд отличных IDE, например PyCharm, сильно облегчают разработку. Continue reading
Миграция с Vim на Emacs
Долгие годы я активно использовал пользовался Vim. Честного говоря, до сих пор считаю, что если говорить именно о редактировании текста, то ничего лучшего Vim на данный момент нет. Но вот если встает необходимость в чем-то большем чем в простом редактирование текста, то Vim оказывается не в лучшей ситуации из за своей однопоточной натуры. Об эту особенность разбиваются и продвинутые автокомплиты и работа со внешними приложениями и многое другое.
Так что, я решил в дальнейшем использовать Vim исключительно для правки небольших текстов и конфигов, благо в любой *NIX системе он есть “из коробки”, а для чего-то большего использовать Emacs. Помня о том, что в стародавние времена мне очень сильно помогла книга Hacking Vim, я начали искать что-либо не менее полезное про Emacs.
К сожалению, на практике быстро выяснилось, что чего-то на столько же выдающегося про Emacs никто не написал. Тем не менее, достойная книга есть, это – Learning GNU Emacs, 3rd Edition. Ее нельзя назвать на столько же интересной и полезной, т.к. в ней маловато информации обо всяческих трюках но в любом случае очень достойно. В итоге довольно быстро дочитал до раздела про ELISP, и бросил, т.к. вроде все понятно и удобно стало. Как захочу улучшить конфиг собственными функциями – дочитаю
Если захотите научиться пользоваться Vim либо Emacs, очень-очень рекомендую эти книги. Не так страшен черт, как его малюют, а удобств ну просто море