16.2
Karma
0.8
Rating

User

Свистать всех на Linux, гром и молния

0

Ну вот тут я скорее за то, чтобы системынй ПМ не трогать, а копировать программы локально, чтобы можно было легко менять версии на те, которых в системном ПМ нет и чтобы программист чётко знал, что ему необходимо для работы.

Свистать всех на Linux, гром и молния

0
Например, поставить docker

О докере то я и не подумал. Остальное ещё как-то можно, а докер получается придётся админам ставить

Свистать всех на Linux, гром и молния

0
Возможны проблемы с совместимостью и накладными расходами.

Это какие?

Свистать всех на Linux, гром и молния

0
Конечно, нет.

И какая IDE не использует git.exe ?


Никто не запрещает использовать/написать библиотеку по работе с файлами Git'а.

И некотороые даже пишут, но в IDE используют git.exe

Свистать всех на Linux, гром и молния

0
Касательно GIT — да, консольный GIT в Windows — это боль.

И что не так с консольным клиентом git в Windows? Там же msys в котором тот же самы bash и всё остальное.

Свистать всех на Linux, гром и молния

0
Программист без админских прав на локальной машине — это бред.

А для чего программисту админские права на локальной машине? Что он может с ними сделать что без них невозможно?

Apple в 2019 году — это Linux в 2000 году

0
Действительно, и чего это ноутбук не разгоняет проц больше чем могут десктопы?

Чего-то я не понимаю, вам сказали, что проц работает на 3GHz, хотя может на 4GHz, вы ответили, что 4GHz это частота до которой процессор может разгоняться лишь кратковременно, вам указали, что кратковременно может и до 5GHz, а 4 GHz это рабочая частота, вы дали ссылку на спеку процессора, где прямо сказано, что 5GHz это частота турбо буста, получается ваше высказывание про то, что частота турбо буста это 4GHz неверно.


Но там же написано, что базовая рабочая частота 2.4GHz, то есть даже меньше, чем 3GHz, но вы почему-то не акцентируете на этом внимания, хотя это бы опровергло высказывание вашего оппонента что нормальная частота 4GHz. Я что-то упускаю?

Apple в 2019 году — это Linux в 2000 году

0
Переключаюсь на них сочетанием Win+[Num]

К сожалению, на Win + [letter] повесить запусе программы без танцев с бубном не получится. Что в убунте, что в винде. Это очень напрягает.

Apple в 2019 году — это Linux в 2000 году

0
Это можно не в i3, а в принципе в Линуксе.

В известных мне дистрибутивах линукса из коробки так сделать нельзя. Нужно самостоятельно писать скрипты и самостоятельно прикручивать их к хоткеям.


А в i3 приложение привязывается к рабочему столу и при запуске происходит переключение на нужный стол и запуск его там.

И из коробки можно сделать так, чтобы по нажатию хоткея если приложение не запущено, оно бы запускалось, а если запущено, то его рабочий стол становился бы активным?

Apple в 2019 году — это Linux в 2000 году

Apple в 2019 году — это Linux в 2000 году

0

А в i3 можно посадить каждое приложение на свой хоткей? И чтобы если он было не запущено, то оно бы запускалось, а если уже запущено, то я бы попадал в окно с ним?

Apple в 2019 году — это Linux в 2000 году

0
Но увы, на Маке все двухпанельные файловые менеджеры, раздражают то теми, то другими недоделками и ни один не прижился

Double Commander пробовали?

Делаем из Vim-а конфетку

Делаем из Vim-а конфетку

+1
Нет, режимами пока пользуешься — надо постоянно переключаться еще :)

Проблем с переключением между режимами не больше, чем проблем с переключением между состоянием, когда Ctrl зажат и когда он отпущен. А по субъективным ощущениям так и меньше.

Делаем из Vim-а конфетку

0
Я же говорю что режимы и не нужны

А вам отвечают, что нужны ))


вместо этого есть палитра комманд и мощная система манипуляции текстом. Они выполняют те же функции что и режимы по сути.

Только с режимами пользоваться всеми этими функциями удобнее.

Делаем из Vim-а конфетку

+1
Пока ваше объяснение выглядит так:

Да вообще нет. Вот как всё выглядит.


  • Зачем пользоваться вимом?
  • Чтобы иметь возможность использовать режимы.
  • Зачем использовать режимы?
  • Это удобно.

Делаем из Vim-а конфетку

+1
Ни разу нe привели (дайте ссылку)

Вот ссылка. https://habr.com/en/post/468265/#comment_20687629


Про режимы вы сейчас в первый раз упомянули.

