Миграция с Vim на Emacs

Долгие годы я активно использовал пользовался Vim. Честного говоря, до сих пор считаю, что если говорить именно о редактировании текста, то ничего лучшего Vim на данный момент нет. Но вот если встает необходимость в чем-то большем чем в простом редактирование текста, то Vim оказывается не в лучшей ситуации из за своей однопоточной натуры. Об эту особенность разбиваются и продвинутые автокомплиты и работа со внешними приложениями и многое другое.

0509_Hacking Vim 7.2covТак что, я решил в дальнейшем использовать Vim исключительно для правки небольших текстов и конфигов, благо в любой *NIX системе он есть “из коробки”, а для чего-то большего использовать Emacs. Помня о том, что в стародавние времена мне очень сильно помогла книга Hacking Vim, я начали искать что-либо не менее полезное про Emacs.

lrgК сожалению, на практике быстро выяснилось, что чего-то на столько же выдающегося про Emacs никто не написал. Тем не менее, достойная книга есть, это – Learning GNU Emacs, 3rd Edition. Ее нельзя назвать на столько же интересной и полезной, т.к. в ней маловато информации обо всяческих трюках но в любом случае очень достойно. В итоге довольно быстро дочитал до раздела про ELISP, и бросил, т.к. вроде все понятно и удобно стало. Как захочу улучшить конфиг собственными функциями – дочитаю

Если захотите научиться пользоваться Vim либо Emacs, очень-очень рекомендую эти книги. Не так страшен черт, как его малюют, а удобств ну просто море

Заметки везде и всегда

Screen Shot 2014-05-26 at 21.31.15  Это удивительно, но Microsof таки сумел выпустить продукт, который не хочется немедленно развидеть! По началу я хотел было написать про два продукта, так как на первый взгляд OneDrive очень не плох. Но это только на первый взгляд, а на практике OneDrive отказался синхронизировать мои файлы, как это не прискорбно, но Майкрософт продолжает штамповать откровенное говно. Continue reading

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

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

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

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

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

Разбитые надежды или просто непонимание?

В одной из лекций с PyCon US 2014 проскочила очень заинтересовавшая меня информация о том, что с Python 3.3 CPython поддерживает оптимизацию для классов, и старый вариант использования Python, когда класс могли просто заменить на Dict не верен в корне, т.к. Dict не поддерживает никакой типизации. Вроде все верно и логично: никак не ограничиваемый по данным ассоциативный массив против класса, в котором можно предсказать используемые типы и количество полей. Continue reading

Rust 0.10

Сегодня вышел, на мой взгляд, интереснейший релиз Rust 0.10. Ломающих изменений в нем не очень много, зато был проведен просто грандиозный рефакторинг: две основные библиотеки libstd и libextra были разделены на полтора десятка библиотек “одной функции” в процессе чего libextra перестала существовать. Это хорошо в первую очередь тем, что появилась реальная возможность начать использовать Rust практически в пределах libstd (все же необходимо еще немного порезать libstd для отключения работы с задачами), а не только самого компилятора, на низком уровне, к примеру в драйверах. Сейчас как раз занимаюсь подобным экспериментом, выглядит ну очень заманчиво!

Ну, все изучать Rust!

Быстро разобраться в новом проекте

Довольно часто возникает необходимость разобрать новый большой проект и не совсем очевидно с какой стороны подступиться к огромной горе исходных кодов которая свалилась на вас. Если вам повезло и проект написан на C++, C, Objective-C, Python, Java, PHP, C#, Фортран или VHDL то простое решение есть – Doxygen + GraphWiz.

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

В качестве примера я решил взять LLVM с размером исходного кода около 12Мб. На построение документации ушло около 2 минут, что, конечно, не мало, но с учетом однократности подобной операции совершенно не критично. Continue reading

WTFPL

Я долгое время был уверен что лучшая лицензия для открытого ПО – это The BSD 3-Clause License. Но сегодня, внезапно, наткнулся на Do What The Fuck You Want To Public License (WTFPL) и как-то даже засомневался. Эта лицензия мне нравится еще больше предыдущей, хотя, конечно, изрядная доля шутки в ней есть

Дизассемблер под OSX

Иногда бывыет нужно что-то по-быстрому дизассемблировать, понять как работает или почему работает не так, как ожидалось. Недавно, в очередной раз вознила такая задача и я стал думать чем же мне воспользоваться. По большому счету, под OSX с дизассемблерами не очень: возможности OTool как дизассемблера (им я раньше и пользовался, но уж больно не удобно что-либо дизассемблировать в командной строке) очень скудные, IDA Pro за $1129 (да, именно Pro, а не Starter, которую я еще согласен оплатить из своего кармана) и очень понравившееся мне приложение с великолепным соотношением цена/качество – Hopper Disassembler.
Безусловно, по возможностям Hopper Disassembler основательно уступает IDA Pro, но, в большинстве случаев вся мощь IDA Pro не очень-то нужна и возможностей Hopper вполне хватает. Так что, будет кому-то нужен недорого дизассемблер под OSX – поглядите в сторону Hopper.