  |
はてなキーワード: CLIとは
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
AWS CLI を何らかのスクリプト言語に組み合わせることは出来るが、AWS CLI はスクリプト言語では無いだろ？理解できたか？
あと、お前は Google Apps Script と AWS CLI を「スクリプト」という同カテゴリに捉えているようだがそれは間違いだぞ
AWS CLIっていうみたい、質問くれなかったらググりもしなかったわ、ありがと～
iPhoneの話題でAndroidとの比較を、日本のケータイの歴史も絡めた増田がホッテントリしていたけど、
個人的には、むしろAndroidがここまで普及したことのほうがにわかに信じがたい話だったりする。
自分は、大学で覚えたパソコンで2ちゃんどっぷりだったキモオタ系ということもあり、
すでにJK～20代の女性とっては当たり前になっていたガラケーも、仕事するようになって数年後、渋々持ち始めたくらいの代物。
だからそもそも、ガラケーの文字入力からして使いにくかったし、iモードに至ってはなにそれおいしいの？という感じ。
だからW-ZERO3とかBlackBerryといった、液晶画面+qwertyのハードウェアキーボードという当時のスマートフォンは、文字通り垂涎の的だった。
「本物のネットはパソコンの世界にあるもんだ、スマホはそこらへんをよくわかってる」
と胸踊らせたものだった。
しかし自分がいたキャリアはあくまでガラケー一辺倒=そういう機種は一切ラインナップに加えないので、本当に歯がゆかった。
そんな自分がアラサーのとき日本に上陸したiPhoneには、そりゃもう興奮した。
しかしまたしても「スマートフォンはまだ早い」とか言ってたキャリアが…。
さて、そんなiPhoneの後塵を拝す形でひっそり登場したのがAndroidなわけだが、これがモノになるなんて正直思えなかった。
海外ではすでにハードウェアキーボードのスマホが一定のシェアを持っていたことはなんとなく知っていたし、そういう従来のスマホとiPhoneの一騎打ちになると予想していた。
だってBlackBerryもNokiaもめっちゃ強かったから、まさかソイツらがブランドイメージ皆無なAndroidに全て駆逐されるなんて、ありえないと思うじゃん。
何よりAndroidがLinuxのスマホ向けディストリビューション、要は中身がLinuxということが、以下の理由でパっとしない感を更に強めていた。
あと全面液晶の「iPhoneクローン」なスマホだったら、Windowsのモバイル版が伸びるだろうと思ってたこともある。
Windowsはそこそこの値段でそこそこの使い勝手のデスクトップPC向けOSとして、当時はもちろん今もデファクトなわけだし、その実績からLinuxというCLIメインのOSよりも、ずっとスマホに近い場所にいると思ってたし。
それにスタープログラマのカトラーが文字通り人生を賭けて作ったOSなんだから、少なくとも院生のお遊びから始まったLinuxなんかよりは、モバイルでも上手くやるだろうと。
そういう当時を空気感を知っていて、かつ、ほぼXperiaしか触っていないとはいえ5年以上Androidスマホを買い替えつつ過ごした人間として、正直Androidなんて…と思っているわけで。
そして去年ようやく念願のiPhoneに乗り換え1年ちょっと経ち、「別にAndroidでいいじゃん」が「もうAndroidには戻れねえ」となった結果、更にその思いが強くなったと。
だから、AndroidとiPhoneをガチで比較してなお「Androidでいい」とか、ましてや「Androidがいい」という人は、一体何を見てそう思ったのか、心底理解できない。
PixelやGalaxyや中華スマホは触ったことないけど、Xperiaは国産スマホでは最高レベルに優れていると聞くし、そんな高級スマホと比較してもiPhoneのほうが全然使いやすいのだが。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 107 | 10650 | 99.5 | 39 |
| 01 | 45 | 4850 | 107.8 | 31 |
| 02 | 9 | 1493 | 165.9 | 65 |
| 03 | 22 | 4230 | 192.3 | 37.5 |
| 04 | 22 | 2130 | 96.8 | 56 |
| 05 | 23 | 2754 | 119.7 | 62 |
| 06 | 34 | 2137 | 62.9 | 46 |
| 07 | 45 | 4654 | 103.4 | 45 |
| 08 | 107 | 9041 | 84.5 | 52 |
| 09 | 118 | 9562 | 81.0 | 42 |
| 10 | 129 | 12334 | 95.6 | 47 |
| 11 | 148 | 12980 | 87.7 | 44 |
| 12 | 241 | 24107 | 100.0 | 43 |
| 13 | 117 | 13082 | 111.8 | 50 |
| 14 | 174 | 23990 | 137.9 | 58.5 |
| 15 | 167 | 13621 | 81.6 | 43 |
| 16 | 181 | 15159 | 83.8 | 35 |
| 17 | 171 | 11302 | 66.1 | 37 |
| 18 | 157 | 10619 | 67.6 | 40 |
| 19 | 143 | 16385 | 114.6 | 33 |
| 20 | 152 | 11872 | 78.1 | 36 |
| 21 | 131 | 12149 | 92.7 | 41 |
| 22 | 146 | 18136 | 124.2 | 44 |
| 23 | 123 | 8453 | 68.7 | 23 |
| 1日 | 2712 | 255690 | 94.3 | 42 |
小熊(7), CLI(15), 礼子(5), スーパーカブ(20), CUI(8), 都立高校(6), 宗教差別(4), GUI(19), ＩＯＣ(7), ぱふぱふ(3), ガチオタ(3), 数値計算(3), ドラクエ(13), 反差別(15), 中卒(15), ちやほや(10), 五輪(34), BAN(7), Excel(6), 文法(6), コンピュータ(8), バイク(12), 論理的(12), 私立(14), 入試(9), キーボード(10), 開催(30), 接種(16), フィクション(18), オリンピック(41), 老害(16), 科学(19), 選手(17), ワクチン(39), B(34), 中止(21)
■いつまでコンピュータで消耗しなきゃならないの？ /20210527100955(32), ■酒タバコギャンブル薬以外で /20210527220752(24), ■スーパーカブは事故らない /20210527115035(24), ■そういう話じゃない スーパーカブ /20210526180451(20), ■チヤホヤされるのは嬉しいけど男はキモい /20210526202537(19), ■素手でうんこをつかまされた /20210527011354(14), ■anond：20210527000044 /20210527000429(13), ■ドラクエの愚痴。 /20210527161226(12), ■宗教差別ってあんまり話題に上がらない気がする /20210527034931(11), ■人類って案外賢くないのかも /20210527074616(11), ■ /20210526204209(10), ■職場での挨拶問題 /20210527195515(10), (タイトル不明) /20210527113140(9), ■ /20210526132741(9), ■あっさりマスコミの誘導に乗っちゃう人々 /20210526202046(8), ■セルクマはシステム上で禁止すべき /20210527093801(8), ■後発が劣化しているのに古いのを使うと老害と言われる例 /20210522105612(8), ■漫画家が歳をとるとめちゃくちゃ絵が下手になって悲しい /20210527150621(8), ■しなびた個人勢vtuberが好き /20210527160131(8), ■男は女のそういうところを見ている /20210527150810(7), ■世間は男の性欲を甘やかしすぎだろ /20210527153756(7), ■食事が好きすぎる /20210526234417(7), ■数学と、数式をプログラムに落とし込む書籍教えて欲しい /20210527102709(7), ■新人VTuberの毒島あかりと申します。 /20210527121410(7), ■もっとそういう話じゃない スーパーカブ anond：20210526180451 /20210527101944(7)
CLIって、「利用者の知能指数150以上」みたいな要求があるもんだとおもってる。そもそも論として。
デファクトスタンダードになったデザインを変えるのは難しい。だが増田が安心して老後を過ごせるように現状に楔を打ち込んでいくぞ。
対話式のものが色々あるって話ではなくて、対話無しのコマンドを組み合わせて自動化するのが簡単ってことでは？
そもそも CLI みたいなコードしか元々理解できないのがコンピュータなんだよ。
初期の DOS にはグラフィックなんてなかったし、それは Linux でもなんでも一緒。
その CLI でできること（＝プログラム）の一部をグラフィックで使えるように後付けされたのが GUI だ。
どんな GUI のプログラムも最終的には CLI のようなコードに変換されて動いてる。
そして、CLI でできることのうち、よく使うものを GUI のメニューとかから使えるように
（CLI のコードに加えて）プログラムを作成するわけだから、GUI の方がコストが増えるに決まってる。
CLI でできる処理の組み合わせは無限にあって、いちいち CLI の全パターン分の
メニューやボタンなんて作ることはできないので、CLI に比べて GUI でできないことの方が多いのも当然。
結局、GUI でできないってなったら CLI に戻るしかないということだな。
これはコンピュータのベースの部分がこの仕組みで動いている以上、
ユーザーの言う通りに動くようにしてたらコードがスパゲッティ化して訳分かんなくなりやすい。
CLIのプログラミング環境って話があまり一般的な話ではないから誤解した。
というのも、Androidアプリとかを作りたい場合は環境がGUIになるのは必然だが、インフラ側で動作するスクリプトを書く場合は、GUIのない環境でCLIだけでコーディングする場合があるからCLIを使う場合も多い。
書く量は少なかったとしても、結局GUIがあるってだけで保守コストが増えるんだよね...
例えば形態素解析機を作りたいってときに、ライブラリとかCLIとかで作るのはわかるけど、そこにGUIをつけようとは思わない。
