×Закрыть

Так ли необходима программисту командная строка?

Меня долгое время удивляло такое раритетное явление, как использование командной строки там, где есть графический интерфейс (равно как и его отсутствие где-либо). В этом всегда есть что-то религиозное — то есть противоречащее здравому смыслу.

Да, я слышал все доводы вроде:
«с помощью командной строки можно быстро полазить по системе и все сделать не открывая 10 окошек»
«не люблю долго клацать мышкой»,
«так я имею доступ ко всему компьютеру»
,

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

По сути, команда из командной строки и клик по кнопке в GUI делают одно и то же — запускают программу на выполнение. Это вроде все знают, но напомнить не лишне — это действительно все(!), что делает GUI и командная строка; никакой интеллектуальной или бизнес-логики — все остальное делает программа, и выбор только в этом одном маленьком вопросе, как ее запустить.

Разберем это все немного подробнее

Допустим, мы имеем случай с редко используемой операцией...

Ситуация в случае с КС: ты пытаешься вбить команду, но допускаешь ошибки в синтаксисе, — лезешь в Инет — находишь команду и копируешь ее в КС — получаешь результат.

Ситуация в случае с GUI: ты лазишь по приложению и находишь кнопку (ошибки в назначении правильной кнопки, как правило, не возникает) — получаешь результат.

Заметили разницу: выпадает элемент серфинга по инету и копирования команды, который сам по себе пользы не несет.

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

А что же часто используемые операции? Тут разница еще более ощутима.

После первого использования кнопки в GUI ты запоминаешь, где находятся кнопки, и легко находишь их. А вот запоминание синтаксиса сложных команд идет похуже и загружает мозг, в сущности, мусорной информацией. По удобству это можно сравнить с картой и текстовым описанием местности: представьте себе, сколько слов нужно потратить, чтобы описать, к примеру, Украину с той же информативностью, какую дает один взгляд на карту.

Про 10 окон и как быстрее работать

В случае, когда мы имеем дело со сложными структурами данных, ситуация еще больше усложняется. Человек не просто так открывает 10 окон, иногда ему еще для этого нужно 2, а иногда и три монитора, чтобы одним взглядом обозреть ситуацию. Соответственно, у него нет времени вбивать команды — работы и так хватает, причем работы сложной, которая поглощает все его умственные силы.

Если вы понаблюдаете за работай в автомастерских, то увидите, что там практически не используют такой чудесный инструмент, как разводной ключ. Вместо них у механика под рукой развалы ключей на все существующие гайки. Почему так? Ведь один разводной ключ намного дешевле, занимает меньше места и вообще, казалось бы, одни преимущества. Но все дело в том, что механикам работать надо, а не ключи туда сюда сводить-разводить. И стоимость ключа для профессионала значения не имеет, значение имеет время, которое — деньги. Разводной ключ — это удел любителя на тот случай, если когда-то что-то понадобится. Так же и командная строка.

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

Мне кажется, это вопрос скорее психологический, нежели технический. Потребность самоутвердиться — естественная потребность человека — принимает самые разнообразные формы. Как многие псевдоученые и псевдопреподаватели используют редкие и непонятные без справочника термины там, где можно обойтись простым объяснением человеческим языком (часто бывает, правда, что при этом никакой науки уже не остается, тогда запутанная терминология помогает). Так же многие программисты используют для самоутверждения командную строку, ведь более приятно казаться великим великим гуру черного экрана, чем простым нажимателем кнопок.

Казалось бы, какое мне дело до личных предпочтений того или иного программиста? Но практика показывает, что они тащат за собой на работу свои детские проблемы, там сбиваются в стада и поддерживают традиции, которые замедляют разработку и жрут кучу времени и у них, и у тех, кто их окружает.
Более того, под влияние их стадного инстинкта попадают люди, которые смогли бы сформировать собственную позицию, развить интеллект в сторону других профессиональных устремлений, но вместо этого они зубрят команды давно устаревшей технологии.

В PHP на поводу этого стада пошли даже такие монстры как Zend и Symfony, а ведь необходимость использования командной строки в них вообще нулевая, но стадо хочет строку:)
И это притом, что веб-технологии предполагают, что ты будешь использовать для общения с сервером браузер или на крайняк http-протокол из какого-то приложения. Браузер дает возможность запустить скрипт на сервере, а все остальное последний сделает сам (см.выше).

Закончу вечно зеленой бритвой Оккама: «Не следует множить сущее без необходимости»


ЗЫ: Лично у меня есть опыт работы и с командной строкой, и без нее. Считаю, что использование командной строки иногда необходимо сисадминам, но совершенно не нужно и даже вредно при нормальном процесе разработки ПО.

LinkedIn

Лучшие комментарии пропустить

Вот уж действительно статейка... Столько эмоциональных слов, а полезного ничего.

Статью можно сократить до объема твита: «Командная строка не нужна некоторым PHP разработчикам(включая автора), а так же тем, кто не умеет эффективно ею пользоваться».

Фу, какой примитивный вброс. Автор похоже видел только виндовую «командную строку» и про современные интерпретаторы знает меньше, чем ничего. Как с помощью GUI реализовать повторение комманд, комбинирование, перенаправление ввода/вывода? Как получить историю? Как работать с системами, в которых графический интерфейс в принципе отсутствует (а их миллион)? Про автоматизацию и скриптинг я вообще молчу. Короче незачет.


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

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

Черт, это что — на полном серьезе?

Вы, уважаемый, такой психоаналитик как и, видимо, программист. Хреновый.

@Макс Ищенко, коли вже можна буде мінусувати? автори ж хочуть і створюють топіки зла. а зла і не видно.

Вот и выросло поколение девелоперов, оторванных от командной строки и unix-way...

“О бідна Данія, кінець всім сподіванням......” © Лесь.

352 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

поддерживаю в топку консоль, я как то с гитом с консоли работала — в итоге заработала на командную строку стойкую аллергию )))

чем? Вполне удобно как раз гитом в консоли пользоваться.

а вызвать gitk и «git citool» из консоли не пробывали ?

«команда из командной строки и клик по кнопке в GUI делают одно и то же — запускают программу на выполнение. Это вроде все знают, но напомнить не лишне — это действительно все(!), что делает GUI и командная строка; никакой интеллектуальной или бизнес-логики — все остальное делает программа, и выбор только в этом одном маленьком вопросе, как ее запустить.» — я повністю згодний із автором, що запускати консоль заради того, щоб написати notepad.exe, не варто. Але я морально неготовий виклацувати мишкою дії типу find -name \*.[ch] -executable -exec chmod -x ’{}’ \; або dd if=/dev/zero of=file.bin seek=20 bs=1 count=3, або навіть банальний bunzip2 *.bz2 . Командний рядок зручний тим, що бізнес-логіка конфігурується на льоту (а не намертво залита в програмі), а unix-way дозволяє будувати з простих виразів досить нетривіальні дії, які в GUI потребували б власної утиліти. Командний рядок для мене — проміжна ланка між елементарними діями і важковаговим скриптуванням, це дуже легке скриптування на льоту (чого адепти GUI практично позбавлені, клавіатурні/мишині макроси лише тінь цієї потужності).

«не глупые люди, которые к тому же в своей повседневной жизни получают прямое опровержение этих утверждений.» — коли я бачу, що якісь дії в CLI забирають більше сил, ніж перемикання на мишку і виконання мишкою, я стараюсь використовувати легший спосіб (да-да, попри частку фанатизму, тут все вирішується чесним змаганням в ергономіці і зручності), з тим застереженням, що для мене давно легше набрати ls/cd/vim, ніж відриватись від клавіатури, втрачати фокус уваги і довго блукати очима по розсипу непотрібної і кричущої інформації на екрані.

«элемент серфинга по инету и копирования команды, который сам по себе пользы не несет.» — man/info, а ширше кажучи, документація хорошого командного рядка має бути доступна в самому ж командному рядку. Автор гризе кактус і здивовано заявляє, що він гіркий і колючий.

«А что же часто используемые операции? Тут разница еще более ощутима.» — скажіть, будь ласка, як багато графічних програм підтримують автоматизацію дій, в них є макроси, якими активно користуєтесь, чи можна на шорткати прив’язати нетривіальну послідовність дій і т. д.? В консолі ж для мене поступово відбувається природний відбір (так, вона достатньо гнучка для цього): якщо я помічаю, що часто використовую якусь послідовність команд, вона одразу стає три-чотирилітерним скриптом/функцією/аліасом.

«запоминание синтаксиса сложных команд идет похуже и загружает мозг» — конкретно у мене хороша пам’ять і повільне сприйняття, для мене простіше один раз запам’ятати, ніж дратуватись від щоденного зіткнення з графічним шумом (тим самим сміттям!) на екрані.

«В случае, когда мы имеем дело со сложными структурами данных, ситуация еще больше усложняется.» — один із небагатьох пунктів, із яким я можу погодитись. Маніпуляції з текстом дійсно потребують більшої осмисленості і інструмент для складних задач має бути хорошим і пристосованим (і тому я таки користуюсь qgit, а не git log). Але знов-таки, все залежить від специфіки задачі.

«разводной ключ. Вместо них у механика под рукой развалы ключей на все существующие гайки.» — ви абсолютно праві. Навіщо мені ці всі жахливі комбайни типу VS або Eclipse, або той самий Total Commander, якщо можна просто користуватись купою хороших, перевірених часом unix-утиліт/vim/простішим IDE?! Мої прості ключі — це unix-утиліти та внутрішнє скриптування програм.

«Потребность самоутвердиться» — щось у цьому є. Але непотрібно вважати, що річ лише в самоствердженні. Науковець не буде говорити «простою, людською» мовою, він буде використовувати «таємничі» терміни своєї галузі — бо вони передають суть і є правильним інструментом для його роботи. Скільки в цьому самоствердження?!

Щодо GUI. Я за свободу вибору і за потрібні інструменти на потрібних місцях. І саме тому я не уявляю, на що б проміняв bash і я проти того, щоб мене примушували робити все через один інтерфейс. Ідеальних інтерфейсів не буває і GUI точно не ідеальний інтерфейс.

І взагалі, давайте не фанатіти від інтерфейсів, є багато інших цікавих речей :)

Одразу згадав офігєнну пропрієтарну графічну утіліту на проекті, де треба в Гуішному віконечку проставити з десяток голочок для того, щоб конвертнути файл, а потім ще й кожний конвертовуваний файл відкривати по черзі через файл/опен діалог перед тим як натиснути «конверт»... І коли приходить чергова сотня файлів, то це сприймається як кара небесна...

--------

Шановні борці з командним рядком якось забули, що в ході своєї роботи вони [b]переважно і пишуть команди[/b] (оператори, інструкції, стейтменти) — на С, С++, Джаві, ПХП ітд... навіть якщо і ніколи не заглядали в командний рядок і не писали *.бат файлів.

Чи ні? Може вже всі вони під час програмування малюють блоксхеми в візуальному редакторі (цікаво якому?) і тягнуть від гарних кольорових іконочок стрілочки до візуального ГУІ з намальованими кнопочками?

Ану давайте заведемо ще одну холіворну темку про те, що програмувати (писати алгоритми) в текстовому вигляді "

совершенно не нужно и даже вредно при нормальном процесе разработки ПО.

"...

Тільки не забудьте продумати спосіб як мерджити такі от візуальні алгоритми між бранчами :)

Одразу згадав офігєнну пропрієтарну графічну утіліту на проекті, де треба в Гуішному віконечку проставити з десяток голочок

Можна використати, наприклад, Test Complete від Smart Bear Software.

Тільки не забудьте продумати спосіб як мерджити такі от візуальні алгоритми між бранчами :)

Наприклад в Rhapsody (середовище для розробки на основі UML) є можливість прикрутити до системи котролю версій утілітку яка мержить UML діаграми. В принципі цє є варіант того що ви сказали.

Можна використати, наприклад, Test Complete від Smart Bear Software.
Так, можна купити цю чудову тулзу, розібратися і автоматизувати... а ще (якщо буде час на такий таск) можна написати свій конвертер замість готового і т.ін. бо наскільки життя було б легше, якби автори згаданої мною тулзи передбачили аргументи командного рядка...
я не заперечую що ГУІ добре, але з тим, що командний рядок шкідливий — категорично не погоджуюся.
Наприклад в Rhapsody (середовище для розробки на основі UML) є можливість прикрутити до системи котролю версій утілітку яка мержить UML діаграми. В принципі цє є варіант того що ви сказали.

Дякую, якщо буде нагода, то неодмінно ознайомлюся, бо ж справді цікаво буде побачити Diff для ЮМЛ діаграм, і як не просто мерджиться текст в нерухомих кубіках, а як мерджиться граф, коли додаються нові гілки, видалаються старі і т.д...
---
а ще, від шановних Колумністів дуже цікаво було б побачити огляд таких тулзів з прінтскрінами на Девелоперс.орг.юа — ато, натомість, бачу тут все про 23річних сеньйорів базарять

Запускать скрипт через браузер — фу, какая гадость :) Скажем так, я использую два HD монитора и 12 рабочих столов в Compiz — на которых, окромя браузеров, Eclipse — для Android project лучше не найдешь, Emacs, RDC клиентов и т.п. — крутятся как минимум 5 открытых консолей. Причем целые спарки рабочих столов отведены именно для терминалов :) Minicom, который фетчит логи с COM порта, adb logcat’ы, adb shell’ы — все, что нужно запускать с маленького разрабатываемого мобильного устройства :) Или просто дома, зайти на свой рутованный HTC — и покопаться в нем — не занимаясь глупыми поисками — или, тем более, написанием GUI для выполнения тех или иных действий. Я даже не говорю про автоматизацию.

посоветуй как запустить makefile без КС...

я пробовал как-то, это жестокое садомазо

Да, но тем не менее :)

Но оснавная идея статьи — ГУИ мега удобен, а командная строка должна умереть. Так что ваш пример мимо кассы.

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

