Идея о «тащить личный девайс» весьма спорная. У меня был (и я его использовал) административный ресурс, чтобы ограничивать трафик на рабочем месте. Личное общение это не остановило (у всех есть телефоны), но продуктивность понизило, потому что вместо того, чтобы быстро переписываться на рабочей станции, сотрудники печатали на телефоне, что намного медленнее.
Думаю, надо просто менеджерам делать свою работу лучше. Все-таки мы работаем с людьми, а не машинами. Это очень соблазнительно набросать кучу правил, и ожидать, что все будут им следовать. Но люди сложнее. В общем случае личное общение на рабочем месте не снижает, а иногда даже повышает продуктивность (коллеги устанавливают дружеские отношения, и потом обмениваются опытом; супруги вместо того, чтобы висеть на телефоне в обеденный перерыв, иногда переписываются в рабочее время, и в итоге не растягивают весь перерыв, чтобы выкроить время и т.д.).
Есть, конечно, и обратные случаи, но для этого надо:
Вести контроль качества работы сотрудника (сколько и какого качества пишется код, как закрываются тикеты, насколько коллеги довольны работой этого сотрудника) — вот здесь обычно самая большая проблема, ибо менеджеры либо ленятся либо слишком заняты на ненужных собраниях (это больная тема многих организаций, но к текущему обсуждению не относится);
Вести профилактические беседы, и если наблюдаются проблемы, пытаться их устранить;
В крайнем случае, можно ввести ежедневную отчетность. В целом, это не особо удачная идея, но может дисциплинировать, и можно применять избирательно, а не ко всем подряд.
К сожалению, единого подхода не существует, я много лет пытаюсь формировать культуру написания хорошего кода в разных командах, и зачастую, даже имея все инструменты на руках, упираешься в психологические аспекты. Особенно это заметно в последние годы, когда многие идут в профессию за деньгами, а не из-за любви к собственно программированию.
Из того, что я пробовал, и давало хорошие результаты (но в конце концов, все-равно надо ожидать трений):
Минимальный мануал по стилю, зачастую можно ограничится одной фразой: «Код пишется для людей, а не для машины». Стену текста все-равно никто не читает, а так хотя бы будет минимальный чек-лист, по которому реально проверять код перед коммитом.
Все максимально автоматизировано: коммит вызывает CI цепочку — проверка стиля кода, запуск юнит-тестов, генерация документации, генерация конечного пакета, интеграционные тесты с использованием конечного пакета.
Семинары по обмену опытом, показ используемых инструментов, их настроек и как это облегчает жизнь. Даже такие мелочи, как fish shell, могут сделать процесс разработки приятнее.
Использовать промышленные стандарты, так проще ссылаться — «если все сообщество так работает, то почему бы нам не следовать их стандартам».
Code review, но нужно быть очень осторожным в высказываниях. Желательно подкреплять примерами. Совсем недавно у меня было откровение, что еще не все знают, что singleton — это антипаттерн, который стоит использовать очень осторожно. Мне не верили, пришлось искать статью с подтверждением.
Позвольте мне рассказать, как так получается, что для backend-а используются неподходящие технологии — так уж получилось, что я сам был виновником такого, и теперь из-за моего решения страдают другие разработчики (впрочем, они бы страдали и так и так, и я, наверное, все-таки смягчил ситуацию). Чтобы не быть голословным, я говорю про UTM-устройства FortiGate и про использующийся там Python в backend-е (сисадмины наверное знакомы с этими устройствами, хотя в России они вряд ли сильно распространены).
Все началось, когда другая команда, работающая над FortiController (менеджер этих железок) внедрили там PHP для UI. Им было это сделать очень просто, т.к. они использовали современный Linux, и им просто надо было написать пару расширений для PHP, чтобы он нормально заработал. Наш CTO загорелся идеей скриптования в backend-е и начал это активно продвигать (его понять можно — до этого была возможность только рекомпиляции и обновления прошивки даже для малозначительных изменений). Нас поставили перед фактом — внедряйте PHP в FortiGate, и чтобы это было готово уже вчера (ибо конкуренты не дремлют).
Я был очень сильно против, и после длительных дискуссий с угрозами увольнения мне сказали — предложи что-нибудь работающее и лучше, тогда подумаем. И мне дали всего 2 недели. Для контекста: FortiGate — это весьма кастомный Linux со своим ядром, файловой системой и никакими менеджерами пакетов. По сути, основное ПО на железке — это один исполняемый файл, в котором несколько точек входа (соответственно, ls и rm отличаются только точкой входа в этом файле). Как бы я не хотел внедрить что-нибудь достойное типа того же go-lang, я просто не мог заставить его работать в отведенное мне время. Другое условие — чтобы мы могли найти разработчиков. В итоге мне пришлось выбирать между JS, Python и PHP (я потом часть работы оформил в небольшую статью). К счастью, в то время V8 имел какие-то проблемы с нашим ядром (какие-то ioctl запросы не работали), поэтому несмотря на то, что мой непосредственный начальник хотел выбрать JS, я смог уговорить его использовать Python.
Я, конечно, упускаю много деталей, но выводы я сделал: выбор технологий иногда определяется не самой технологией (ее плюсами и минусами), а ограничениями (например, время внедрения) и кадрами. И к сожалению, кадры на западе — это весьма плачевное зрелище. Рынок наводнен выходцами из Китая и Индии, любовь к профессии заменена на жажду легких денег, клановое мышление заставляет их покрывать друг друга и просто отторгать всех талантливых и самостоятельно думающих разработчиков в сторону. От этого и уровень — найти JS-разработчика намного проще (даже найти нормального Python-разработчика было проблемой).
P. S. Хотел бы отметить, что я как раз недавно плотно работал с сотрудником Facebook-а, который пишет на OCaml — на нем разрабатывается Infer. Полное покрытие тестами у них не всегда есть, иногда они полагаются только на интеграционные тесты. Так что не стоить думать, что у гигантов софтоиндустрии все прекрасно, там тоже есть немало проблем.
По Leak Canary: нам встроенных возможностей было достаточно. Даже с одним активити можно тестировать утечки, просто надо закрывать приложение через кнопку «Назад» (так активируется весь нужный жизненный цикл и приложение на некоторое время «засыпает», что позволяет делать проверку памяти), а не через список приложений (через список идет просто операция kill). Другие варианты:
Сделать отдельное активити для тестирования, и переходить в него по скрытой кнопке (активируется константами в коде или отдельной сборкой). Дополнительное достоинство: можно в это активити выводить другую отладочную информацию.
Использовать RefWatcher напрямую с подозрительными объектами (фрагментами, потоками и другими высокоуровневыми примитивами).
P. S. Сорри за долгий ответ, гугл почему-то решил поместить сообщения с хабра в спам.
Генерация HPROF-файла во время инструментальных тестов и последующий анализ этого файла (Memory Monitor в конечном итоге показывает те же данные). Замечу, что в начале мы использовали Monkey, но потом отказались из-за его недостаточной гибкости и вручную написали все UI-манипуляции с помощью Espresso.
Отмечу еще полезные инструменты, которые мы используем для улучшения качества кода (пусть и не связано с утечками):
StrictMode, контроль производительности приложения.
Checkstyle, некоторые правила помимо улучшения стиля кода, косвенно помогают найти потенциальные проблемы — например, требование везде использовать final помогает более тщательно подходить к использованию переменных, и это в конечном счете влияет на использование памяти.
Здесь достаточно интересная история. Она начинается в 2008 году, когда было объявлено о публикации StyleCop, инструменте, используемом в MS для проверки соответствия их стандартом. Инструмент до сих пор используется — StyleCop Analyzers, и список правил (не особо оформленный правда, причину см. ниже) доступен на сайте: https://stylecop.pdelvo.com/
Но в 2015 году, возможно из-за внутренних пертурбаций, стандарты поменялись — Automatic code formatter released to GitHub. Основное отличие, на которое все жалуются — это использование подчеркивания вместо «this.», как это было рекомендовано StyleCop. Тем не менее, на текущий момент рекомендуется использовать именно эти новые стандарты кодирования. Учтите, что это внутренние стандарты, Microsoft не публиковало каких-либо официальных стандартов для внешнего использования, так что используете эти инструменты на свое усмотрение.
Я в свое время думал написать плагин для LLVM, который бы делал проверку этого закона, но предварительные эксперименты по внедрению такой проверки в стандарты кодирования провалились. Причиной тому была не чистая функциональность используемых языков программирования (в данном случае это были C++ и Python) — из-за того, что объекты можно передавать по ссылке, контролировать операции над ними не представлялось возможным (особенно, если это были библиотечные вызовы). В итоге мы использовали другие критерии, как например, тестируемость кода и ограничение cyclomatic complexity.
Полностью согласен. С другой стороны, в штатах некоторые расходы можно сократить путями, которые виртуально невозможны в России (но надеюсь ситуация исправится) — например, можно превентивно сократить расходы на починку машины, взяв новую в лизинг с полным покрытием (например, Ford делает все ремонты за свой счет без каких-либо дополнительных вычетов).
Насчет ресторанов в Калифорнии (как минимум даунтаун SF) — да, дорогие, что-то я подзабыл, привык к Ванкуверским ценам. Хотя вроде Red Lobster имел вполне нормальные цены, правда он немного на отшибе.
Скорее всего, отсутствует входной этап тестирования (или он слишком простой). На stack overflow можно увидеть кучу вопросов, которые являются полной копией тестовых вопросов для собеседований. Плюс руководство не всегда достаточно гибкое и дальновидное — некоторые считают неэтичным тратить время соискателя на решение тестовых задач, другие считают, что такой подход слишком сильно формализован и может отсеять хороших кандидатов.
Ну а то, что индусов — большинство, это неудивительно, судя по последней статистике, они как минимум сравнялись по численности с другой известной нацией. Сильная клановость (и соответственно стремление пристроить «своих») тоже играет свою роль. И здесь нет никакого расизма, это просто их культурная особенность.
P. S. Аналогичная ситуация в Канаде — программистов много, а толковых сосчитать по пальцам. То же и с тестерами — было не очень приятно слушать, когда соискатели на роль QA сетевого оборудования не знали, как даже примерно работает DNS (хотя в требованиях явно указывалось знание OSI model).
К сожалению, уже не все так (последний год часто бываю в России) — единственное, что дешевле в России, это пожалуй еда (если вы, конечно, согласны на импортозамещенные аналоги) и аренда жилья. Техника — дороже, рестораны — дороже. Мелочевку типа интернета и транспорт не берем в расчет, медицина весьма плачевна вне зависимости, сколько за нее платишь. Про дороги и отсутствие нормальных парковок я вообще молчу.
4000 чистыми в месяц для США после всех расходов — это весьма неплохо. Это значит, что можно спокойно ездить на элитные курорты два раза в год не напрягаясь. 2500 чистыми в России — придется копить, чтобы хоть куда-то в достойное место выбраться (не в последнюю очередь из-за дороговизны местных перелетов, особенно если живете на Дальнем Востоке).
А то, что аренда в SF зашкаливает — это давно известный факт. Стартапы уже начинают уезжать из Кремниевой Долины, вот например: Startups Leaving San Francisco For Portland Oregon. В принципе, это имеет смысл: OR — весьма неплохой штат и по экологии, и по доступности. CA — еще то горячее пекло, только пожалуй в SF еще как-то более или менее комфортно :)
P. S. Это мое исключительное мнение, тем кто любит отдыхать в Турции летая туда чартерами и поесть картошечку с майонезом с небызызвестным 40-градусным напитком, удаленка в России будет, наверное, намного лучше описанного вами образа жизни в SF.
Сорри, попутал с UWP AnalyticsInfo.VersionInfo.DeviceFamilyVersion, в iOS все с этим нормально. Впрочем, других примеров достаточно: [NSLocale currentLocale] Для NSLocale у них вообще достаточно куцая документация (чем например отличается systemLocale от currentLocale? ни у той, ни у другой функции нет описания).
Впрочем, это все неважно, я не увидел, что это перевод статьи.
Вы не отметили еще одну большую проблему для разработчиков — плохая документация. MSDN (как минимум, что касается UWP) тоже не блещет, но документация от Apple — это очередной плевок в сторону разработчиков от компании. Хорошо, что они хотя бы одну старую проблему устранили — поиск, раньше надо было пользоваться либо исключительно индексом или поиском от гугла, сам поиск на сайте разработчиков Apple работал еле-еле.
Очень много функций просто не задокументированы, и опять приходится гуглить, чтобы найти что-то толковое. Простой пример — получение мажорной версии оси. Смотрим operatingSystemVersionString: This string is not appropriate for parsing. Ладно, переходим на ту функцию, которая должна использоваться: operatingSystemVersion: детального описания вообще нет (могли хотя бы упомянуть, что это битовые поля упакованные в целочисленный тип). И так про кучу функций.
То же касается инструментария (lipo для создания Universal Frameworks особо нигде даже не упоминается на сайте разработчиков) и man-pages (некоторые функции просто отсутствуют).
P. S. В галерее позора по юзабилити у меня еще висит Xcode с показом невидимых символов. К счастью, можно редактировать код в любом текстовом редакторе, так что это не является проблемой, заслуживающей упоминания.
Sony Vaio — были очень хорошие ноутбуки, но акцент на слове были, они покинули рынок PC (Sony Quits the PC Business). Плюс они закрыли очень много собственных фирменных магазинов (Sony Phasing Out Its Retail Stores). Так что пока будущее Sony не особо ясно, но будем надеяться на лучшее.
Пользовался разными картами и навигаторами: встроенными в Ford, Toyota и Mercedes, внешними Garmin и TomTom, Android (offline & online) Google maps, iPhone maps & Windows Mobile maps (< — самое худшее из всего). В большинстве случаев онлайн карты в Андроиде — самый лучший вариант (ибо самый лучший поиск), оффлайн сопоставимы с обычными навигаторами, ничего такого. Во многих случаях сначала искал в Андроиде, а потом вбивал в автонавигатор. Единственное, чем хороши встроенные автонавигаторы — показывают пробки и радары, но и то не все.
По оффлайну самый лучший для меня был Garmin, но исключительно в Канаде. Причина очень простая — можно прикупить Backroad maps. Google maps и рядом не стоял по детализации. Собственно, offroad-карты иногда даже лучше в OpenStreetMaps, чем в гуглокартах.
Так что на самом деле, эта тема достаточно интересная, и отрасль еще развивается — гугл хотя и достаточно хорош, но с собственно картографией и детализацией у него не очень хорошо (What happened to Google Maps?), и пока золотой середины еще не наблюдается (но должен честно признаться, что новейшие модели гармина и томтома я еще не пробовал).
Эксперты 80-го уровня просто читают документацию, например: Emulating numeric types (естественно, что знание английского подразумевается, иначе это не эксперт). Книжки в основном и нужны новичками, экспертам они ни к чему.
Правда должен признать, что есть такие темы, когда документация не особо помогает. Когда я переделывал CPython для работы с проприетарной встроенной платформой (прикручивал jmalloc и переделывал многопоточность на использование clone() напрямую), пришлось ковыряться в исходниках. Но это нужно единицам, книги на такие темы просто бы не окупились.
Мои пять центов к дискуссии. Использовал и использую vi(vim) и emacs много лет, но они не являются моими основными текстовыми редакторами:
emacs — если надо редактировать по ssh что-то посложнее чем «Hello world»
vi — если нет выбора, или что-то совсем простенькое, как например, комментарии к коммитам git-а
Почему emacs > vi для меня — просто меньше нажатий (отредактировал, Ctrl-X, Ctrl-S vs i, отредактировал, Esc, :wq).
Основной текстовой редактор — Sublime Text, и причина проста — очень быстрый полнотекстовой поиск. Практически все языки программирования высокого уровня позволяют использовать динамические вызовы кода, и это означает, что при рефакторинге надо искать текст тоже, не только прямые вызовы методов. К сожалению, многие IDE имеют с этим проблемы, так что проще использовать полный поиск.
Более того, все приведенные примеры в статье ориентируются на массовые изменения кода, и это подразумевает только одно — код написан с высокой степенью дублирования. Если писать код правильно, используя принцип DRY, массовые изменения практически не нужны. А где они нужны, можно просто воспользоваться multi-cursor или обычным find-replace. Конечно, приходят на ум унылые динозавры типа старой Java, где надо было писать много, но в современной Java это практически не нужно.
Мышки, потоки сознания — это все субъективно. Например, в MacBook Pro очень хороший тачпад, и руки не сильно отрываются при его использовании. И если программист хороший, он сразу пишет хорошо, ему не нужно отрывать руки от клавиатуры, чтобы править что-то выше или ниже. На крайний случай, можно вставить TODO в текст и подправить позже.
vi (не vim) есть всегда — он входит в список утилит POSIX: Utilities. Есть очень редкие случаи, когда vi не установлен, но я такое встречал только на специализированных Linux-based firmware (впрочем, там не было и nano тоже).
Небольшой оффтопик. Сравнивая разные кроссплатформенные библиотеки, мне больше всего тоже нравится wxWidgets, потому что она использует нативные контролы. Qt, конечно, богатая библиотека, но все-равно не то (контролы собственные), плюс необходима лицензия для коммерческих приложений.
Используя соотвествующие алгоритмы, конечно. Напомнило мне вопрос к Гвидо: как отсортировать миллион 32-битных целых используя 2 мегабайта памяти. Вот его ответ: Sorting a million 32-bit integers in 2MB of RAM using Python Вкратце: используя merge-sort и временные файлы (естественно, при условии что оригинальный список тоже в файле, т.к. в памяти он не поместится).
R очень популярен в Big Data (по крайней мере, на западе), на нем прототипируют, а потом переписывают на Python, Scala или другой язык программирования, более пригодный для разрабатываемой платформы. С развитием Apache Spark уже появилась возможность использовать R непосредственно в production (SparkR), так что прогресс на месте не стоит.
GPU instances использовать в AWS дороговато, поэтому многие не особо заморачиваются, но опять-таки прогресс идет, и на последнем Spark Summit уже обсуждали поддержку GPU: GPU Support In Spark And GPU/CPU Mixed Resource Scheduling At Production Scale Как я понял, в случае R это было бы: Spark создает RDD, R использует GPU для вычислений фаз DAG (используя соответствующие пакеты или непосредственно через Rcpp). Но могу быть не прав, без экспериментов не скажу насколько это практично.
Думаю, надо просто менеджерам делать свою работу лучше. Все-таки мы работаем с людьми, а не машинами. Это очень соблазнительно набросать кучу правил, и ожидать, что все будут им следовать. Но люди сложнее. В общем случае личное общение на рабочем месте не снижает, а иногда даже повышает продуктивность (коллеги устанавливают дружеские отношения, и потом обмениваются опытом; супруги вместо того, чтобы висеть на телефоне в обеденный перерыв, иногда переписываются в рабочее время, и в итоге не растягивают весь перерыв, чтобы выкроить время и т.д.).
Есть, конечно, и обратные случаи, но для этого надо:
Из того, что я пробовал, и давало хорошие результаты (но в конце концов, все-равно надо ожидать трений):
Все началось, когда другая команда, работающая над FortiController (менеджер этих железок) внедрили там PHP для UI. Им было это сделать очень просто, т.к. они использовали современный Linux, и им просто надо было написать пару расширений для PHP, чтобы он нормально заработал. Наш CTO загорелся идеей скриптования в backend-е и начал это активно продвигать (его понять можно — до этого была возможность только рекомпиляции и обновления прошивки даже для малозначительных изменений). Нас поставили перед фактом — внедряйте PHP в FortiGate, и чтобы это было готово уже вчера (ибо конкуренты не дремлют).
Я был очень сильно против, и после длительных дискуссий с угрозами увольнения мне сказали — предложи что-нибудь работающее и лучше, тогда подумаем. И мне дали всего 2 недели. Для контекста: FortiGate — это весьма кастомный Linux со своим ядром, файловой системой и никакими менеджерами пакетов. По сути, основное ПО на железке — это один исполняемый файл, в котором несколько точек входа (соответственно, ls и rm отличаются только точкой входа в этом файле). Как бы я не хотел внедрить что-нибудь достойное типа того же go-lang, я просто не мог заставить его работать в отведенное мне время. Другое условие — чтобы мы могли найти разработчиков. В итоге мне пришлось выбирать между JS, Python и PHP (я потом часть работы оформил в небольшую статью). К счастью, в то время V8 имел какие-то проблемы с нашим ядром (какие-то ioctl запросы не работали), поэтому несмотря на то, что мой непосредственный начальник хотел выбрать JS, я смог уговорить его использовать Python.
Я, конечно, упускаю много деталей, но выводы я сделал: выбор технологий иногда определяется не самой технологией (ее плюсами и минусами), а ограничениями (например, время внедрения) и кадрами. И к сожалению, кадры на западе — это весьма плачевное зрелище. Рынок наводнен выходцами из Китая и Индии, любовь к профессии заменена на жажду легких денег, клановое мышление заставляет их покрывать друг друга и просто отторгать всех талантливых и самостоятельно думающих разработчиков в сторону. От этого и уровень — найти JS-разработчика намного проще (даже найти нормального Python-разработчика было проблемой).
P. S. Хотел бы отметить, что я как раз недавно плотно работал с сотрудником Facebook-а, который пишет на OCaml — на нем разрабатывается Infer. Полное покрытие тестами у них не всегда есть, иногда они полагаются только на интеграционные тесты. Так что не стоить думать, что у гигантов софтоиндустрии все прекрасно, там тоже есть немало проблем.
P. S. Сорри за долгий ответ, гугл почему-то решил поместить сообщения с хабра в спам.
Отмечу еще полезные инструменты, которые мы используем для улучшения качества кода (пусть и не связано с утечками):
Но в 2015 году, возможно из-за внутренних пертурбаций, стандарты поменялись — Automatic code formatter released to GitHub. Основное отличие, на которое все жалуются — это использование подчеркивания вместо «this.», как это было рекомендовано StyleCop. Тем не менее, на текущий момент рекомендуется использовать именно эти новые стандарты кодирования. Учтите, что это внутренние стандарты, Microsoft не публиковало каких-либо официальных стандартов для внешнего использования, так что используете эти инструменты на свое усмотрение.
Я в свое время думал написать плагин для LLVM, который бы делал проверку этого закона, но предварительные эксперименты по внедрению такой проверки в стандарты кодирования провалились. Причиной тому была не чистая функциональность используемых языков программирования (в данном случае это были C++ и Python) — из-за того, что объекты можно передавать по ссылке, контролировать операции над ними не представлялось возможным (особенно, если это были библиотечные вызовы). В итоге мы использовали другие критерии, как например, тестируемость кода и ограничение cyclomatic complexity.
Насчет ресторанов в Калифорнии (как минимум даунтаун SF) — да, дорогие, что-то я подзабыл, привык к Ванкуверским ценам. Хотя вроде Red Lobster имел вполне нормальные цены, правда он немного на отшибе.
Ну а то, что индусов — большинство, это неудивительно, судя по последней статистике, они как минимум сравнялись по численности с другой известной нацией. Сильная клановость (и соответственно стремление пристроить «своих») тоже играет свою роль. И здесь нет никакого расизма, это просто их культурная особенность.
P. S. Аналогичная ситуация в Канаде — программистов много, а толковых сосчитать по пальцам. То же и с тестерами — было не очень приятно слушать, когда соискатели на роль QA сетевого оборудования не знали, как даже примерно работает DNS (хотя в требованиях явно указывалось знание OSI model).
4000 чистыми в месяц для США после всех расходов — это весьма неплохо. Это значит, что можно спокойно ездить на элитные курорты два раза в год не напрягаясь. 2500 чистыми в России — придется копить, чтобы хоть куда-то в достойное место выбраться (не в последнюю очередь из-за дороговизны местных перелетов, особенно если живете на Дальнем Востоке).
А то, что аренда в SF зашкаливает — это давно известный факт. Стартапы уже начинают уезжать из Кремниевой Долины, вот например: Startups Leaving San Francisco For Portland Oregon. В принципе, это имеет смысл: OR — весьма неплохой штат и по экологии, и по доступности. CA — еще то горячее пекло, только пожалуй в SF еще как-то более или менее комфортно :)
P. S. Это мое исключительное мнение, тем кто любит отдыхать в Турции летая туда чартерами и поесть картошечку с майонезом с небызызвестным 40-градусным напитком, удаленка в России будет, наверное, намного лучше описанного вами образа жизни в SF.
Впрочем, это все неважно, я не увидел, что это перевод статьи.
Очень много функций просто не задокументированы, и опять приходится гуглить, чтобы найти что-то толковое. Простой пример — получение мажорной версии оси. Смотрим operatingSystemVersionString: This string is not appropriate for parsing. Ладно, переходим на ту функцию, которая должна использоваться: operatingSystemVersion: детального описания вообще нет (могли хотя бы упомянуть, что это битовые поля упакованные в целочисленный тип). И так про кучу функций.
То же касается инструментария (lipo для создания Universal Frameworks особо нигде даже не упоминается на сайте разработчиков) и man-pages (некоторые функции просто отсутствуют).
P. S. В галерее позора по юзабилити у меня еще висит Xcode с показом невидимых символов. К счастью, можно редактировать код в любом текстовом редакторе, так что это не является проблемой, заслуживающей упоминания.
По оффлайну самый лучший для меня был Garmin, но исключительно в Канаде. Причина очень простая — можно прикупить Backroad maps. Google maps и рядом не стоял по детализации. Собственно, offroad-карты иногда даже лучше в OpenStreetMaps, чем в гуглокартах.
Так что на самом деле, эта тема достаточно интересная, и отрасль еще развивается — гугл хотя и достаточно хорош, но с собственно картографией и детализацией у него не очень хорошо (What happened to Google Maps?), и пока золотой середины еще не наблюдается (но должен честно признаться, что новейшие модели гармина и томтома я еще не пробовал).
Правда должен признать, что есть такие темы, когда документация не особо помогает. Когда я переделывал CPython для работы с проприетарной встроенной платформой (прикручивал jmalloc и переделывал многопоточность на использование clone() напрямую), пришлось ковыряться в исходниках. Но это нужно единицам, книги на такие темы просто бы не окупились.
Почему emacs > vi для меня — просто меньше нажатий (отредактировал, Ctrl-X, Ctrl-S vs i, отредактировал, Esc, :wq).
Основной текстовой редактор — Sublime Text, и причина проста — очень быстрый полнотекстовой поиск. Практически все языки программирования высокого уровня позволяют использовать динамические вызовы кода, и это означает, что при рефакторинге надо искать текст тоже, не только прямые вызовы методов. К сожалению, многие IDE имеют с этим проблемы, так что проще использовать полный поиск.
Более того, все приведенные примеры в статье ориентируются на массовые изменения кода, и это подразумевает только одно — код написан с высокой степенью дублирования. Если писать код правильно, используя принцип DRY, массовые изменения практически не нужны. А где они нужны, можно просто воспользоваться multi-cursor или обычным find-replace. Конечно, приходят на ум унылые динозавры типа старой Java, где надо было писать много, но в современной Java это практически не нужно.
Мышки, потоки сознания — это все субъективно. Например, в MacBook Pro очень хороший тачпад, и руки не сильно отрываются при его использовании. И если программист хороший, он сразу пишет хорошо, ему не нужно отрывать руки от клавиатуры, чтобы править что-то выше или ниже. На крайний случай, можно вставить TODO в текст и подправить позже.
vi (не vim) есть всегда — он входит в список утилит POSIX: Utilities. Есть очень редкие случаи, когда vi не установлен, но я такое встречал только на специализированных Linux-based firmware (впрочем, там не было и nano тоже).
Небольшой оффтопик. Сравнивая разные кроссплатформенные библиотеки, мне больше всего тоже нравится wxWidgets, потому что она использует нативные контролы. Qt, конечно, богатая библиотека, но все-равно не то (контролы собственные), плюс необходима лицензия для коммерческих приложений.
GPU instances использовать в AWS дороговато, поэтому многие не особо заморачиваются, но опять-таки прогресс идет, и на последнем Spark Summit уже обсуждали поддержку GPU: GPU Support In Spark And GPU/CPU Mixed Resource Scheduling At Production Scale Как я понял, в случае R это было бы: Spark создает RDD, R использует GPU для вычислений фаз DAG (используя соответствующие пакеты или непосредственно через Rcpp). Но могу быть не прав, без экспериментов не скажу насколько это практично.