  |
はてなキーワード: ライブラリとは
別に高級なスクリプト言語でも標準ライブラリやインタプリタのバグは踏むときは踏むし
マイクロタスクな標準コマンドは高級言語のインタプリタほど頻繁なセキュリティアップデートは必要ないので使うバージョンはだいたい決まってるし
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません
PSplusにも入っているので今月のフリーゲームをライブラリに追加するためにもサインインしようとした。
するとサインインするためのチェックがあり、人間かどうか見極めるためのものらしい。
別段そうしたチェックは物珍しいものではないだろう。
しかしいつから仕様変更したのか、Psstoreでのサインインは一風変わっていた。
二分割した画像にはそれぞれ車が表示され、左右の車はどのぐらい離れているか？
それを入力するミニゲームのようなものになっており、これが非常に分かり難い。
離れた距離を視認できるよう物差しのようなメモリがあるものの、車の位置がメモリとずれており”左の車と右の車は何数字分離れているか？”
正確に把握するのは難しい。
そうした問いを5連続で課せられ、一問でも間違えればサインインできない。
流石ソニー。
こんな細やかなところにも遊び心を見せ、ゲームを設けるとはね。
俺はサインインを諦めた。
昔、Google Plusでこのような議論があった: 「Facebookぐらいの企業なら、自社全体で自作のOSを使っているだろう」
しかし私はその点について非常に疑問に思っていた。
「OSの自作？そんなことをして利益の足しになるのだろうか？」
一から何かを作るよりは、既存のツールやライブラリの力を借りたほうがバグも少ないし安上がりである。
そういった基礎部分は、外部のライブラリ開発者に任せてしまえばよい。
多くの場合、ビジネスドメインを相手に仕事をしているため、基礎部分を組み合わせた応用に主眼がある。
基礎部分に時間をかけてしまうと、その分の時間や労力が無駄になってしまう。
Webシステムを開発する企業は、ビジネスロジックこそが注力すべき部分であると忘れてはならない。
たまたまコードの3つの部分について、共通性があったとして、この共通性を一般化してライブラリ化し、再利用可能にしたとする。
一見すると良いプラクティスに思えるが、文脈次第では痛手を追う。
この「共通性」が、今後未来に渡ってずっと続くとは限らない。たまたま現時点において一般化できると言うだけで、未来では3つの部分が別々の機能性を持つことも考えられる。
そのときに再利用可能なライブラリとして作ったことを後悔することになる。別々なら影響を限定して作れたのに、ライブラリにするといちいち手間がかかる。
加齢のせいなのでしょうか？
チェーンソーマンとかダンジョン飯とか、最新刊を買ってスッと読もうとすると、アラ？このキャラクター誰でしたっけ？ってなるときがあるんです。
そもそも、あれこの話は私が記憶してる話の続きではないのでは？とKindleのライブラリを開いて既刊を読み返すと、
ようやく、あーそうだったっけ？ああそうそう思い出した、そういう話になってたんだった！とエウレカする。
これがね、悲しい。
まあ昔みたいな記憶力がないのは諦めたつもりだけど、それでも数ヶ月前に読んだはずのお話がこんなにも飛んでるものかね？と自分でもビックリしてしまう。
私、emacsって知ったのってエディタ戦争を知ってからで、専門学校の1年生の頃だったかなぁ。
秀丸とかしか知らなかったから、emacsやvimっていうのを知って、なんだかワクワクしちゃったんだよね。
Andy Huntさんもエディタに詳しくなれって言ってるし、カスタムキーバインドやオートコンプリートでめっちゃ効率アップできるって聞いて、自分も試しにやってみたんだよ。
結局、私にはemacsが一番しっくりきて、emacs lispも勉強して、エディタを自分好みにカスタマイズする方法を覚えたんだけど、他の人が作った可愛い.elライブラリを使うことが多かったな。
bashも最初からemacsキーバインドを使ってるし、覚えておいて超便利だったよ。
最終的にはemacsを常に立ち上げて、開発やメール、TODO管理も全部emacsでやっちゃうようになったんだけど、でもff14はやっぱりemacsじゃできなかった（笑）。
ストールマン先生がペド疑惑で騒動になったりして、ちょっと混乱した時期もあったけど、それでもemacsをやめるってことはなかったな。
まあ、とにかく小指がちょっと痛いんだよねぇ。
わし「メールでよく使われるmbox形式のファイルを読みたいんや。dotnetならどうするといい？」
Bing先生「MimeKitとかMboxReaderという.NETライブラリがええで」
わし（ほーん、MimeKitええな。。。MboxReaderってどんなんやろ）
わし（あれれ、MboxReaderとかいう.NETライブラリは無いぞ・・）
わし「MboxReaderの詳しいところ教えてや」
どや」
わし「ほーん・・・？」
わし「MboxReaderとかいうライブラリって実在するん？」
Bing先生「するで。これや https://github.com/nodemailer/mbox-reader 」
今までだと嘘はすぐに破綻してたはずなのに、今度の嘘はなかなか破綻しないぞ・・・
今、「MboxSharp」とかいう架空の.NETライブラリの説明を受けてる・・・
しかしさすがのBing先生、MimeKit の中の Rfc2047 クラスの使い方をちゃんと教えてくれた。
まあ Stack Overflow にも書かれてある事をまとめただけではあるが。。
やっぱ先生はすげえんよ。
もともとPythonは世界的に見ればとても成功した言語だった（Python2のころ）。
PythonにはPEPという言語の仕様を決めるための文書があってこいつがOSS開発者の中では非常に受けが良かったんだ、Pythonの開発者であるGuideは「優しい終身の独裁者」などと揶揄されていた。
この時代に作られた多くのPythonによる資産が多くのOS（特にLinux派生のOS）に組み込まれたために、OSにはPythonがプリインストールされることになり、そして未だに存在し続ける理由となったんだ。
プリインストールされているPythonのバージョンを確認すると2系であることが分かるはずだ。
しかしPythonは2から3へのバージョンアップで多くのユーザーを失って死に体になってしまったんだよね、Railsが台東したあたりからプログラミングに興味を持った人からみると死に体のPythonとイケイケのRubyを初めに見てしまったからRubyのインパクトが強くなってしまうのは仕方ないね、でも、もともとはPythonのほうが圧倒的にユーザーもシェアも多かったんだよ。
しかし、PythonにはPythonによる優秀な資産があるので簡単には死ななかったんだ。
中でも数値計算に使えるライブラリを持つ言語としてはPythonが最もポピュラーだったことから機械学習とセットで一気に息を吹き返すことになる。
とはいえ、この頃からは当初のPythonの理念とはかけ離れた金の臭いにつられたようなユーザーが多く参入してきたためにGuideも疲れ果ててしまい開発者の座を退くことになってしまう。
今やPythonは多くのメディアによる祭り上げによって金の臭いにつられた人間が集い金を稼ぐ手段として用いられており、そういった理由からPythonの本やらなんやらが多く夜に出回っているんだよ。
あぁ、私の好きだった頃のPythonはもう帰ってこないのだ！
