Однажды я писал один проект. Проект выдался большим и писал я его долго.
Там было все что только можно было запихнуть — и retrolambda/java8, и пара десятков
других библиотек (жадность заказчика до новых фич не знала границ, а потому
росло число зависимостей).

Но речь даже не об этом. Настало время делать релиз. И оказалось что в проекте
множество логов и неплохо бы их из релизной сборки убрать. Всем известный
способ с ProGuard не сработал с первого раза. С каждым новым "-keep"
приложение падало в каком-то новом месте. Так что ProGuard пришлось отключить
до лучших времен.

Все это время меня не покидало ощущуение, что управление уровнем логировния c
помощью изменения байт-кода — это нелепо. И тогда за полчаса я написал свой
примитивный логгер.

Обычно я редко довожу свои проекты до конца, но тут он был настолько прост — что теперь он лежит на гитхабе, желающие — пользуйтесь.

Хабрапривет!

Ниже речь пойдет о view injection, костылестроении, аннотациях, рефлексии, о жалкой попытке превзойти Джейка Уортона и о том, что свой велосипед ближе к телу.

Что же такое view injection? Это способ избежать вот такого рутинного кода:

Button button = (Button) findViewById(R.id.button);
button.setOnClickListener(new View.OnClickListener() {
  public void onClick(View v) {
    // ...
  }
});

Если использовать view injection с помощью, скажем, ButterKnife, написанного Джейком Уортоном (Jake Wharton), то код становится прозрачнее:

@InjectView(R.id.button) Button mButton;

@OnClick(R.id.button)
public void onButtonClick() {
  // ...
}

Но при ближайшем рассмотрении оказывается, что и ButterKnife не идеален.

Возможно вы сочтете это глупостью, но я не люблю IDE. Обычно всю работу проделываю в vim+tmux+терминал. Я признаю все преимущества IDE, просто мне удобнее в хорошем текстовом редакторе. Но речь не об этом.

Когда я пишу что-нибудь под андроид — я часто правлю XML (разметку, стили, строки, ...). Так вот в текстовом редакторе это делать не очень удобно. И я решил потратить пару часов и написать генератор XML на основе упрощенного языка разметки (типа lesscss или stylus для CSS). Все-таки NIH — очень уж соблазнительный стимул.

У меня — 'cd'.

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

Но должны же быть решения!

В моей любимой оболочке zsh есть такая возможность — «разворачивание» путей по нажатию : например, "/u/in/sy" -> "/usr/include/sys/"

В остальных оболочках можно приноровиться и использовать $CDPATH или pushd/popd, но лично мне это до сих пор кажется неудобным.

А еще есть пара утилиток для ускоренной навигации. Самая известная из них, пожалуй, autojump. Она следит в каких папках пользователь проводит больше всего времени и позволяет указывать только фрагмент пути к папке. Например "incl" приведет вас в "/usr/include", если вы там часто бываете.

Autojump вдохновила другого разработчика на создание утилиты "z". "Z" использует в качестве критерия для перехода т.н. "frecency" - комбинацию частоты посещений папки (frequency) и времени последнего перехода туда (recency).

Обе утилиты хороши по-своему, и я так бы и пользовался autojump или z, однако что-то мне не давало покоя. А недавно я услышал одну фразу:

If the product is used as a tool, its interface should be as unintelligent as
possible. Stupid is predictable; predictable is learnable; learnable is usable.

И тут я понял что самое время придумать свой велосипед. Не-intelligent. Тупой и удобный.

Я считаю, что каждый программист должен написать свой компилятор.

Я сам долгое время считал, что создание компиляторов — это удел элиты, а простому смертному программисту не постичь этой науки. Попробую доказать, что это не так.

В посте мы рассмотрим, как можно написать свой компилятор C-подобного языка меньше чем за час, исписав всего 300 строчек кода. В качестве бонуса, сюда входит и код виртуальной машины, в байткод которой будет компилироваться исходник.

В прошлой статье мы рассматривали простейший Forth CPU J1. Теперь самое время рассказать что за язык этот Форт, и как его хорошо компилировать для этого процессора.

На Хабре было мало постов про Форт, и впечатленный недавней великолепной работой Мура, расскажу о другом форт-процессоре — J1.
Это, наверное, самый минималистичный процессор, которому можно найти практическое применение.
Его можно сделать самому на FPGA, но я, как человек далекий от электроники, попробую написать его эмулятор. И, чтобы добавить ненормальности посту, писать эмулятор буду на языке Go.

Язык Go отпразновал недавно первый год своей жизни. Интерпретатору CHIP-8 стукнуло уже под сорок.
Любителям новых языков и старого железа посвящается этот пост — в нем мы будем писать эмулятор виртуальной машины CHIP-8 на языке Go.

О том, как настроить окружение для работы с Go писали уже не раз. За последнее время мало что изменилось, разве что версия для Windows стала более стабильной.
Установив все согласно инструкциям, приступаем к изучению внутренностей CHIP-8.