Я покупал коммерческие программы для командной строки, это подойдёт? Я купил Intel® C/C++ Compiler PE, так же купил WinRAR, в котором я пользуюсь только command line.

WinRAR продаётся по $21.

Intel C/C++ Compiler PE по $599.

У меня командная строка и обмен данными в виде XML работает в веб-сервисах. Командная строка обычно (как и писал ранее, и не только я) активно используется для вызова регулярно повторяющихся по крону (через равные интервалы времени) процедур, аналогично регулярной проверке/отсылке эл. почты, сверке данных (DNS etc.) с удаленных сервисов и т.д.

И, кстати, любая GUI-софтина, работающая с документами в виндоус поддерживает командную строку, хотя бы как аргумент для «своих» файлов. А ещё у многих из них есть дополнительные флаги ком. строки.

Ну и программы php, mysql и Apache тоже являются в т.ч. и коммерческими продуктами у которых ого сколько опций ком. строки.

У меня командная строка и обмен данными в виде XML работает в веб-сервисах. Командная строка обычно (как и писал ранее, и не только я) активно используется для вызова регулярно повторяющихся по крону (через равные интервалы времени) процедур, аналогично регулярной проверке/отсылке эл. почты, сверке данных (DNS etc.) с удаленных сервисов и т.д.

Насколько я понимаю, речь идет о командной строке в системе «оператор — программа», в Вашем примере «программа — программа» .

По-моему вопрос был не от вас, и я отвечаю ровно на него. Итоговые программы (порталы, сайты и т.д.) — коммерческие, с необходимостью функционала, созданного «для командной строки». Т.е. без упомянутого мной функционала полезность и ценность этих продуктов в итоге резко падает.

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

ну вот IRC и клиенты под нее, в том числе коммерческие, вполне себе активно используют коммандую строку :)

поле урла в браузерах — однозначно коммандная строка

> но стадо хочет строку:)

Я нечасто даю різкі оцінки, але автор або має мало досвіду, або людина недалека. КС набагато швидша для речей, які використовуєш постійно і відповідно не треба «лазити» по інету. ГУЙ — для відповідних речей (браузер), або ті, що рідко використовуєш. Я наприклад нечасто використовую БД і інколи доступаюсь через pgadmin, деколи через psql а DBA/DBD — 70% через psql. Ціна того, що не памятаєш чогось однакова — man, F1, google. Мабуть на лінуксі і в гуглі одні дураки сидять, 70% часу в КС.

Стаття про програмістів, а не про адмінів, якщо вони 70% часу сидять у КС то коли вони працюють? :). Про переваги та недоліки лінукса вінди чи мака , говорити недоречно фінансові показники самі за себе говорять:)

ви бачили той vim або emacs — то є командна строка або ні ?

Я говорив саме про програмістів (c++/python, про джавних не знаю), а з адмінами і так ясно. А у вашій конторі вони стоячи працюють? Фінаснові показники тут не мають значення, компи купують і використовують звичайні люди, КС їм не треба. Доречі, Windows 8 server можна буде запустити в command-line only.
«Windows Server 8 will have three modes. Microsoft has added to the two existing modes—the traditional GUI mode, with the full GUI stack and shell, and Server Core, that offers only a command-line».
Я б сказав, що розділ проходить по прикладній задачі. Якщо це backend, тоді КС 100% виграш, якщо UI app — тоді миш ваш брат (брр...)

Вообще-то уже выпущенный и продаваемый Windows Server 2008 R2 как раз и имеет упомянутые Вами редакции

На серверах теж GUI ставите?

интересно а использование гуи с коммандной строкой (vim\emacs) является использованием гуи или кс ?

Не читал, но осуждаю :)

iTerm + emacs это наше все.

а по мне vim хорош, но товарищ не поймет :)

Я когда разрабатывал под Линукс постоянно пользовался консолью. Так было легче и быстрей, чем через ГУИ это всё делать. К слову, это была разработка на Qt.
Старший разработчик на J2EE проекте только консолью и пользовался для сборки проекта и развёртывания его на сервере заказчика. Может и есть утилиты с графическим интерефейсом, но через консоль всё быстрее.
При работе с Windows/Eclipse/Salesforce я консолью не пользуюсь — у меня вся разработка в IDE и время от времени я лажу через браузер посмотреть чего я навоял в UI.

Так что всё зависит от платформы/проекта/имногогодругого.

Почти триста каментов. Славно набросил. Так держать!

Пожалуй ты прав. Ждем статью с темой «Так ли необходимы компиляторы».

Здесь не очем спорить. Каждый имеет право использовать то что считает удобным и уместным для себя. А выводы типа «консоль не нужна и даже вредна» скорее характеризуют самого автора. Я вообще по этому поводу не парюсь — стараюсь думать в первую очередь о задаче. Но поверьте жать изо дня в день одну и туже тупую последовательность в GUI тоже очень задирает (а реально приходится). Согласен у GUI гораздо ниже порог входа. Зато через командную строку очень просто автоматизировать действия. И полученный скрипт, к стати, можно просто положить в SVN, а не писать длинные и красивые инструкции с картинками что и где жать.

У консоли тоже могут оказаться подчас свои преимущества. А вообще, все определяется спецификой задачи. Логично, что если приложение будет запускаться исключительно из консоли, то тут не помогут никакие графические интерфейсы. Так что по поводу «мусора» в голове... не согласен ни разу.

А зачем специально делать приложение которое завпускается исключительно из консоли? Понятно что создание хорошего ГУИ это трудоемкая задача, и проще оставить все в консоли, но если есть задача сделать приложение дружественным для людей (иногда это равнозначно комерческому успеху) то ГУИ это необходимость.

А зачем специально делать приложение которое завпускается исключительно из консоли?
Затем, что это может более полно отвечать поставленной задаче.

Например, софт в исходных кодах на C/C++ может отлично завестись и под *nix и под Windows, а уже создание нативных GUI под возможные оболочки Линкуса и под винду могут стоить разработчикам неоправданно дорого. Особенно если проекты хотя бы частично бесплатные.

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

а если есть задача автоматизировать что-то для себя? Сам я обойдусь без траты кучи времени на ГУИ, мне лишь бы побыстрее закончить задачу.

Если для себя то вопросов нет, а если для промышленного использования то лучше потратить болше времени и написать нормально. Код читается чаще чем пишется и с разрастанием проектов и задач такие костыли боком вылазят.

Я как-то проще отношусь ко всему. Есть приложения которые нужно использовать с гуи (броузер, почтовый клиент, файл менеджер). Но и многие приложения работают строго только из консоли. Например, я по работе работаю большую часть в редакторе и консоли. Почему? Потому что я пишу на скриптовом языке, который отлаживаю, тестирую, запускаю через консоль.

Не знаю не знаю, но что-то не с первого прыжка по документации можно завести Django или RoR на Windows :)

А вот к примеру XAMPP, можно завести практически сразу из инстаятора, и на него можно также спокойно и сразу установить многие из СМС тоже через инсталятор, это я не к тому что Django плохой, но отсутствие удобного интерфейса это скорее его недостаток чем достоинство.

Вечный вопрос «кс или гуй» не имеет отношения к профессии, как это озвучено в топике. За предпочтение отвечают личностные характеристики человека, половина человечества предпочитает полную детерминированность поведения устройства ввода (клава), вторая половина вполне комфортно чувствует себя с устройствами ввода, требующими обратной связи (мышь).

Мне не нравится необходимость глазами следить за мышью и смотреть попал ли я в кнопку меню или нет, это — лишние полсекунды-секунда на каждой операции. За год я прибавляю лишний день к своему отпуску, используя КС.

Под впечатлением прочитанной статьи сидел и думал, чем в виндовом гуе заменить ipconfig и ping, чтобы было быстрее удобнее, чем в КС. Решения не нашел. Да альтернатива собственно и не нужна ибо результата в КС достигаешь легко и просто: запускаешь ярлык cmd с рабочего стола, за секунду пишешь команду, жмешь Enter — и все.

1. Знание коммандной строки позволяет делать скрипты.
2. Комманды одни и те же на многих операционных системах.
3. Ресурсы системы не тратятся на последовательный запуск десятков интерфейсов, где в этом нет необходимости.

4. Разница такая же как фильмы смотреть и книжки читать.

Подскажите, какой гуишной утилитой под Windows можно делать svn sync? В Visual SVN Server не нашёл =)

Молодец, понял правильно:)

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

За такие статьи нужно процент от рекламы на сайте платить.

Ситуация в случае с КС: ты пытаешься вбить команду, но допускаешь ошибки в синтаксисе, — лезешь в Инет — находишь команду и копируешь ее в КС — получаешь результат.

Причем, хочу заметить лезет в нет не через браузер командной строки :) А через графический интерфейс

Хотя бывают ситуации когда именно командная строка экономит кучу времени. Особенно если надо что-то массово распаковать, переименовать, переместить и все там поменять. Причем делать это регулярно :)

Если настроить себе регулярные вещи как функции либо отдельные скрипты, то время экономится в разы. Ну и опять же вопрос кому как удобно. Можно в холодильнике продукты хранить а можно на балконе тапочки в нем.

Общий ответ для многчисленных коментаторов на тему как выполнить какую-либо хитрую команду из GUI: Большая красная кнопка посередине черного экрана, на которой написана команда. Вы ее нажимаете и она запускает програму с нужными параметрами, слева можно разместиь желтую кнопку с другими параметрами:). Похоже для многих это тайное знание будет сюрпризом, но те буквы, которые вы вводите в командную строку сами по себе ничего не делают. Они имеют смысл лишь в том случае, если кто-то уже написал программу, которая их воспринимает и вложил в нее логику. И вопрос о том, как удобней ее запускать, к этой логике не имеет никакого отношения. Хорошие консольные программы со временем обрастают GUI, для удобства пользования — Tortoise, к примеру.

Ок, допустим, у тебя есть большая красная кнопка, которая делает «diff file1.txt file2.txt».

Сколько времени тебе понадобится, чтобы изменить поведение на «diff <(sort file1.txt) <(sort file2.txt)» ? (отсортировать файлы до сравнения)

А на «diff file1.txt <(ssh user@host grep something file2.txt)»? (сравнить со строками из файла file2.txt на хосте host, содержащими something)

Сколько таких изменений будет сделано до того, как автор забъет на идею красной кнопки окончательно?

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

Хорошие консольные программы со временем обрастают GUI, для удобства пользования — Tortoise, к примеру.

Дома пишу небольшие джаваскрипты, лежат они в меркуриале на битбакете. Пользуюсь консольным меркуриалом (дома мак), удобно.
На работе понадобилось использовать один виджет. Попробовал вытащить тортосомХаГе.:
1) Понадобилось время понять что такое «Synchronize»
2) Потом найти в большом меню кнопочку обновить

3) И все это клацая как левой так и правой кнопками мыши (вызывать какие-то меню).

Вам уже писали, но я повторю:

Вы какую консоль имеете ввиду? Виндовую? Или нормальную?

Тортос НЕ лучше чем консольные варианты в винде, просто консоль в винде хуже чем ГУИшные варианты.

И что мешает написать батник с заданными параметрами и сделать к нему ярлык на рабочий стол (если вы висите под Виндой)? Вот вам и будет ваша универсальная кнопка.

Но — всего одна-две задачи, которые будут «много жрать» даже в фоне, и которым GUI нафиг не сдался (про рутинно-конвеерные задачи вам тут немало написали, в т.ч. и я) — фактически аналоги демонам или службам (если мы про винду опять-таки), и что, вы их изначально будете разрабатывать с позиции «сделать GUI», или сделаете как консольную, или (что вернее всего) — вообще поначалу без интерфейса, только с CLI?

Службы Винды как-то сами по себе GUI не имеют. Под *nix- то же самое. Итак, задача вам — написать службу на php. Начнете с GUI и будете костерить разработчиков фреймворков за то, что они предусмотрели Console Appplication?

Вы ее нажимаете и она запускает програму с нужными параметрами

А параметры нужные откуда берутся? Большая кнопка «сделать зашибись»? ну нет такого гуя на замену хитрых команд.

такое ощущение что вы «плаваете» в элементарных вещах или только начали заниматься программированием

Статья хорошо подняла настроение.
Сейчас ещё посмотрю комменты, чтобы оно поднялось ещё выше.

В предвкушении вопросов автору как через GUI грепать логи и как будет выглядеть GUI-обертка например для awk =)

Есть подозрение, что кнопка «Pro mode» открывает КС.

206 комментариев — вброс удался? :)

Реально порадовали :) Советую опубликовать это на ЛОР. Там заценят :) Будет у анонимусов всех мастей праздник ... Может автору почетное звание и медаль дадут.

Если предположить «немаловероятное» и автор не тролль и это не холивар.

Я редко, но часто пользуюсь КС. Причин несколько — 1)Так написано в хелпе Windows 2)Некоторых GUI аналогов не существует 3)Это реально удобнее и безопаснее.

Более того, я думал написать GUI для наиболее часто используемых мной команд и вот что выяснилось — понятный и безопасный GUI в некоторых случаях просто нереализуем — это будет чудовище с десятком окон и сотней чикбоксов вместо одной удобной строки.

Ещё мне кажется что интерфейс командной строки это знаковое, переломное изобретение в системе человек-машина и он чем то напоминает человеческую речь то есть исключает неопределённость которой в GUI зачастую более чем. Примеров качественного GUI не так уж много.

И, вуа-ля, оказывается автор поднял интересную, на мой взгляд, проблему.

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

Просто Вы недостаточно хорошо знаете возможности и последовательность действий для выполнения этих процедур. Все это разжёвано в литературе M$. Ваша ситуация странна для того, кто изначально администрировал Windows и нормальна со стороны тех, кто, работая с *никсом, вынужден кое-что иногда делать в Windows. Да, вышедший относительно не так давно PowerShell имеет много возможностей, недоступных через традиционный командный интерпретатор, но назначение прав и атрибутов папок/файлов — это уж явно просто некомпетентность