Нет, не в первый. Вот первый — https://habr.com/en/post/468265/#comment_20693261. А так то я целый пост на эту тему сделал когда-то https://habr.com/en/post/339908 .


Тем более это все равно ничего не объясняет, просто «потому что там есть режимы»

Вас же интересует зачем пользоваться вимом? Ответ — для того, чтобы иметь возможность использовать режимы. Зачем использовать режимы это другой вопрос. Тут ответ простой — потому что это удобно. Об этом я тоже говорил.


Режимы там есть, потому что вим вышел когда на компьютерах ни то что мышек не было, а даже стрелочек на клавиатуре (оттуда кстати и перемещение по hjkl)

Ну да. К счастью причина по которой появились режимы не делает модальные редакторы менее удобными.


В современных редакторах можно одновременно и манипулиовать текстом и осуществлять навигацию, находясь при этом в режиме ввода.

В виме тоже можно, только это неудобно. Как и в других редакторах.


Я ожидал увидеть пример каких-то манипуляций с текстом, часто используемых в работе, где виму реально нет равных.

Таких нет. Киллер фича вима — режимы.

Делаем из Vim-а конфетку

0
Ну так я и говорю о том что сейчас есть гораздо более удобные и современные инструменты чем вим. Без адского «learning curve».

И без режимов.


Разумеется я не пытаюсь никого из вимеров отговорить им пользоваться, но мне не понятно зачем новым людям учить этот инструмент.

Для того, чтобы иметь возможность пользоваться режимами.


Тут в комментариях уже несколько раз говорили что вим умеет что-то, что недоступно в других редакторах, но пример никто так и не привел.

Несколько раз привели. Продублирую. В виме есть режимы. В других редакторах их нет.

Делаем из Vim-а конфетку

0
Говорить что в виме тачпад не задеваешь руками, а в остальных редакторах задеваешь — это еще проверить надо.

Ну я думаю skrimafonolog проверил )). Я, кстати, задеваю тачпад независимо от редактора, просто когда пользуешься чем-то вроде вима — тачпад можно отключить.

Делаем из Vim-а конфетку

0
Я лично ввожу :300. Вим у каждого свой, ага :). Правда, число нажатий всё равно не меняется.

Shift,:, 3, 0, 0, Enter — итого на одно нажатие больше, плюс надо зажимать шифт ))

Делаем из Vim-а конфетку

0
Правда количество нажатий клавиш — то же, что и в предыдущем примере.

Ну мы же не про самый короткий, а самый простой )). С моей точки зрения, чем меньше шифтов зажимаешь, тем лучше.

Делаем из Vim-а конфетку

0
Не знаю, как сейчас (сам вимоид), но лет 5 назад студия пыталась много чего поддерживать.

clang много сделал для C++, да. До его появления в студии и того не было. А сейчас вон можно на ходу макросы вычислять.


Дело именно в языке.

Да, именно в языке. С++ жёсткая штука.

Делаем из Vim-а конфетку

0
Если вы не девопс/сисадмин — нафига?

Чтобы работать было удобно.

Делаем из Vim-а конфетку

0
Ну согласитесь, совсем «edge case» аргумент.

Какая разница edge case это или нет? У человека есть проблема, он нашёл какое-то решение. У меня с тачпадами на ноутбуках кстати точно такая же проблема.

Делаем из Vim-а конфетку

+1
Перейти к строчке по её номеру несложно (самый простой вариант — gg300j).

Самый простой — 300gg

Делаем из Vim-а конфетку

0
Вопрос — нафига так мучаться?

Для того, чтобы иметь возможность пользоваться модальным редактором

Делаем из Vim-а конфетку

+1
Чуть шаг в сторону от Джавы — всё становится хуже. Даже для такого старого и популярного языка как C++ выгоды IDE уже не так очевидны.

Для С++ IDE дело сдвинулось с мёртвой точки только тогда, когда появился clang, тут дело как раз в том, что язык старый и IDE для него, как я заметил, раньше больше акцентировались на отладке и кодогенерации.


А чем новее язык, тем проще для него сделать IDE, вот как-то так выходит.

Делаем из Vim-а конфетку

0
Спасибо за подсказку, но и без умных ваших советов — у меня MacBook Pro свежий в околотоповой конфигурации. Дело в расходе аккумулятора при автономной работе.

И получается, что вам лучше долгое время работать в виме, чем какое-то недолгое в идее. Из этого я делаю вывод, что по фичам у Идеи и вима получается плюс минус паритет. А почему когда есть мощный десктоп вы предпочитаете Идею? Что там такого хорошего?

Делаем из Vim-а конфетку

