Результат: https://github.com/podgorniy/alfred-translate

Заметил, что пользуюсь переводом, чтобы придумать корректное название переменной, или понять английское слово. Процесс выглядит так: открываю браузер, открываю страницу перевода, вбиваю текст, выделяю перевод, копирую, вставляю. Многовато телодвижений, несмотря на то, что все действия отлажены. К тому же гугловый переводчик, которым периодически пользуюсь, не умеет автоматически понимать язык с которого переводить, а это означает еще несколько движений, чтобы настроить направление перевода (чтобы в следующий раз снова менять настройки). Яндекс перевод в этом плане умнее.

При попытке упростить этот процесс, нашлись только варианты workflow, в которых авторы предлагают вводить направление перевода вручную. Получается многословно, да и неудобно, например как этом случае. В идеале workflow должен сам понимать с какого языка переводить. С немецким, французским, английским этого достичь не так просто, а вот для пары русский-английский – пара пустяков.

Идеальный вид:

В качестве сервиса перевода используется API Яндекс словарей. Альфред писать расширения на ряде языков, где ноды, к сожалению нет. Наверняка ноду можно к нему прикрутить, но это бы усложнило жизнь потенциальным пользователям расширения (не я один могу страдать от реализаций существующих workflow). Среди языков – bash, applescript, php, python, perl, ruby. Выбор пал на python, заодно подучил его.

Из интересных решений – API словаря требует явно указать направление перевода (en-ru, ru-en), поэтому нужно отличать на уровне workflow язык ввода: латинские буквы – значит en, иначе – ru.

UPD
Забыл описать как им пользоваться. Можно переводить текст из самого окошка альфреда, ключевое слово – “t”. После “t” пишешь слово, что нужно перевести, и получаешь список вариантов. Плюс можно используя глобальный шоткат ctrl+shift+t перевести любое выделенное слово (без необходимости копировать). При выборе одного из вариантов перевода по enter, текст перевода копируется в буфер обмена.

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

Результат.

Игра состоит в том, что вселенная – поле из клеточек, имеет заполненные (живые) и пустые клетки (мертвые). Каждую итерацию клетка может “ожить”, “умереть”, или “продолжить жить” в зависимости от состояния ближних клеток (восемь штук в разных направлениях)

• Eсли рядом с метвой есть 3 живых, то клетка “оживает”.
• Eсли рядом с живой есть 2-3 живых, клетка продолжает жить.
• Eсли рядом с живой 1 или больше 3 живых, клетка “умирает”.

При таких простых условиях появляются стабильные структуры (пульсары), структуры, двигающиеся по вселенно, структуры порождающие другие структуры. Чем не модель зарождения жизни.

Вселенная может быть замкнутой поверхностью, когда правый край – продолжение левого, а верх – продолжение низа. Такой подход используется в реализации. Для хранения вселенной используется одномерный массив в ущерб простоте доступа к соседним элементам клетки. В будущем планируется переход на типизированный массив для скоростных оптимизаций. Поэтому проще в первой реализации описать формулы доступа к соседним клеткам через индекс клетки и ширину и высоту вселенной.

Формулы доступа к соседним клеткам писались вручную для каждого соседа, с учетом “сворачивания” вселенной. Код неоптимизирован. Например, если рядом с живой клеткой уже есть 4 живых, она в любом случае умрет, и не имеет смысла продолжать искать живых соседей у нее. Но скорее всего его оптимизация принесет больше проблем с усложнением кода, чем решит вопросов производительности.

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

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

Производительность первого вариант желает лучшего как в плане математики, так и в плане FPS (более менее смотрится поле 320 x 240, увеличение ведет у проседанию FPS – ов на моем ноуте).

Интересно выглядит лесенка javascript heap в вебинспекторе

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

Список возможных оптимизаций. Хороший повод потрогать новые технологии, кстати.

• Вынести математику в webworker. Иметь запас вычисленных состояний поля на несколько итераций вперед
• Использовать типизированный массив.
• asm.js. Для меня было странным не найти компилятора из js в asm.js. Поищу еще, но я был уверен, что такой существует.
• Не перерисовывать те области канваса, которые не требуют перерисовки.

Этого эксперимента не было, если бы ему не предшествовали размышления о жизни.