Я редко, но часто пользуюсь КС.

Это чтобы удовлетворить и тех и других?

Нет, это именно так. Я вначале подумал, что редко использую КС, потом прикинул статистику и оказалось, что на самом деле довольно часто, просто я не очень обращаю на это внимание и получается, что всё-таки редко. Понятно?

не очень обращаю на это внимание и получается, что всё-таки редко. Понятно?

Нет.

Если не думать о том как часто я использую КС то складывается впечатление, что редко, но если сделать выборку по работе с ЭВМ для решения задач для которых могут быть использованы КС или ГИП, как альтернатива КС, то получается, что часто.

Я вначале подумал, что редко использую КС, потом прикинул статистику и оказалось, что на самом деле довольно часто, просто я не очень обращаю на это внимание и получается, что всё-таки редко. Понятно?

Fuzzy logic?

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

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

вам нужно сделать билд для 3 платформ — windows, linux, osх (32 и 64 бита) — итого 6 умножаем на количестов версий самой майки ( котрые используются юзерами ) пускай 4 — получаем 24. ч-з GUI можно запахаться + что-нибудь пропустить.

Автор опускает очень важную деталь, а именно о какой ОС идет речь. Если говорить о Windows, то можно только целиком согласиться с автором. Окружение Windows объектно-ориентировано и целиком доступно из GUI. С *nix все совершенно по-другому. программы очень сильно заточены на выполнение в командной строке: переменные окружения, ключи, алиасы — все это реально используется повсеместно. Если разработка касается *nix, то знание командной строки и ее особенностей очень поможет пользователям.

Вдобавок автор забыл, что у всех утилит командной строки есть минимальная документация о синтаксисе, в nix* вообще централизованная база подробной документации.

Окружение Windows объектно-ориентировано и целиком доступно из GUI.

Нет. Тогда не было бы регедит, команды net, ipconfig, и прочих, и прочих.

Всмысле? regedit доступен из графики, настройка сети тоже предоставлена в GUI. То что вы перечислили — это дублирующие утилиты для командной строки. Да, в некоторых случаях ими удобно пользоватся. В том же *nix некоторые инструменты вовсе не имеют аналогов в виде GUI.

Как это сделать из GUI?:
1) ipconfig /flushdns
2) ipconfig /renew
3) shutdown \\RemoteComputerName

4) route — добавить persistent route.

1+2 — Свойства соединения — Исправить;
3 — www.radmin.ru/...ucts/ipscanner , причем с выбором из списка, чтоб не вспоминать имя компьютера;

4 — через оснастку Удаленный доступ и маршрутизация (RRAS).

Это команды администрирования и никак не связаны с предметом разговора.

Довелось програмувати під Віндоус (С++, трохи .NET) і чомусь навіть настільки потужні речі, як Visual Studio, не рятували мене від щоденної рутини в cmd.exe (mklink, купа доморощених батників, утиліти .NET/Boo і т.п.).

А взагалі інтерфейс — це тільки інтерфейс, і якщо я не уявляю, на що проміняв би bash, то до бази даних по ліні підключаюсь через phpmyadmin, всьому свої засоби і я за свободу вибору, яку Windows не дає.

а вы, в свою очередь, упускаете такое изобретение, как PowerShell

Холивар. Зачем на кухне ножи, если есть электрическая овощерезка? Ножом можно выполнить более широкий спектр действий — можно порезать овощи, а можно отрезать бошку. Попробуйте отрезать бошку овощерезкой. Epic fail !!!

С другой стороны производительность овощерезки намного выше, чем производительность ножа.

Автор занят исключительно шинкованием капусты. Посему делает вывод — ножи нужны только стаду.

Як на мене холівар і тролінг розводять всі хто постить коментарі а не Автор. Автор виразив свою думку. Всі решта (перечитав добре половину коментарів) з піною у рота доказують як же їм добре з живется командною стрічкою і те що GUI «отстой».

Якщо cmd/emacs/vim рулить. Навіщо вам ікси на Linux/Unix? Чому ви почту не читаєте з командної стрічки? Чому в інтернеті не лазите з неї ж?

Кому ви це доказуєте? Ви хочете переконати автора, чи себе? Де обгрунтований підхід до порівняння — коли ви потратили стільки непредвзятого часу на вивчення обох можливостей.

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

Підсумовуючи. Проблема не в тому що ліпше. Проблема в тому чи люди періодично оглядаються (готові оглядатись) навколо і шукають інші варіанти як певні операції можна робити ефективніше.

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

Снизу есть куча примеров, когда ком. строка предпочтительнее. Ответов аффтара — не видать. А вот провокация в тексте присутствует при нулевой полезности. Но аффтар не тролит и не холиварит, что за глупости, ага.

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

Снизу есть куча примеров, когда ком. строка предпочтительнее. Ответов аффтара — не видать. А вот провокация в тексте присутствует при нулевой полезности. Но аффтар не тролит и не холиварит, что за глупости, ага.

аффтару работать надо — за деньги, а не днями на форумах сидеть:)

Это конечно оправдывает написание длинного, провокационного и по сути глупого вброса.

Вы слишком радикальны.

Якщо cmd/emacs/vim рулить.

Рулит, конечно.

Навіщо вам ікси на Linux/Unix? Чому ви почту не читаєте з командної стрічки? Чому в інтернеті не лазите з неї ж?

Потому что графический броузер тоже рулит.

КС удобнее для некоторых задач, в частности многих задач разработчика, но не всех. Например броузер, очевидно, удобне графический. (Но в графическом FF ставлю плагин Pentadactyl и управляю многими действиями (обратите внимание, не всеми) с клавиатуры клавишами, аналогичными vim).

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

Про ваш комментарий можно сказать то же самое :) “Как-будто увидели фразу про КС, и перестали вникать в факты, решив, что люди использующие КС презирают любые формы GUI”

Так трохи радикальний.

Просто всі хто наводить приклади чому командна стрічка рулить уникають прикладів коли GUI рулить. Всі стараються навести очевидні факти коли відповідних альтернатив немає (або вони їх не знають).

Я схиляюсь до думки що автор хотів виразити як сильно його замучили люди які стараются робити все що можна в командній стрічці і на любі вікна кажуть своє «фі».

Я схиляюсь до думки що автор хотів виразити як сильно його замучили люди які стараются робити все що можна в командній стрічці і на любі вікна кажуть своє «фі».

Нет же, он написал:

Считаю, что использование командной строки [..] совершенно не нужно и даже вредно при нормальном процесе разработки ПО.

Автор видимо настолько «дивелопер», что явно опускает единственно нормальный способ дебажить яваскрипт — консоль.
Автор видимо настолько «одмин», что держит сервера на винде и удивляется «why so slow».

Автор видимо настолько крут, что на месте директора — я бы его уволил за подобные спичи.

Как там Лебедев сказал: «Как только закрытое общество начинает думать, что оно закрытое и элитарное, оно тут же накрывается медным тазом.» (Зацензорено)

Вы даже не представляете, насколько больше денег приносят некоторым людям сервера на винде чем сервера на юниксе, настолько больше что от поддержки юниксовых они отказались из за незначительности:)

Га-га, myspace был на винде и что? А фейсбук на чем, и что?

Не по тем параметрам сравниваешь

лол, а по чем? По зарплате — не смешите, ей богу

По идее, целевой аудитории, и качеству, эти параметры выбили Фейсбук в лидеры, а отнюдь не используемый сервер.

Хотя... Возможно я не правильно понял Ваше высказвание

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

Майспейс был тормозным, люди ушли в фейсбук и другие сети, которые давали бОльшую производительность.

Винда — это для ентерпрайза и прочего говна. Highload — это не про нее. И не надо вспоминать про облачные технологии от мелкомягких — это все буллшит и сосет у ближайших конкурентов.

Я практически полностью с Вами согласен и прекрасно осознаю важность unix сервера.
Просто считаю что успех Фейсбука в самую последнюю очередь обеспечен их серверами, точно так же как и завал майспейса в последнюю очередь зависел от Мелкомягкого сервера.

Основная моя работа как раз энтерпрайз(ASP.NET) и я неплохо осознаю достоинства и недостатки того же IISa. Да для хайлоад — это не вариант, но и IIS имеет свою нишу, эта ниша далеко как не мала

Да, но говорить, что эта ниша приносит гораздо больше денег, чем другие — несколько неверно, что и делает автор

Винда — это для ентерпрайза и прочего говна.

больше денег приносят некоторым людям сервера на винде чем сервера на юниксе

Энтерпрайз — больше денег. Всё сходится. О чём спор?

Простите вас давно из ЛОРа выписали? Хотя похоже что вы сами сбежали. Не те сейчас резервации...

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

СтекОверфлоу?

Суть в том что мир не чернобелый. Он коричневый! и то не равномерно.

Ув. автор, вы когда нибудь поддерживали сервер под виндой? А удаленный? А удаленный на пол мира? Вы осознаете разницу при работе с Виндоус сервером по RDP где нибудь в Америке с каналом 512kB, и аналогичным сервером под BSD и работа с ним по SSH?

Вы даже не представляете, насколько больше денег приносят некоторым людям сервера на винде чем сервера на юниксе
 Не могли бы вы пояснить финансовую выгоду от использования платной Винды, по сравнению с бесплатным UNIX(Linux, BSD etc)? ASP.NET в пример не ставить и так ясно, но ПХП? Рельсы? Питон?

ну почему не представляем — мы в курсе про откаты, в т.ч. на покупке ПО. Только вот неясно, чем тут гордиться?

Автор статьи написал х**ню. Порицаю.

Матиться нехорошо, но по сути господин Treskin прав.

Сначала хотел завязать спор. Потом понял, что речь про неокрепших специалистов и тех кто не пользуется системами контроля версий, вроде git, не нужно вытворять чудеса с файлами и «curl» для них «что-то, наверное, про кальян».

Мир вам, милые виндузятники :) .

Вот, собственно, опровержение вашей статьи, подтвержденное практикой:

www.developers.org.ua/...-stroka/#143017

Еще раз перечитал, напомнило:

Янукович: Киев лучше,чем Москва!
Путин: Чем лучше?

Янукович: Чем Москва.

Путин: У России авиастроение лучше, чем на украине
Янукович: Чем лучше?

Путин: Чем на украине

Астрологи объявили статью холиваром. Количество комментариев удваивается.

С «нетерпением» ждем разоблачающих постов автора на темы:
— почему до сих пор используются emacs/vim, когда есть такой хороший eclipse;
— как можно использовать древние UNIX, когда есть такой новый windows;

— ну и конечно классификация самоутверждений и заблуждений программистов не программирующих на PHP.

Черт, меня хватило только на полстатьи и возникло большое желание, чтобы автора выпили из колумнистов.

Так с пеной у рта доказывать, что удобно, а что нет — это еще надо уметь.

Автор — вы вообще про какую консоль? Виндовую? Unix консоль?

Если речь про виндовую — то еще можно согласиться и то с множеством оговорок. Но если про Linux, то вброс просто величайший, такого накиданного говнеца на вентилятор я давно не видел.

Вот простой еще пример — пишу я достаточно крупный проект... Одно из требований — производительность, при той же просторе разработки. Поэтому на скриптовом языке, но оптимизируя все и вся.

Не подскажешь какую кнопочку мне нажать, чтобы проверить действительно ли в этом языку сдвиг влево быстрее умножения на степень двойки? Где эта волшебная кнопка?

_Программистам_ жизненно необходима.

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

Когда на заре изучения похапе, регекспов или еще чего-то там, я просто набираю в открытой консоле $ php -r ’..., другие создают файлик, кормят его апачю, и меняя текст усердно давят F5 в браузере. И это реальные истории.

А когда разрабатываешь сервер и в процессе разработки общаешься с ним с помощью telnet. Как без этого вообще разрабатывать?

ИМХО, автор просто быдлокодер и ему консоль не нужна.

Разводной ключ это инструмент сантехника, а не автомеханника. Потому, что разводной ключ ТРУБНЫЙ, а не ГАЕЧНЫЙ. Как тебя к компу пускать, если ты ключи не осилил?

что-то вы путаете, у меня есть вот такой разводной ключ www.auto-tools.ru/...?goods_id=1657 размеры 0-24мм не для сантехники. Кстати и ссылка про автоинструменты. Так что поставьте себе вопрос про комп.

Это в любом случае трубный ключ. В сантехнике применяются диаметры от 12мм. кстати. Более того — наивно предполагать, что в автомобиле есть одни метрические гаечки...

Как так получилось что сантехнический ключ попал на сайт гордых автолюбителей?

Ну у меня в машине лежит вот такой ключик:

www.ridgetool.ru/...9f4d5528f5f.jpg

Это оберег.

Как раз это — гаечный ключ. Трубный отличается тем, что он зажимает деталь и, в отличие от гаечного, с его помощью можно проворачивать детали не имеющие специальные поверхности под ключ (трубы).

В общем, осильте ключи для начала, а потом сами себя к компу допускайте ;-)

Спасибо что напомнили. Этот ключ который вы называете трубным, разводным, а еще его так же называют газовым. Нифига не разводной — он называется — ключ Бако и имеет такое же отношение к разводным ключам как и плоскогубцы.

Перестаньте нести самозабвенную чушь. Политехнический БЭС в качестве авторитетного источника Вас устроит?

dic.academic.ru/...olytechnic/1686 — на картинке среди гаечных в позиции е изображен гаечный ключ «с регулируемым размером зева (разводной)».

Тот ключ, который я «называю трубным», он является разновидностью разводного и по имени правильнее его называть ключом Йохана :) Как бы Вам понятно для дилетанта.... О! Вы про ООП слышали? Разводной — суперкласс, а гаечный разводной (с регулируемым зевом — en.wikipedia.org/...ustable_spanner ) и газовый/трубный ( en.wikipedia.org/.../Plumber_wrench ) - подклассы, потомки разводного ключа.

