Обработка исключений в Clojure

Одной из основных претензий к Java у меня всегда была её “многословность”. Особенно эта многословность раздражает в обработке исключений, где сравнительно небольшой участок кода часто обильно сдабривался “соплями” обработки исключений. Разнообразные среды типа IDEA эту многословность позволяли в той или иной степени сгладить в процессе написания кода, но, к сожалению, она никуда не девалась из кода уже написанного и мозолила глаза. Как эту радость прятали в Scala я уже не помню, т.к. язык мне показался мало пригодным для моих нужд, а вот варианты доступные в Clojure мне очень даже понравились.
Исключения в Clojure, по логике работы с ними, можно разделить на две группы. Первая группа – это исключения возбуждаемые Java-библиотеками. Для примера возьмем функцию выполняющую запрос HEAD:

(defn test-fn [url]
  (client/head url)
  )

Continue reading

Конфигурации

Со всех сторон нас окружают файлы конфигураций. Иногда, это просто некий набор значений по умолчанию, который читается на старте и пишется при изменениях. Такой тип конфигураций обычно оказывается в более-менее приемлемом и читабельном виде вне зависимости от его формата. Но периодически приходится сталкиваться с довольно странной формой извращения – “программирование на конфигурациях”. Обычно для этих целей берется совершенно не пригодный инструмент, например XML файл или, что еще хуже, база данных и придумывается загадочный псевдоязык для скрещивания логически не совместимых вещей.
Continue reading

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)

Прекрасная фича доступна начиная с CMake 3.1 1 и включается она 2 очень просто. Если какие-то обходные пути при отсутствии у компилятора поддержки C++11 не планируются, то стоит объявить 3 наличие поддержки C++11 обязательной.

Браузер в песочнице

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

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

  • Запустить генератор профайла и выкинуть все лишнее;
  • Запускать приложение и отслеживать все, что выводится в консоль с тегом sandbox.

Continue reading

Swift – это изумительно!

Давно ничего не писал по программированию, т.к. у меня возрадилось старое хобби – фотография. Но про такое я просто не могу молчать! Язык Swift просто покорил меня с первого взгляда! Я долго откладывал знакомство с ним, воспринимая язык как улучшенную версию Objective-C в чем был сильно не прав. Первые впечатления которые оставляет язык – это как Python, только лучше и со статической типизацией. Основная крайне досадная проблема связанная с языком – поддержка исключительно OSX. Хотя, насколько я помню, было обещание Apple выпустить язык под какой-то свободной лицензией, что меня сильно обнадеживает.

На данный же момент мы получили просто мечту OSX/iOS разработчика.
Continue reading

TeamLead С++ OSX wanted!

Не думал что когда-то напишу такое, но… я ищу себе замену! По деньгам не обидят, официально вилка звучит как 140-180. Функцоинал двоякий, есть интересное, есть болото, но это как и в любой другой работе. Писать можно мне на e-mail. Если не интересно самим, поделитесь с теми, кому может быть интересно. Заранее спасибо!

C++ TeamLead, описание вакансии

Основные функции и задачи:

  • Создание программных решений в составе команды разработчиков;
  • Анализ требований и постановка задач членам команды;
  • Разработка оптимальных решений, оценка трудоемкости задач;
  • Участие в подготовке проектной и технической документацию по порученным задачам.

Позиция предполагает работы по:

  • портированию существующих Windows-компонент на Mac (включая и последующую отладку портированного кода);
  • реализации Mac-специфических компонент и сервисов (включая драйвера);
  • интеграции компонент в общий продукт.

Требования к кандидату:

Обязательно:

  • Инициативность и умение внятно, корректно обосновать логичность и правильность выбранного решения;
  • Опыт в управлении командами до 10 человек;
  • Опыт в создании WBS, распределении задач по членам команды и контроле за их выполнением;
  • Отличное знание C и C++;
  • Отличное знание библиотек STL и BOOST;
  • Знание платформы Mac OS X ИЛИ обширный опыт разработки под *NIX системы (FreeBSD, Linux, etc.) и желание перейти в разработку под Mac OS X;
  • Знание инструментальных средств разработки под *NIX, таких как GDB, Make, CMake;
  • Знание Sh, стандартных консольных *NIX приложений и какого-либо скриптового языка (предпочтительно Python);
  • Опыт работы с логами и крэш-дампами;
  • Опыт разработки мультиплатформенных систем (Windows, UNIX).

