  |
はてなキーワード: 入門書とは
自分はプログラミングほぼ未経験（大学の学部時代にCのコードを写経して動かすと単位がもらえる謎の講義に出たことがあるぐらい）の状態から、社会人になってから独学でPHPを勉強していわゆるweb系のソフトウェアエンジニアに転職した。以後8年近くソフトウェアエンジニアとして働いている。
初心者向けのプログラミングスクールの話題が尽きないが、スクールに通わなくても独学でもなんとかなった自分みたいのもいるよ．という例を紹介してみたい。このエントリがプログラミングに興味がある人の役に立てば幸いである。昔の話なので出てくる話題が古いのはご勘弁いただきたい。
なお、web系のソフトウェアエンジニアになる前は、上流系SIerでExcelと顧客折衝をがんばるSEをしていた。基本情報ぐらいは持っていたがコードを書く業務は一切なかった。
菜食主義・ベジタリアン・ヴィーガンの議論（直近だと anond:20201226231316 に対するコメントとか）において、特に肉食側からの倫理的な議論が少ないように思えるので、簡単ではあるが、倫理的な観点からの肉食擁護を書いてみたい。
私はあくまで素人であり、以下の文章は個人の見解以外の何物でもないことは最初に断っておく。
肉食を倫理的観点から批判する際の最も大きな論点は「種差別」である。種差別とは、「単に種が違うからという理由だけで、ヒトとそれ以外の動物を差別すること」である。肉食が相手の"命"を奪う行為であることは万人が認めるだろう。また人間同士では相手の"命"を奪う行為に大きな制限をかけるべきであるということも大多数は認めるだろう。であれば、「"命"を奪うことについて、相手が人間以外の動物だからという理由で人間と同じだけの制限をかけないのは差別である」というのが種差別の考え方である。
この考え方は性差別や人種差別の形式と近い。例えば、男性の利益を"男性だから"という理由で優先して、女性には"女性だから"という理由で配慮しないことや、白人の利益を“白人だから”という理由で 優先して、黒人には“黒人だから”という理由で配慮しないことは現在では大多数の人が差別であることを受け入れている。同じ用に、人間の利益を"人間だから"という理由で優先して、人間以外の動物には"人間以外の動物だから"という理由で配慮しないことは差別であるというのが主張になる。
一方で、関係する全員に対して平等な考えに基づいた適切な理由によって、ある存在と別の存在の取り扱いを変えることは差別ではなく、倫理的に問題はない(※ここでいう差別とは”不公正な扱い”を意味しており”不平等な扱い”ではない)ことも重要である。「菜食主義者だって植物の"命"を奪っているじゃないか！」という批判はよくあるが、多くの菜食主義者は"苦痛を感じる能力(sentient)"の有無を理由にして動物と植物を区別しておりそこに倫理的な問題はないと考えている。（なお、植物本体を傷つけない果実のみを食べるフルータリアンはこの点で他の菜食主義者を批判する）
このように倫理的な観点から肉食を擁護するためには、人間が動物を食べることについて、すべての生命に対して平等な考えに基づいた適切な理由を検討して採用する必要がある。
すべての生命に対して平等な考えに基づいた適切な理由を検討といっても、何から手を付ければよいのかは難しい。考え方はいくつもあるが、ここでは、伊勢田の「動物からの倫理学入門(2008)」の議論を元に進めていく。余談だが、この本は倫理学の入門書としてはかなりオススメである。タイトルからは菜食主義の本のように思えるがそうではなく、各主張を紹介した上で応用の一つとしてそれを動物に当てはめるとどうなるかを検討している。また、伊勢田自身は菜食主義者ではないとのこと。
伊勢田はこの本で下記のように主張している。
④認知能力や契約能力等、動物と人間を区別する道徳的に重要な違いとされている違いは人間同士の間にも存在する（すなわち、限界事例の人たちが存在する）
これらの組み合わせから容易に「動物にも「人権」があり、危害を加えてはならない」という結論が導ける
（p320 終-3 結局動物とどう接すればよいのか）
「①～⑤を認めると動物に危害を加えてはならない」ことが正しいとすると、肉食を擁護するためには少なくとも1つを削除する必要がある。それは①～⑤のどれにすべきだろうか？
普遍化可能とは、簡単に言えば"ある状況である倫理判断を善いとするなら、同じような他の状況でも同じ倫理判断を善いとしなければならない"ということである。例えば、私が借金を貸す側のときに「借金を返さないことは悪いことだ」と言うならば、借りる側のときも同様に「借金を返さないことは悪いことだ」と言わなければならない。
これを削除すると、多くの倫理判断や社会のルールが無効化されてしまう。例えば、貸し手のときは「借金を返さないとダメ」と言いながら、借り手のときは「返さなくても問題ない」と言えてしまう。こうなると強者が弱者を思い通りにできる（少なくとも倫理の観点から批判することは出来ない）社会になるが、それを良いとする人は少ないだろう。また「人間と動物はお互いを殺してよいし、両者ともそれに抵抗してもよい」という方向で普遍化することも可能だが、それでは「人間は人間を殺してもよい」を否定する理由が難しい。
（双子を除いて）完全に同じ遺伝子を持つ人間がいない以上、遺伝的差異を差別の理由とするのは難しい。例えば肌の色を黒くする遺伝子を持つから差別していいとは多くの人は賛成しないだろう。生物学的種を考えて、交配して子孫を残すことが可能かという観点で区別するという主張はあるかもしれない。だが種差別の議論を考えると、交配の可否を"なぜ"差別の理由としてよいかを説明することは非常に難しい。また、（進化論を認めれば）すべての生物は連続しているので、AとB、BとCは交配可能だがAとCは交配不可というA, B, Cが絶滅種も含めれば必ず存在する。Aの立場で考えて、Aと交配可能なBは差別してはいけないが、差別してはいけないBと交配可能なCは差別して良いとするのはルールとしての一貫性を欠くだろう。
確かに、例えば未来の概念や愛の概念の有無などによってその苦しみの程度は異なるだろうし、動物の権利を主張する人たちも犬と人間が溺れていた場合に、より苦しみが大きいであろう人間を優先して助けることを否定するわけではない。しかし、多くの動物が少なくとも痛みや苦しみを感じる(sentient)ことは事実であり否定はできない。
先にも書いたように、多くの菜食主義者はこの③について、「脳を持たない植物（主張によっては一部の貝なども含む）は人間を含む動物と同じようには苦しみを感じない」として植物と動物を区別し、植物を食べることに問題ないと考えている。「植物も実は苦痛を感じているかもしれないじゃないか」というのもよくある批判だが、これはあまり意味のある問いではない。確かに植物も苦痛を感じている"かもしれない"が、動物は"明らかに"苦痛を感じている。何かを判断するときに、よくわからないことが1%あるから残りの明らかな99%も無視して良いとはならない。また、将来もし植物が"苦痛"を感じることが明らかになった場合は、菜食主義者の多くはフルータリアンなどに態度を改めるだろう。
これも事実であり否定はできない。人間の知能を動物の知能と直接比較すること（牛は人間でいうと何歳程度の知能か？など）はほぼ不可能であるが、それでも例えば0歳児や重度痴呆症、ある種の知的障害者などの限界事例の人たちと比較して牛や豚や鳥のほうが"賢い"と考えることは大きく間違っているとは言えないだろう。
③に関係して、動物も人間と同じ用に苦しむのは事実だが、動物を苦しめずに殺すことは問題にならないと主張できるかもしれない。未来の概念がなければ生活計画を持たずにその時だけを生きているので、殺害して未来を奪うこと自体は倫理的に問題がなく、苦痛を与えることだけが問題であるという主張である。また、④に関係して、認知能力や契約能力などの"賢さ"によって人間と動物を区別でき、"賢くない"動物は殺しても良いと主張できるかもしれない。
しかし、これらの主張からは、未来の概念がない人間や"賢く"ない人間=限界事例の人たちを殺しても良いという主張が直接的に導かれてしまう。もし、限界事例の人たちを殺すのは良くないと考えるならば、その根拠は人権であろう。であればこれを否定することも難しい。そして限界事例の人たちに人権を認めるなら、動物たちに「人権」を認めないとするのは一貫性に欠ける。
以上のように①～⑤を検討してきたが、どれも削除するのはなかなか大変そうだ。「現代の代表的な倫理学者で動物の問題について発言している人はほぼ例外なく動物が直接の配慮の対象になるべきだという立場である（伊勢田, 2008）」というのもよく分かる。
しかし、倫理的な観点から肉食を擁護するためにはどれかを削除する必要がある。私は差別者であるという批判を受けることは承知の上で、⑤を削除することを提案したい。
最初のプログラミング言語として最もおすすめなのは、Bourne (Again) Shell。通称sh(bash)です。shはUNIXの標準的なシェルであり、bashはその拡張です。現在、多くのLinuxディストリビューションでは、bashが標準のシェルです。以下、これらのシェルの上で動作するコマンド言語およびそれによって作られたプログラムを指して「シェルスクリプト」と呼ぶことにします。
シェルスクリプトを最初のプログラミング言語におすすめする理由は、主にその実用性にあります。ほとんどのプログラミング学習者にとって、プログラミングで実現したいことは、「10000以下の素数を求める」などの教科書の課題のようなものではなく、大量のファイルから情報を検索するとか、インターネットから定期的にコンテンツを取得する、などの具体的なタスクのはずです。シェルスクリプトを使えば、後者のような実用的なプログラムを手軽に作成できます。一方、多くのプログラミング入門書には、制御構文などの細かい説明はあっても、後者のようなトピックはあまり載っていません。というのも、そのような機能は汎用的なプログラミング言語（C、Java、Python、Rubyなど）のコアの機能ではないからです。それらの機能は通常、ライブラリによって提供されます。したがって、汎用的なプログラミング言語で実用的なことをしようと思えば、外部モジュールの読み込みや、場合によってはパッケージ管理ツールを使ったライブラリのインストール方法などを学ばなければいけません。これらは、初学者にはいささかハードルが高いです（たとえば、Webフロントエンドのツール群を初学者が独学でインストールするなどは、ほぼ不可能でしょう）。一方、シェルスクリプトでは、grep、sed、awkのようなシェル上のユーティリティは全て、他の言語における組み込みの関数と同様です。つまり、モジュールのインポートや初期化処理などを行わずに使用することができます。
また、シェルスクリプトは、より本格的な言語やフレームワークへステップアップする過程としても非常に適しています。プログラミング入門書ではほとんど語られないことですが、プログラミングにおいては「プログラミング言語以外の技術」がプログラミング言語自体と同様に重要です。たとえば、ファイルやディレクトリを操作するには、OSのファイルシステムにアクセスしなければいけませんし、インターネットからコンテンツを取得するには、HTTPというネットワークプロトコルを知らなければいけません。シェルスクリプトを使う場合、それら「プログラミング言語以外の技術」を自然に利用します。それらは、プロのエンジニアを目指す上でも欠かせない知識です。また、多くのプログラミング言語では、制御構文を用いて変数の値を更新していくプログラミングスタイルが取られます。一方、シェルスクリプトでは、コマンドの出力を他のコマンドの入力に渡してデータを変換するプログラミングスタイルが取られます。後者のスタイルは、現代のソフトウェア開発では多くの場合、良いスタイルだと認識されています。シェルスクリプトを最初に学ぶことで、そのような良いプログラミングスタイルが身につきます。
シェルスクリプトを体系的に学ぶならば、次の文献が信頼できます。
入門書の第6章くらいで「これまでやってきた長文の処理をなにかちょっと上位の概念で短く置き換えるのでこの部分全消ししましょう」みたいなのがあると
「ここでリファクタリングとテストの概念ぶち込め！新しく書き換えたが動かない・前と同じ動作かどうか確証持てないって点で学習中一番ご利益あるシーンやぞ！！」
と思うのだが、やってる入門書は見ないな
まあ寄り道にもほどがあるしな
1についてだけ。
＞分かるけれどこれでどうやって動画や音楽のエンコードをしたり画像処理をしたりするソフトウェアになるのか
エンコードに関してはプログラムはエンコードの理論に従って作られているだけ。大事なのは研究者の考えた理論
画像処理は定型の処理の塊でこれも代替やり方は決まってる。"python 画像処理"とかでググれば多分出てくる
＞あるいはWordとかExcelとかがどうやってこんなので作られているのかが分からない
まず基本的な、ウィンドウシステムがどのように実現されているかをWin32アプリベースでも
よいので理解するべき。ユーザーのマウス操作、キーボード操作をどのようにプログラムが認識し、
処理するかが理解できる。この仕組みは基本的にすべてのアプリで共通と思われ。
＞プログラミング入門書を読んでも、一般的に知られているソフトウェアの作り方みたいな事が書いてない
多くの人が共通的な作り方に挑み敗れているわけで、プログラムは10個あれば10通りの作り方がある。
また、クラスレベルで抽象化してソフトウェア構造を整理しようとする、オブジェクト指向(最近は
クリーンアーキテクチャに昇華させる流れもあり)もあるけれど、オブジェクト指向に向かない
対象領域があったり、なんでもクラス病にかかる等して、銀の弾丸とは言い難い。
また自説だが、順次処理を基本とする、手続き型言語はデータと処理が入り乱れることになるため、
全てを設定しきることが極めて困難なため、きれいにすべてを設計するのであれば関数型言語を使う必要が
あると感じている。
＞だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。
そのフレームワークが内包するベストプラクティスの量を鑑みれば、中身を意識せずに
＞つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
＞プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
＞これがもう滅茶苦茶イライラする。
天才的な人はコードを書きながら、考えられるけれど、常人はまず詳細設計と言われる
フローチャートを書けるようになったほうがよい。
次に"抽象化"を覚える。"抽象化"を使うことで少なくとも、処理は全体をざっくり設計できる
＞つまり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。
githubに山のように転がっている。
ただそれを見て理解できるかは別問題。モチベーションを保って継続学習可能な形に
消化できる人間の登場が待たれる
プログラミングで主にやる事は下記の2つ。
①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
とてつもなく複雑で冗長な処理によって実行されている。
わかりやすいので画像処理でいうと、数十万から数百万の画素（RGBAの24bitで表される数値）を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンをテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。
「まさかそんな事できるわけないだろ」というレベルの処理が実際に行われており、これまた直感的でない。
だからそれをどう書くんだよ。という答えはコレ。有名なjpegの実装だ。
libjpeg というライブラリを書くことはできるだろうか？画像の圧縮の理論から考え始めることはできるか？
正直無理だ。自分はプログラマだがそんなに数学が得意ではなく、頑張ったとしても下手するとコレを作るのがライフワークになってしまい、他のことができなくなる。
例えばブラウザを0から作るとして、jpegの処理以外にも画像だけでpngとかgifとかwebpとか、その他もろもろとてつもない作業が必要になる。
「とてつもなくて想像もできないので流石に無理だろう？」
いや、でも、実際動いてるのよ。ここ何十年、コツコツと積み重ねて実現している。
「積み重ね」とはライブラリであったりフレームワークであったりOSであったりする。
「どういう風になっているのか」
外部に向けたインターフェイスがどうなっているのかは理解する必要がある。「使う」ために必要だからだ。
この2つは分けて考えなければならない。
ちなみに、たとえばChromeのコアであるChromiumはのコードはコレだ。
つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
これがもう滅茶苦茶イライラする。
「これで判定と繰り返しという基礎ができます」というのが基本的な理論（定理的なもの）で、その他に必然的だが唯一無二ではないベストプラクティスというものがある（法則的なもの）。
後者をうまく説明する入門書に出会っていないんだろうな。という印象。イライラはやめよう。つかれる。
ベストプラクティスはいろいろあるのだが「層の構造にする・レイヤーに分ける」というのは重要なアイデアだ。
libjpegというのはjpegの処理を行う「ライブラリ」だ。他のアプリケーション...たとえばブラウザはこのライブラリを「使う」。
ブラウザではjpeg画像の圧縮展開というとてつもなく難しい処理を「libjpegの使い方」の理解までで済ませ、過去の蓄積であるlibjpegのコードを利用することで真の意味で0から実装しないようにしている。
この場合、libjpegが「低レベル・低レイヤー」の存在であり、中身については「使い方」つまり「仕様」の理解までしか行わないことで、実際に作りたいものを作れるようにしているわけだ。
完成しているプログラムは二例ほど挙げたがどうですかね？
複雑なことをする、特に低レイヤーのコードはとてつもなく難しい。
でも、とりあえずこんな感じのコードなら解るよね？
こういうレベルから理解して、ちょっとずつ難しい処理を学んでいくしかない。
ハードルは高いんですよ。実際。
なので、木材からだと難しいからプレハブのキット的なものを探すとか、ログハウスのカタログを読むとか、あるいは100人乗れる物置を買うのがいいかもしれない。そういうところから始める。
それらがフレームワークであったりライブラリであったりする。目的に合うものを探して、自分がやりたいことをどう実現するかとにかく考える。
「テキシコー」https://www.nhk.or.jp/school/sougou/texico/ で言われる通り、「小さく分けて考える」「手順の組み合わせを考える」「パターンを見つける」「大事なものだけ抜き出して考える」「頭の中で手順をたどる」をひたすら実行する。
unityはコードが公開されているので、本当に読みたいなら。。
オブジェクト指向は一旦忘れよう。
オブジェクト指向の「隠蔽」というのは層の構造が持っている重要な要素ではあるけど、「低いレイヤーについて考えない」のが基本的な作戦だという理解の方が重要だ。
前述の通り「できる限り作らない」んですよ。「使う」だけ。知るべきことを最小化する。
そして本当に作るべきものに関しては、利用する下のレイヤーのライブラリなりを探して・仕様を理解して、どう組み合わせてfor, if, あるいは計算させれば実現できるのかをひたすら考える。
単に翻訳がしたいのか？表示に割り込む方法を知りたい？日本語に翻訳するのは実行時なのか開発時なのか？
要求される表示エリアが言語によって異なるために、デザイン調整が必要になる問題をどうするか？
分解が甘いので何をしたらいいか調べることができないんだと思う。
ちなみに、アプリ内の文言というのはアプリの外部から変更できないように実装されている事が多いので、利用者が上書きする仕組みはかなり難しい。
AndroidなりiOSの仕様にもそのへんに割り込める機能はないはずなので、OSの開発に入っていく必要がある。結構大変だとおもう。
アプリの開発者が、そういう機能を備えた多言語化のためのライブラリを使うようになれば実現可能ではあるので、そっちの方向で頑張るのがおすすめだが、英語圏の開発者には多言語化のモチベーションが低いという基本的な問題はあるのよね。
この辺の「できる・できない・むずかしい」の判断は、いろいろな勉強をすると常識としてある程度みえてくる...気がする。
ついでに。ウェブサイトやウェブサービスの翻訳だとこういうサービスがあったりする。
ブラウザはページの描画処理のなかに割り込む余地が大きく取ってあるので、ブラウザのExtensionとかならできることがいくらかあるかもしれない。
個人的に気に入らない話はOSのアップデートは使いやすくなるからとてもいい事だからすぐにやった方がいいと宣伝されている事。
まあ、半分は嘘だよね。古いものが残っていると先に進めないんだよ...。
現在のクライアントOSは、巨大なプラットフォームのパーツの一部として理解したほうが正しくて、古いパーツが残っているとツライんですよ。
そして「サービスを受けるための道具であって、あなたが何でも好きにできる機械ではないです」みたいな世界になりつつあって、ちょっと問題と言われてもいる。
これはかなり困った傾向なんだけど、全体としての流れはあんまり変わりそうにない。
オブジェクト指向好きですな...。ここではオブジェクト指向は特に気にしなくていいですよ。
とてつもなく複雑なことをやっているために、すべてのバグを潰すことはコストが高すぎてできないんですよね。
それよりバグは未来を先取りするコストと考えて、本質的に価値のある機能を増やしていくというのが基本的な方向になっている。
だからパソコンはたまに不具合を引き起こすんです。しゃーない。
しかし中途半端に理解している老人などは、そんなことじゃ分からん。自分に分かるように説明しろと言い出す。
説明は出来る。しかし相手はイライラするし理解されない。よって説明をしてはいけないという状況に追い込まれる。
ここでどうすればいいのだと理解不能に陥る。
まあ、説明って得てして難しいよ。しゃーない。
そのとおりです。
オープンソースのプロダクトなら原理的には調べられるけどね。Androidとかはオープンになってる。
それを許容することで先に進んできているという事実は受け入れたほうがいいと思う。
「把握・理解可能な範囲」に留めていたら、数十年前のコンピュータの世界から抜け出せなかった。
deep learningの世界ではそれがより一層進むかも。この辺は詳しくないけど。
ここでの「理解」についてはそのとおり。これはもう諦めるしかない。
これが常にある。IT関連は常に新しい情報が出てくるのでそれに送れると無知になってしまう。
なんでこんなことも分からないんだとか言われ放題で、IT系の企業に努めている人は常に新しい知識を入れられる
面倒くさがらない人が向いている。
「面倒くさがり」の方が問題に気づいて「頑張って面倒じゃなくする」ことができるので、プログラマにとっては美徳なんて言われますけどね。
同時にくじけないとか諦めない、しつこいみたいな素養は必要かも。
応用まではとろうな。がんばれ。
このへん自分も知らんですよ。べつに全部知っている必要はない。
（追記: はてな記法の引用すらもさっきまで知らなかったしな！そんなもん）
層の構造をとっているということと関係があるんですが、仕様が変わると、その上に乗っているものを全部なおさないといけないんですよね。
でも革新のために互換性を捨てなければいけないケースも多い。このへんはハードでもソフトでも同じ。
そして、メンテのコストが上がっても使い続けたほうがトータルで安上がりという場合は、古いものが残ってしまう。
あるいは「（多少の問題はあっても）動いているものは変えるな」という経験則から意図的に残す場合もある。
西暦2020年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、
ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。
それなのに毎日理解のできないパソコンやスマートフォンを使っている。
オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。
自分の全く知らない場所でいけしゃあしゃあと演算を行い、そして結果を出す。それも大半が正しい結果で
利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。
そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械の奴隷のようだ。
本当に理解できない。辛い。
勘違いしてはいけないのは、それらはすべて先人の努力の蓄積によって成り立っているということ。
「よくわからないけど存在している道具」ではなくて、信じられないほど複雑だけど、多くの人々の行動によってなんとかかんとか実現した道具なんですよ。
「オブジェクト指向のおかげ様」じゃないんです。（もちろんオブジェクト指向というのも大きな発明の一つですが）
そしてブラックボックスとして使うのは多くの場合正しいです。そこは諦めましょう。
でもエンジニアとしての立場からは、その裏に隠れているとてつもない技術や思考の蓄積に感動してほしいなと思う。
人類がこんなもん作れたのって、かなりすごいよ？
これでどうやってゲームを作ったり、検索エンジンを作ったりするんだとなってくる。
つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
これがもう滅茶苦茶イライラする。
検索エンジンを作るとしても、検索エンジンにも色々あるのだけど、仮にGoogleを作るとする。
そうすると、まずページランクの論文を読むのは必須だと思われるが、
論文読まなくても日本の大学の授業の内容などが公開されてるので、それで分かりやすい解説を探したとする。
そうするとマルコフ連鎖とか、少なくとも高校、大学学部の行列計算の知識は必須となる。
ここで受験勉強なんて何の役に立つの？といった詰め込み教育に反対していた人達は挫折する。
英語も数学も単なる道具であって、詰め込み教育というのは理由はともかく先に道具を持たせる教育である。
必要になれば必要性を感じるのだから、必要になってから学べばいいというのは往々にして遅い場合がある。
例えば、敵が襲い掛かってきてから初めて剣や盾の使い方の必要性を感じても遅いのである。
よく分からんが学校や塾で装備をくれるというのだから貰っておこう、と思えなかった人はここで脱落する。
プログラミング言語の本でよくあるパターンは文法の説明などで始まり、ファイル入出力などで終わるというのがある。
なぜ、ファイル入出力で終わるのか？
これはUnix哲学とも言えるのかもしれないが、現在になってもコンピュータの世界では、すべてをファイルと考える、というのがある。
と思う人がいるだろうが、それは半分正解であり、半分ちょっと違う。
文字とかバイナリと呼ばれるものが入っているファイルはファイルの一面に過ぎない。
例えば、ディスプレイに図形や文字を表示する、プリンタに出力する、別のコンピュータと通信するための仮想的なつなぎ口を作る、
これらはすべてファイルで実現できる、すべてファイルを読み書きするように実現できうるものである。
まず絵がたくさん書いてある入門書を最初から順番どおりにやっていくことをおすすめする。
妙に単語だけぽろぽろ出でくるところを見ると、入門書を飛ばし飛ばしやっているように見える。
足し算がわからないのに、掛け算を理解しようとして混乱しているように見える。
まずは、足し算を理解しないことには、掛け算は絶対に理解できんのと同じだ。
基礎ができていないのに応用に進んだらダメなんよ。
例えば、サンプリング定理（標本化定理）を知らなければ音声の録音も圧縮も理解できないのは当たり前。
だから、大学で情報科、もしくは電子工学や機械工学を履修するのは無駄ではない。
日本の専門学校だと給与が安い仕事の即戦力になるようなカリキュラムになりがちだから。
（専門学校が扱う職業のラインナップを見ればそれは明らかだと思う
乱暴に一言で表現するなら、この世のすべてはビット、つまり0と1で表現できてしまう。
例えば小数点以下無限に数字が続くような数字は、言い換えれば無限に情報が必要ということになる。
メモリは有限だし、たった1つのそんな感じの数字を記憶するためにどんな巨大なメモリも埋まってしまうのでは意味がない。
だから、コンピュータで浮動小数点を表現する場合、どこかで足を切らなければならない。
それによって、紙で計算すれば問題ないことが、コンピュータではおかしな結果になることがある。
しかし、これを知っていなければ科学計算はもちろん、銀行のようなお金の計算もおかしな結果になってしまう。
大学で数値計算の授業を取得するのは退屈だが、これを理解してなければ社会に出ても間違ったコードを書いてしまう。
というか、私も大学在籍中に間違ったコードを書いたことが何回かあるｗ
その原因は根源的で哲学みたいな話で、
世の中のほとんどの物事には正解がないとか、そういう話にしかならない。
良いテキストはあるわけだけど、それを読むべきタイミングもあるし、万人向けが自分に向いてるとも限らない。
本なら何冊かはドブに捨てるつもりで買うしかない
みんなが良いから読めという本も、なんとなく自分にはこれがいいんじゃないか、も買うしかない
買って家でじっくり読んで、途中でナニコレ？みたいな本だったら後悔するかもしれないけど、世の中そういうもんだから。
自分はレシピ通りに作らないでヒントにしかしないタイプなのだけど、
焼く、炒める、煮る、蒸す、みたいな方法だけ理解していれば味付けなんて適当でいいのだ。
なんらかの魚があったとして、それは食べられる魚だと分かっているが調理方法はまったく知らなかったとする。
どうするか？
とりあえず、まず口に入れられるサイズに切るべきだろう。
口に入れられないと食事にならんのだから、魚を切って骨を取る。
さばき方もググれない状況なのだから、もう適当に切断していくしかない。
鱗も大味で取るしかない。
ググらないと、とんでもないほど非効率的なさばき方をしている可能性があるが、とにかく食えればいいのだ。
腐らせては意味がない。
日本の刺身みたいな生で食べる文化はイヌイットではないが、漁師が船の上で食べることとも関係しているように思う。
何が言いたいかというと、生食は現代文明のロジスティクスは保存技術の成せるわざであって、料理の基本は何でも熱を通すべきなのだ。
切った魚を、焼く、炒める、煮る、蒸す、みたいな方法で熱を通せば料理は終わりだ。
C#の入門書を読んでいて、第4章くらいに4ページくらい割いて書いてあるキャスト
( )で変換するのと int.Parse() で変換するのとどう違うのか（どちらか片方でいいのではないか）をネットで調べ、
なんか as とか int.TryParse() とか出てきてあーんー参照型と値型がーになってダウンキャストとポリフォーニズムでお昼ごはんが夜ご飯になったところで切り上げた
型の違う数値同士のときが ( ) で、文字列から数値に変換したいときが int.Parse() とかだな
入門書に書いてあるそのまんまだな
もういいや次ページ行こう全然進まん
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
336あとで/3338users 良い歯医者を見つける唯一の方法｜おてう｜note
261あとで/2389users 凡人が、天才に勝つ方法。｜つんく♂
249あとで/1714users 最新研究からわかる 学習効率の高め方 - 分裂勘違い君劇場 by ふろむだ
205あとで/1413users 総務省が無料データサイエンス講座を開講、松尾豊氏ら講師に | Ledge.ai
195あとで/2017users 竹書房退職エントリ｜竹村響 Hibiki Takemura｜note
194あとで/1529users いつもの作業が5秒速くなるツールをひたすら列挙するページ | futsu | Zenn
193あとで/1328users 数学ガールオタクが初見VTuberの積分配信にめちゃくちゃ感動したメモ1｜kqck｜note
181あとで/1196users コードレビューの目的と考え方 - osa_k’s diary
147あとで/792users えるエル on Twitter: "コンピュータサイエンスで有名なアルゴリズムのPython実装を大量に公開しているリポジトリ https://t.co/379T4izBle 教養レベルのデータ構造やアルゴリズムから機械学習やブロックチェーン,Web関連などの応用ま… https://t.co/vSmYZW5SHw"
135あとで/1389users 200円以上のサバ缶を買うと世界が変わる。サバ缶レビュワーが本当においしいと思ったサバ缶＆簡単アレンジレシピ - ソレドコ
134あとで/827users レガシーおじさん、SPAを始めてみた。そして限界を知る | koduki | Zenn
132あとで/788users Adobe、ストック素材7万点を無料で公開 商用利用も可 - ITmedia NEWS
126あとで/1173users 「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)
126あとで/719users ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 - Qiita
125あとで/736users 高知県物部村にある、消滅寸前の「堂平集落」 数回にわたる訪問による、近隣地区の住民からの聞き取りや現地の様子、祭事の記録 - Togetter
124あとで/827users 個人的UIデザインの情報源まとめ | takanorip | Zenn
121あとで/799users エンジニアなら知っておきたい生産性を爆上げするツール8選 - Qiita
117あとで/543users 東京大学の講義「AWSによるクラウド入門」をTypeScriptで写経した - dackdive's blog
115あとで/582users エンジニアの辛い仕事をいい感じにする技術 - コンサルの仕事術・思想から学べること - Lean Baseball
115あとで/997users 東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について : 富士通
111あとで/1435users 特殊詐欺（受け子、出し子）を始めようとしているあなたへ。｜ZDH｜note
110あとで/529users マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
110あとで/1092users 東証の記者会見は「技術がわかる経営者」「受け答えが理路整然」と絶賛する感想が集まる。なお横山CIOは落研出身 - Togetter
110あとで/840users 2020年10月に発生した東京証券取引所のシステム障害についてまとめてみた - piyolog
110あとで/887users まだ手元のパソコンでイベント配信してるんですか？クラウド上でTeamsを利用してOBSで配信した方が楽ですよ。 | 技術的な何か。
110あとで/1366users 「本醸造の醤油が当たり前になったのはここ20年ぐらい」と言っていいのは今から30年前 - 醤油手帖
109あとで/575users 入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita
106あとで/653users Low-Level Academy
104あとで/693users 全部、完全に商用利用無料！さまざまなUIデザインに適した1,064種類のSVGアイコン素材 -Emblemicons | コリス
104あとで/1276users 「自閉症は津軽弁を話さない」この謎に挑んだ心理学者が痛感したこと（プレジデントオンライン） - Yahoo!ニュース
常連サイトのNote、Qiitaに加えてZennというサイトから3ページもランクインした。Qiitaのようにプログラマー向けだがNoteのように報酬を得られるサイト。はてブに捕捉されたのはこの9月と割と最近。サルワカ | サルでも分かる図解説明マガジンの人が開発したらしい。