Все они разводные. Кроме разницы в принципе зажима детали (гаечному нужна «поверхность под ключ») они отличаются тем, что у гаечного червячный механизм изменения размера зева, а у газовых — винтовой. Винтовой позволяет менять в более широких пределах.

Что называется ключом Бако, Вам в качестве домашнего задания. А как правильно называются те ключи, о которых говорил я, доверьтесь ГОСТам: yandex.ua/...d=604619&lr=143

P.S. Иногда лучше вовремя остановиться. Признание своей ошибки на раннем этапе — признак мудрости, упорствование в заблуждении — глупость.

P.P.S. Я — инженер-механик. Это так, на всякий случай.

О, ключ Йохана (Йохансона) часть народу называет «попкой» — ибо несколько схож с попугаем :) Я — счастливый обладатель 2 разновидностей ключей — и «трубного» и гаечного, того что BAHCO.

Прошу прощения, но все же «бобкой», а не «попкой»

Я думаю, верны оба варианта. Инструменту и я не чужд, а мои старшие товарищи (имевшие счастье проработать и по рабочим специальностям, и имеющие регулярно необходимость применять инструменты по назначению по работе и по сей день) называют этот ключ именно «попкой». Вместе с тем охотно верю, что в других средах его называют «бобкой» :)

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

Это так, на всякий случай.

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

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

Тогда, в отличие от обычного программиста, Вам непростительна та чушь, которую Вы несли про разводные ключи.

Давайте перестанем вводить лишние сущности. Ваше первичное утверждение:

Разводной ключ это инструмент сантехника, а не автомеханника. Потому, что разводной ключ ТРУБНЫЙ, а не ГАЕЧНЫЙ.

.

Вам совершенно определенно доказано, что это утверждение ложно:
1) среди разводных ключей есть в том числе гаечные;
2) разводные гаечные ключи — инструмент автомеханика;

3) упомянутые мной выше ГОСТы 18981 и 7275 вводят совершенно четкие понятия ключей «разводной гаечный» и «трубный рычажный».

Вы же утверждали, что разводные НЕ гаечные, а трубные. Нет?

Если Вы в течении 6 часов что-то держали, это, в отличие от ГОСТ и Политехнического БЭС, не прибавляет Вашим словам ни малейшего веса по вопросу. Бойцы в армии траки на физо таскают, от этого их мнение о влиянии гусеничного движителя на вибранагруженность агрегатов трансмиссии не становится значимым (в отличие, например, от моего).

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

Очень жаль, что практика применения вас не интересует.
Наверное нет смысла объяснять вам, что например полдюймовый кран с шестигранником под ключ это все же не гайка, несмотря на то, что он вполне подпадает под определение гайки данное во многих источниках. Если вы считаете что это так — согласен я не прав.
Если включить в рассмотрение трубные дюймовые контрогайки то я, безусловно тоже не прав.

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

Но так как формальная логика страшно далека от реальной жизни и здравого смысла, я все же попытаюсь донести до вас кое какие факты из RL.
Дело в том, что существует отличие между трубными дюймовыми резьбами и гаечными метрическими. Как в диаметре, так и в шаге.
Банальный пример — 15 труба, называемая так в народе на самом деле совсем не 15 мм. в диаметре. Она полдюймовая, а 15 мм это ее условный проход.
Этот факт влечет за собой и разницу во внешних размерах гаек и шестигранников на кранах и накидных гайках.
Например, найти 25 рожковый ключ, даже сейчас проблематично.
Именно поэтому сантехники и применяют разводные червячные ключи.

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


Дело в том, что существует отличие между трубными дюймовыми резьбами и гаечными метрическими. Как в диаметре, так и в шаге.

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

Как пример:

www.conexmetals.com/...ion_din985.html

Безусловно!
Более того — даже в отечественных авто они встречаются.

И в каком-то из комментов выше я интересовался у оппонента — неужели он думает, что автослесарь не сталкивается с дюймовыми типоразмерами в своей работе.

Вы должны усвоить одну простую истину, которую, к сожалению, не поняли до сих пор: ключи для гаек «дюймового типоразмера» называются... гаечными, так же как и ключи для гаек с метрической резьбой.

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

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

P.S. Практика применения меня таки интересует. Буквально на этой неделе собрался купить новый разводной гаечный ключ, потому что а) старый 30-летний заржавел, б) он куда-то подевался и в) мне нужно поменять прокладку в кухонном кране (да, в кране, от этого гаечный ключ не превращается в трубный).

Всегда считал гайку крепежным изделием предназначенным для навинчивания на винт или шпильку. Если для вас шаровый кран — гайка — ради бога — пусть им и остается.

А причем здесь гайка? Вы странным образом подменяете существующий понятийный аппарат ассоциациями на бытовом уровне.

Что за дурацкая логическая цепочка «кран не гайка => ключ не гаечный»? Кстати, кран (конкретно этот) не шаровый.

Чтобы было понятно, ответьте сами себе на контрольные вопросы: 1) как называется ключ, которым крутят... болты, неужели болтовой? 2) как называют ключ, которым крутят... шурупы с шестигранной головкой, неужели шурупный? 3) Винт — винтовой?

Вы поняли мою мысль?

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

Процитируем одно из определений:

га́ечный ключ — ручной инструмент для завинчивания и отвинчивания болтов, винтов, гаек и других деталей.

Ссылка: dic.academic.ru/...sf/enc_tech/252

И других деталей. Корпус крана с шестигранником под ключ не подпадает под другие детали?

Более того, специально для Вас в этой же статье: «Ключи гаечные разводные — незаменимый инструмент в каждом доме; вместе с трубными ключами их часто используют при сантехнических работах.».

Выделено мной. Неожиданно, правда?

Прошу простить, если вызвал подрыв устоев и крах укоренившихся заблуждений.

Если уж на то пошло, то то что вы собираетесь откручивать вообще не кран, а смеситель.
А уж шаровый кран из моего комментария ни как не был связан с вашим.
Что до моих устоев и заблуждений, то подорвать их очень сложно и достаточно давно. Уж тем более это не под силу вам.
Безграмотность мою и моего окружения определять тоже не вам — увы и ах.

Жаль только что вы, с высоты своей тяги к точности понятий и определений, так ничего и не поняли...

Нет уж, позвольте, кран! Из смесителя «елочка» выкрутить кран горячей воды и поменять прокладку :-)

Хотите продолжить разговор по этой интересной теме или замнем, пока не поздно? ;-)

А понял я одно (правда уже давно) — безграмотно наехать на автора способны многие. При этом признать свою ошибку — единицы.

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

Давайте продолжать конечно. Вытащим горы определений, потом начнем цепляться к словам, перейдем на орфографию и употребление Ё после шипящих...

Это же ваш стиль. Не?

Э, батенька, а Вы софист ещё тот. У меня все ходы записаны!

Я: мне нужно поменять прокладку в кухонном кране
Вы: Если уж на то пошло, то то что вы собираетесь откручивать вообще не кран, а смеситель.
Я: Из смесителя «елочка» выкрутить кран горячей воды и поменять прокладку

Вы: Из какого смесителя? Был же кран.

У меня кран как был, так и остался. Это не я, а Вы наплодили лишних сущностей. Я продолжаю настаивать, что собираюсь откручивать кран, а не смеситель. Смеситель именно Вы ввели в обсуждение. А раз уж ввели, то я уточняю, что откручивать именно кран, а не смеситель, т.к. кран, который надо открутить, находится в смесителе, который я не буду откручивать, а смеситель в (на) раковине, она на кухне, а кухня в квартире.

Так что я собираюсь откручивать, кран или смеситель? Ась?

Вот об этом я и говорю — вы пытаетесь формализовать разговорную речь, вообще говоря чуждую формализма.
ГОСТ’ы — это хорошо (хотя и не все), но не очень они уместны в обычной беседе. В обычной жизни мы слишком редко используем слова в их значениях из ГОСТ’ов и нормативных документов.

Признайтесь — когда вы впервые написали слово «кран» вы ведь имели введу именно смеситель. Не думаю, что вы всегда употребляете по отношению к смесителю только слово «смеситель». Понимаете о чем я?

Когда я впервые написал кран, я имел ввиду именно кран.

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

Кстати, ключ купил. Он лежал рядом с трубными. Вопрос продавцу называл ли кто-нибудь этот ключ трубным вызвал у него недоумение: «Так вот же трубные, рядом!»

Интересные рассуждения. Жаль, не имеют отношения в вопросу.

На ссылку www.auto-tools.ru/...e?goods_id=1657 вы утверждали:

Это в любом случае трубный ключ.

Резьбы, метрическая-не-метрическая. Не имеет значения. Гайка с любой резьбой — гайка и ключ, который проворачивает захватом за специальные, предназначенные для этого шлицы, — гаечный.

Вы оперируете не общепринятыми понятиями, а своими ощущениями по поводу этих понятий. Трубный ключ не потому трубный, что он для дюймовых резьб, а потому что он, в отличие от гаечного, способен проворачивать детали круглого сечения (а это, как правило, трубы), не имеющие для этого специальные шлицы.

Еще раз. Вам привели ссылки на более чем авторитетные источники. Остановитесь, перестаньте нести чушь. Вы, как неподготовленный студент, вводите в разговор лишние сущности и всё больше демонстрируете проблемы в понимании предмета.

Что ж — хорошо.
Давайте поступим так.
Я признаю, что действительно высказывал обиходную, обывательскую, относящуюся только к практике точку зрения, понимая под гайкой только крепежное изделие с шестигранными шлицами под ключ.
В конце концов не мое это дело как вы там крутите гайки — хоть плоскогубцами их крутите, хоть ременными ключами.

Из этого последует вывод, что консоль не нужна?

Вы высказывали свое личное мнение о именовании ключей. К практике оно не имеет отношения. На практике грамотные люди гаечные ключи именуют гаечными, трубные трубными или газовыми.

О гайке, как об изделии, разговора вообще не было. Вы её, наряду с рассуждениями о метрических резьбах, ввели как лишний элемент обсуждения. Как, впрочем, и сейчас консоль. Причем здесь консоль? И почему последует вывод, что она не нужна?...

Прошу, не отвечайте, когда много бытовой логики (т.е. её просто нет), я перегреваюсь. Пожалейте мой моск, он и так перегружен несовершенством этого мира.

То что вы не знаете что такое бытовая (aka традиционная) логика, не означает что ее нет.
А сколько этих логик есть еще...

Да и кто вам сказал, что мир не совершенен?

(вспомнилось) «Учись, сынок! А то так и будешь всю жизнь ключи подавать...» © %)

Сначала сами изучите матчасть, потом комментируйте. Среди разводных есть гаечные ключи и газовые (трубные). Более того, любой уважающий себя автомеханик кроме специализированных имеет в своем комплекте и универсальные разводные гаечные ключи.

Ради интереса поинтересуйтесь, что изображено на знаке, и что означает сам знак: upload.wikimedia.org/...(Road_sign).gif

1 Я не утверждал, что автомеханику не нужны разводные ключи, как и отвертка сантехнику, например.
2 А где поинтересоваться что изображено на знаке? Мне кажется, что это штангенциркуль.

Чтобы окончательно закрыть тему.

Относящиеся к разводным ключи трубные рычажные по ГОСТ 18981-73 ( www.gosthelp.ru/.../gost41549.html ) действительно инструмент сантехника.

Автор же совершенно определенно говорил о ключах гаечных разводных по ГОСТ 7275-75 ( www.vsegost.com/.../41/41088.shtml ). Эти ключи — инструмент любого механика, в том числе и авто, и, кстати, поскольку у сантехника есть трубный ключ, — не инструмент сантехника, к большому сожалению. К сожалению, потому что злоупотребляя использованием трубного ключа, сантехники часто портят медные и хромированные головки под ключ, зажимая их трубным ключом, хотя надо было бы использовать гаечный.

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

«Так почему же командная строка еще не отмерла и не стала уделом узких спецов, почему люди продолжают тратить в разы большее количество времени на выполнение рутинных операций, чем это возможно?»

Это пиар, обман, грязные приёмчики. Консоль оптимизирует рутинные операции, а когда не оптимизирует, тогда ей и не пользуются

«Так почему же командная строка еще не отмерла и не стала уделом узких спецов, почему люди продолжают тратить в разы большее количество времени на выполнение рутинных операций, чем это возможно?»

Это пиар, обман, грязные приёмчики. Консоль оптимизирует рутинные операции, а когда не оптимизирует, тогда ей и не пользуются

Пять копеек от GUI дизайнера: каждый имеет право на свое мнение и с мнением автора статьи о бесполезности командной строки я не соглашусь по нескольким причинам:

1. Серебряной пули не существует и все задачи одним только GUI не решить.

2. Для людей, владеющих определенным языком или другими словами знающих набор команд определенной среды, командная строка позволяет во много раз повысить скорость работы. И даже если пользователь на уровне мышечной памяти помнит, где кнопка, довести мышку до нужного места на экране займет больше времени нежели набор команды. На пол-пути между GUI и CLI в этом плане находятся клавиши быстрого доступа.

3. Командная строка позволяет во много раз больше гибкости нежели даже хорошо спроектированный графический интерфейс. Это почти как сравнить адресную строку браузера и ссылку. И довольно часто именно это свойство командной строки адаптируется в GUI решениях.

4. Защита от дурака. Не все функции системы стоит делать легко-доступными. Особенно это касается необратимых или причиняющих вред функций. Ниже много говорится о Маках, как хорошем примере в этом плане.

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

А про любовь и ненависть — нет ничего плохого в том, что люди, виртуозно владеющие инструментом гордятся этим. Никто ведь не критикует скрипача, когда дома есть мр3 плеер.

>>

Командная строка позволяет во много раз больше гибкости нежели даже хорошо спроектированный графический интерфейс.

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

>>

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

Татьяна, если бы Вы когда-либо собеседовались ко мне в команду, наше с Вами интервью закончилось бы ровно на этом месте.

>>

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

