Может, раздражает человека. Между прочим я могу его понять — у меня скрыты панели кнопок (те, которые по периметру) и показываются они по double cmd (с зажатым последним) и иногда случается, что они показываются когда мне не надо, или когда надо — нужно по несколько раз сделать triple-double cmd чтоб наконец увидеть их. Так что при определённых условиях попап по double-shift вполне может появляться "неожиданно".
Если совсем короче — все хоткеи должны быть изменяемы. То, что удобно вам — может быть неудобно другим.
Такой вопрос, немного оффтоп:
Вот есть youtrack, где в принципе, можно получить какой-то фидбек на баг и понять когда будет исправлено, какой workaround можно применить, пока не пофиксили, предоставить дополнительные логи/конфиги если нужно, собирать +1ны и т. д.
Есть https://ea.jetbrains.com, куда репортятся исключения прямо из IDEA — но понять абсолютно ничего нельзя. У меня, например, в последнем EAP билде есть стабильный exception, который я репортил, и видели его или нет, фиксят его или нет — не понятно.
Можно ли как-то популярно объяснить, что оно и зачем-почему ответвление от багтрекера? И может стоит просто копипастить исключение и заводить issue в багтрекере?
А какой смысл в выравнивании версий? Если взять, например, RubyMine и IntelliJ IDEA, сравнять версии, то, мне кажется, будет ещё запутаннее, поскольку они вроде как одной версии, но при этом плагин в IDEA старше, чем нативная поддержка в RM, и в итоге всё всё-равно сводится к версия ИДЕ + версия плагина.
Или это исключительно в маркетинговых целях?
2016.1, 2016.2, 2016.3
Тут не понятно, то ли 1, 2 и 3 — это разные продукты, то ли минорные релизы в пределах года.
Я так понимаю, что это справедливо для Android < 4.4, поскольку с этой версии в webview используется уже Chromium: https://developer.chrome.com/multidevice/webview/overview.
Так что ежели у кого приложение тормозит на 4.4+ — тут такие приёмчики не помогут.
Ну хорошо, допустим логика такая: вводим название города, получаем координаты -> вписываем вручную в нужное поле.
Открываем другой комп (новый, взамен украденного/потерянного/переустановка системы/etc) — вводим название города (координаты-то не помним), используем найденные — а они оп, и изменились. Вот о чём речь, нестабильно это как-то, тем более если речь идёт о генерации паролей.
Насколько я понимаю, то вы используете координаты, которые возвращаются гуглом по определённому поисковому запросу. Не знаю, как гугл, но я сталкивался с изменениями координат для запроса (проще говоря, центра города) на какие-то там пару метров. Если я правильно понимаю, то в таком случае резко херятся все пароли ко всем ресурсам. То же самое для смен урлов или даже http на https, но локально — придётся менять пароль на самом ресурсе.
В целом, идея интересна с точки зрения самого интереса. Насколько это целесообразно — уже много раз писалось.
Ну хорошо, вот мы подошли той самой точке, когда «уже не получается» — дальше что делать, куда идти? Путей множество, выбор крайне неочевиден и на всех них в изобилии рассыпаны подводные камни и грабли.
«Крайне неочевиден выбор» тогда когда вы начинаете решение задачи с изучения «новых-сложных фреймворков», типа как автор. А когда вы уже решили 90% задачи на том же, как вы пишете, jQuery — то поиск необходимого инструмента для решения оставшихся 10% — уже не кажется таким сложным, разве нет? Ведь речь как раз об этом.
Как писал хабраюзер Awake
Чтобы сделать небольшой бложик для друзей, не надо использовать Spring. Нужно просто взять Wordpress и сделать.
— простым задачам простые (≈известные) инструменты.
А если задача и есть изучение фреймворка — ну, значит нужно стиснуть зубы и изучать
Любой неизвестный фреймфорк (если речь о фреймворках, а не о микро-библиотеках, которые решают определённую задачу и заводятся с полпинка) заведомо сложный. В любом случае гораздо сложнее чем известный.
Просто нужен другой подход. Не "берем всё самое новое-сложное и пытаемся сделать простое приложение", а "пытаемся сделать простое приложение начиная с простых инструментов". А вот если уже не получается — наслаиваем библиотеками и/или технологиями. Не нужно ничего нигде описывать.
Я думаю, что оба варианта нужно просчитывать «здесь и сейчас». А потом уже решать на основании спрогнозированных повреждений. Например, при въезде в дерево можно спасти пассажиров какой-либо стороны авто, Может быть даже всех, если грамотно свалить машину в занос. При сплошном кустарнике просчитать что-либо гораздо сложнее, а ведь там ещё может оказаться и булыжник.
Вы смотрите на данную ситуацию с точки зрения человеческой реакции, но робомобиль сможет анализировать и корректировать действия на ходу в тысячи раз быстрее человека. Так что я тоже за этот вариант.
Хотя, то же самое можно применить и к двум другим вариантам — предположить, что робот сможет рассчитать минимальные потери при продолжении движения или просчитать наиболее безопасную траекторию при съезде в кювет (может даже приведя в активное состояние некоторых подушек безопасности заранее).
По-моему, карму вообще нужно отменить и ввести в прямую зависимость от рейтинга. Смысл в том, что если ты когда-то написал дурацкий комментарий — заминусовать его ещё глубже уже никто не сможет (из-за ограниченного времени), а вот минусануть в карму — это завсегда (а человек, скорее всего, если не тролль, уже давно понял что сглупил). Я считаю, что голосовать за карму можно (нужно) только по определённым причинам (как выразились выше, с сопутствующими комментариями), тогда достаточно просто рейтинг конвертировать в карму.
Мне кажется гораздо более логично получить в карму +1 если у тебя заплюсовали какой-то коммент, чем от какого-то одного человека, потому что твоя точка зрения ему симпатична. Это и есть саморегулирующаяся демократичная система. Сейчас это далеко не так.
Может быть, оставить соотношение плюс/минус как «плюс заработать сложнее», но при этом плюсы за статьи выше по рейтингу плюсов за комментарии.
P.S. похоже какой-то глюк записал мой коммент в эту ветку, хотя я писал его через форму внизу.
Если совсем короче — все хоткеи должны быть изменяемы. То, что удобно вам — может быть неудобно другим.
Вот есть youtrack, где в принципе, можно получить какой-то фидбек на баг и понять когда будет исправлено, какой workaround можно применить, пока не пофиксили, предоставить дополнительные логи/конфиги если нужно, собирать +1ны и т. д.
Есть
https://ea.jetbrains.com, куда репортятся исключения прямо из IDEA — но понять абсолютно ничего нельзя. У меня, например, в последнем EAP билде есть стабильный exception, который я репортил, и видели его или нет, фиксят его или нет — не понятно.Можно ли как-то популярно объяснить, что оно и зачем-почему ответвление от багтрекера? И может стоит просто копипастить исключение и заводить issue в багтрекере?
Или это исключительно в маркетинговых целях?
Тут не понятно, то ли 1, 2 и 3 — это разные продукты, то ли минорные релизы в пределах года.
Так что ежели у кого приложение тормозит на 4.4+ — тут такие приёмчики не помогут.
Открываем другой комп (новый, взамен украденного/потерянного/переустановка системы/etc) — вводим название города (координаты-то не помним), используем найденные — а они оп, и изменились. Вот о чём речь, нестабильно это как-то, тем более если речь идёт о генерации паролей.
В целом, идея интересна с точки зрения самого интереса. Насколько это целесообразно — уже много раз писалось.
Как писал хабраюзер Awake — простым задачам простые (≈известные) инструменты.
А если задача и есть изучение фреймворка — ну, значит нужно стиснуть зубы и изучать
Ну-ну.
Хотя, то же самое можно применить и к двум другим вариантам — предположить, что робот сможет рассчитать минимальные потери при продолжении движения или просчитать наиболее безопасную траекторию при съезде в кювет (может даже приведя в активное состояние некоторых подушек безопасности заранее).
Мне кажется гораздо более логично получить в карму +1 если у тебя заплюсовали какой-то коммент, чем от какого-то одного человека, потому что твоя точка зрения ему симпатична. Это и есть саморегулирующаяся демократичная система. Сейчас это далеко не так.
Может быть, оставить соотношение плюс/минус как «плюс заработать сложнее», но при этом плюсы за статьи выше по рейтингу плюсов за комментарии.
P.S. похоже какой-то глюк записал мой коммент в эту ветку, хотя я писал его через форму внизу.