{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "Dmitry Podgorniy, posts tagged: проект выходного дня",
    "home_page_url": "https:\/\/blog.dmitrypodgorniy.com\/tags\/proekt-vyhodnogo-dnya\/",
    "feed_url": "https:\/\/blog.dmitrypodgorniy.com\/tags\/proekt-vyhodnogo-dnya\/json\/",
    "icon": "https:\/\/blog.dmitrypodgorniy.com\/user\/userpic@2x.png",
    "author": {
        "name": "Дмитрий Подгорный",
        "url": "https:\/\/blog.dmitrypodgorniy.com\/",
        "avatar": "https:\/\/blog.dmitrypodgorniy.com\/user\/userpic@2x.png"
    },
    "items": [
        {
            "id": "139",
            "url": "https:\/\/blog.dmitrypodgorniy.com\/all\/pravilny-alfred-workflow-dlya-perevoda-ru-en-i-en-ru\/",
            "title": "Правильный alfred workflow для перевода ru-en и en-ru",
            "content_html": "<p>Результат: <a href=\"https:\/\/github.com\/podgorniy\/alfred-translate\">https:\/\/github.com\/podgorniy\/alfred-translate<\/a><\/p>\n<p>Заметил, что пользуюсь переводом, чтобы придумать корректное название переменной, или понять английское слово. Процесс выглядит так: открываю браузер, открываю страницу перевода, вбиваю текст, выделяю перевод, копирую, вставляю. Многовато телодвижений, несмотря на то, что все действия отлажены. К тому же гугловый переводчик, которым периодически пользуюсь, не умеет автоматически понимать язык с которого переводить, а это означает еще несколько движений, чтобы настроить направление перевода (чтобы в следующий раз снова менять настройки). Яндекс перевод в этом плане умнее.<\/p>\n<p>При попытке упростить этот процесс, нашлись только варианты workflow, в которых авторы предлагают вводить направление перевода вручную. Получается многословно, да и неудобно, например как <a href=\"https:\/\/github.com\/thomashempel\/AlfredGoogleTranslateWorkflow\">этом случае<\/a>. В идеале workflow должен сам понимать с какого языка переводить. С немецким, французским, английским этого достичь не так просто, а вот для пары русский-английский – пара пустяков.<\/p>\n<p>Идеальный вид:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/blog.dmitrypodgorniy.com\/pictures\/alfred-translate-in-action.png.png\" width=\"638\" height=\"319\" alt=\"\" \/>\n<\/div>\n<p>В качестве сервиса перевода используется <a href=\"http:\/\/api.yandex.ru\/dictionary\/doc\/dg\/reference\/lookup.xml\">API Яндекс словарей<\/a>. Альфред писать расширения на ряде языков, где ноды, к сожалению нет. Наверняка ноду можно к нему прикрутить, но это бы усложнило жизнь потенциальным пользователям расширения (не я один могу страдать от реализаций существующих workflow). Среди языков – bash, applescript, php, python, perl, ruby. Выбор пал на python, заодно подучил его.<\/p>\n<p>Из интересных решений – API словаря требует явно указать направление перевода (en-ru, ru-en), поэтому нужно отличать на уровне workflow язык ввода: латинские буквы – значит en, иначе – ru.<\/p>\n<p><b>UPD<\/b><br \/>\nЗабыл описать как им пользоваться. Можно переводить текст из самого окошка альфреда, ключевое слово – “t”. После “t” пишешь слово, что нужно перевести, и получаешь список вариантов. Плюс можно используя глобальный шоткат ctrl+shift+t перевести любое выделенное слово (без необходимости копировать). При выборе одного из вариантов перевода по enter, текст перевода копируется в буфер обмена.<\/p>\n",
            "date_published": "2014-01-09T08:06:31+02:00",
            "date_modified": "2014-01-09T18:42:50+02:00",
            "image": "https:\/\/blog.dmitrypodgorniy.com\/pictures\/alfred-translate-in-action.png.png",
            "_date_published_rfc2822": "Thu, 09 Jan 2014 08:06:31 +0200",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/blog.dmitrypodgorniy.com\/all\/pravilny-alfred-workflow-dlya-perevoda-ru-en-i-en-ru\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/blog.dmitrypodgorniy.com\/pictures\/alfred-translate-in-action.png.png"
                ]
            }
        },
        {
            "id": "132",
            "url": "https:\/\/blog.dmitrypodgorniy.com\/all\/igra-zhizn-na-javascript\/",
            "title": "Игра жизнь на javascript",
            "content_html": "<p>Модель, показывающая возможность появления стабильных структур при простых начальных правилах в условиях замкнутой среды. <a href=\"http:\/\/en.wikipedia.org\/wiki\/Conway's_Game_of_Life\">Вики в помощь<\/a>.<\/p>\n<p><a href=\"\/projects\/conways-game-of-life\/run.html\">Результат<\/a>.<\/p>\n<p>Игра состоит в том, что вселенная – поле из клеточек, имеет заполненные (живые) и пустые клетки (мертвые). Каждую итерацию клетка может “ожить”, “умереть”, или “продолжить жить” в зависимости от состояния ближних клеток (восемь штук в разных направлениях)<\/p>\n<ul>\n<li>Eсли рядом с метвой есть 3 живых, то клетка “оживает”.<\/li>\n<li>Eсли рядом с живой есть 2-3 живых, клетка продолжает жить.<\/li>\n<li>Eсли рядом с живой 1 или больше 3 живых, клетка “умирает”.<\/li>\n<\/ul>\n<p>При таких простых условиях появляются стабильные структуры (пульсары), структуры, двигающиеся по вселенно, структуры порождающие другие структуры. Чем не модель зарождения жизни.<\/p>\n<p>Вселенная может быть замкнутой поверхностью, когда правый край – продолжение левого, а верх – продолжение низа. Такой подход используется в реализации. Для хранения вселенной используется одномерный массив в ущерб простоте доступа к соседним элементам клетки. В будущем планируется переход на  <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Typed_arrays\">типизированный массив<\/a> для скоростных оптимизаций. Поэтому проще в первой реализации описать формулы доступа к соседним клеткам через индекс клетки и ширину и высоту вселенной.<\/p>\n<p>Формулы доступа к соседним клеткам писались вручную для каждого соседа, с учетом “сворачивания” вселенной. Код неоптимизирован. Например, если рядом с живой клеткой уже есть 4 живых, она в любом случае умрет, и не имеет смысла продолжать искать живых соседей у нее. Но скорее всего его оптимизация принесет больше проблем с усложнением кода, чем решит вопросов производительности.<\/p>\n<p>По хорошему, формулы вычисления индекса соседних клеток надо было бы прогнать через юниттесты. Но лень сделала свое дело. К тому же опыт работы с канвасом показывает, что частые действия лучше не выносить в методы. Для отладки использовался консоль лог индекса элемента и индекс его верхнего левого соседа, например, а корректность проверяется по начерченной таблице на листике.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/blog.dmitrypodgorniy.com\/pictures\/conway-tests.jpg\" width=\"640\" height=\"480\" alt=\"\" \/>\n<\/div>\n<p>Второй этап проверки – запустить <a href=\"http:\/\/en.wikipedia.org\/wiki\/File:Game_of_life_animated_glider.gif\">шагающую структурку<\/a>, и убедиться, что она не ломается.<\/p>\n<p>Производительность первого вариант желает лучшего как в плане математики, так и в плане FPS (более менее смотрится поле 320 x 240, увеличение ведет у проседанию FPS – ов на моем ноуте).<\/p>\n<p>Интересно выглядит лесенка javascript heap в вебинспекторе<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/blog.dmitrypodgorniy.com\/pictures\/conways-js-heap.png\" width=\"1125\" height=\"64\" alt=\"\" \/>\n<\/div>\n<p>Все из-за того, что на каждую итерацию создается новый массив. Возможно копирование массива можно будет избежать, используя несколько <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/ArrayBufferView\">arrayBufferView<\/a> для типизированного массива..<\/p>\n<p>Список возможных оптимизаций. Хороший повод потрогать новые технологии, кстати.<\/p>\n<ul>\n<li>Вынести математику в webworker. Иметь запас вычисленных состояний поля на несколько итераций вперед<\/li>\n<li>Использовать типизированный массив.<\/li>\n<li><a href=\"http:\/\/asmjs.org\">asm.js<\/a>. Для меня было странным не найти компилятора из js в asm.js. Поищу еще, но я был уверен, что такой существует.<\/li>\n<li>Не перерисовывать те области канваса, которые не требуют перерисовки.<\/li>\n<\/ul>\n<p>Этого эксперимента не было, если бы ему не предшествовали <a href=\"\/blog\/pro-zarozhdenie-zhizni-na-zemle\/\">размышления о жизни<\/a>.<\/p>\n",
            "date_published": "2013-12-19T15:53:41+02:00",
            "date_modified": "2013-12-15T19:39:49+02:00",
            "image": "https:\/\/blog.dmitrypodgorniy.com\/pictures\/conway-tests.jpg",
            "_date_published_rfc2822": "Thu, 19 Dec 2013 15:53:41 +0200",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/blog.dmitrypodgorniy.com\/all\/igra-zhizn-na-javascript\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/blog.dmitrypodgorniy.com\/pictures\/conway-tests.jpg",
                    "https:\/\/blog.dmitrypodgorniy.com\/pictures\/conways-js-heap.png"
                ]
            }
        }
    ],
    "_e2_version": 3254,
    "_e2_ua_string": "E2 (v3254; Aegea)"
}