Я проектирую интерфейсы разного уровня сложности уже лет 10, в разных странах и на разных языках и мне никогда не доводилось видеть функциональность, которая «причиняет вред». О чем идет речь???

>>

Серебряной пули не существует и все задачи одним только GUI не решить

В свое время об этом еще говорил Капитан Очевидность. Не вашей ли первоочередной задачей, как проектировщика взаимодействия сделать так, чтобы о командной строке забыли навсегда?

>>

Это почти как сравнить адресную строку браузера и ссылку.

Я правда пытался сформулировать мысли по этому поводу, но потом просто устал.

На пол-пути между GUI и CLI в этом плане находятся клавиши быстрого доступа.

На дворе 2011 год, какие клавиши?

Татьяна, это одно из самых спорных утверждений, о которых мне приходилось когда-либо слышать, если конечно Вы не проектируете консоль для Linux.
Алексей, ребята уже много об этом написали ниже и выше по треду. Из бытовых примеров, функциональность выбора страниц для печати в драйверах принтеров, где одни грубо ограничивают выбор номером первой и последней страницы, а другие дают возможность выбирать «1, 15-35» (первую и с пятнадцатой по тридцать пятую страницы).
Татьяна, если бы Вы когда-либо собеседовались ко мне в команду, наше с Вами интервью закончилось бы ровно на этом месте.
Я тоже так считаю. Про скорость ползания мышки по экрану и предсказание скорости работы с интерфейсом смотрите здесь: en.wikipedia.org/wiki/GOMS
Я проектирую интерфейсы разного уровня сложности уже лет 10, в разных странах и на разных языках и мне никогда не доводилось видеть функциональность, которая «причиняет вред». О чем идет речь???
Случайное и безвозвратное быстрое удаление ста тысяч файлов (смотрите ниже в комментариях), полная остановка сервера, редактирование прав доступа... Стоит ли это прятать от рядового пользователя?
В свое время об этом еще говорил Капитан Очевидность. Не вашей ли первоочередной задачей, как проектировщика взаимодействия сделать так, чтобы о командной строке забыли навсегда?
моя первоочередная задача сделать интерфейс, который соответствует задачам пользователя, а не учить его как жить
На дворе 2011 год, какие клавиши?
Ctrl+C, Ctrl+V Вы ими уже не пользуетесь?

Из бытовых примеров, функциональность выбора страниц для печати в драйверах принтеров, где одни грубо ограничивают выбор номером первой и последней страницы, а другие дают возможность выбирать «1, 15-35» (первую и с пятнадцатой по тридцать пятую страницы).

Татьяна, смоделируйите ситуацию, когда пользователю недостаточно распечатать диапазон страниц или выделенный текст. Комментарии «ребят» я честно говоря не читал — душевное здоровье мне дороже.

Я тоже так считаю. Про скорость ползания мышки по экрану и предсказание скорости работы с интерфейсом смотрите здесь: en.wikipedia.org/wiki/GOMS

Проблема в том, что википедия, как и предсказания, никакой роли в реальных проектах не играют. Суровая правда жизни в том, что миром правит Web, несмотря на то что Desktop по фукциональности и архитектуре на голову выше. Но таковы правила игры на сегодняшний день. (Где командная строка в Firefox?)

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

ЗАБОТА ОБ ЭТОМ — НЕ ЗАДАЧА ПРОЕКТИРОВЩИКА ИНТЕРФЕЙСОВ! (простите за CapsLock)

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

Я не буду это комментировать, но программисит (CLI) это не пользователь (GUI). Это совершенно другой образ мышления. Моей целью является создние интерфейса, понятного персионерке 85 лет, а не самовлюбленному .NET программисту, в 30 лет отправляющемуся на пенсию (потому что очередная «динамично развивающаяся» компания не нанимает кандидатов старше 27 лет).

Ctrl+C, Ctrl+V Вы ими уже не пользуетесь?

Шутку понял, смешно. А почему Вы не упомянули Ctrl-Alt-Z, сидящий где-нибудь в контекстном меню Вашей программы, которая «the cutting edge» according to your marketing department?

Alt+Ctrl+Shift+S и удачи вам, Алексей, в мире, где правит веб

Alt+Ctrl+Shift+S и удачи вам, Алексей, в мире, где правит веб

Это какой-то параллельный мир...

Зря Вы так, я надеялся на конструктивный диалог.

Извините, Алексей, но тяжело поддерживать конструктивный диалог в капслоке. И судя по выше написанному мы таки живем в параллельных реальностях.

Безмерно разочарован. Если какой-то Алексей Егоров резок в комментариях — это не повод ссылаться на CapsLock.

Где командная строка в Firefox?

JFYI:
kb.mozillazine.org/..._line_arguments

developer.mozilla.org/...nd_Line_Options

Кесарю кесарево, а слесарю — слесарево. Вы разрабатываете только взаимодействие с юзерами — вам командная строка не нужна или не очень нужна. Вам надо добавить какие-то «редкие» (и не очень) опции — их вызов уже вполне можно «вбить» в командную строку.

Вызов любого документа в любой среде GUI в конце концов сводится к вызову ассоциированной программы с именем документа в командной строке в качестве аргумента. Вас это использование CLI и его обязательное наличие не смущает? :)

Достаточно же перейти к разработке сервис-сервис, машина-машина и пр. и внезапно окажетcя, что системные вызовы (cli лишь один из интерфейсов среди них, замечательный тем, что софт можно «дернуть» и автономно, руками из общедоступной и общеобязательной консоли, в отличие от, например, unrar.dll или команд управления из COM-порта) в массе случаев совсем не требуют GUI, но зато требуют скорость выполнения, универсальность интерфейсов и т.д.

Причем в вебе вполне вероятны (и востребованы) задачи как профиля frontend/gui, так и cli/background, о чем, собственно, автору более компетентные люди и пытались сообщить.

Максим, проектировщик интерфейсов, которого интресуют потребности программиста, это программист.

Достаточно же перейти к разработке сервис-сервис, машина-машина и пр. и внезапно окажетcя, что системные вызовы

В последние 6 месяцев мне пришлось лично, по телефону, общаться с представителями около 30 нацинональностей по поводу одной и той же проблемы UI одной из систем — никто из них не выразил желания набирать «Regedit» в Windows Command Prompt. У них, к сожалению, другие интересы в жизни.

автору более компетентные люди и пытались сообщить.

Я буду рад обсудить проблемы UX с человеком, интерфейсами которого пользуются свыше 500K человек.

Статья называлась «Так ли необходима _программисту_ командная строка».

ВНЕЗАПНО, 80-летние бабушки, 500К пользователей и можно грабить корованы :)

ВНЕЗАПНО,

Годный срач всегда привлекает хомячков

никто из них не выразил желания набирать «Regedit» в Windows Command Prompt. У них, к сожалению, другие интересы в жизни.

Вы упорно говорите о программировании для непосредственного взаимодействия «человек-программа». Я же пытаюсь пояснить и автору топика и вам, что существует масса задач, выполняющихся на уровне программа-программа, и лишь на 5-10-м уровне цепочки с этим многообразием будет сталкиваться человек через, естественно, GUI. Для остальных звеньев этой цепи вполне будет достаточно CLI, либо любого другого интерфейса, максимально удовлетворяющего большей части требований и пользователей задачи. Посему юзеру — GUI (за оговорками), а программистам и интерфейсам взаимодействия — адекватную реализацию, которая может оказаться чем угодно (включая и CLI и GUI). Я надеюсь, это адекватный ответ на вопрос топикстартера «Так ли необходима программисту командная строка?»

Максим, какое отношение

программа-программа

имеет к UX в контексте IT?

Мы говорим о необходимости в софте UX или об исходном топике «Так ли необходима программисту командная строка?»

Особенно в контексте фраз топикстартера:

В PHP на поводу этого стада пошли даже такие монстры как Zend и Symfony, а ведь необходимость использования командной строки в них вообще нулевая, но стадо хочет строку:)

И это притом, что веб-технологии предполагают, что ты будешь использовать для общения с сервером браузер или на крайняк http-протокол из какого-то приложения. Браузер дает возможность запустить скрипт на сервере, а все остальное последний сделает сам (см.выше).

?

проектировщик интерфейсов, которого интресуют потребности программиста, это программист.

Да, а доктор, которого волнует здоровье пациента должен быть больным, юрист — судим, а у сантехника дома обязательно текут трубы :)

Ага, только без услуг Senior Java Developer человечество как-нибудь обойдется, но вото без доктора с сантехником уже гораздо сложнее.

Ага, только без услуг Senior Java Developer человечество как-нибудь обойдется, но вото без доктора с сантехником уже гораздо сложнее.

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

Нет сомнений, что программисты в той или иной степени разбираются в usabiliy и проектировании взаимодействия,

но врядли являются специалистами по когнитивной психологии, например, и, следовательно, UX специалисту есть чем помочь в проекте/продукте для программистов.

Alex, Вы ничего мне не показали. Вы с ног на голову перевернули то о чем я пытался сказать — программист, проектируюший интерфейс это mainstream. В большинстве software shops так и происходит — но от этого еще никто не умер. А вот если завтра отключат электричество и из туалетов побежит сами знаете что (хотя будут проблемы и поважнее) — кого Вы будете звать? Специалиста по C++?

Нет сомнений, что программисты в той или иной степени разбираются в usabiliy и проектировании взаимодействия

У меня есть очень большие сомнения по этому поводу. Я работаю с людьми, которые гораздо умнее меня, и которые проводят в офисе по 16 часов далая работу, которую они любят (R&D и программирование). И их никогда не заботит проблема взаимодействия.

UX специалисту есть чем помоч в проекте/продукте для программистов

UX специалист абсолютно бесполезен если у него нет authority в команде. К тому же он/она не должны «помогать» — они должны руководить. Нравится Вам или нет, но 90% «программистов» — это обслуживающий персонал, как и сантехники. Открою Вам небольшой секрет — в Австралии, в которой я в данный момент нахожусь, сантехник в час зарабатывает больше чем contractor в IBM (100 долларов в час) на инфраструктурных проектах. И этого сантехника мне в последний раз пришлось ждать 3 дня — признаюсь, было не легко.

А вот если завтра отключат электричество и из туалетов побежит сами знаете что (хотя будут проблемы и поважнее) — кого Вы будете звать? Специалиста по C++?

Откуда это вообще появилось?

проектировщик интерфейсов, которого интресуют потребности программиста, это программист.

я отвечал на этот комментарий и говорил что не обязательно проектировщик интерфейсов должен быть программистом и если следовать логике, то получается то-то и то-то. Вас с темы куда-то носит постоянно ...

И их никогда не заботит проблема взаимодействия.

Проведите опрос, узнайте пользуются ли они КС ;). Любой хороший программист очень серьозно относится к тому, что он использует.

UX специалист абсолютно бесполезен если у него нет authority в команде.

Это проблемма конкретного специалиста и, возможно, процесса разработки если нужен authority. Хотя он действительно может быть абсолютно бесполезен и поэтому у него нет authority в комманде.

К тому же он/она не должны «помогать» — они должны руководить.

Очень и очень и очень спорно, но спорить об этом я не буду, так как судя по динамике конца не будет этому треду.

Нравится Вам или нет, но 90% «программистов» — это обслуживающий персонал, как и сантехники.

кто по вашему оставшиеся 10% ?

И этого сантехника мне в последний раз пришлось ждать 3 дня — признаюсь, было не легко.

Очень вас жаль.

Откуда это вообще появилось?

Это я написал. Если Вы не поняли ассоциацию, повторю, что роль программиста чрезвычайно преувеличена в современном мире, в особенности за счет чрезвычайно завышенного ЧСВ этих самых программистов. Особено больно смотреть на толпы уволенных в один день Java gurus, потому что из-за очередного кризиса «бабушки-пенсионерки» решили пока подождать с очередной покупкой.

я отвечал на этот комментарий и говорил что не обязательно проектировщик интерфейсов должен быть программистом и если следовать логике, то получается то-то и то-то. Вас с темы куда-то носит постоянно ...

Sorry, you’ve lost me.

кто по вашему оставшиеся 10% ?

Alex, к чему риторические вопросы?

Очень и очень спорно

А Вы перестанте программировать и поймете что неправы.

Если Вы не поняли ассоциацию, повторю, что роль программиста чрезвычайно преувеличена в современном мире, в особенности за счет чрезвычайно завышенного ЧСВ этих самых программистов.

Я не понял откуда это взялось у нас обсуждении, как это касается вопроса нужен ли UX специалист в комманде разрабатывающей продукты для программистов. Да и причем тут ЧСВ? Наболело? Создайте топик :)

Alex, к чему риторические вопросы?

Это не риторический вопрос, это любопытство.

А UX специалисты являются обслуживающим персоналом? Какой процент?

Я не понял откуда это взялось у нас обсуждении, как это касается вопроса нужен ли UX специалист в комманде разрабатывающей продукты для программистов.

Не UX специалист нужен программистам, а программисты нужны UX специалисту, с целью создания качественного и конкурентого продукта. User Experience очень часто путают с interface/interaction design only. Немного теории. User Experience состоит из 4 взаимодоаолняемых частей:

1. Knowledge domain — это Information architecture и Business analysis — это называется «know your enemy». Мы программируем «for fun» или нам кто-то платит за это деньги? Для чего IA анализирует запросы в online store, почему существует проблема labeling and categorization?

2. «Среда (ОС, browser) и транспорт (С++, NET, JAVA и т.п.)» — это то, что «транспрортирует» информацию (даные + контекст и структура) из баз данных к пользователям с целью получения knowledge (это то, за что люди платят деньги и причина того, почему у нас с Вами есть работа). Так вот, все программирование со всей своей субкультурой (Agile, Scrum, Рихтером, Кнутом, developers.org.ua и так далее) — это просто пункт № 2. Эта та причина, почему я никогда не работаю с программистами напрямую — это level down, обсуждение деталей вместо целей и waste of time. Это та причина, по которой я упомянул бабушек и сантехников. Программист — это обслуживающий персонал, единственная задача которого обеспечить качественную «передачу информации» тому, кто за это заплатил. Обсуждать проблемы UX с программистом, это как лоцману советоваться с матросами о том куда плыть.

