シェルを使わざるを得ないシチュエーションの例をいくらか挙げてほしいです。
というのも経緯として、curlというコマンドについて調べていたのですが、Google Chromeにはcurlコマンドを簡単に叩いてくれるDHCやPostmanなどの拡張機能があります。この拡張機能を使えば、わざわざcurlのコマンドを叩かなくてもいいのではと思っていました。しかしシェルしか使えないような環境で開発せざるを得ない場合は、curlコマンドを理解する必要があることを知りました。このようにbashやzshなどのシェルしか使えない環境で開発する事例はどんなものがあるのでしょうか。
また、実際に製品を作る段階でCUIの特長がどのように利いてくるのかを知りたいです。GUIよりCUIの方が優れている理由ならググれば出てくるので理解はできるのですが、実際の利用例が想像できません・・・。
例えばcurlだったらわざわざ慣れないCUIを使わないで、GUIベースの別のPCを使ってChrome拡張機能から叩いた方が楽でいいんじゃないかと思ってしまいます。しかし、curlを使っている人々はネット界隈で多く見ます。curlをシェルから使うエンジニアの方々は、どういう動機でcurlコマンドを叩くようになったのでしょうか。当方Linuxを勉強しているのですがまだあまり慣れておらず、CUIを使うモチベーションがもう少し欲しいです。
以上まとめると
- GUIではなくCUIしか使えない環境で開発した事例
- 回答者様がGUIからCUIに移行しようと思った動機(できればこちらも回答願えたらと思います)
の回答をお願いしたいです。
teratailで質問するにふさわしい内容であるか微妙なラインかもしれませんが、教えていただきたいです。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答9件
0
MacbookProを購入して徐々にCLIの領域を増やして、
最終的にほぼ全ての作業をターミナルで行うようになりました。
その理由は速さです。
GUIはどんなに洗練されたインタフェースでも、マウスを操ってあっちでポチリ、こっちでポチリという操作になります。
知識あまりなくても簡単に使えて楽でいいじゃんは確かにその通り、じゃあ作業に慣れたから次からは1/3の時間でやろうか、自動化して1/100の時間でやろうか…値をちょちょっと変えて再送するだけでしょ?えっむり?
そうなのです。
マウスをあっちこっちにふりふりして操作するGUIは作業速度がボトルネックになります。
ショートカットキーを沢山覚える事でCLI操作に肉薄は出来ますが、GUIはそもそもマウス操作するためのもので、全てキーボードで完結する環境は整っていません。
結局いくら慣れても作業速度は一定以上上がらない、これがGUIの弱点です。
逆に言えば不慣れな人でも一定の速度が出せるのがGUIの強みですが、私としては効率化出来るならしたいものです。
逆にcurlですがこれ自体はコマンドなので、
コマンドの文字列をそのまま持っていってエビデンスとして使う事が出来ます。
大量のファイルから動的にcurlコマンドを作って一斉に飛ばすこともできますし、
コマンド文字列をまるっと保存しておいて結合テストなんかにも使えます。
Vimでcurl込みのコマンドを大量に作って、Shift+Vで選択して:w !bash
で発行するなんて手段もあります。
発想次第でいくらでも速度を稼ぐ事が出来るのがCLIの強みです。
最初に時間はかかるけど、慣れればコマンドを組み合わせて自動化させて、次からほぼ0の時間で実行出来る事が強みになります。
また、コマンドなのでタイピング速度を上げるために練習すればするほど効率がよくなります。
そして最後に、GUIとは違いCLIは成長しないとは考えていませんか?
逆です、CLIはちょっとした発想ですぐにコマンドやスクリプトを付け足して新しいTOOLが作れるので、
便利アプリで溢れかえっています。
GUIでアプリを作るのは辛いので、こまめにメンテされている良いアプリは少ないです。
投稿2017/02/04 10:30
総合スコア21158
0
ベストアンサー
下記の場合シェル前提で作ります。
1)セキュリティ対策が施された環境に対して作業を行う場合
2)相手にしている環境の数が多い場合
3)テキストを検索・整形・集計する場合
セキュリティ対策が施された環境では、GUIサービス(GNOMEやKDE)がほぼ間違いなく停止されています。runlevelが5ではなく3になっている感じです。コマンドでGUIを起動させることもできるのですが、そもそもセキュリティ対策で停止しているのに、便利だからということを理由に起動することはできません。なのでシェルで設定変更等を行うようにします。
環境の数が多いとホスト名やIPアドレスなど環境によって差が出る部分を手作業で直していては大変です。間違う事も多いですし、間違えると調べて対応する分時間もかかってしまいます。なので、環境が複数存在する場合には、環境の違いを吸収するようにシェルを活用します。
ログの調査やテキストベースのデータの加工・集計の時にはシェルを使っています。GUIだとテキストエディタで検索・加工をかけたり、スプレッドシートで加工・集計をすることになりますが、CUIのシェルだと、sed,awk,grep(egrep),sort,wc,find,xargs + 各ミドルウェア固有のコマンド に パイプ(|)が使えればGUIよりも簡単で素早くかつ柔軟に作業が行えます。多少複雑&大データ量でもユニケージを活用することで解決できます。
1)がシェルを使わざるを得ないシチュエーション
2)がGUIでもでききるけどシェルを使ったほうが良いシチュエーション
3)がGUIよりもCUIを使う理由
という感じです。
ちょっと脱線しますが、滅多にない機会だと思うので
AP開発者だと自身が使っているクライアントPCとサーバ1環境程度なのでCUIのメリットは感じないことと思いますが、1)~3)いずれも実は意識しておく必要はある要素ですね。
・本番環境ではGUIは使えないのでCUIによる設定方法は求められる要素。
・本番環境ではホスト名やIPは変わるのでどこにそうした環境依存が存在するかは聞かれる要素
・障害調査における対応のスピードと原因・対応・解消証明の単純・簡潔・明瞭さは感謝される要素
と思います。
こうした部分はインフラや運用保守の仕事と線が引かれることもままありますが、
対応するための仕込みを行えるのはAP開発者のみという部分でもあります。
GUIの代表格のWindowsにもBashが搭載され標準的コマンドは網羅される方向のようです。
AP開発者もCUIも活用して効率・品質・速度を上げていきたいですね。
投稿2017/02/04 00:49
総合スコア804
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
他の方があげていない点で、どんな操作をしたかログが残せることがあります。
他の人に引き継ぐ際にも、問題があったとき調査するにもGUIの操作は残らないことが多い上に、意図しない操作をした際に発見しずらいことがあります。また、再利用がしやすい点があります。
サーバ設定などで”ちゃんとやりました”ではすまないことが多いですし、画面のスナップショットを取るより、CUIのログの方が残すのも調査するのも圧倒的に楽です。
CUIは不親切なUIですが、差し引いても余りある利点があります。CUIの経験を積めば必ず理解できるはずです。
投稿2017/02/06 04:55
総合スコア2883
0
「開発環境」に絞るなら、CUIシェルしか使えないというのは今時ないと思います。なぜならGUIの方が生産性が桁違いに高いからです。
UNIX/Linux向けの開発は何度か経験しましたが、CUIシェルのみということはありませんでした。ターゲットがサーバーや組み込み製品などCUIシェルのみの場合は、通常クロス開発を行います。
ただし、CUIシェルを使う必要性は依然としてあります。というか、UNIX/Linux向けの開発においてCUIシェルの使用は必須です。本番環境はGUIなしというのはよくあるので、CUIシェルが使えないとテストができません。また、シェルスクリプト等による作業の自動化やバッチ処理など、CUIシェルでなければできないこともあります。スクリプトを使いこなせるかどうかは生産性にも関わってきます。
投稿2017/02/04 07:58
総合スコア5938
0
既に他の方も書かれていますが、実際に運用する本番環境では GUI が使えないなんてのはざらにあります。
さらには本番機が複数存在するなどの場合、環境を更新するためのコマンド群をシェルスクリプトで記述して配布して叩く、なんてこともあります。
手順から可能な限り手入力を省いて自動化するのが、ミスを防ぐための重要なポイントだからです。その点でいえば GUI でのリリース作業なんてのは危険(ボタン一発くらいまえ自動化してあればともかく)なんですね。
また、トラブルシュートでログを見たりする場合、ログから必要な部分を抜き出したり検索をかけるのに、CUI なら簡単なことを、GUI だといったんファイルをローカルに持ってきてから、なんてことになる場合もあるので、CUI(というかコマンド群)は一通り使えないと困ることもあります。
昔と比べて個人で UNIX コマンドを使うハードルは大幅に下がりました。仮想マシンで Linux を立てて使ってもよし、Windows であれば cygwin を入れて使うのもよし、Bash on Windows もあります。Mac は完全に UNIX ですしね。
投稿2017/02/04 02:45
総合スコア13703
0
cloud9 では、GUI はつかえません。
Cloud9(クラウド9)とはアプリケーションの開発やデータベースなどをクラウド環境で利用できるサービスです
参考 Cloud9を使ってみよう http://dotinstall.com/lessons/basic_c9/37001
細かな操作は コマンドラインでおこなわなければなりません。
投稿2017/02/04 01:12
総合スコア22324
0
「GUIが使えない開発環境」というのは今時は無いと思います。
CUI(CLI)を使うのはGUIより楽だからです。マウスに持ち替えずキーボードだけですべて出来るし、違うボタンをクリックしてしまわないように注意する必要も無いし(ブラインドタッチできない人は逆に思うかも)。
特に、同じような作業を繰り返しするのはGUIにくらべると段違いに楽ですね。
「コマンドラインで出来る物を何故わざわざGUIで?」とか思っちゃいます。
あ、もちろんプログラム開発の時のIDEのようなものはまた別ですね。
あと、パフォーマンスグラフを書くような本質的にグラフィックなものとかも。
とにかく、楽な方を使います。
投稿2017/02/03 23:47
編集2017/02/03 23:49総合スコア84423
0
ローカルで開発している場合だと、GUIを扱う場合が多いので不思議かもしれませんね!
CUIしか扱えないケースは基本的にはサーバー上で作業をする場合です。
Linuxで動作する多くのサーバーではGUIを搭載しないことが一般的です。
そのため、サーバー上で何か作業を行う場合ではCUIで作業をする必要が発生します。
インフラを扱う方が特に得意とするところだと思いますが、
昨今ではアプリ開発者がインフラを整備する機会も増えました。
VagrantやDockerを始めとして、自分自身のローカルマシン上に仮想マシンで
サーバーで動作させるのと同等のソフトウェアを実際に動かす機会が増えたからです。
これらの環境だとGUIを入れませんので、CUIを扱う必要がでてきます。
また、日頃CUIを扱う環境に慣れている方がChromeの拡張機能などを使わず、
どのOSでも基本的には扱えるコマンドを使うのかもしれません。(Windows On Bashも登場しました!)
シェルスクリプトにして保存しておけば、何度でも再利用できますし、
それらを束ねたファイルを作っておけば、正常なレスポンスが返ってくるかどうかのテストも可能というメリットもありますね
投稿2017/02/03 18:44
退会済みユーザー
総合スコア0
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/02/04 11:15