-1
Это касается только массово распространенных языков.

Есть такой момент.


Для тех, что еще не стали широкораспространенными и/или никогда не станут таковыми — IDE или не существуют или они убоги.

Наверное настанет такой момент, когда плагин для IDE будет написать легче, чем плагин для vim, но вроде пока не настал.


Именно поэтому на ноутбуке в дороге я пользуюсь vim, а на мощном десктопе — Jetbrains IDE.

Если вы действительно используете vim на ноутбуке потому, что IDEA слишком прожорливая, то имеет смысл начать копить на новый ноутбук с быстрым процессором и большим количеством оперативной памяти. Хотя вроде из моего опыта следует, что i7 U восьмого поколения и 16 гигабайт оперативной памяти в общем хватает.


Важный вопрос. Какие плагины у вас установлены в Jetbrains IDE?

Делаем из Vim-а конфетку

0
Java как раз неудачный пример, один из немногих.

К джаве нужно добавить ещё C#, C++, Kotlin, Groovy, Scala, TypeScript, возможно JavaScript, не уверен. Подозреваю, что ещё в этот список попадут Go, Ruby и Python.


Под Java уже лет 20 как целенаправленно точит свой софт Jetbrains. А их IDE — одни из лучших на планете.

Ну во-первых не только под Java, а во вторых кроме JetBrains есть ещё и другие конторы )))


Решения есть и для Java, конечно

Конечно есть. И они, увы, хуже того, что есть в IDE.

Делаем из Vim-а конфетку

+1
vim — это база, основа.

Вот именно


На котором уже надстраиваются плагины под конкретную ситуацию, под конкретный язык.

И вот сборка из этих плагинов будет иметь меньше фич, чем IDE, заточенная под конкретный язык. Суровая правда жизни (((

Делаем из Vim-а конфетку

Делаем из Vim-а конфетку

+1

И как с помощью vim сделать рефакторинг по выделению интерфейса из класса?

Делаем из Vim-а конфетку

+1

На каком языке пишете в vim? В случае с типизированными языками банальный рефакторинг с переименованием класса уже проблема, не говоря уже о таком же рефакторинге в языке с динамической типизацией.

Карго-культ в разработке ПО

0
Тестопригодность и хороший код/архитектура понятия параллельные и не обязательно пересекаются.

Тестопригодность — один из признаков качественного кода

Не учите паттерны, учите концепции

+1
ООП говорит: «чувак, я нашел наглядный и понятный способ представления программ».

Вот это конкретика! Вот это точность! Правда многие то же самое имеют в виду под ФП или под любой другой аббревиатурой. А вот фабрика и синглтон это размыто и неточно, да.

Карго-культ в разработке ПО

+2
Никто ж не говорит, что unit-тесты всегда бесполезны и их нельзя применять.

Ну да, в основном говорят, что юнит тесты полезны в 90 процентах случаев.


Это как один из инструментов для повышения качества продукта вполне эффективен, в определенных ситуациях и правильно написанные.

Примерно в 90 процентах случаев этот инструмент эффективен, да.


Естественно, за это нужно платить временем разработчиков/тестеров и другими ресурсами, что неизбежно.

За отсутствие юнит тестов придётся серьёзно заплатить временем тестеров, разработчиков и другими ресурсами, тоже верно.


Для некоторых типов проектов, например, стартапов, это малоприменимо, так как нет столько времени на раскачку, а требования меняются чуть ли не ежедневно, что тянет за собой изменение тестов.

Странно, что вы не переживаете, что изменение требований влечёт за собой изменение документации, её, видимо, тоже лучше не писать. И ещё придётся поправить код методов, поэтому лучше на методы код не делить.

Карго-культ в разработке ПО

+2
Уверен, что клиент бы и первом этапе создания не захотел бы оплачивать 100% покрытие тестами

Я думаю он и выделение логики в отдельные классы не готов оплачивать и разделение приложения на слои тоже.

Карго-культ в разработке ПО

0
Что Вам мешает покрыть тестами этот легаси-код сейчас, если возникла в этом потребность?

На покрытие тестами кода, который не был покрыт тестами в процессе создания придётся потратить раз в 10 больше времени. Плюс его ещё придётся неплохо так отрефакторить.

Только что вышла Java 13. ZGC начал делиться памятью, CDS сам запоминает классы, и другие чудеса техники

+1

Сейчас я так и делаю, но мне кажется, что открывать отдельный файл ради того, чтобы посмотреть на 5 строк json, которые в нём находятся, гораздо мучительнее, чем посмотреть на текст, который находится в том же самом файле, что и тест.

1 There