3. Usability/Interaction design/Graphical Design — это также не задача UX специалиста, у меня для этого есть специальная команда.

4. Quality. Предположим, что Вы создали безупречный с точки зрения usability продукт. Ваша единственная проблема в том, что каждую минуту на экране появляется Access Violation. Каков UX в данном случае? Нулевой.

Вот эти 4 пункта и есть scope UX специалиста в любой организации, которая понимает что это такое. Именно поэтому я задал Татьяне «неудобные» вопросы с целью обсудить мою теорию. В реальной жизни мнение программистов по поводу UX меня не интересуют — их даже нет на митингах, на которых я «продаю» свои идеи. Мой дизайн это не рекоммендация — это things to do, no arguing.

Да и причем тут ЧСВ? Наболело?

Оно всем наболело. На любом интервью я всегда акцентирую внимание работдателя на том, что если очеродной 21 летний «гений» (окрыленный своей «огромной» зарплатой) начнет обсуждать со мной мой дизайн — он сразу идет в топку. Если интервьюер понимает о чем речь, есть шанс на успех.

Создайте топик :)

Alex, я могу попросить Вас не ставить смайлики, если только конечно Вы не Великий Учитель Истины?

Алексей, вам эго не жмет? Вы пришли на девелоперский ресурс и пытаетесь навязать свой взляд на мир, UX и процесс разработки. Чего вы добиваетесь таким образом?

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

Вас оскорбила формулировка «помогают» ? Хорошо — трудятся совместно. Но, судя по вашему комментарию, это тоже не подойдет, этого тоже мало...
Программист сам может создать успешный программыный продукт — это факт.

А UX спец? Фиг! Но он может способстовать успешности продукта. Тем не менее кто вы без команды программистов, что можете сделать сами и кому нужны?

В общем, полагаю, вы согласны, что UX спец должен участвовать в создании

продуктов для программистов. Это уже прогресс, хотя из некоторых ваших комментариев вытекало, что UX не нужны (как не удивительно это было слышать от UX) при создании такого продукта как VS, например.

Из приведенного выше не ясно чем же занимаеся UX специалист.
1) IA + BA
2) программисты;
3) дизайнер и казалось бы UX спец, но судя по вашему комментарию — нет;

4) тестеры и QA.

Вот эти 4 пункта и есть scope UX специалиста

Поясните, каким образом вас, как UX специалиста, касается 1,2 и 4? Конечно, программа может тормозить и выдавать ошибки, но что вы можете с этим сделать? Правильный ответ — ничего? Что вы можете подсказать IA? А BA?

3 вы тоже не занимаетесь ...

В реальной жизни мнение программистов по поводу UX меня не интересуют

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

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

Именно поэтому я задал Татьяне «неудобные» вопросы с целью обсудить мою теорию.

Этого не видно. Зато есть бестолковый и неадеватный наезд не в тему. Попыки объясниться множат вопросы и извлекают на свет бабушек, 500к пользователей, обиды на программистов, и — ПАПАМ! — целую? вашу (она правда ваша?) теорию, призванную показать,

что UX архитекторы правят миром никак не могут помогать программистам — это программисты помогают. Это по-вашему конструктовное обсуждение?

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

Я не буду это комментировать, но программисит (CLI) это не пользователь (GUI). Это совершенно другой образ мышления. Моей целью является создние интерфейса, понятного персионерке 85 лет, а не самовлюбленному .NET программисту...

Алексей вы вообще тему топика читали? Причем тут ваши пользователи-пенсионерки?

В свое время об этом еще говорил Капитан Очевидность. Не вашей ли первоочередной задачей, как проектировщика взаимодействия сделать так, чтобы о командной строке забыли навсегда?

Боюсь, вы неправильно понимаете термины «интерфейс» и «проектирование взаимодействия» (что странно для UX architect, но вполне объяснимо для GUI designer).

Программисты тоже пользователи ) со своими потребностями и задачами и необходимостью автоматизировать свои ежедневные операции. КС прекрасно справляется иначе её давно бы уже не было и мы бы с вами о ней не разговаривали. Да и, конечно, usability matters — реализации бывают самые разные.

Да еще вопрос:

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

ЗАБОТА ОБ ЭТОМ — НЕ ЗАДАЧА ПРОЕКТИРОВЩИКА ИНТЕРФЕЙСОВ! (простите за CapsLock)

Так чья же это задача?

Алексей вы вообще тему топика читали? Причем тут ваши пользователи-пенсионерки?

Нет, не читал. Я ответил на комментарий Татьяны. «пользователи-пенсионерки» в том или ином виде платят Вам зарплату. Больше Ваши skills абсолютно никому не нужны.

Программисты тоже пользователи

Пользователи чего? Вы про Visual Studio?

Так чья же это задача?

Alex, Вы программист? Кто нанимал Вас на работу?

Нет, не читал. Я ответил на комментарий Татьяны.

А зря, нужно бы читать, чтоб не плодить в комментах всякую хрень про бабушек. Темы не касается кто вам и мне зарплату платит — читайте тему топика. К тому же, вы упускаете из виду большое количество решений для подготовленных пользователей (опять таки, объяснимо для web gui designer).

Пользователи чего? Вы про Visual Studio?

Да всего, чем пользуются. Gnome, KDE, Xmonad, emacs, vim, eclipse, bash, zsh, svn, hg, make, gcc, grep, sed, awk .... Это очень большой список. У всех этих программ есть интерфейсы (если вам это не понятно) и кто-то проектировал взаимодействие.

Вы не согласны, что программисты тоже пользователи?

Так чья же это задача?

Alex, Вы программист? Кто нанимал Вас на работу?

Вопрос как раз не о моей компетениции (если вы про это) ...

Как UX специалист вы утверждаете, что интерфейс не должен быть спроектирован таким образом, чтоб уменьшать количество операторских ошибок. Приплыли ...

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

Alex, Вы человек вроде бы неглупый, но я так и быть повторю еще раз — я не читаю темы, созданные программистами или для программистов (как говорил один относительно талантливый музыкант — «не стоит прогибаться под изменчивый мир»). Я заметил комментарий на главной странице, который показался мне спорным и выходящим за рамки development tools. Создавать новую тему мне показалось излишним — уровень не тот.

Gnome, KDE, Xmonad, emacs, vim, eclipse, bash, zsh, svn, hg, make, gcc, grep, sed, awk ....

О мой мозг, прости меня! Вам интересно как работает hospitality industry когда Вы приезжаете с семьей в какой-нибудь Египет?

что интерфейс не должен быть спроектирован таким образом, чтоб уменьшать количество операторских ошибок

Хороший интрефейс не предусматривает непреднамеренных ошибок. Хотите поговорить о преднамеренных ошибках (=некомпетность) — поговрите с оператом на Чернобльской АС, заступившем на смену весной 1986 года.

Я заметил комментарий на главной странице, который показался мне спорным и выходящим за рамки development tools.

Вы нигде не написли чем плоха КС для программистов и почему ею не стоит пользоваться призывая UX специалистов искоренять ее.

Не все пользователи бабушки — это вам понятно? Есть подготовленные пользователи, такие как программисты, на них и ориентирован интерфейс КС.

О мой мозг, прости меня!

Вы хотели примеров.

Хороший интрефейс не предусматривает непреднамеренных ошибок.

Любой интерфейс не исключает ошибок оператора. Тем не менее это не значит, что интерфейс должен способствовать ошибкам.

Я заметил комментарий на главной странице, который показался мне спорным и выходящим за рамки development tools.

Как можно комментировать комментарий к топику, которого не читали? Никто ведь не писал, что бабушкам нужна КС.

Получается весь этот тред — пустая трата времени так как вы просто не разобрались в чем дело. Брр о чем тут еще говорить ...

Татьяна, кулаками после драки не машут, не Вам ли как UX designer этого знать?

Какой драки, Алексей? Вы ворвались в разговор, не поняли темы и все же продолжаете яростно отстаивать свои заблуждения.

я не читаю темы, созданные программистами или для программистов (как говорил один относительно талантливый музыкант — «не стоит прогибаться под изменчивый мир»). Я заметил комментарий на главной странице, который показался мне спорным и

Context matters. Любой текст, вырванный из контекста можно интерпретировать ошибочно. Не вам ли это, как UX архитектору, знать.

Серебряной пули не существует и все задачи одним только GUI не решить
В свое время об этом еще говорил Капитан Очевидность. Не вашей ли первоочередной задачей, как проектировщика взаимодействия сделать так, чтобы о командной строке забыли навсегда?
Не противоречите ли вы сами себе? С одной стороны говорите, что это очевидно и одним GUI всех проблем не решить, а с другой — призываете искоренить КС ничего не предлогая взамен.

Самая лучшая командная строка это КС в хроме. Сам не фанат КС, но похоже нам еще долго с ней работать.

Меня долгое время удивляло такое раритетное явление, как использование десктопного графического интерфейса там, где есть веб-интерфейс (равно как и его отсутствие где-либо). В этом всегда есть что-то религиозное — то есть противоречащее здравому смыслу.

Интересно посмотреть как тормозила бы visual studio написанная на javascript

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

Ну так в чем же проблема? Установи Eclipse и наслаждайся зрелищем.

Удивительное чувство юмора.

как использование десктопного графического интерфейса там, где есть веб-интерфейс (равно как и его отсутствие где-либо).

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

One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful.
“The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.”
Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master’s hand.
“I don’t understand you!” said the programmer.
Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window.
“What are you trying to tell me?” asked the programmer.
Master Foo pointed at the programmer’s head. Then he pointed at a rock.
“Why can’t you make yourself clear?” demanded the programmer.
Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan.
As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him.

At that moment, the programmer achieved enlightenment.

catb.org/...programmer.html

лишняя статья, imho место ее на хабре но не тут

На хабре никто бы не осмелился такое опубликовать :) Карму слили бы моментально

Да, здесь место постам о бабле, карьеризме, кидалах и муках выбора «правильной» технологии

Необходима — потому что много тулов у которых нету графического интерфейса.

Много тулов — потому что command line интерфейс построить намного проще и он намного портабельней, поэтому популярен особенно в open source.

Макс А можно сделать кнопку — «ЭТА ТЕМА НЕ ДЛЯ ДОУ»?

Типа, «ДОУ только для белых»? На одного автора-неофита есть тысяча неофитов-читателей, которые я надеюсь сделают свои выводы.

Такая тривиальная задача как очистка корзины в MacOS. Вроде все просто, но если в корзине очень много файлов, то время очистки из GUI и в консоли через rm отличается в разы.

P.S У меня мака нет, но все знакомые, когда корзина забита, чистят ее через консоль

А теперь попробуйте сделать что-то нетривиальное в каком-то сложном ГУИ, а потом повторите это же через пару месяцев. Если эта задача выполняется не часто, то скорее всего придется потратить много времени на то, чтобы разобраться что в каком порядке нажимать. В случае же командной строки вы скорее всего сможете найти нужную команду в истории, вспомнив всего кусок команды. Механическая память при тыканье кнопок — временна, история — вечна ;)

Действия в GUI — not composable (как это канонически переводится?)

Действия в командной строке — composable

Вот и весь сказ.

diff <(sort a.txt) <(grep -v INVALID b.txt | sort)

Да я думаю вполне реально нарисовать графическую тулзу для текстовой обработки, что бы там всякие операции кружочками рисовались а пайпы стрелочками, типа как у MS DTS.

можно, я давно такое озвучивал — никто не берётся :). Сам хотел, да понял, что командную строку быстрее осилить (благо есть zsh с кучей плюшек)
А ведь делов-то — сделать систему плагинов для описания (чем-нибудь плейнтекстовым) соответствий опций команды виджетам диалога настройки с подсказками из мана. Можно даже прилепить готовые часто используемые сниппеты с описанием — что делают. Что ещё — предпросмотр, множественное перенаправление (которое, кстати, напрямую в консоли не делается) в пайпы.

можно, я давно такое озвучивал — никто не берётся :)

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

Останется проблема работы с этой системой через два действия — click и drag. Это будет сильно сужать ее выразительную мощность.

Я затрудняюсь придумать интерфейс, в котором создание аналога вот этой команды не будет занимать совершенно непрактичное количество времени:

ssh user@host -p 222 psql -u dbuser -h dbhost -d mydb -t -A ’select * from mytable’ | sed -n -e 1d | cut -d, -f1,3,5,6 | sort -u | column -d,

А в комстроке такое после минимальной практики пишется быстрее, чем придумывается :)

Твой исходный пост был о том что ГУИ не composable, я показал что это не так.

На простых действиях командная строка рулит, на графах действий побольше получится нечитаемая и слаборасширяемая каша, я уж не говорю о том что взрослые решения предоставляют тулы намного лучшие чем командная строка(как там из командной строки присосаться к MQ и сериализировать сообщения в формат пригодный для последующей обработки).

взрослые решения

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

а кто конечный пользователь у этих решений — программисты или пользователи?

Прграммисты, дба, дата аналисты и прочие сочувствующие.

Нет уж, я не увидел примера того, что GUI — composable. Был рассказ про то, как можно сделать некую среду, которая будет заниматься стыковкой unix-like утилит. Но это ж совсем не то.

А composable GUI — это вот что. Имеем Word, который умеет текст с картинками. Имеем фотошоп, который умеет картинки обрабатывать. Имеем WinZip, который создает архивы. А теперь вопрос — как легко и быстро создать комопзицию этих функций, которая берет вордовый документ, извлекает оттуда все картинки, пережимает их фотошопом так, чтобы они были не больше 640×480, складывает их в архив с именем, совпадающим с именем вордового документа? Адекватность полученного результата проверяется на следующей задаче — взять и обработать таким образом 100 файлов.

