  |
はてなキーワード: シェルスクリプトとは
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
この記事はよく調べてあるなぁと思う反面，事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが，空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから，安易に『UNIX 哲学』とかいうな」という主旨には大賛成である。
初期の UNIX の歴史について興味がある向きには次の書籍をお薦めする。
Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)
和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが，原書は The Unix Heritage Society (tuhs) で PDF が無償公開されているので，英語が苦にならないのなら読んでみるといい。
また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』（1989, Prentice Hall）を読めば80年代終りの UNIX の状況（XENIX についてもしっかり言及されている）や利用者目線での雰囲気もある程度判るだろう。
元記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ，当時は設計の基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。
https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date
ほぼ毎号のように出現していたのが判るだろう。
もっとも猫も杓子も「哲学」を振りかざしていたわけではないし，UNIX の開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT＆T の定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事で言及されているマキルロイの Forword の初出がこれで，ネットのアーカイブから PDF が入手できる。
この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本（全172ページ），第二部が UNIX に関する（Preface や Foreword を含む）論文22本（全416ページ）となっている。さて前述の PDF は OCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX の論文なのだ。もちろん論文の性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイの哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白い。UNIX の開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが，それまでにない新しい考え方に基づいた OS を開発しているという意識があれば，そういう言葉を選ぶのが自然な時代だったことは間違いない。
UNIX が認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい，あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが，そんなたいしたものではない。マキルロイの論文に影響を受けた布教のためのああいう説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本で最初期の UNIX 解説本のひとつである，村井純・井上尚司・砂原秀樹『プロフェッショナル UNIX』（1986，アスキー）には冒頭次のような一節がある。
オペレーティング・システムは，コンピュータを使うものにとっての環境を形成する基盤であるから，そのうえで生活する者の個性を尊重し，より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが，UNIX のオペレーティング・システムとしての個性ではないだろうか。
「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能のコマンド群のことで，これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性を尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが，たまたまガンカースだったというだけのことである。
そしてじつは UNIX の場合，布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが，その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。
UNIX は PDP というミニコンピュータ（ミニコン）上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は，もちろん場所によって違うわけだが，マアおおよそ学校の教室くらいの大きさだ。長机が何列か並んでおり，そのうえにはブラウン管ディスプレイとキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校にコンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器はコンピュータではなくコンピュータに接続するための端末装置（ターミナル）だ。端末装置のキーボードで打った文字がコンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 Unix 系 OS で CLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置のエミュレータで，もともとは実体のある装置だったわけだ。
さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥や洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっともコンピュータが何台もあるわけではない。この箪笥が CPU でそっちの洗濯機がハードディスク，あの机に置かれているタイプライタが管理用コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて，なんてミニ！」という時代のお話だ。
端末装置それぞれから（USB のご先祖様の）RS-232 という規格のアオダイショウみたいなケーブルが伸び，マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び，root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。
結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは，マアどうでもいい。
当時の UNIX の評価を一言で表すと〝自由で不安定な OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由。さらに他のメインフレームやミニコン用 OS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロ用 OS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番のディスりだった。UNIX の落とし方，みたいな情報がなんとなく廻ってきたものだ。
こういった雰囲気を鮮やかに伝えてくれるのが，高野豊『root から / へのメッセージ』（1991，アスキー）だ。当時アスキーが発行していた雑誌『UNIX MAGAZINE』に連載されていた氏のエッセイの1986年11月号から1988年10月号掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器で1980年ごろから UNIX サイトのスーパーユーザを務めており，日本では最古参の一人である。この本の中で高野氏は繰返し UNIX の自由さと不安定さに言及している。すこし長くなるが，その中の一つを引用しよう。
CPU は，システムにとって重要な共有資源であるが，この CPU を実質的に停めてしまうことが UNIX ではいとも簡単にできる。たとえば，cc コマンドを10個くらい同時に走らせてみたらよい。VAX-11/780 といえども，同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが，他に与える影響が無視できなくなる。つまり，てきめんに vi のカーソルが動かなくなる。あるいは，すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり，タイムアウトでログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると，UNIX は破壊されたに等しい。真夜中，独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし，20人30人と多数の人間が使っているときに勝手をやられると非常に困るのである。当人の仕事が遅れるのは自業自得だとしても，そのとばっちりで他のエディタまで止まってしまうと，もはやどの仕事も進行しなくなる。
ディスクについても同様なことがいえる。UNIX では，ファイルシステムを使いはたすまで大きなファイルを自由に作ることができる。したがって，自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと，コンソール・タイプライターにエラー・メッセージが出力されるが，夜中にそれが発生して，コンソール・タイプライターが一晩中エラー・メッセージを打ち続け，朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい，ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると，それをしでかした本人のプロセスは当然のこととしても，同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい，わずかでも仕事を先に進めようとする意図も完璧に打ち砕かれてしまうのである。
そして，こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンドを10個くらい同時に走らせ」たり「自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイトの利用者全員に UNIX の設計の基本的な考え方を理解してもらうことが，自分のために必要だった。UNIX の伝道がより苛烈だった理由のひとつがここにあるのだ。
ミニコン上で誕生した UNIX は 4.3BSD（1986）で最高潮を迎える。注意したいのはミニコン時代の UNIX は Research UNIX と CSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX と記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT＆T から UNIX のライセンスを購入し，そのうえでカリフォルニア大学バークレー校（UCB）から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研で発明された UNIX を外部の人たちも含めみんなで改良し，それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。
もっともそういう70年代風味の牧歌的風景はミニコン世界限定の話であった。BSD そのものはミニコン用のものしかなかったが，そのコードを受け継いだ BSD 系 Unix や AT＆T が推し進める System V などがワークステーション市場を舞台に80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で，PC 用 Unix であるマイクロソフトの XENIX も当然参戦した。ミニコン世界が牧歌的だったのは，ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争はあくまでも標準という聖杯を争う戦いであり，AT＆T と BSD 系 Unix の Sun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。
こうしたミニコン UNIX からワークステーション Unix への転変は Unix そのものや文化にも変化をもたらした。まず激しい競争は Unix の高機能化を加速した。商品として判りやすい惹句が「あれもできます，これもできます」なのは誰もが知っている。もちろん安定性を増すために quota のような利用者の自由を制限する機能も含まれていた。またワークステーション Unix は現在の Unix 系 OS と同様同時に一人が使うものであり前述の布教の必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』（1993，オーム社）を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unix のシステム管理の入門書だ。この本ではたんに知識を羅列するかわりに架空のソフトウェアハウス（開発会社）を舞台に新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており，そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。
当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイの論文の結論部分に書かれたそれは，1973年に出版されたイギリスの経済学者エルンスト・シューマッハーの著作の題名で，中学生の英語力があれば十分に理解できる平明な一文だ。
Small is beautiful.
マキルロイは『人月の神話』を引いて一定の留保をつけてはいるものの，これが UNIX 哲学の背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•cs のアンチテーゼである UNI•x にとって，これ以上のスローガンがあるだろうか？
ひるがえって現在の Unix 系 OS をみれば，ブクブクと肥え太ったシステムコール，全容を俯瞰するだけでも一苦労するライブラリインターフェイス，一生使うことのないオプションスイッチまみれのコマンド群。UNIX が仮想敵とした OS そのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ，コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ，歴史書を飾る一項目になっただけだ。ただ現在「UNIX 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
315あとで/2676users じゅじゅ on Twitter: "ネット上にある、完全無料で勉強になる有益なコンテンツまとめました。 （お金/資産形成、Excel、仕事術、資料作成、英語、ファイナンス、統計・データ分析、プログラミング、ITなど） GWでなにか勉強したいな～、と思っていた方はぜ… https://t.co/wHbkKFUnFM"
303あとで/1947users ITエンジニア採用入門 | てぃーびー | Zenn
262あとで/2510users 2000時間の遠回り英語学習を経てたどり着いた、1日30分でネイティブの会話が聞き取れるようになる練習法 | anond.hatelabo.jp
255あとで/1643users 「時間がない」症候群、その傾向と対策 | NAVITIME JAPAN | SpeakerDeck
252あとで/1809users デザインのしたじき – コ・デザインのためのシンキングシート | 株式会社グラグリッド
230あとで/1314users 本当は教えたくないWebデザイン参考ギャラリーサイト30選【2022年版】 - PhotoshopVIP
228あとで/1665users ソフトウェアエンジニアでテストマンな私が家を買う際にやったこと - 若くない何かの悩み
225あとで/2050users 中日新聞:自動車工場のガロア体 ＱＲコードはどう動くか
206あとで/1852users 「便利になる」だけでは人は動かないし、「当事者意識をもってくれる人」はめちゃ貴重だという話 | Books＆Apps
200あとで/1325users 君には今から3時間で機械学習Webアプリを作ってもらうよ | alivelimb | Zenn
192あとで/1944users オンラインゲームでは、お互いの位置がだいぶ離れていても (日本とブラジルくらい) 何故素早く同期できるのですか？どのように通信しているのでしょうか？に対するNakamura Yutaさんの回答 - Quora
191あとで/1472users 人気エントリーで増田の１５年の歴史を振り返る | anond.hatelabo.jp
189あとで/1371users 新疆公安ファイル | 毎日新聞
181あとで/1518users じゅじゅ on Twitter: "英語に少しでも苦手意識がある人のための、英語関連神ツール9選 https://t.co/2W9ZwzIdL6"
177あとで/1430users 君はインド最大（多分世界最大）の無料MOOCの「NPTEL」を知っているか。 | anond.hatelabo.jp
159あとで/914users なぜ今シェルスクリプトを学ぶのか・シェルスクリプトのTips - 理系学生日記
156あとで/1328users 楽器できないヤツのためのDTM入門【追記あり】 | anond.hatelabo.jp
154あとで/878users 超上流から攻めるIT化の事例集：システム化の方向性と計画：IPA 独立行政法人 情報処理推進機構 社会基盤センター
149あとで/991users Chrome拡張 つくりかた 令和最新版 | r7kamura.com
149あとで/1123users 197冊の教えを1つにまとめた黄金律の教科書 - 本しゃぶり
135あとで/748users VSCodeおすすめ設定大公開！！おすすめ拡張機能も - Qiita
133あとで/984users あなたにとって適切な転職先か判断するための面接時の逆質問20選 | ちばキャリPLUS
126あとで/745users データベース設計におけるNULL - kawasima
120あとで/755users Markdownでシーケンス図とかが書けるMermaid記法で業務フローを書いたら意外とイケたので自分なりのコツを紹介してみる | DevelopersIO
118あとで/928users 【夫婦で開発】1年かけて1週間を振り返えるアプリを本気で開発してみた | wheatandcat | Zenn
117あとで/628users Python だけで作る Web アプリケーション(フロントエンド編) | alivelimb | Zenn
112あとで/612users 質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition | 和田卓人 | SpeakerDeck
112あとで/1400users ノア・スミス「日本の生活水準，低すぎ」（2022年5月24日） | optical_frog | 経済学101
111あとで/1825users 名前も知らない人のアカウントを2年かけて特定したら人生が確変に入った｜四月｜note
111あとで/730users ソフトウェアエンジニア、家を建てる - ここぽんのーと
ウイグルのジェノサイドについて中国の内部資料が流出、公開された件については毎日新聞の特設ページが入った。
お役立ち系の増田が4件もランクインした。ここ1,2年は増田のホットエントリ入り件数も減少傾向で推移してきたけれど今月は急に増えた。
しろよ
……。
なんで対処ができないんだろう
しなくてもなんとかなってるから？というのは「対処ができない」の理由じゃないな
めんどうなのはどうして？
←毎回方法を考えてるから（逆に実践に移してることが一度もない）
←実践に移すとき、自分だけだったら次の日になったら忘れてるし、他の方法がいいかもとかなるから
他の人に言わないのはどうして？
←リアルだと人によっては理解得られないこともある（そんなことなかったけど）
趣味とかオープンにするのがかなり恥ずかしいと思ってる節があって同じ感じで恥ずかしいから（プライド高い？）
忘れちゃうのはどうして？
そう思わないことがあるのはどうして？
→そう思っちゃうのはどうして？
積極的に人と違う道を選ぶのとただ何もしない結果人と違う道になっていくのと、前者のみが面白くて後者はオリジナリティのないありがちな人生なのに勘違いしてるから
－－－－－－－－－－－－
さらに箇条書きを増やして一個一個潰してこ
思い付きで繋いでるだけだもんな…
2/19
ちなみに今日は期限のある仕事ほっぽりだして自動化のためのシェルスクリプトを書いてて、それで型を作ったらいいかと思い当たったのかもしれない
個人的にTcl/Tkの今の立ち位置は、これはこれでありというか、
例えば、何か新しい言語ができると、まずTkをバインディングしてGUIも作れます！するとかなんだけど、
Tclはオブジェクト指向なの作ってたけど、頓挫してしまったというか、
まあ、MacPortsがTclだったか、所詮シェルスクリプトの延長なので、
Tclはこれはこれでこのままでもいい気もする
TkとかFltkとか、GUI周りは動作するOSとか環境に振り回されがちだし、
独自のレンダリングとかlook and feelを貫き通してもいいんだけど、
それもまた夢がないというか、古臭いイメージが漂いすぎてしまうんで、
Tkもナウでヤングな若者にウケるようにしようぜ、って動きが20年近く前にあって、
こっちもほんのちょっとだけ手伝ってたんだけど、
最近、ネット彷徨ってたら昔懐かしい次世代Tcl/Tkの話を読んだんだけど、
まあ、Pythonだよね！
猫も杓子もPython！
蛇が嫌いなおいらはどうすればいいの？と思ったけど、
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
作業効率化のためにシェルスクリプトで書いたツールは今も使っているが、JavaやRubyやPythonで作ったツールはほとんど使っていない
JavaやRubyやPythonは、何でもできてしまうから、ちょっとしたフォーマットの変更などで変更や拡張が頻繁になされるし、その結果プログラムは肥大化する
一方、シェルスクリプトは得意不得意が極めて明確で、扱うデータにはかなり強い制約がかかる。その結果、本質的な機能以外の変更に晒されることが少なく、個々のプログラムは単機能疎結合になりやすい。
というか、「まともなデータ構造が無いからデータに強い制約をかけないと実用的なプログラムを書けない」「構文やモジュール機構が貧弱すぎて単機能にしないと読めなくなる」ので、ある程度センスのある奴なら必然的に良いスタイルでプログラミングすることになる。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
288あとで/2715users 大学の恩師に教わった、「なにがわからないか、わからない」ときの質問のしかた。 | Books&Apps
281あとで/1814users 最初の一歩を踏み出すという汎用的な技術 - 本しゃぶり
250あとで/1465users 線形代数をアニメーションで幾何学的に簡単に理解できる36記事まとめ | HEADBOOST
236あとで/1717users ASCII.jp：天才プログラマー・オードリーさんがたった200行で効果的なアプリを作れる秘訣
221あとで/1568users 「140秒とは思えない満足感」「なぜこれだけの傑作が埋もれているのか」 崩壊した日本を旅する“最後の動画配信者”のショートフィルムが話題（1/2 ページ） - ねとらぼ
215あとで/1805users メルカリが検索に「売り切れ品」を置く理由、初期のLINEが友だち追加を「電話番号マッチング」に絞った理由など、アプリのマーケティング施策まとめ30｜アプリマーケティング研究所
189あとで/1454users 暇を潰せそうなサイトを沢山見つけたので貼りまくる:哲学ニュースnwk
174あとで/1269users メルカリ、「無意識（アンコンシャス）バイアス ワークショップ」の社内研修資料を無償公開 | 株式会社メルカリ
161あとで/1028users 文系パパエンジニアが放送大学等でコンピュータサイエンス・数学を学んで理系学士を取りに行く話 - とあるCS学徒のブログ
154あとで/906users Google TypeScript Style Guide
151あとで/1192users ゲームを作ったらハリウッドから映画化オファーが来た話 - Hirayaブログ
141あとで/1330users オーケーとその他スーパーたち - 14店舗のフィールドワークと500人のアンケートでわかったシンプルな結論｜太田正伸｜note
139あとで/819users 『ゼロからのOS自作入門』に込めた思い - uchan note
134あとで/712users 元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL
133あとで/1430users 游ゴシックの話題の解説 | anond.hatelabo.jp
132あとで/1127users 36歳で印刷会社の社長になった僕が、減り続ける売上をなんとか立て直した話｜工藤太一／印刷会社二代目／glassy株式会社代表取締役｜note
128あとで/799users Linuxの基礎用語を完全理解するためにエンジニアが作成した「10のミニプロジェクト」とは？ - GIGAZINE
127あとで/795users よく見かけるレイアウト・UIコンポーネント、それだけを実装するHTMLとCSSのシンプルなコードのまとめ | コリス
126あとで/1200users 「こんなん履いててプログラミングできるわけない」天才プログラマー登大遊氏が情熱大陸に登場、名言を連発しザワつくTL - Togetter
124あとで/543users 仕組みから理解する Git 入門 ~ ひとり開発でも便利 ~ - Speaker Deck
123あとで/612users Webエンジニアが勉強できるGit Repository 10選 - Qiita
118あとで/848users シェルスクリプトを書くときにいつもやるやつを調べた - Please Sleep
117あとで/990users 「SEOに強いHTMLの書き方」についての個人的な見解 | TAK | Zenn
117あとで/645users 英語力と技術力向上のための海外Tech系Youtuber10選 +n - Qiita
117あとで/1337users EXPERIENCE JAPAN PICTOGRAMS | 日本デザインセンター
117あとで/882users 管理職のための役職引退マニュアル | DevelopersIO
116あとで/1931users 森氏辞任に考える 日本社会に残る無意味な風習: 日本経済新聞
115あとで/1126users いとうまい子「アイドルだった私が遺伝子の研究者になるなんて」｜芸能｜婦人公論.jp
114あとで/617users 「挑戦させすぎ？」マネジメント勉強会で分かった組織課題とその解決策 - ZOZO Technologies TECH BLOG
114あとで/646users GitHubのawesomeリストが本当にawesomeなものばかりだから一度見てほしい - Qiita
最初のプログラミング言語として最もおすすめなのは、Bourne (Again) Shell。通称sh(bash)です。shはUNIXの標準的なシェルであり、bashはその拡張です。現在、多くのLinuxディストリビューションでは、bashが標準のシェルです。以下、これらのシェルの上で動作するコマンド言語およびそれによって作られたプログラムを指して「シェルスクリプト」と呼ぶことにします。
シェルスクリプトを最初のプログラミング言語におすすめする理由は、主にその実用性にあります。ほとんどのプログラミング学習者にとって、プログラミングで実現したいことは、「10000以下の素数を求める」などの教科書の課題のようなものではなく、大量のファイルから情報を検索するとか、インターネットから定期的にコンテンツを取得する、などの具体的なタスクのはずです。シェルスクリプトを使えば、後者のような実用的なプログラムを手軽に作成できます。一方、多くのプログラミング入門書には、制御構文などの細かい説明はあっても、後者のようなトピックはあまり載っていません。というのも、そのような機能は汎用的なプログラミング言語（C、Java、Python、Rubyなど）のコアの機能ではないからです。それらの機能は通常、ライブラリによって提供されます。したがって、汎用的なプログラミング言語で実用的なことをしようと思えば、外部モジュールの読み込みや、場合によってはパッケージ管理ツールを使ったライブラリのインストール方法などを学ばなければいけません。これらは、初学者にはいささかハードルが高いです（たとえば、Webフロントエンドのツール群を初学者が独学でインストールするなどは、ほぼ不可能でしょう）。一方、シェルスクリプトでは、grep、sed、awkのようなシェル上のユーティリティは全て、他の言語における組み込みの関数と同様です。つまり、モジュールのインポートや初期化処理などを行わずに使用することができます。
また、シェルスクリプトは、より本格的な言語やフレームワークへステップアップする過程としても非常に適しています。プログラミング入門書ではほとんど語られないことですが、プログラミングにおいては「プログラミング言語以外の技術」がプログラミング言語自体と同様に重要です。たとえば、ファイルやディレクトリを操作するには、OSのファイルシステムにアクセスしなければいけませんし、インターネットからコンテンツを取得するには、HTTPというネットワークプロトコルを知らなければいけません。シェルスクリプトを使う場合、それら「プログラミング言語以外の技術」を自然に利用します。それらは、プロのエンジニアを目指す上でも欠かせない知識です。また、多くのプログラミング言語では、制御構文を用いて変数の値を更新していくプログラミングスタイルが取られます。一方、シェルスクリプトでは、コマンドの出力を他のコマンドの入力に渡してデータを変換するプログラミングスタイルが取られます。後者のスタイルは、現代のソフトウェア開発では多くの場合、良いスタイルだと認識されています。シェルスクリプトを最初に学ぶことで、そのような良いプログラミングスタイルが身につきます。
シェルスクリプトを体系的に学ぶならば、次の文献が信頼できます。
なんか以前からずっと思ってたんだがRailsというかRuby界隈は宗教というか自己啓発ビジネス臭さえするのがイヤだ
金持ち父さん…とか７つの習慣とか、そういう詐欺のカモっぽい人も多いイメージがある
しかし、Ruby登場当初からやたらとエレガントに書ける、スッと書ける（この「スッ」という表現も詐欺で多い表現なので嫌い）とか、
そんなことは個人的にはどうでも良くて、ソフトウェアを使うユーザーは機能が便利かとかそういう視点でしか見ない、悲しいけど
保守の観点からも美しいソースコードを書こうという意気込みは間違っていない、というか正しいと思う
しかし、プログラマーが美しいコードが書けたと悦に浸る、自己満足におちいっているだけのようにも見えるのが納得いかない、不愉快にさえ思える
C++やJavaのような型のあった時代から、型なんてダセーよな、プレステの方が全然おもしれーよな、を経て、また型に戻ってきてる
型推論云々にかまけてパフォーマンスよりも綺麗なコード、富豪プログラミングからまた元に戻ってきてる
学習コストが高いものほど評価されるような傾向も個人的には感心しない
どうせ同じゴールなのに、そこに辿り着く方法が険しいほど評価されるなんて、プログラマーの美徳の怠惰だのから逆行している
実によろしくない
そういう点ではRustよりもGoやC#の方が評価できる気がする
もちろんRustの守備位置はそこではない気もするので単純比較はおかしいのだけど、ゴールが同じなら自分はC#やJavaで書いて終わらせるのにと思うことがある
別にWebだけでなくコマンドラインでの捨てコードにPHPやJavaScriptも適している
そういう意味ではPythonはやはり強い、Glueだからだろう
正直PHPなんかよりPythonの方が言語としてはおかしい気もするのだけど、正しいとかエレガントが生き残る条件ではないのである
しかし、学習コストとしては低いシェルスクリプトは便利ではあるが流石に古いというか罠が多い気がする
PowerShellの方が使える気がする、少なくともWindowsでは優先的な選択肢になった
生き残るというのはそういうことではないのではないか
プログラミングを生業にするために一番簡単なのは、未経験可・学歴不問でエンジニアとして雇ってくれる会社に入社することかと思います。
自分は専門学校や大学に行かずに実践からプログラマになったクチですので、
以下、ご参考にしていただければと思います。
1. 普通科高校卒業（当時PCを持っておらず、プログラミング経験ももちろんなかった）
2. 高校出た後プログラミングとは全く関係ない仕事を数年やる。飲食とか色々
3. 2に限界を感じてプログラマーに転職。未経験可・学歴不問のSIerで派遣プログラマーとして雇ってもらう。プログラマーを選んだのは、当分食いっぱぐれなさそうだから。与えられた課題を解決するために必死で勉強したのでここで基礎ができたと思う。最初は先輩エンジニアがお題を色々くれて、そのお題の中で必要な知識を解説してくれた。大抵は先輩が開発しているシステムの一部の小さい部品がお題になっていた。ディレクトリを指定したらその中のファイルから特定の文字と数字のセットを抜き出して数を足し合わせるシェルスクリプト、とか。ある程度慣れてきたらバグ修正や機能追加のタスクをふってもらえるようになった。一つ一つのタスクが勉強になりました。
5. 何度か転職を繰り返し、500人規模のIT企業で正社員＋副業で受託開発に落ち着く
https://tech.nikkeibp.co.jp/it/article/COLUMN/20090702/333080/
すべて「Bash」と呼ぶスクリプト言語で記述する。しかもデータベース管理ソフトを使わず、データはすべてテキストファイルで管理する。「ミドルウエアのオーバーヘッドがない分、処理も速い。ごく普通のパソコンで動作させても、25万件の商品データなら2秒程度で全件検索できる」と山崎課長は胸を張る。
情シス、ベンダーがそれぞれの仕事を全うすることがベストな関係を生む～良品計画がシステムを内製する理由
https://enterprisezine.jp/iti/detail/1380
「無印良品」ブランドでおなじみの良品計画。いまや海外15カ国にも展開するなど、好調な事業を支えるのが、“ユニケージ開発”と呼ばれる独特の開発手法だ。Linux標準装備のシェルスクリプトの他は、開発言語やデータベースなどを一切利用せず、1～2週間というきわめて短い開発期間で、次々にシステムをリリースしていく。
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
Z君と仕事をするようになって僕は雨男という存在を信じるようになった。
雨男と言っても、本当の天候の渕上様的な意味での雨男ではなく、「彼が参加したプロジェクトにはことごとくトラブルが発生する」という意味でだ。僕が知る限りでも、いくつかの転々としたプロジェクトやチームで
などなど、枚挙に暇がない。原因をたどると必ずしも彼一人の責任とばかりは言えないものだったり不可抗力的なものだったりする。にも関わらず彼のいるところでは明らかにそういうトラブルが頻発するので雨男なのである。
でも正直言うと、僕はやっぱり原因は彼にあると内心思っている。彼はとにかく粗忽で人並み外れてミスが多い。数行のメールの中で一行目と二行目で矛盾したことを書く。指示をことごとく間違って解釈する。やらなくていいことをわざわざやってミスを作り込む。報告の内容が何度聞いても要領を得ない。そしてミスや問題を隠す。一つ一つのエピソードは笑えるものもあるし新人の可愛い女の子だったらドジっ子キャラで愛されるかもだけど、この業界で10年以上経験があってこれはどうなの。
と書くと絶対「ミスは誰にでもあるもの、チェックやレビューする体制をしっかりすべき、報告を隠さないような雰囲気を作れ」と言われるでしょう。うんわかりますよ、全くその通りだと思います、一般論としては。でもかなりのことはすでにやっていて、それでも彼の粗忽っぷりはさらにその斜め上を行っているので結果として周囲の負担がさらに大きくなっている。それがトラブルを招きこむ要因になってるとしか思えない。
彼は今は別の組織に異動したので今はうまくやっているのかよくわからない。やっぱり使えないと言われて突っ返されてこないことを祈るのみだ。
