  |
はてなキーワード: 算術とは
例えば先進国が共同で食料生産から輸送までを最適化して、世界の食料難を解決しようとする
そうすると一時的に飢餓から開放される。しかし、飢餓から開放された人類は人口爆発によっていつか食料生産が追いつかなくなる
そうすると人口だけが増えつ続けてより、多くのひとが飢餓に見舞われ死ぬことになる
人口は幾何級的に増加するが、食糧は算術級数的にしか増加しないからだ
数百億の人類同士の飢餓からくる健康被害、治安悪化、資源争奪の争いは現代からは想像もつかないものとなるだろう
果たして、この前提に立ったとき食糧を最適化することは正義か悪か？
架空の話ではなく、現状人類はこうならない為に多くの人を見殺しにしてるってのが事実だと思う
よく言われる人権やらなんやらは実は都合の良いときにだけ持ち出されるまやかしだってこと
それ以外に説明つく？
エンジニアと一言で言っても星の数ほどのジャンルがあるが、その中でも代表的なのはハードウェアエンジニアとソフトウェアエンジニアだと思う。
さて、自分は新米ハードウェアエンジニアで、ソフトウェアが趣味の人間である。
はてなにはソフトウェアの記事（及びブックマーク）が多く、日曜プログラマの自分にとって大変有益である。
大抵の悩みは検索をかければ解決するし、自分では想像し得ないようなユニークな記事もあり毎日が発見の連続だ。
特にユーザのコメントが好きで、皆の関心が伺える“はてな”はいくら見ていても飽きない。
ただ、ハードウェアに関する記事が少ないことが残念でならない。
エンジニアカテゴリを覗いても、ハードウェアに関する記事が上がっていることは稀である。
たまにラズパイやIoTキットに関する記事があるだけで、デジタル回路におけるインピーダンスのシミュレーションとか、高速差動信号の放射電波対策とか、そういった踏み込んだ記事はほぼ無いと言っていい。
当然アナログ回路のGNDレイアウトに関する記事は皆無だし、ソフトウェア寄りと言えるRTLコーディングの記事さえ見当たらない。
イマイチ盛り上がらないハードウェア業界と比較して、ソフトウェア業界の隆盛は火を見るよりも明らかである。
コーディング環境、つまりPCがあればその先には広大な世界が広がっている。
語弊を恐れず言うが、アイディア次第ではその日のうちにスターダムにのし上がることも可能かもしれない。
当然、アマチュアを含めたエンジニア人口を見るとソフトウェアエンジニア人口は突出しているだろう。
なので記事数の多さは人間の性質に依るものではなく、単純に人口の違いだろう。
ハードウェアも面白いのに、何故手を出す人が少ないのだろうか。
ハードウェアは自然界の物理法則の下で成り立っているため、主に電磁気学・電気回路・電子回路を勉強するだけでいくらでも応用が効く。
言うなればソフトウェアよりも参入障壁は低いはずで、高校物理で習ってきたことである程度の回路が組める。
FPGAなりでハードウェア・アクセラレータを自作し始めると計算機科学の知識が必要になるが、ここはむしろソフトウェアエンジニアの方が得意な領域だ。
こんなことを言っておいて、自分がハードウェアを始めたのは社会人になってからである。
学部・修士時代の専攻は材料物理学だったため、工学とは全く縁が無かった。
ここからは自分がハードウェアの道に進んだきっかけを書こうと思う。
新人研修の昼休み、あるフラクタル図形を高速描画するハードウェアの記事が目に留まった。
当時の自分にはその偉大さが理解できなかったが、2年もの間寝食を忘れて没頭できるその世界に心が惹かれた。
早速オームの法則から復習し、使ったこともない半田ごてやテスターを買ってきて4bit CPUの製作に取り掛かった。
ALU（算術論理演算回路）以外はディスクリート部品で組んだため、デバッグ含めて完成までに6ヶ月も掛かってしまった。
機械語を勉強し、命令デコーダを設計して1年後、自分の考えたプログラムが動作したときは嬉しかった。
上述した記事を追体験しているようで、仕事を忘れて没頭していた。
続いてFPGA＋マイコン＋汎用ROMの組み合わせでプリント基板を起こしてみた。
ここでレベル変換やリセットシーケンスなど、デジタル回路の基礎を身に付けることができた。
基板レイアウトの考え方は専門的であるもののWEBで簡単な情報が手に入ったし、殆ど電磁気学の世界なので理不尽なものは無かった。
機械語は論理的な手順をコード化するだけだったが、組み込みC言語はそのルールが難解だった。
言い方は悪いかもしれないが、人間の考えたルールだろうと理不尽に思える理論もその設計思想を調べもせず暗記で済ましていた。
メモリリークが発生した場合もハードウェアのように現象を観察して仮説検証することが難しく、ダンプなどのデバッグ手法も知らなかった。
そんなとき、社内でセキュアプログラミングなる研修があったため同期と潜り込んでみた。
参加資格の無い自分が参加できたのは、配線だらけの汚い自作CPUを子供のような目で見てくれた上司の厚意だった。
そして1年後、自分はモニタの中で鮮やかに描画されるフラクタル図形を眺めていた。
上述した研修の講師に1年間師事し、半ばマンツーマンで計算機科学を教えて頂いていた。
大学講師の方だったため、C言語のルールではなく命令処理系としての働き、ハードウェアとの関連を核にして叩き込んでもらった。
こういう部署では多少なりともソフトウェアができると光るものである。
ただ組み込みC言語以外はサッパリのため、日々独学の毎日だった。
そこにある記事はどれも眩しくて、「ある疑問の解決法」を検索するだけでは決して出会えない珠玉の記事の宝庫だった。
きっとハードウェアの世界にも、自分では想像し得ないような発見があるはずだ。
それこそあのフラクタル図形のような驚きが。
今は仕事の傍ら、奇しくもプロになってしまった自分の義務として細々とハードウェア記事を書いている。
残念ながら驚くような技術ではないが、誰かにとって小さな発見があれば嬉しい。
これを読んだ人がハードウェアに興味を持ってくれたらと思う。
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
伏字が嫌い、問題であるという指摘について。引用部分は【伏字の文化史】という本から引いたものです。
現在マンガなどで行われている伏字は、人名・商標などに対してお遊び的に行われている１文字伏字だと思いますが、日本の歴史上、伏字は検閲逃れとして、元の語が分からなくなるように行われていました。
新聞紙上に伏字が登場した頃、読者からの次のような投書が掲載されました。
此頃諸新聞に文字の代りに何だか○○○点がよく書て有ツて分りませんから或る学校の教師に尋ねましたらあれハ算術で○(本では「れい」のルビあり：匿名ダイアリー執筆者注)の処へ遣ふ符微だから大かた算法律から代用したので有らうと申されましたが如何でございますヱ新聞屋さん 麻布市兵衛町 長屋平太郎
検閲で発禁処分(言論弾圧)を受けないために使用された伏字ですが、投稿者も教師も伏字の意味が分かっていなかったようです。
明治十年には伏字に対しては下記のように違和感を表明し、使用を止めるように新聞社へ促す投書が見られます。
どうも了簡が少し卑屈で「うづく○(本では「まる」のルビあり：匿名ダイアリー執筆者注)」様に見えるから此丸々の新聞は止て貰ひたいと貴社へせ○(本では「まる」のルビあり：匿名ダイアリー執筆者注)もの
このように、卑屈で蹲るような文体は止めて下さいと、新聞社に対して駄洒落つきで求めています。
と指摘されました。
内閲制度改正運動の発端を作った藤森成吉は、後に「亀のチヤーリイ」という作品の文末において、次のように書いています。
附記、「争う二つのもの」について。あまり伏字は多くなるので、その掲載をやめる事になりました。どうも住みにくい国です。同作者
小説家である上林暁は、戦前に改造社にて編集部員をしていた人物でした。著書「伏字」では、伏字の対応が記述されています。
結局、どんなに手を尽してみても、伏字といふものはきれいなものではなかつた。紙面を汚くしたといふより、紙面を滅茶苦茶にする場合もあつた
当時は、「革命」「平和」「反戦」などの言葉や、それらを匂わす章句も全て駄目でした。
小林多喜二は、伏字が多いために作品が読みにくくなることは避けるべきであり、そのために作家としては伏字が少なくて済む作品を書き、編集側は一文字でも伏字を少なくした出版をするよう説得を試みています。
読書論・読者論と言った研究においては、大前提として、読者が入手したテキストは完全なものであることが必要です。
社会は公民や歴史、地理など広く知っておくべき事が多岐にわたる。
だけど、理科は？
理科科目って社会とくに会社務めする上で必ずしも必要ではないと思う。
現にそういうのがいる会社はあっても、普通そういう会社に就職するなら
だけど、一般にある普通会社に就職するのに理科って必要かなと思う事がある。
よく理系大は文系とか体育会より賢いからって自慢する人多いけど、
実際の社会生活において理科が生かされる機会ってあるんだろうか。
実は生物学とか物理学って大学によっては文系の範疇にある事もある。
つまり理科系統とされてる分野ですら文系と呼べるものもあって、
話は戻るが、理科科目は本当は社会生活の役に立たないのではないか。
何故なら、それらの分野は理科と異なってちゃんと学問としてあって
もし理科系統ならば、医学部じゃなくて理科学部医学科といった学術体系に置かれなくてはならない。
故に理科は社会生活において、どの程度関与する事が出来るのか。
恐らくそこから考えない限り理科が社会生活に必要かどうか断定できないのでないかと思えてならない。
そういうのは大学以降で行うべきだ。
天才とは色々定義されるが、一番の特徴は集中力（あるいは勉強体力）があり、非常に長い間その問題に取りかかることができることだと思う。
例えば、望月新一氏について、オックスフォード大学の教授であり、望月新一氏の友人でもある人は次のように言っている。
「彼が他の数学者と違うのは、彼がものすごく高い耐性(tolerance)があることなんだ。何時間も、何時間も机に向かって数学をすることができるんだよ」
「彼が学部生の頃の話なんだけどね。フランスのグロタンティークって人の代数学や算術幾何の著作は、その分野を学ぶ人はみんな読まなきゃいけないんだけど、普通は少しずつ理解していって、何年も費やすんだよ。何千ページもあるからね。でも望月は学部時代のほんの数年で理解してしまったんだ。」
掛け算には順序があるよ (順序肯定派)
｜ └─ 教科書もそう書いてあるんだからそうなんだよ (教科書固執派)
｜ └─ 学習指導要領にもそう書いてあるよ (実は書いてない派)
｜
├― 理解を深める、理解力を測るために必要なんだよ (教育論派)
｜ ├─ 根拠はあるよ (根拠教えて派)
｜ ｜ └─ 日本の数学の教育水準は高いよ (相関因果混同派)
｜ └─ 根拠は無いよ (論外派)
｜ └─ 逆に順序がないという証拠を見せろよ (悪魔の証明派)
｜
｜ ├─ 授業の終わりまでだよ (不正解否定派)
｜
｜ └─ 不正解を貰うことで子供は考えるよ (正解を不正解にする派)
｜ └─ この程度で萎縮するようじゃどの道挫折するよ (マッチョ派)
｜
├― 逆が正解だよ (変則肯定派)
｜
├― 順序に反対したところで教育現場は変わらないよ (消極的肯定派)
｜
｜
└― 受けと攻めははっきりしておく必要があるよ (カップリング派)
掛け算に順序はないよ (順序否定派)
｜
｜ ├─ 数え方で順序は入れ替わるよ (トランプ配り派)
｜ └─ 面積を教えるときどうするんだよ (縦横派)
｜
｜ ├─ 不正解にすることで子供が萎縮するよ (萎縮危惧派)
｜ ├─ 順序を重視するなら問題文に記せよ (無記述否定派)
｜ └─ "×"を使わず独自の記号を使えよ (算術記号原理派)
├─ 算術記号の"×"と言語の"掛ける"は別物だよ (算数国語分離派)
｜ └─ ×は「掛けるまたは掛けられる」という算術記号だよ (新定義派)
├─ 順序は教えるための道具でその場限りのローカルルールだよ (順序道具派)
└─ 順序があるとする根拠が何も無いよ (根拠見せろ派)
