Category: Application and Tools
Лучшая мышка для программиста — это трекбол и трекпоинт
TL;DR Мышки — долой. Просто покупайте Logitech MX Ergo Bluetooth и попробуйте поработать месяца три. Если не подойдёт то берите другой трекбол. На цену не смотрите, сомнения оставьте.
Ежедневно мы так много работаем с мышью что она уже является продолжением нашей руки. Даже спустя десятилетия производства мышей выбрать подходящую довольно сложно. Осуждения мышей на программистских форумах не утихают. Лично я уже много лет пользуюсь не мышью, а трекболом Logitech M570 wireless trackball, вместе с ThinkPad трекпоинтом и они так классно дополняют друг друга что уже просто не понимаю как программисту можно пользоваться чем-то другим.
Купил как только начался туннельный синдром в запястье на правой руке и он прошёл. Но из-за клавиатуры чуть позже начался на левой руке, поэтому стараюсь лишний раз ею не пользоваться и полечил её в клинике ультразвуком, вроде пока прошло.
Боли в суставах большого пальца я не замечал но всё таки вспомнил что да, действительно бывали. Т.е. проблема есть но не очень критична. Хотя тут может быть очень индивидуально.
Но кроме того что рука отдыхает самое крутое что трекболом можно пользоваться на любой поверхности и не надо ёрзать. Т.е. нет этого противного звука скрежета по столу, не нужно ковриков для мышки или гладкого стола. Особенно это круто когда ты работаешь за ноутбуком в постели: положил его на живот или скомканную простыню и работаешь себе спокойно. Я даже успешно поработал едя несколько часов микроавтобусе при сильнейшей тряске.
Из-за того что ты не елозишь по столу получается тише но, у него довольно громковатый клик. Причём у клика звук странный — «двойной» ты слышишь клик как опустилась клавиша и ещё клик как поднялась.
Чистить приходится, но в отличии от шариковых мышек он засоряется намного реже, потому что загрязняется только жиром с пальца а не грязью со стола. К тому же вычищается намного легче, потому что грязь не на роликах а на пластиковых прижимателях шарика.
Ещё из проблем: кликер ломается и вместо одного клика срабатывать как двойной. Это бесило люто — жмёшь на крестик закрыть программу она закрывается и невольно нажимаешь на крестик закрыть следующей программы.
Из-за того что я перешёл с удалёнки обратно в офис я его каждый раз вытаскивал и носил на работу. От постоянных вытаскиваний у меня сломался USB ресивер. Вообще говоря, нужда в отдельном ресивере это плохо. Во первых он занимает USB порт, а у меня на ноуте их только три а на рабочем стационарном компьютере он вообще сзади системника. Хотелось бы Bluetooth но вроде как для блютуза нужно чтобы полностью система загрузилась и драйвера. Так что ресивер даже лучше в этом отношении.
Но у рабочего тоже по-моему периодически срабатывал двойной клик. Так-что это может быть их родовой травмой.
Ещё из неприятных моментов: когда падает на пол вылетает и укатывается шарик. Случается редко, обычно в путешествиях но очень неприятно его искать.
Отдельно мне не нравится что нет средней кнопки, а кликать роликом очень жёстко и неприятно.
Ещё тут нужно сказать что трекбол тяжёлый, большой и занимает больше места. Это может быть неудобно если у вас какой нибудь нетбук и вам хочется иметь маленький вес и размер. У меня например он полностью занимает боковой карман рюкзака, а например, в карман штанов он вообще не поместиться.
Но из-за того что он большой, ладонь полностью ложиться на него и ощущения приятнее. Т.е. это требование эргономики.
Кстати, в отличие от обычных беспроводных мышей, которые из-за батареек становятся тяжелее больше и неудобнее ими ёрзать, для трекбола это проблемой не является.
Ещё один неприятный момент: когда парно программируешь с коллегой, он пытается поелозить трекболом как мышкой 🙂 Поэтому у меня за компьютером лежит ещё отдельно «гостевая» мышка, и кстати получается удобнее — нужно куда-то навести курсор, ты не просишь коллегу дать мышку а просто сам наводишь. Поэтому если вы работаете в офисе то вам от традиционной мышки всё равно не избавиться. Но и даже если у вас будет две обычные мышки это сильно улучшит удобство в парном программировании.
Ещё на трекболе есть две кнопки для броузинга «Вперёд по истории» и «Назад». Но я ими не пользуюсь. ИМХО намного было бы удобнее если бы кнопки работали как «Page up» и «Page down». Может их можно перемапить но у меня руки не доходили.
Очень важный момент: привыкание к нему после мышки было очень быстрым, уже за день я спокойно пользовался. Точность очень хорошая, возможно даже лучше чем у мышки. Но! Скорость перемещения меньше чем у мышки. Поэтому для стрелялок, типа Халвы или Контры, он не подходит, но для неспешной и долгой работы, как например за стратегиями типа Эпохи Империй он просто отличный.
Батарейки держат очень хорошо, точно больше двух лет и я ещё ни разу не менял. Дальность приёма ресивера огромна — через две комнаты ловит отлично.
Итак, плюсы:
* Не болит кисть руки
* Работает на любой поверхности, включая просто на весу что можно использовать во время презентации.
* Не нужно ёрзать по столу
* Хорошая точность
* Привыкаешь быстро
* Батарейка практически вечная
* Беспроводная
* Эргономичная
Минусы:
* Не панацея: может заболеть сустав на большом пальце, один раз было у меня но это ничто в сравнении с болью в запаястье
* Очень часто и довольно быстро начинаются проблемы с двойным кликом: ты кликаешь раз а происходит двойной щелчок.
* Дороже чем обычные мышки
* Только для правшей
* Может начаться боли в суставах большого пальца
* Скорость перемещения ниже — не годится для динамичных игр
* Периодически нужно чистить под шариком
* Шарик при падении вылетает
* Пользоваться сможете только вы, поэтому если вы парно программируете нужно вторую мышь держать.
* Шумновата
* Нужен ресивер
* Неудобная в транспортировке
* Тяжелее найти
Из-за проблем с двойным кликом умельцы перепаивают кликер:
* Logitech Mouse Trackman M570 Trackball Repair — Left Click Problem
* Repair Mouse With Double Click Problem
Варианты которыми я не пользовался, но может вам подойдёт:
* Для левшей или тех у кого болит большой палец есть трекбол Logitech MARBLE.
* Некоторые пробуют вертикальные мышки, например DELUX M618 Wireless Vertical Laser Mouse
Как определить ставить ли новую Windows или любую другую программу
Среди IT-специалистов распространено мистическое убеждение:
Считается, что каждая четная версия Windows выходит у Microsoft неудачной, а каждая нечетная, наоборот, хороша. Здесь стоит вспомнить критику Windows Millenuim, Windows Vista и Windows 8, которые были четными, а также успех Windows XP и Windows 7. Microsoft пропустила цифру «девять», сделав Windows 10 нечетной в этом списке. Впрочем, некоторые специалисты «девяткой» считают Windows 8.1, что переводит «десятку» в совсем другую категорию.
На самом деле мистики никакой тут конечно же нет. В Майкрософте работают тысячи лучших инженеров, ну ладно, шучу, конечно не лучших, но в принципе уже горько опытных. Над ними ещё десять звеньев всяких менеджеров среднего звена, маркетологов и прочих бабкорубов. Поэтому по теории больших чисел результаты из труда не случайны а имеют определённую закономерность. Почему так происходит чётко видно по кнопке пуск — в один релиз её убрали, а на следующий, получив гневный фидбек, вернули.
Всё выстраивается так что в одном релизе вводят новую или меняют старую функциональность, затем на следующий релиз её либо убирают либо меняют и стабилизируют. Просто почитайте что какую судьбу предсказывали восьмой винде:
Вспоминаем: после XP люди ждут очень перспективной ОС с ещё более красивой графикой, гиберацией, повышенной безопасностью и возможностью не перезагружать комп после установки программ или драйверов. Появилась Vista. Люди негодуют — глюки, производительность никакая и т.п.
Разработчики чешут репу, многое отключают в системе чтобы не мешало, исправляют баги, что-то добавляют и выпускают семёрку.
Пользователи смотрят — производительность лучше чем у висты, радуются и забывают, что XP работала быстрее (момент немного спорный) и требовала намного меньше ресурсов для компьютера.
microsoft начинают воевать со старушкой XP, так как она остаётся неплохим конкурентом семёрке и активно используется в Китае вместе с IE 6Сейчас повторяется то же самое: обещают поддержку ARM процессоров и телефонов, совместимость со старыми приложениями и возможность играть в игры для Xbox, революционный интерфейс и т.п.
Когда восьмёрку выпустят внезапно поймут что погнались за двумя зайцами, есть много багов, на телефонах тормозит и т.п. и т.д.
Разработчики почитают гневные реплики пользователей и к следующей (наверно, девятой) версии всё исправят. Судя по всему, ещё лет пять-десять как минимум семёрка будет оставаться одной из используемых ОС для компьютеров.Впрочем, неудачная (если вдруг) Windows 8 не понравится некоторым пользователям, и они перейдут на linux или продукцию компании Apple, которая в последнее время имеет свободных денег больше чем microsoft. Не будем забывать и про Google, которые, в принципе, тоже могут что-то выпустить.
(с) http://forum.boolean.name/showthread.php?t=15523
ИЧСХ и всё прямо так и случилось!
Поэтому есть релизы стабильные или успешные а есть тестовые или неуспешные. Понять успешность можно лишь по статистике как быстро на него переходили («адоптировали»). Я например за вистой и восьмой виндой даже не поработал. Иногда когда вижу у кого-то удивляюсь что это такое.
И это касается не только Виндовс но и других крупных продуктов с длинным релизным циклом, обычно у «коробочных» типа Microsoft Office. Но есть интересный пример версии Java:
1.0 Её даже не публиковали, так что скипнем
1.1 Первая опубликованная, ажиотажа не вызвала. Помещалась на дискету. Можно считать релиз неуспешным.
1.2 Появились коллекции, JIT, Swing, Java plugin и аплеты (а тогда это был крутяяяк) — количество кода библиотек выросло в три раза и уже на дискету не влезало. Успех!
1.3 Вообще ниочём, багфикс. Неуспех.
1.4 Регекспы, уродский логинг АПИ, но зато NIO, криптография, XML парсинг. Вроде ничего такого особого, но Успех. Началось активное использование для веба, сформировались библиотеки и фреймворки, появились первые JVM языки Groovy и Scala.
1.5 Синтаксический сахар (статик импорты, аннотации, for each, enum, varargs) но главное что появился внятная Java Memory Model и Concurrency. Внезапно успех, хотя почти на всех старых джава проектах этот на этот сахар ещё не переписали. Но грамотно заложенная и чётко специфицировання JMM сыграла
1.6 Последний релиз Sun’а ничем не интересный кроме внятных процессоров аннотаций. Всё замерло на этом релизе надолго и все только и любая магия так и делалась на аннотациях пока по ночам мы плакали в подушку мечтая о лябдах. Тем не менее релиз оказался довольно стабильным и всё работало много лет, так что всё таки успех.
1.7 Первый релиз Оракла. Ничего интересного, просто промежуточный перед восьмой джавой. Неуспех.
1.8 Ляяямбдыыыыы! И наконец-то внятный Date API. Все перешли на восьмую почти мгновенно. Успех!
1.9 Уже на выходе, по сути будет только улучшена модульность что конечно тоже сверхважно для древних энтерпрайзных монолитных проектов, но хипстеры уже всё говнокодят на микросервисах где всё проще переписать и не нужно сильно запариваться архитектурой. Так что особо ажиотажа особого не будет.
Итак, тут закономерность чётности версий прослеживается ну только при очень большом старании. Но если посмотреть не каждую вторую, а каждую третью версию то можно заметить что 1.2, 1.5 и 1.8 то эти релизы были особенно успешными. Причём даже не так, они наделали шума. В основном из-за того что в них появлялись новые «Вау» фичи. И это принципиальное дело кстати.
Представьте себя менеджером продукта. У вас есть некие срочные задачи — например секьюрити уязвимости, есть задачи по долгосрочному плану улучшения архитектуры проекта, но периодически вам нужно добавлять в продукт что-то такое что снова привлечёт внимание пользователей и даже те кто пользовался древней версией и довольны захотели бы купить новую версию. Например в случае с Джавой это новые возможности языка.
Т.е. есть разные задачи с разными характеристиками по важности и срокам и при грамотном менеджменте ты их учитываешь. Если их граммотно разложить и расписать на графике то можно найти множество таких закономерностей и предсказывать свойства следующей версии.
Поэтому можно смело предсказывать что например в десятую версию Джавы будут внесены какие-то вау фичи.
Но что самое интересное, если посмотреть на минорные версии джавы то там это правило чётности уже заметили давно и с пятой джавы даже приняли как схему версионирования: чётные релизы содержат новый функционал, нечётные багфикс и секьюрити апдейты. А позже ещё и усложнили настолько что даже пришлось на конференциях объяснять как теперь с этим разбираться
Но не всегда четно-нечётная схема усложняется, многие как раз наоборот стараются перейти к более частым и но последовательным и плавным rolling releases и continuous delivery:
Между сериями 1.0 и 2.6.x ядро Linux использовало нечётные номера для бета-версий, и чётные — для стабильных. Например, Linux 2.3 был серией в разработке, а Linux 2.4 — серией стабильных релизов, в которую перерос Linux 2.3. В номере релиза Linux kernel сначала писался номер второстепенной версии, а затем номер релиза в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После релиза 2.6 в 2004 году Linux больше не использует эту систему, теперь цикл релиза намного короче. Сейчас они просто увеличивают третье число, используя при необходимости четвёртое.
Тоже самое кстати происходит и с броузером Chrome а позже и с Firefox’ом. Какая версия Хрома уже никто не знает (у меня например уже 16.3.0.6796). Для обеспечения надёжности они просто создали отдельную «вечную бету» которую могут себе поставить и протестировать все желающие и Feature toggling.
Таким образом цикл релиза и фидбека ускорился и подобные схема рано или поздно будет использована почти во всех программах.
И вы не отставайте 😉
«Comparing JVM Web Frameworks» by Matt Raible
It’s very cool talk about qestions that every Java developer must decide on new project. Overview of all popular Java frameworks from JSF and Struts to Play and Vaadin.
Код стайл не только для читаемости но и для редактируемости
Тема код стайла очень хорошо раскрыта в замечательной книге Clean Code.
От себя я бы хотел обратить внимание на пару не очень очевидных вещей к которым пришёл со временем.
- Во первых это вертикальная плотность кода (Vertical Density). Где-то я слышал что программист не может в голове держать больше 400 строчек кода. Собственно это и есть лимит на количество строк в вашем файле. Если больше — разбивайте на другие классы.
Скролить файл вниз — утомляет. Более того, иногда похожие или связанные методы идут рядом и хотелось бы их сразу видеть рядом.
Ещё один момент — обычно вертикально идут сами команды а горизонтально их параметры.
Обычно когда ты смотришь в код тебе более важно понять логику и последовательность команд а не их уточнения.
По сути это визуальное отображение принципа High Cohesion (Сильное Сцепление).
Поэтому я начал очень сильно следить за вертикальной плотностью и несколько следующих принципов вытекают из этого требования. -
Принцип неразрывности — когда вы избегаете писать пустые строки внутри методов потому что обычно являются запахом что тут следовало бы экстрактнуть метод.
В IntelliJ Ctrl+S > Code Style > Java > Blank lines всё выставьте по нолям или максимум 1 -
Не переносите строки: сегодня у нас очень широкие мониторы и уже следует избегать переносов команд на две строки. На моём мониторе спокойно влезает по 256 символов. Это более чем достаточно, но обычно IDE переносят строки по границе в 120 символов. Более того, обычно если у час всё равно длинная строчка и не влезает полность на экран то это не страшно — обычно там идут неинтересные параметры вызова метода. В любом случае горизонтально скролить приходится в тысячу раз реже чем вертикально.
Поэтому сразу полезайте и отключайте эти переносы или ставьте им границу в 400 символов.
В IntelliJ Ctrl+S > Code Style > General > Right Margin -
Джавадоки тоже пытайтесь делать однострочными.
Т.е. вместо/** * Some method description */ void someMethod() { ... }пытайтесь писать так
/** Some method description */ void someMethod() { ... }В IntelliJ Ctrl+S > Code Style > Java > Java Doc > Do not wrap one line comments
-
Отключите выравнивание (arange) кода. Очень многие IDE по умолчанию наводят «красоту» и выравнивают (тут я отметил нижним подчёркиванием _)
void someMethod() { def params = [ firstName:_'John', lastName:__'Doe', age:_______42 ] }С одной стороны принято считать что это добавляет красоты и читаемости. С другой стороны, если вы удалите например первую строчку то вам придётся перевывравнивать соседние сточки и эти изменения подзагадят вам diff в системе контроля версий.
В IntelliJ Ctrl+Alt+S > Code Style > Java > Wrapping > Align when multiline
Вместо заключения
На стиль кода влияют несколько вещей:
1. Удобство чтения кода — большую часть мы код читаем
2. Возможности IDE — очень многие вещи они могут отображать более удобно (сворачивать гетеры и сетеры, копирайт заголовки, импорт лист).
3. Система контроля версий — очень важно чтобы изменения были как можно более атомарными и в diff’е не было слишком много строк чтобы было проще понять суть.
4. Дебагинг — иногда лучше вместо method chaining выделить переменную потому что дебагер идёт построчно.
[Заметка] Статический анализ кода на Java: Sonar и Maven
Вкратце о том как подключить Sonar к вашему проекту на Maven.
Чтобы ваш проект попал в сонар по дефолту достаточно просто выполнить команду
mvn sonar:sonar
Проблема в том что для выполнения этой команды сонару нужно знать дополнительно несколько вещей, а именно:
- Язык вашего проекта:
sonar.language - Адрес сайта сонара:
sonar.host.url - Настройки БД сонара:
sonar.jdbc.url, sonar.jdbc.driver, sonar.jdbc.username,sonar.jdbc.password
Язык вашего проекта и адрес сайта это публичная информация и указываем их прямо в pom.xml файле:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
...
<properties>
<sonar.language>java</sonar.language>
<sonar.host.url>http://sonar.example.com:9000/</sonar.host.url>
</properties>
...
</project>
Настройки БД не должны быть видны народу поэтому мы устанавливаем их в settings.xml
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<sonar.jdbc.url>jdbc:postgresql://localhost/sonar</sonar.jdbc.url>
<sonar.jdbc.driver>org.postgresql.Driver</sonar.jdbc.driver>
<sonar.jdbc.username>user</sonar.jdbc.username>
<sonar.jdbc.password>password</sonar.jdbc.password>
</properties>
</profile>
После этого запускаем
mvn sonar:sonar
Ещё годная статья по теме
Why do I hate Maven?
Мавен упорно позиционирует себя как билд тул, хотя на самом деле он ни что иное как менеджер пакетов и конфигураций.
Т.е. через мавен я не могу через мавен ставить например ява пакеты как программы, а не как библиотеки.
Не могу например grails или какой нибудь sdk скачать и установить.
Когда я работаю с мавеном у меня постоянно всплывают воспоминания и дебиановском пакетном менеджере.
Мавену явно нужно было брать с ниго пример, там очень много крутых вещей в документации таится о которой не все линуксоиды знают (я помню меня сильно впечатлил строгость формата changelog файла).
Во вторых мне не нравится что мавен является не эволюционным продолжением анта, а конкурирующим с ним продуктом.
В итоге нельзя эволюциооно обновлять свой антовский проект — только сразу на мавен, только хардкор. Для слабоков смиловались и запилили ант плагин к мавену, что вообщем хоть как то, но выручает.Отсюда кстати и поползли холивары.
Документация к мавену ужасна. Только гугл, только stack-overflow.
Кодировка исходников и версия джавы под которую они написаны прописывается неявным образом:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jdk>1.6</jdk>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<encoding>${project.build.sourceEncoding}</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${jdk}</source>
<target>${jdk}</target>
<compilerVersion>${jdk}</compilerVersion>
</configuration>
</plugin>
</plugins>
</build>
И даже тут есть проблема: нужно укзывать версию стандартных плагинов. Какую ёё прописывать непонятно.
Упаси бог написать вам свой java agent — они не поддерживаются на уровне конфигурации мавена. И даже плагина ещё нет.
В итоге для прогона юнит тестов библиотеки javaagent приходится изголятся таким образом:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>pertest</forkMode>
<argLine>-javaagent:${project.build.directory}${file.separator}${project.build.finalName}.${project.packaging}</argLine>
<workingDirectory>${project.build.directory}</workingDirectory>
</configuration>
</plugin>
И при первом прогоне оно не работает, посокольку джарника ещё нет, а мы уже к нему обращаемся.
Но как ни странно стадия тестов от этого не валится и он таки билдитcя. Мрак.
И так же тут всплывает ещё одна проблема: в пропертях мавена нет пути к сбилдженому артефакту.
Приходится самому её имитировать:
${project.build.directory}${file.separator}${project.build.finalName}.${project.packaging}
Кстати сами проперти в отдельный файл никак не вынесеш, как это сделано в анте.
settings.xml явно не самая удобная вещь. И непонятно почему репозитории не перенесены туда.
Не до конца понятный build lifecycle:
- clean и site запускается только вручную, по сути это самостоятельные таргеты а пункты лайфцайкла.
- install это совсем не то что что и install в make.
- deploy тоже у всех ассоциируется немного с другим процессом.
С версииированием артифактов всё тоже не всегда хорошо. Дописывать alpha beta к релиз пакетам геморно (через плагин). А ведь это вполне стандартная система версиирования.
Вообщем недостатков много, и всё равно в основе мавена лежит очень правильная идея: описывать проект, а не процесс его создания. Это очень правильная философия.
UPD
Интересная статья Maven is broken by design
stokito on software 