Спасибо за перевод. Отличный продукт, отличная статья. Действительно, более понятно и логично, нежели scikit-learn. Было очень интересно читать. Установил TF, буду изучать.
Пользуюсь и Vim и Pycharm. Несколько лет пользовался только Vim, и для правки конфигов и для написания кода. Vimrc оброс плагинами, был и eclim и прочее. Так продолжалось 3-4 года. Я был истинным апологетом вима, всем рекомендовал вим, восхвалял его, вступал в дискуссии. Потом я попробовал PyCharm, где я сразу же установил IdeaVim, с тех пор не мыслю промышленное программирование без него. Vim — отличный редактор, прекрасный редактор текста: режимы, навигация, hjkl — очень удобно. Но PyCharm дает больше за меньшее усилие. Умный автокомплит, интеграцию с фреймворками (django, flask), встроенные утилиты и помощники — генерация UML, интерфейсы для модульного тестирования, множество удобных инструментов для систем контроля версий и хабов репозиториев, количество полезных плагинов доступны и легко устанавливаются, рефакторинг гораздо умнее всего, что я пробовал под python для vim (rope, eclim), проект выглядит как одно целое — а не просто директория с файлами, профилирование, полноценный дебаг, удаленный интерпретатор и, как следствие, удаленный дебаг (например внутри vagrant), тут и инструменты для деплоя, докер. Ну и, конечно же, какое редактирование кода без удобного редактора? Пожалуйста — IdeaVim, который ставит окончательную точку с выбором среды разработки. Vim — это для быстрой правки файлов, конфигов, особенно удаленно. Vim — хороший продукт, но, имхо к программированию его стали адаптировать, потому что не было достойных IDE, и людям хотелось vim-like workflow. Сейчас это не так, сейчас вим никогда не догонит профессиональную IDE, если такая IDE конечно есть (а есть она не для всех ЯП).
В конфиге не хватает эмуляции колесика (не плохо для прокрутки), а также режима выделения. Пойду посмотрю man по xdotool, реально ли такое. А так, я тоже использую i3, возможность оценил.
Я не использую aioredis, я использую deferToGreenlet где у меня вызывается простой блокирующий код библиотеки redis (внутри которой select, os, socket, threading… ), вызовы которого перехватываются gevent. Так что не знаю, в чем разница именно aioredis (как асинхронной реализации redis) и redis. Gevent довольно реактивен (внутри libevent), в своих тестах разницы производительности не замечаю. В любом случае есть опасность заблокировать процесс при использовании целиком синхронного редиса в асинхронном приложении (без greenlets а именно на coroutine), при условии если redis вдруг затормозит, затупит, зависнет или случится какая-то беда внутри сети.
Мое мнение по этому вопросу. Проблемы с потоками начинаются когда их становится слишком много, или когда забивается очередь пулла, а нам жизненно необходимо быстро обратиться к ресурсу. Тут и получается выигрыш от асинхронности, так как на поддержание и создание соединения не нужно выделять ресурсы на создание потока или же ожидать высвобождения потока из очереди. А так как синхронный код работает только в потоке, то общая производительность системы падает, падает rps. Если соединений не много, то потоки будут выгоднее асинхронности зачастую (особенно если используется пулл), но при возрастании нагрузки отдельно работающий быстрее код будет заторможен внешними зависимостями — переключением контекста, блокировками и другими особенностями многопоточных приложений.
И тут врывается такой начальник с криками: «Почему так долго? Сроки горят, клиенты уходят, конкуренты уже 100500 фич запилили, а вы тут чем занимаетесь, дармоеды?»
Не всегда asyncio подходит. Не всегда подходит python 3. Плюс ко всему asyncio позволяет работать только с сетевым IO и с модулем subprocess. Как насчет файлового IO? Как быть с библиотеками, которые реализуют множество интерфейсов и протоколов, все переписывать на asyncio? Asyncio — это светлое будущее, но в суровом настоящем это, в основном, боль, в условиях, когда приходится работать над бизнес-проектами.
Мы храним все конфиги в системе управления конфигурацией (у нас ansible). Конфигурация (куча yaml файлов и jinja шаблонов) версионируется гитом, настроены разные хосты, роли, плейбуки, разная конфигурация для vagrant, production, test-server, local-development, remote-development и так далее. Нам нравится.
Чем это лучше Google Protocol Buffers, который, к тому же, еще и «language-neutral, platform-neutral extensible mechanism for serializing structured data.»?
Я не поклонник Windows и сам пользуюсь Linux. Но все же, вы уверены, что альтернативные инсталляторы создаются именно эмуляцией действий пользователя? Все, какие видел сам, отслеживают действия инсталлятора: какие файлы и куда копирует, какие записи в реестре делает. Затем все эти файлы собираются в архив и приаттачивается скрипт, исполняющий сохраненные операции. Вот и готов автоматический инсталлятор.
Подобные костыли спасают многих администраторов. И если сделают, наконец-то, пакетный менеджер для Windows, 21й век для данной ОС, все же, наступит. Интересно вот, будет ли это только автоматическая инсталляция, или же полноценный менеджер с контролем зависимостей и состояний библиотек в системе.
А зачем убивать оригинал? Пусть живет. Пусть живут все клоны, хорошие и разные, и пусть умирают. Главное чтобы синхронизировались почаще в общее хранилище памяти.
Понимайте «пол часа» в переносном смысле. Другими словами: оптимально быстро. Понятно, что функциональность такой системы будет ограничена, и все же, это лучше чем ничего.
У меня нет умного дома, я снимаю квартиру и часто переезжаю. Но про умный дом всякий раз задумываюсь. Есть ли реализации переносимых умных домов? Который можно за пол часа собрать в коробку, увезти в новую квартиру и за пол часа развернуть систему? Такой умный дом я бы хотел использовать.
Не совсем согласен с балансовой характеристикой, предложенной в статье. Базовые функции IDE в VIM'e поддерживаются, для новых ЯП появляются практически одновременно с выходом ЯП и создаются, как правило, разработчиками ЯП и первыми программистами, благо написать пару скриптов для VIM не такая уж трудная задача. Остальные же инструменты не так уж и важны, хоть и облегчают немного жизнь, но на мой взгляд, львиную долю времени отнимает как раз редактирование текста — кода, и, как следствие, хороший редактор текста играет ключевую роль, а уж великолепное знание ЯП — вообще залог успеха. Ставить в один ряд владение ЯП и владение IDE, на мой взгляд, не правильно.
He's dead, Jim
Подобные костыли спасают многих администраторов. И если сделают, наконец-то, пакетный менеджер для Windows, 21й век для данной ОС, все же, наступит. Интересно вот, будет ли это только автоматическая инсталляция, или же полноценный менеджер с контролем зависимостей и состояний библиотек в системе.