Ну и как, спрашивается, делается такая композиция? А никак. Только с помощью человека. Причем человеку отводится роль «демона Максвелла», который занимается перекладыванием промежуточных данных от одной программы к другой, и вручную разворачивает циклы.

Нет уж, я не увидел примера того, что GUI — composable. Был рассказ про то, как можно сделать некую среду, которая будет заниматься стыковкой unix-like утилит.

Я привел пример MS DTS, которая занимается преобразованием всяких форматов популярных в бизнес среде, от цсв файлов до дб из мэйнфреймов, таких тулзей на рынке достаточно. Про unix like я ничего не говорил. Я не вижу никакиx идейных проблем в создании ГУИ который будет делать тоже самое только в узлах будут всякие програмки для фотошопа и ворда. Просто рынка для этого нету, а иначе бы уже нагородили комбайн.

Еще раз — в приведенном примере (MS DTS) нет композиции гуев. Есть композиция действий внутри одной программы, и не более того. Ну, так этим никого не удивишь.

В исходном посте было про «действия в ГУИ» а не про «композицию гуев».
shell -> GUI
commands -> операции/действия

в чем кривость аналогии? Шелы они тоже не так что бы композировались. Притензии исключительно терминологические?

Кривость аналогии в том, что шелл — это средство объединять разные (отдельные, произвольные, написанные разными авторами) программы, при условии что они умеют работать простым общепринятым образом, выдавая или принимая строки символов.

В то же время работа в ГУИ вообще (и MS DTS в частности) — это НЕ средство объединять разные (отдельные, произвольные, написанные разными авторами) программы, т.к. они НЕ умеют работать единым простым общепринятым образом, выдавая и принимая что-то, что могут понять composable гуи-программы.

Другими словами, у операции композиции в шелле семантика есть, а в гуи ее нет. Соответственно, нет и composability.

Вместо исходного текста предлагаю (пере)читать исходный (мой) комментарий с которого и началась дискуссия. И представить себе ГУИ-версии diff и sort (такие, знаете, shareware за 15$) и как чудесно они стыкуются друг с другом.

то НЕ средство объединять разные (отдельные, произвольные, написанные разными авторами) программы,

В MS DTS операции могут быть в том числе написаные программистами процедуры.

т.к. они НЕ умеют работать единым простым общепринятым образом, выдавая и принимая что-то, что могут понять composable гуи-программы.

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

Другими словами, у операции композиции в шелле семантика есть, а в гуи ее нет. Соответственно, нет и composability.

Почему это нет семантики? Почему это «другими словами», я тоже не понял.

Вместо исходного текста предлагаю (пере)читать исходный (мой) комментарий с которого и началась дискуссия.

Я вообще то сослался именно на твой коментарий с которогo началась дискуссия. Именно в нем говорится о «действиях в гуи»

И представить себе ГУИ-версии diff и sort (такие, знаете, shareware за 15$) и как чудесно они стыкуются друг с другом.

ditto o гуи программы вс действия в гуи

Тогда, действительно, у нас спор о терминах.

Я считаю, что «действия в ГУИ» == «работа с графическим интерфейсом вообще», а не «работа с графическим интерфейсом конкретной программы».

Хотя, справедливости ради, даже при работе в одной программе два отдельных действия фиг скрестишь (и предлагаю уже забыть про ДТС, ок? Он тут — то самое исключение, которое только подтверждает правило).

Касательно семантики: хотелось бы тогда услышать какое-никакое определение.

Я считаю, что «действия в ГУИ» == «работа с графическим интерфейсом вообще», а не «работа с графическим интерфейсом конкретной программы».

Второе это подмножество первого?

и предлагаю уже забыть про ДТС, ок? Он тут — то самое исключение, которое только подтверждает правило

Никогда не понимал смысл этой фразы. dts подобные инструменты есть во всех больших etl инструментах. Вот например ibmовский интерфейс: www.ibm.com/.../S1JobSkel2.jpg

Так что никакое это не исключение.

Касательно семантики: хотелось бы тогда услышать какое-никакое определение.

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

Инструменты в etl — это узкая-узкая ниша, и эти ужасные гуи живут в этой нише под гнетом expression problem, и таи им и место. Еще раз предлагаю не замыкаться на узкой нише и смотреть на вещи шире.

Ок. Забудем сложное слово семантика. Вопрос — что «на входе» и «на выходе» операций, совершаемых в гуи, если рассматривать их как функции?

На входе — клик или драг со стороны пользователя, на выходе — ничего (нет никакого возвращаемого значения) + куча побочных эффектов (создали файл, показали картинку, скачали фильм, показали диалоговое окно ...), ради которых человек, собственно, выполнял операцию.

Поскольку весь полезный «выхлоп» — это побочные эффекты, мы не можем выполнить одну gui-операцию и засунуть ее результат в другую gui-операцию

(grep ... | sort .... | uniq ... | sed .... | grep ...)

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

(grep ... > 1.txt; {drag or click} sort <1.txt > 2.txt {drag} uniq ... {drag} sed .... {drag} grep ...)

.

Причем без кликающего человека связать действия в цепочку — нельзя. И в этом вся трагедия.

Инструменты в etl — это узкая-узкая ниша, и эти ужасные гуи живут в этой нише под гнетом expression problem, и таи им и место.

это все эпитеты на уровне вброса топикстартера.

На входе — клик или драг со стороны пользователя, на выходе — ничего (нет никакого возвращаемого значения) + куча побочных эффектов (создали файл, показали картинку, скачали фильм, показали диалоговое окно ...), ради которых человек, собственно, выполнял операцию.

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

ОК. Отдельные действия в нескольких конкретных экземплярах GUI — composable, но не «действия в ГУИ вообще». С таким я тоже соглашусь.

not composable (как это канонически переводится?)

компонируемы? составимы?

Операция называется «композицией». Соотв. прилагательное должно быть хотя бы отдаленно похоже :)


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

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

Черт, это что — на полном серьезе?

Вы, уважаемый, такой психоаналитик как и, видимо, программист. Хреновый.

Вот и выросло поколение девелоперов, оторванных от командной строки и unix-way...

“О бідна Данія, кінець всім сподіванням......” © Лесь.

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

Наверное, не хотят потратить немножко времени и научиться работать с командной строкой.

Главное достоинство командной строки — универсальность. Можно без проблем построить GUI-приложение на основе существующего консольного(для которого он даже и не предполагался), а вот наоборот — уже сложнее.

А вообще, right tool for the right job.

Про универсальность я писал в контексте разводного ключа:) универсальный инструмент всегда хуже специализированого, попробуйте для сравнения попилить дрова сначала швейцарским ножем (очень хороший универсальный инструмент), а потом любой бензопилой — и вы поймете разницу.

здесь прослеживается аналогия нож — «на коленке», бензопила — «энтерпрайз». И Bingo — правильный ответ : если сравнивать КС с инструментами — для меня это мастерская полная всего, там есть и швейцарский нож, и бензопила.

А что для Вас значат эти 2 буквы? «КС»

@Макс Ищенко, коли вже можна буде мінусувати? автори ж хочуть і створюють топіки зла. а зла і не видно.

Да, что очень интересно, что в самой статье какие-то общие принципы и именно рассуждения о концепции КС и GUI. В комментариях наоборот очень много примеров и конкретики.

Написал ответ на 2 экрана, потом все вытер.

Попробую ответить короче:

Считаю, что использование командной строки иногда необходимо сисадминам, но совершенно не нужно и даже вредно при нормальном процесе разработки ПО.

Сценарии. Если ГУИ дает возможность создавать сценарии (при этом эффективнее чем ИКС), то ИКС не нужен.

ИКС=CLI, тогда почему ГУИ а не ИГУ? (GUI)

Потому что GUI — это ГИП (Графический интерфейс пользователя), но данный термин я не понимаю еще с первого курса :)

То-то microsoft создало PowerShell.

Бл....!!1АДАН

Простите, не сдержался. Эти м..ки даже консоль нормальную сделать не смогли.

У меня в Windows хорошая консоль появилась после установки msysgit.

она уже растягивается по горизонтали не из диалога свойств чегототам?

Посмотрел (раньше не замечал такой проблемы) — не растягивается, но все равно показалось лучше, чем cmd.exe

Я всё равно пользуюсь Far’ом :) Типа тоже консоль :)

Рельсовики, где Вы?! Я уж не знаю как там в Зенд и Симфони, но глупо было бы писать графический интерфейс для rails generate, rake db:migrate и тд. Вот если бы разработчики Rails тратили время на графическую обертку для своих инструментов — вот тогда бы точно лет через пять встречали Rails 3.

куда там автору до рельс

вот вам тоже вброс: «командный интерпретатор опирается на язык (который, как известно, определяет мышление), а графические оболочки — на тыкательный инстинкт, действующий всегда по одной и той же схеме. » © не мое

Как уже отписали в комментариях, с помощью командной строки можно сэкономить массу времени. У меня чаще всего это операции с файлами по маске. А если файлов несколько тысяч — вообще незаменимый инструмент получается. Лог большой tail-ом подсмотреть тоже удобно, GUI редакторы могут несколько минут открывать.
Под OS X, к примеру, я так и не нашел GUI клиент для sqlite, без КС никак.
По поводу того, что надо помнить всякие параметры команд и из-за этого якобы тратятся силы — у кого как, а у меня всякие ls -la и прочие часто используемые команды набираются иногда на автомате случайно даже там, где не нужно.
Скажу очень субъективную вещь, но лично мне лучше в гугле или мане подсмотреть параметр команды, чем лезть мышкой в меню третьего уровня.
Ну а положение чекбоксов в настройках MS Word мозг никогда не запомнит.

Клиент для SQLite есть — Navicat. Умеет Oracel, MySQL, Postgres, SQLite. И есть бесплатная lite версия.

Смотрел Navicat, но насколько я понял, софтина на Java написана. А у меня субъективное отвращение к клиентской джаве, поэтому и «не нашел» :).

Не java. Оно, похоже, нативное.

Вы Navicat с Oracle SQLDeveloper не перепутали? Navicat нативная софтина. И я бы рекомендовал специализированный, а не универсальный.

P.S. Кроме JDBC есть масса других способов взаимодействовать с различными RDBMS, ага

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

хорошо что вы работаете не на АЭС и не управляете самолетом, преимущество кнопки в том, что ее нельзя нажать неправильно

Можно зато очень просто промахнуться по кнопке и нажать не ту.

ПС: когда я поддержал твой пост, я на самом деле промахнулся по кнопке ;-)

Хорошо, что программисты (смотрим название) не управляют самолетами (:

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

Жесть.

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

Сколько действий требуется в виндовом гуе, чтобы перезапустить сервис? sudo service left_engine restart всяко побыстрее набрать.

>>Под OS X, к примеру, я так и не нашел GUI клиент для sqlite, без КС никак.

addons.mozilla.org/...sqlite-manager

Удалите папку с тысячами файлов и подпапок через терминал/GUI :)

клик — Shift+Del — ok? Enter! -> «оставшееся время 100500 минут» -> где-то в средине процесса окошко «Вы точно хотите удалить системный файл wtf.log?», которое мы замечаем спустя 2 часа.

rm -rf /path/to/dir

ы?

Или еще круче — удалите все файлы *.pyc, *.pyo, *.orig, *.rej, .viminfo, *.bak и т.п. в текущей и всех ее поддриекториях (файлов может быть ОЧЕНЬ много). У меня это один алиас — rmpyc.

Разместив рекламу в каментариях к этой колонке, вы уже в первые сутки получите over 9000 просмотров.

Вывод — пишите больше вбросов :)

кто не пользуется терминалом — тот лох

Вначале о сравнении принципов командной строки и GUI.
Это кривое воспроизведение того, что было изложено подробно, внятно и чётко тут: www.ozon.ru/...ail/id/4288567

в частности, вводились термины интерфейса типа «опережающий ответ» (комстрока) и «опережающий вопрос» (меню, диалог с кнопками, etc.), рассматривалось, как проектировать адекватную командную строку (тут и история, и удобное редактирование...), и многое другое в интерфейсах. Причём не на уровне сказок Раскина (мир праху), а обыкновенные практические приёмы и правила на все случаи жизни.

Так что автор статьи изобрёл велосипед с задержкой на 20+ лет, и его оправдывает разве что отсутствие переизданий. Но вот фатальное отсутствие понимания, чем и почему командная строка хороша — никакой недоступностью литературы не оправдывается.

P.S. Сделал новый акаунт, старый куда-то потерялся с концами.

О! netch! :)

Вот уж действительно статейка... Столько эмоциональных слов, а полезного ничего.

Статью можно сократить до объема твита: «Командная строка не нужна некоторым PHP разработчикам(включая автора), а так же тем, кто не умеет эффективно ею пользоваться».

В современных vi[m] проще нажать ZZ

:)

Это правда, но работает мускульная память. :)

Неоднозначное выражение, у меня сразу перед глазами предстало .../mysql/data/... :)

О! Вот он ответ, который перечеркивает все аргументы автора статьи и в полной мере подтверждает, что «консоль рулит». :)

дайте два пожалуйста, особенно в случае данного персонажа :)

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

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

Т.е. открываешь консоль, руки «сами» практически вслепую набирают знакомые команды и тут же получаем результат. А в случае с GUI после каждого движения мышкой нужно переключать внимание — убедиться что курсор встал «куда надо» — над кнопкой, в зоне окна и т.д. — тут в «слепую» не получится никак, а соответственно будет дольше.

Кроме того в GUI нельзя кликать «наперед», а вот в шеле можно печатать следующие команды до того как выполниться текущая.

Когда продакш вдруг лег и каждая секунда может стоить $$ — это особенно важно ;)

Ну, у кого руки «практически вслепую» набирают команды, а у кого и действительно вслепую. Уверен, большинство разработчиков умеет набирать десятью пальцами, не глядя на клавиатуру.

Соответственно, по скорости выполнения нажатие кнопочки в GUI — даже не рядом. Единственный GUI-элемент из известных мне, который мог бы сравниться по скорости (в том числе и вслепую), это Marking Menu в Autodesk Maya.