Желательно:

  • Понимание принципов и опыт разработки многоуровневых клиент-серверных приложений;
  • Знание и опыт использования межпроцессных взаимодействий;
  • Понимание принципов основных сетевых протоколов (как минимум TCP/IP);
  • Опыт портирования приложений с Win32 и UNIX.

На что бы заменить Python?

На прошлой неделе интегрировал наши замечательные автотесты не только нам, но и команде тестирования и задумался. А правильно ли я изначально сделал выбрав Python в качестве языка для реализации системы? Мне видится ряд плюсов и минусов, ну и некоторые дополнительные мысли созрели.

Плюсы

В качестве главного плюса этого выбора выступает простота самого языка и, как следствие, требованию к уровню разработчика необходимого для вхождения в проект очень низкие.
Динамическая природа языка способствует экспериментам в REPL и облегчает поиск оптимального решения.
Язык очень емкий, что сильно сокращает объем код и позволяет в пару строк написать очень не тривиальные для многих других языков вещи.
Огромное количество библиотек на все случаи жизни позволяет сосредоточиться на задаче, а не инструменте.
Ряд отличных IDE, например PyCharm, сильно облегчают разработку. Continue reading

Ранний доступ к новым книгам о Scala

Я, надо признать, остался не равнодуным к Scala. Мне действительно нравятся возможности, которые дает JVM, а Scala, как ни ругай ее – самый продвинутый язык для этой платформы. Поэтому, новости связанные с этим языком я отслеживаю и почитываю.

Так вот, в O’Reilly открылся ранний доступ к двум новым книгам по Scala. Сам, пока, книг не читал, но выглядят довольно заманчиво, так первая версия Programming Scala мне очень понравилась.
   

 

Как бороться с динамической типизацией?

Я довольно часто писал на Python какие-то вспомогательные вещи, иногда сравнительно крупные, но почти всегда не знание типа объекта с которым работаешь было не критичным. Плюс возможность разрабатывать в IPython сильно облегчала жизнь. И так было до тех пор, пока я не решил плотно использовать Twisted. И оказалось что в IPython не попишешь нормально, а занание типов параметров в функциях обратного вызова и классов из обширного становится необходимостью.

И вот тут то я оказался в неком тупичке. Есть большое количество разнообразных классов со сложными интерфейсами. Перепробованные IDE (Eclipse, PyCharm и даже Emacs) не позволяют воспользоваться автодополнением в незнакомых им классах, что логично. В результате, весь код начинает выглядеть как пример ниже.

def _call_later(self, request):
"""
тут какое-то описание функции
@param request: тут какое-то описание параметра
@type request: Request (1)
"""

Да, безусловно, указывать 1 для каждой из создаваемых функций типы передаваемых параметров это решение, только оно выглядит как откровенный костыль. В итоге, у меня создается ощущение, что я как-то не верно использую этот замечательный язык… Что не так? Как с этим жить? Наиболее подходящим вариантом выглядит то, что все помнят параметры у API наизусть, я же вполне могу писать на C++ с подстановкой параметров исключительно из открытых файлов.

Remote: офис не обязателен

На днях дочитал крайне интересную книгу “Remote: офис не обязателен” от создателей небезызвестной компании 37signals (да, те самые авторы RoR). Меня давно интересует все что связанно с удаленной/частично удаленной работой, т.к. ходить в офис совсем невмоготу становится, так что книга оказалась более чем к месту и ко времени.

До прочтения Remote, мне и самому не раз приходила в голову мысль о том, что полноценно работать в офисе, особенно если это OpenSpace не возможно в принципе, т.к. там постоянно кто-то отвлекает: обсуждает прокачку танка в WoT, рыбалку, политику, да что угодно кроме работы! Хотя чем лучше обсуждение стороннего проекта у тебя под носом? В итоге, если понаблюдать за тем, как тратится время сотрудником в офисе, становится заметно что на выполнение полезной работы расходуется хорошо если 50% рабочего времени. А если сюда еще добавить кучу крайне важных и неимоверно “полезных” совещаний…
Continue reading