  |
はてなキーワード: プラクティスとは
道を歩いてると、どこっ、という何とも言えない音が車道から聞こえてきた。
ぱっと見やると、スクーターが何かを残して走り去っていく。落とし物か？と思いよく見ると、なんと猫ちゃん。
うわー！と思ったものの動く前に後続車がノーブレーキで通過。幸い車体の中心線を潜り抜けて更なるダメージは免れた。
その後、他の人が抱えて車道から連れ出してくれたので、自分は警察に連絡。10分経っても到着しなかったけど、その間に回復してぱっーと走って逃げた。
大丈夫かな…
と言うわけで今回の状況は閉じたけど、轢かれて息のある野良の動物を目撃したらどう対処すべきか？をこの機会に覚えたいと思った。警察が無難かもだけど、一刻を争う場合、警察待ってると間に合わないかもだし、保護後にどうなるかも分からないので…
諸賢の知見をご共有下さい。
追記:
・猫ちゃんは左顔面を打ったみたいで、鼻血と目の腫れがあったけど、運動器は無事だったっぽい。回復を願う。
・轢き逃げ犯は許せない。でも、ぱっと状況判断してナンバーを控えるのは難しい…
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
441あとで/3236users コグニカル
285あとで/1829users 経産省が公表した「フリーランスとして安心して働ける環境を整備するためのガイドライン」はフリーランスじゃない人も必読らしい - Togetter
238あとで/1442users Python言語による実務で使える100+の最適化問題 | opt100
227あとで/2515users 山本ゆり（syunkon レンジは600W) on Twitter: "友達に「どうやって作ったん？！」と聞かれた自信作。衣ザックザクで中ジューシー！もう売りもんの域。 【レジ横チキン】 特別な材料ナシ。油も少量でいける！袋2枚で作るから洗い物少ないし衣が飛び散らんし片付けがラク！下味の水と油、小… https://t.co/7gDCHTjdjB"
216あとで/1280users 主観と客観を切り替える鍛錬｜Miwa Kuramitsu｜note
215あとで/1696users 庵野秀明（2000） - 早稲田大学 人物研究会 公式サイト
202あとで/1882users note版 突然画力が伸びだした時、僕が発見した事｜安倍吉俊｜note
200あとで/1416users 心のバリアを取り去って「正規表現」に取り組む一歩を踏み出すためのメモ｜DTP Transit 別館｜note
197あとで/1580users 地震発生から72時間｜NHK東日本大震災アーカイブス 証言webドキュメント
194あとで/1964users 100均収納グッズのカタログ情報サイト MONO SIZE（モノサイズ）
186あとで/987users 2021年にJavaScriptやNode.jsを勉強し始めたので、読んで良かった資料をまとめる | matsumanaの技術メモ
184あとで/1208users プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
175あとで/1439users ［速報］マイクロソフト、無料でRPA機能「Power Automate Desktop」をWindows 10ユーザーに提供開始。Microsoft Ignite 2021
175あとで/1975users 「ごめんなさい 救助のヘリじゃなくてごめんなさい」｜NHK取材ノート｜note
175あとで/1412users 長かった10代の終わり、エヴァが想い出になった日。(『シン・エヴァンゲリオン劇場版』感想 ※ネタバレ注意)｜祥太｜note
174あとで/970users YouTubeで「中学生から分かるAI数学講座」が無料公開 E資格に対応 | Ledge.ai
172あとで/1798users ジャンプの漫画学校講義録⑥ 作家編 松井優征先生「防御力をつければ勝率も上がる」 - ジャンプの漫画学校
167あとで/1331users カズオ･イシグロ語る｢感情優先社会｣の危うさ | 読書 | 東洋経済オンライン | 経済ニュースの新基準
161あとで/892users Dockerfileのベストプラクティス Top 20 | Sysdig
157あとで/1386users 建築好きなら死ぬまでに見ておきたい建築１００（日本国内編） | anond.hatelabo.jp
157あとで/1279users Microsoft、文字起こしアプリ「Group Transcribe」を公開 - iPhone Mania
156あとで/1347users お金のことを考えたくない人はFP3級を勉強するといい - アオヤギさんたら読まずに食べた
156あとで/1290users 「プロフェッショナル 庵野秀明スペシャル」NHKが取材を後悔した庵野監督の生態 - Togetter
153あとで/1239users Keigo Hattori on Twitter: "YouTubeで学ぶコンピュータ・サイエンス。これを完了したら実質学位を取ったようなもん。という話だが、すごいなこれ・・・。全部無料でここまでの・・・。 https://t.co/xNHNvBM5Aa"
150あとで/1018users 「シン・エヴァンゲリオン劇場版」公開から１週間分の感想エントリまとめ - まなめはうす
148あとで/705users React を深く知るための入り口 | Panda_Program | Zenn
148あとで/1130users 情報ではなく経験をアウトプットすること - lacolaco
144あとで/1159users 「浄土」PDF一覧 | 法然上人鑽仰会
140あとで/1166users 売られている防災リュックがピンとこないので…カバンから食料まで『100均だけ』で防災グッズを揃えて検証してみた→防災士もオススメ - Togetter
137あとで/1028users こうやって切れば良かったんだ！鶏むね肉がぷるっぷるになる「うましおごま油漬け」が鶏ムネ肉を疑うレベルの柔らかさ | Gourmet Biz-グルメビズ-
トップのコグニカルは個人運営の"「分かりやすさ」と「心地良さ」を追求した学習サイト"だそう。
なぜか仏教雑誌「浄土」がブクマを集める。無料公開されて古い号の歴史的な価値を面白がられている。読み切れなそう。
YouTubeで「中学生から分かるAI数学講座」……で紹介されていた動画を開いてみたが1000弱のブクマを集めている割に再生数数百止まり。
結局そうなんじゃないかと思い始めた
べつに毎日手首切ってます！って感じでもないし、病み垢なんかを作って死にたい死にたい言ってますって人もそうはいないだろう
でも、なんか、毎日しんどいし、これが死ぬまで続くのか……っていう絶望感みたいなものをうっすら感じつつ、できるだけ意識しないようにしている、そういう人がかなり多いように思う(根拠、ナシ！w)
いくら愚痴っても Life goes on...なので言わないだけで、助けてくれ！と思ってる人はかなりいるんじゃないか
で、それの支えとしては、結局結婚して子供作って……っていう伝統的なアレが一番効くんだろうなと最近思う
そら一人で趣味やって充実してます！って人もいるだろうし、子供作ったけどぜんっぜんなんの感情も湧かなくて破滅！って人もいるだろう
しかし、やっぱりこう、全体としては、子ども作ってその成長に注力して辛さから目を逸らすっていうのがベストプラクティスなんじゃないかな
運否天賦で、というか、あんま何も考えんとエイヤっと子供を作って、育てるぞーと思ってるうちに老境、そんでまあええわと思いながら死ぬ そういう感じでやってきたんだろう、人類
残すもん何もないし、そもそも何かを残すことにこだわりを感じないし、大切な人は別にいない となると、モチベーションを自分で生み出さないといけない
月に行くんだ！とか、良い絵を描くぞ！とか、武道館を満員にする！みたいな夢をもったりできると良いのかもしれないが、夢ってたぶん持つことにすら才能が必要で、パンピーにそれはできないんだよな
一緒に過ごしたい家族もいない、熱意を注げるものもない、叶えたい夢もない って状態で週40時間労働を40年以上やるのは、まあ相当しんどいわよね
どうなるんだ？この社会
俺は滅ぶだろうなと思うんだけど、じゃあ具体的にどんなふうに滅ぶのか、というかそもそもどうなったら滅んだことになるのか、というとわからない
個人的に人類の未来を全部見てみたいな、とは思うんだけど、実現不可能だし、夢ってほど夢じゃないな 呪術廻戦を完結まで見たいっていうのと大して変わらん熱量
俺ってどうしたらいい
なんのために生きたらいいんだ
生まれた意味とかはどうでもいいので、仕事をしてまで生き続ける意味がほしいんですよね
参考書とかにはアルファベット順って呑気に書いてあるけどこれいわゆるASCII順だよねと思って
（彼らが揃いも揃ってアルファベットだけで構成された単語の比較例だけしか出さず、数字開始あり・空白ありの文字列比較をさせないのは怠慢だと思う）
比較に使ってるメソッドなんだろうと思って、String.CompareToからString.Compareに行ってCompareOptionsを見て、
.NET での文字列の比較に関するベスト プラクティス | Microsoft Docs
うわー、うん、なんか見なかったことにしておく
その中でもベストofクソ、つまりクソofクソだったのは、とある広告系企業だった。
ワイが入った時点でひどい状態だった。
まず、Adobeとかソフトのライセンスが管理できておらず、一部は不正コピーを使っていた。
機器は、Windows機やLinux機もあったりしてめちゃくちゃ。
営業さんは「かっこいい」というだけでMacを選んだり、開発さんは「使いやすい」というだけでLinuxを選んでいるしまつ。
好き勝手にバカスカソフトを入れたりしてるので情シスは把握・対応ができない。
しかもソフト類は買ってから事後申請するしくみだったので悲惨だった。
また、情シス長は、いいと思ったシステムを後先考えずどんどん入れていて、
会計システム+（会計+在庫管理システム)＋（会計+人事管理システム）
というように、会計データが重複していて、それを毎月手作業でインポートしていた。
そのためだけに人間を雇っているようなクソofクソなオペレーションだったのである。
「ドカタくん、まずこのソフトライセンスの一覧を洗い出してくれ」
と言われたが、200以上もの有償ライセンスがありめまいがした。
当時はワイもスキルがなく、どのように収集して統計するかがわからなかったのだ。
かろうじてSKYSEAというシステムが入っていたのだが、当時はあまり優秀ではなく、
GUIもみずらくてえらく使いにくかった。（今は改善されているらしいが）
なのでロースキルな現場＋ロースキルな人間（ワイふくむ）という、
その後の現場で、そのクソ現場をワーストプラクティス（造語）として活用できたからだ。
端末情報を収集したりするのはAzure ADやWinRMというツールを使い、
ソフトライセンスはBIツールを使って自動統計することもできる。
それに気づいてなかったし、調べようともしていなかった。
そう、あのクソ現場において最もクソだったのは、
三匹の子豚を見るたびに思うんだけどさ
母親から突然追い出されて家を作ることになって、上の兄二人は自分たちがさっさと家を作り終えたから、のろまな一番下の弟を馬鹿にするけど、実は弟が一番丈夫な家を作ってて上の兄二人はオオカミに食べられる。三男は偉いっていうの
別に三男は深謀遠慮でレンガの家作ったわけでなく、たまたま手元にそれしかなかったから仕方なく作ったんだけど、狼が襲撃してくるという異常な状況下でたまたまベストプラクティスになっただけ、つまり運
家を作るっていうのに関して言えば別に一番下の弟の知恵もそこまで特別なことをしてるわけじゃないっていうところが
豚にしては賢いなってくらいで
なんで教訓話になってるかわかんないんだけど
ハプスブルク家の暴政に怒って得意の射撃術で悪徳役人射殺したウィリアムテルの方がよほど根性据わってるし
魔女の婆さんを策略で倒して金銀財宝かっぱらったヘンゼルとグレーテルの方が頭も度胸もあるし
鬼の本拠地にカチコミかけてバッタバッタと薙ぎ倒して金銀財宝ぶんどった桃太郎の方がよほどこれからの日本社会において教育と教訓になるよね
なんでそういう教育しないんだろうか
自分の内面をさらけ出すような、特にまだ自分でも整理できていないような悩みや、割り切れていない体験をふと話してしまったときに、
話し相手から「話してくれてありがとう」なんて言われると、一気に冷める。
（ああ、はいはい、そうですね、そういうときはまず肯定から入るんですよね）
（そういう研修なりプログラムなりがあって、それを修めたあなたは、この場をやり過ごす、ベストプラクティスできてますねー）
って感じがする。胡散が臭くて白々しいのよ。
ほんとはよ、もしも真剣にそんなことを私が話してしまうときが来るならよ、ちょっとだけ、少しだけ私が話をして、
そしたらそいつはなんかぶつぶつ呟いてちょっとだけしかめっつら見せて、
数分だけ氷とグラスの音しかしない時間が流れて、「場所変えようか」ってなって、二軒目の居酒屋かバーかでまた与太話を始める、ってのがいいな。
強く生きなきゃな。
K字回復だとか、Webの需要は益々増加するとか、ニュースを見ていると出てくる。
一方で日本全体の統計を見ると、売り上げが下がっていて、政府は需要を喚起しないといけないといった声が出ている。
ネットはもっと内需を支えられるくらい需要を喚起することはできないものなのか？
個人情報も取っているし、少し調べたら売り上げを伸ばすにはこうすればいいだとか、ベストプラクティスを真似しようと言っている。
そんなに力があるのであれば、やって欲しい。
Googleは国家くらい力を持つようになったんじゃなかったの？
機械学習で売り上げを伸ばせるんじゃなかったの？
なんか巷では近頃プログラミングスクールが流行ってるらしいが、知らないなら言っておく。それは完全に無意味だ。そんなのはプログラマーなら誰でもわかってるはずだが。情弱が金を搾り取られるのは資本主義社会の常であるにしても、さすがに偽の希望を抱いてプログラミングスクールに通うためだけに安定した大企業に勤めてたのに退職する人の話なんかが流れてきて看過できないなと思ったので書いておくわ。どうせ情弱には届かないだろうが。
そもそも今プログラマーやってる奴はほとんど独学でプログラミングを習得したという事実がある。GAFA 社員もそこらへんのいわゆる下流工程のSEも。30年前はベーマガっていうプログラム投稿雑誌があって、当時プログラミング教室なんか当然ないが普通に小学生とかが独学して自作のプログラムを投稿してたわけだ。プログラミングスクール登場以前はプログラミングは独学するものだった。
確かに既に分かってる人に指導されないと学べない分野は存在することはするんだが(定義・定理・証明スタイルの大学以降の数学とかね)、プログラミングはそうじゃない。数学で論理的に間違った証明を書いても最初は自分では気づけないしだから独学で高等数学を学んだ人というのは控えめに言って悲惨なことになるんだが、プログラミングだと間違えたら分かるんだよな。エラー吐くし動かないし動いても間違った答えを出すので。
間違えたら即座にコンピューターが教えてくれるという最高のフィードバック環境が整っているのがプログラミングというものであって、独学が可能というだけでなく、この上なく独学に向いている。
そうは言っても誰かに教えてもらった方が効率がいいという議論はあるだろう。しかし1年前のベストプラクティスは今日の時代遅れになる、日進月歩のこの環境でエンジニアやっていくなら独学は必須のスキルだし、プログラミングという独学にうってつけの分野で独学だと著しく効率が悪くなるようならそもそもエンジニア向いてない。ゼロからプログラミングを独学してみるというのはその試金石でもあるわけ。よしんば今特定のフレームワークの使い方を誰かに教えてもらって使えるようになったとして、次のフレームワークが出てきたらどうすんの？って話。
プログラミングを独学って具体的にどうするのよ？という人のために学び方を書いておく。
これが出来る奴はそんなに多くないかもしれないが、そもそもプログラミングというのは適性というものがあって、向いてない奴はやらない方がいい。絵心がない奴、音痴な奴、文才がない奴がいるようにプログラミングの適性がない奴がいる。そんなの当り前じゃないか？適性があるなら上の手順で難なく独学できるし、適性がないならプログラミングスクールに行っても無駄。プログラミングスクールは金儲けさえ出来ればいいからプログラマーなら誰でも知ってる適性というものの存在を隠すんだよな。そんな詐欺の被害に遭う人が出るのは嫌なのでこうして正しい情報を書いておいた次第。
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
private メソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
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年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、
ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。
それなのに毎日理解のできないパソコンやスマートフォンを使っている。
オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。
自分の全く知らない場所でいけしゃあしゃあと演算を行い、そして結果を出す。それも大半が正しい結果で
利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。
そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械の奴隷のようだ。
本当に理解できない。辛い。
勘違いしてはいけないのは、それらはすべて先人の努力の蓄積によって成り立っているということ。
「よくわからないけど存在している道具」ではなくて、信じられないほど複雑だけど、多くの人々の行動によってなんとかかんとか実現した道具なんですよ。
「オブジェクト指向のおかげ様」じゃないんです。（もちろんオブジェクト指向というのも大きな発明の一つですが）
そしてブラックボックスとして使うのは多くの場合正しいです。そこは諦めましょう。
でもエンジニアとしての立場からは、その裏に隠れているとてつもない技術や思考の蓄積に感動してほしいなと思う。
人類がこんなもん作れたのって、かなりすごいよ？
登場してから、その効率の良さで永らく使われてきたものの、同時に様々なセキュリティホールを生み出した結果、
今や「可能な限り使わないことがベストプラクティス」と言われているC/C++言語。
実際、PythonやGo言語などで書けそうなら、絶対そっちで書くべきだと心底思う。
以下のような、ド素人としか思えない実装によるやらかしを見てきたこともあって、その思いは一層強くなった。
いわゆる下手のC/C++あるあるで、もう本当にうんざりするほど見かけるのが、
「char型の巨大な配列をグローバルに宣言し、それを使い回す」
それ、今どきのWindowsとかでやられると、ビルドないし実行したタイミングでウィルス対策ソフトが誤検知したりするんだわー。
何しろ人によってはint型の最大数を要素数として配列作るとか、無茶しやがって…みたいな事するんだから無理もない。
必要なときに必要な分だけ領域確保して、ポインタで適切に参照させるとか、基本中の基本じゃねーの？
誰でも初心者の時期があるのは仕方ないが、お前初心者レベルのまま何年コード書いてんだ？いい加減にしろマジで。
そうやって書いてしまったものをリファクタリングするのも、他の安全な言語に移植するのも諦めて、今日も誤検知させる奴がいる。
そもそも、本来コンピュータのことを詳しく知っている専門家が使うことを前提とした言語が、こうも広まってしまったことが歴史の過ちだったのかも。
プログラミングはセンスです。センスの無い人がプログラマになると、他のすべての人に迷惑がかかります。だから、センスの無い人は絶対にプログラマにならないで下さい。
プログラミングのセンスが無い人や、プログラミングをやったことの無い人は、知識を得たり経験を積んだりすれば、誰でも「良いプログラマ」になれると思っているようですが、無理です。
というのも、センスの無いプログラマの問題は、知識や経験の不足ではないからです。センスの無いプログラマの救いようの無い問題は「頭がおかしいこと」なのです。
題材は何でもいいのですが、具体的なコードを見た方がイメージがつきやすいと思いますので、とりあえず以下の問題を考えます。
住民のリストが与えられるので、背の低い順に男女ペアにしたリストを作って下さい。ただし、男女の数は同数であるとします。
const makePair = (persons) => { const males = persons.filter(person => person.sex === MALE) const females = persons.filter(person => person.sex === FEMALE) const compareHeight = (a, b) => a.height - b.height males.sort(compareHeight) females.sort(compareHeight) return males.map((male, idx) => [male, females[idx]]) // 男女の数は同数 }
この例はJavaScriptなので高階関数を使っていますが、仮にそういう機能が無かったとしても、
一方、センスの無いゴミプログラマは、以下のような名状しがたきコードを書いてきます。
function pair(psns) {
var i = -1;
var cnt = 0;
var flg = psns[0] && psns[0].sex;
var j = -1;
var tmp = null;
for(i = 0; i < psns.length; i++) {
//console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
//console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
if(psns[i].sex == flg) {
//console.log('cnt: ' + cnt + '->' + (cnt+1));
cnt++;
} else {
j = i - cnt + 1;
//console.log('swap ' + i + '<-->' + j);
tmp = psns[j];
psns[j] = psns[i];
psns[i] = tmp;
i = j - 1; // <- 理由は分からないが、i = jだと上手くいかない（by XXXX）。
cnt = 0;
flg = flg == MALE ? FEMALE : MALE;
while(j > 1) {
if(psns[j].height < psns[j-2].height) {
//console.log('swap ' + j + '<-->' + (j-2));
tmp = psns[j-2];
psns[j-2] = psns[j];
psns[j] = tmp;
}
j -= 2;
}
}
//console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
//console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
//console.log('')
}
for(i = 0; i < psns.length; i++) {
//console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
j = Math.floor(i / 2);
//console.log(psns, 'i=' + i, 'j=' + j);
tmp = psns[i];
if(!(i % 2)) {
psns[j] = [null, null];
}
if(tmp.sex == MALE) {
psns[j][0] = tmp;
psns[j][1] = psns[i+1];
} else {
psns[j][0] = psns[i+1];
psns[j][1] = tmp;
}
i++;
//console.log(psns, 'i=' + i, 'j=' + j);
//console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
}
psns.splice(psns.length / 2, psns.length);
}
こんなコードのメンテナンスは御免被りたいです。一見して配列の要素を入れ替えていることが分かるだけで、実装を全て読まなければ（いや読んでも）処理の意図が全く分かりません。また、たとえば「i = j - 1」が間違って「i = j」などと書かれていてバグを起こしたとしても、原因を突き止めるのは困難を極めます。
さて、このコードは具体的に何がいけないのでしょうか。長すぎることがいけないのしょうか。変数名が分かりにくいのがいけないのでしょうか。引数を破壊的に変更しているのがいけないのでしょうか。不要なコメントが残っているのがいけないのでしょうか。よく見ると、ソート処理で車輪の再発明をしていたり、「j」や「tmp」などが場所によって意味が違うカメレオン変数になっていたりしますが、それがいけないのでしょうか。どれも正しいですが、それらを逐一直したところで、本質的な解決にはならないでしょう。
後者のコードはもはや「ここを直したら良くなる」とかいうレベルを超えています。たしかに、問題を具体的に挙げることはできます。このコードの致命的な問題が、凝集度の低さと、単一責任の原則(SRP)違反にあるのは間違いありません。しかし、後者のコードを書いてくる人に、
「住民リストを男女に分ける処理や、リストをソートをする処理、2つのリストをまとめる処理は、この問題とは独立して意味のある操作だから、別の関数として抽出しましょう。その方がコードの見通しがよくなるし、一部の処理を修正したときの影響も小さくなるし、単体テストも書きやすくなります」
なんて言ったって聞く耳を持たないでしょう。
そもそも、こういうコードを書く人は、この処理自体を「pair」なんて関数に抽出すらしません。まだこの問題では入出力のフォーマットが明確に定義されているので、他人が1から書き直せますが、実際のプロダクトでは、無数の副作用を起こす数千行のコードの迷路を彼の脳内フォーマットのデータが通るわけです。もちろん、テストコードなんてありません。
つまり、指摘をしても絶対に直らないのです。いくら言語の優れた機能やベストプラクティスを紹介しても、馬の耳に念仏。それらの利点を理解できるだけの脳みそが足りていないのです。
どうして、同じ処理を実装するのに、ここまでの違いが生じるのでしょうか。
これは、プログラミングの技術の問題ではありません。既に述べた通り、ふつうの人なら、特定の機能の有無とか知識の程度にかかわらず、ふつうのコードを書くのです。なぜなら、ふつうの人にはそちらの方が楽だからです。つまり、前者のコードは別に何か卓越した技術を身につけた結果書けるようになるものではなく、まともな感覚さえ持っていれば、プログラミング初心者にとっても前者のコードの方が書きやすいのです。
つまり、後者のようなコードを書いてくる奴というのは、現実世界の捉え方が常人とは著しくずれているのです。要するに、「頭がおかしい」のです。この病気はもう直りません。だから、センスの無い人は絶対にプログラマにはならないで下さい。
プログラミングで食っていくためには、他の職業と同様に様々なスキルが必要になる。単に技術的な面だけに絞っても、以下のようなことが出来なければ話にならない。
プログラミングスクールなどを卒業したゴミには、(1)〜(2)もしくは(1)だけを以て「自分はプログラミングが出来る」と勘違いしている奴が多い印象がある。
本当に嫌になる。
見よう見まねでコード書いてるだけのゴミはプログラマ名乗らないでくれ。
他にもいろいろ書きたいこと（ネットワーク、データベース、セキュリティ、OS、ハードウェア等）はあるが、ソースコードが書けるという点だけにフォーカスすれば、この程度は最低限できないと困る。
上に書いたようなことが完璧にできると断言できない奴が、プログラマを名乗るのがいかに非常識で恥ずかしいことなのか、よく理解して欲しい。
今日も誰かがどこかで死んだ。
自ら生を終えた。
https://www.npa.go.jp/publications/statistics/safetylife/jisatsu.html
今日じゃなかったかもしれない。でも、明日か、明後日か、少なくとも今週か来週には2人以上が死にゆくことが「確定している」。
根性なんてものは存在しないし「責任」なんて概念は科学にはない。環境と、手法や手順、試行、反応、結果があるだけだ。得られた結果や反応が想定と違ったなら、手法や手順を変えてやり直せばいいだけのことなのだ。
なぜ学校ではそのことを教えない？なぜ企業は「体調管理しろ」としか言わない？お前は癌のコントロールができるのか？
人の意識は24時間365日安定しているものではない。夢を見たり、薬で精神に影響を受けることからその絶対性のなさが分かる。コミュニケーションにおいてもわプラクティスとされる手法が行き渡らないばかりに、無用なストレスを生んでしまっている。
言葉を発したその瞬間に、我々は他人の脳に指を突っ込んでいるようなものだと、その影響力の自覚と、曖昧さに意識を向けるようにしたい。