мистер троль :) самая правильная реакция — отсутвие реакции

Ваша реакция — неправильная :-) :-) :-) :-)

Как уже было замечено, UI действительно будет выглядеть монструозно для решения некоторых задач.

Пример из жизни: есть книжки (.txt) в cp866. Хочется забросить их на pda, да вот только читалка ожидает их в utf8. Конечно, можно открыть книжку текстовым редактором, и пересохранить в нужной кодировке. Но когда файлов более сотни (небольшие повести, рассказы по паре страниц) — сами понимаете, да?

Можно найти программу, которая это делает, попутно узнав о новых троянах и т.п.

А можно за те же 10-15 минут написать простейший конвертер в одну строку. И для этого в системе (OS X, linux) все уже есть — bash, iconv.

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

В OS X консолью пользуюсь очень активно — ей просто нельзя не пользоваться при разработке для веба чего-нибудь сложнее чем hello-world на php. На Rails используется консоль (application console, интерактивная сессия интерпретатора в контексте приложения), запуск app-сервера, управление исходными кодами (git).

Фу, какой примитивный вброс. Автор похоже видел только виндовую «командную строку» и про современные интерпретаторы знает меньше, чем ничего. Как с помощью GUI реализовать повторение комманд, комбинирование, перенаправление ввода/вывода? Как получить историю? Как работать с системами, в которых графический интерфейс в принципе отсутствует (а их миллион)? Про автоматизацию и скриптинг я вообще молчу. Короче незачет.

Как работать с системами, в которых графический интерфейс в принципе отсутствует (а их миллион)?

Согласно статье эти системы устаревшие, что в принципе верно. Может ещё и [objective]C считать современным языком, только потому что его активно используют?

Пост ні про що, але є намагання роздути холівар.
Ми на таке не ведемося...
Автору явно не достає досвіду роботи в умовах, коли без КР «нікуда».

Клікайте мишкою на здоров’я :)

так і бачу як автор результат натиска однієї кнопки направляє черех пайп в іншу кнопку...

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

О, какая тема для холивара!

На самом деле всё просто. Если вам нужно использовать некую рутину приложения, не требующую GUI, и потому отъедающую значительно меньше ресурсов системы в виде консоли — вы напишете консольное приложение. И замечательно запустите его из любимого файлового менеджера (от mc/nc до Проводника, Nautilus, Total Commander etc).

Если вы регулярно ошибаетесь с параметрами командной строки приложения для 2-3 постоянных процедур (скажем, апдейт графической статики вы пробрасываете единым архивом на ваши сервера) — вы напишите один раз для себя всё тот же батничек или шелл-скрипт, который уже не будет ошибаться.

Если вам всё-таки нужен GUI — вы таки напишите GUI и, если найдете нужным, оставите в нём опции в командной строке для отладки или для нестандартных вариантов, которые, тем не менее, ограниченно востребованы (напр. профили в той же Mozilla Firefox). Или не оставите.

Возвращаясь к php и необходимости CMDLINE там — нужно ли подымать целый веб-сервер ради события, которое будет выполняться в фоне работы вашего сайта (портала и т.д.) на сервере по крону? Например, регулярная рассылка оповещений, или какие-то обновления со сторонних сайтов. Ведь для этой задачи обычно достаточно средств языка + его расширений, и, как правило, сервера базы данных. А вывод ошибок или логирование событий при выполнении вполне можно сделать в файл. Можно, конечно, дернуть соответствующий метод через wget и прочие браузеры из crontab (и тогда вам таки нужен будет веб-сервер). Но зачем, если можно обойтись прямым вызовом самого интерпретатора языка и получить практически тот же результат, ещё и меньшими ресурсами?

Я не уверен, что вам не приходилось писать такие приложения. И если таки нет — искренне желаю вам профессионально дорасти до осознания необходимости командной строки и в php, и в его фреймворках, и в популярных приложениях совмещающих возможность работать как через GUI так и из CMDLINE (а в некоторых случаях — и с системными вызовами :) ).

Ибо чем «легче» окажется конечный продукт, тем легче будет в конечном счете и вам, как разработчику. И здесь нет никакого детства.

Потребность самоутвердиться — естественная потребность человека — принимает самые разнообразные формы.

Пост безудержно самоутверждательства автора.

«Не следует множить сущее без необходимости»

А вот тут интересно: командная строка появилась раньше GUI. Вы сами себе на язык наступаете :)

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

А по сути:

Так ли необходима программисту командная строка?

Нет, не необходимо, работайте без нее.

Если хотите бурленья мнений то напишите статью «Так ли необходимо программисту тащить на работу детские сумленья и самоутверждаться за счет команды на примере командной строки и наблюдения за двумя коллегами».

А логиниться на удалённый сервер?

не поверите — Putty тоже есть в Linux.

ну а после того как вы залогинились?

как много желающих инстраллировать на сервере GUI и на клиенте его поддержку.

Автору — а Вы знаете что делает команда «tail» ? Особенно с ключом «-f»

ДОУ, А почему нет кнопки пожаловатся на пост?

Можно например, как workaround, удалить все свои комментарии )

злой такой воркераунд

Причин, окрім релігійних, звісно, достатньо. Наприклад автоматизація чи інтергація. Або навіть недоступність нормального GUI до декотрих програм (для мене тут mysql).

Зрештою, не варто забувати, що кожна задача потребує зручних інструментів. І далеко не завжди необхідні зручності можна отримати в графічних інтерфейсах.

Згоден, що треба використовувати ті інструменти, які найкраще відповідають завданням. Якщо якусь операцію можливо виконати лише за допомогою КС, то треба й виконувати — але кому?.
У великих комерційних проектах економічно рідко коли доцільно тримати універсальних спеціалістів, і тим паче недоцільно завантажувати їх різнорідними завданнями, витрачаючи їхній дорогий час на переключення між завданнями.
І фронтенд, і бекенд девелоперам командна строка по факту не потрібна чи потрібна для поодиноких не властивих ім завдань. Реально КС необхідна лише сисадміну для відлагодження сервера.

При розробці складного ПО, якщо вам потрібно максимально сконцентруватися саме на бізнес-логіці, краще віддати такі специфічні завдання вузькопрофільному спеціалісту.

Вы до сих пор верите в то, что админ сделает все за девелопера и проблем не возникнет? На моей практике такого не возникало ни разу. Всеравно что-то приходится допиливать, чисто даже потому, что админ может не знать всех ньюансов того софта, который нужен тебе в проекте (например Sphinx и т.д.).

Бывает что разработка идет на винде, а рабочая система — естессно на линуксе, и конечно не работает. Эту проблему решают билдскрипты для конечной системы, которые нужно запускать в Космической Станции"КС"

правильно разработанное приложение под виндой — будет почти без писка работать на Linux :)

Я сам девелоплю из-под форточек.

«будет почти работать» — на продакшн не поставишь, нужны более весомые гарантии

о чем вы? Никогда нет гарантий, что будет работать, пока не проверишь на боевом сервере.

лолчто? Приложение для похапе? Приложение на win32api со СКРИПОМ будет работать на всякой дрочне, типа wine

из единичных несвойственных задач и состоит вся прелесть разработки, а вот все остальное — что требует бизнес — это «****-кодинг» с разными, но одинаковыми по смыслу, префиксами.

Навскидку как минимум три применения командной строки буквально за сегодня:
1. Пинг удаленного хоста.
2. Запуск блокнота и калькулятора.
3. Запуск студии с регистрацией компонент и сборкой свежих интеропов (большой такой командный файл). Не совсем командная строка, но примерно...

Так что во всем нужно меру знать... Вообще командная строка — это скорость, скорость и еще раз скорость. Как и клавиатура. А если ты не знаешь как что-то сделать в командной строке, то встает вопрос — а насколько ты дорос, что бы делать такие вещи? Ведь поиск в инете — это чтение описания, это how-to и прочее....

Visual Studio )))

О!... Еще билд в релиз моде тоже к списку добавить надо четвертым номером.

2. Запуск блокнота и калькулятора.

По-моему, для таких вещей лучше шорткаты использовать.

Вы знаете, когда Вындоуз наконец-то осознала полезность spotlight-подобной фичи, я за нее откровенно порадовался. Ибо даже мне, никогда с командной строкой не работавшего (окромя копипейста полезных команд из гугла), гораздо удобнее набрать <cmd+space> tex <enter>, чем идти в приложения и искать там текст эдит (то же самое для виндовз: <win> note <enter>).
И это не говоря о том, что для неготорых утилит просто нет GUI.
А про > msbuild ...sln я уже молчу -)

Идею топика не понял. Запретить командную строку на проектах?..

Поддерживаю. Win+R calc (mstsc, notepad, notepad++ и тд.) Enter таки быстрее чем искать калькулятор(rdp, notepad) в необъятном Пуске.

Я недавно узнал, что в Win7 можно запускать программы из таскбара (там где раньше был «быстрый запуск») по Win+1, Win+2 и т. д.

Как то странно будет туда выносить калькулятор которым пользуешься пару раз в неделю) да и на ноутбуке пятнашке — свободное место дороже золота)

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

Автор, представь пожалуйста, допустим есть некоторая прога — обработчик файлов: в гуи всего 3 кнопки, 1 выбирает исходный фаил, вторая выбирает куда сохранить, третья пускает обработку. А теперь представь что нужно обработать 100500 файлов по всей системе, или вообще сети, при том не единоразово, а скажем с определённым периодом, а список этот у тебя вообще вторая прога генерирует сторонняя. Как быть?

В случае с ГУИ — я хз, но в случае если эту прогу можно пускать с различными аргументами (например ./proga.bin file_in file_out), то это всё решается в несколько тыков по клавиотуре.

Вы действительно сравниваете 2 совершенно разные вещи, не путайте мировоззрение людям, это как шурупы с гвоздями сравнивать.

В статье сплошь суждения «со своей колокольни».

Простой пример. Если мне нужно получить чужие изменения из Mercurial-репозитория, то гораздо быстрее и проще написать в командной строке hg pull && hg merge && hg commit -m merge, чем тыкаться по кнопкам в GUI. Если же мне нужно посмотреть историю веток репозитория, то не вижу смысла делать это в консоли — в GUI намного нагляднее и удобнее.

Пример № 2. В Qt Creator есть поисковая строка и по совместительству такая себе недоконсолька. Очень удобно иногда ей пользоваться вместо клацанья мышкой.

На самом деле быстрее это сделать в Eclipse c помощью одного диалога (попутно зарезолвив конфликты) но в общем согласен

Я не люблю Eclipse :) Но в общем согласен.

по поводу разводного ключа:

он быстрее убивает грани на гайках и болтах. так-же как и дешевый и убитый советский инструмент из дедушкиного гаража.

это вам видимо не приходилось отворачивать старые советские гайки новыми дешевыми китайскими ключиками )). гайки это соревнование выигрывают зачастую.

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

мне видимо просто не повезло с производителем — ключики поломались ))

не надо экономить. стенды с хорошими инструментами могут стоить больших денег и очень не зря.

Сам ты стадо. Регекспы писать не приходилось для sed/grep? Я себе могу представить GUI для составления регекспа с необходимым функционалом. А конвеерная обработка данных и перенаправление ввода/вывода (это те которые >, >>, |)? Много гуи/иде для node.js например есть? А для ruby/rails (тут конечно получше, но тоже не сильно зашибись)? В общем представление, что GUI — это и есть идеальный UI — ошибочно, для каких-то задач он подходит идеально и позволяет эффективно решить задачу, для каких-то подходит лучше командная строка.

Гуй для рельс! DHH негодует!

Статья о том, что мягкое лучше тёплого. Спорить не о чем, так как сама постановка вопроса неверна.

tl;dr без КС никуда

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

Ну так и получилась у Редмонда одна из лучших в мире IDE.

Полезность поста крайне сомнительна. Бритва Оккама обоюдоострая — зачем плодить окошки, когда есть одна команда в строке? Если человек уже использует постоянно в своей работе bash, то уж наверняка не полезет в инет искать её синтаксис. А сделает всё за пару нажатий клавиш. Тут кому как удобнее, а не

вредно при нормальном процесе разработки ПО

.

П.С. сам использую командную строку редко. Но знаю случаи (разработки ПО), когда без неё никуда.

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

оно все круто конечно. Вот только прочитайте название вашей статьи еще раз внамательно. Там не о контроле доступа и не о пользователях вроде

А у меня много окошек с консолями. а ещё vim разбитый на 5 окошек.

Умный IE тоже имел много окошечек, но почему-то перешел на табы.

А «приборы в кабине у пилота» требуют 27`` или quad head, что рассеивает внимание и начинает сильно болеть шея.

На htop тоже смотрят и контролируют.
Пилот — не программист

лінуксяки не сидять на доу?) де холівар?

Писал пост, чуть-чуть не успел.

Линукс уже другой и GUI там хватает, а консоль отходит на второй план. Кстати, а многие ли любители Apple пользуются консолью?

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

бред какой. линукс и командная строка неразлучны :)

почти все юзеры пользуются консолью в маках, когда нужно подстроить систему (реакция на радикализм Эпла чаще всего).
да, есть такие вещи как OnyX, но во-первых, gui — это предопределенный набор функционала (конечно, если туда не встроена консоль ))))))) ), а во-вторых, воркфлоу такой: увидел полезность, скопировал, запустил, профит.
В третьих, много полезностей просто портирована и живет в виде command line tools.
Хотя это уже уход в сторону, ибо топик о том случае, когда есть альтернатива.

А програмеры под мак постоянно консоль пользуют. это факт.

Я всего лишь программер под линух и ваш комментарий вызывает у меня удивление. Но будь на моем месте true-linux админ, он бы закидал вас гневными комментариями.

я использую консольное приложение tilda c биндингом на Ctrl+~

Мегаудобно и никаких лишних окошечек

Неосилятор-пост.

Подписаться на комментарии