自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク
以下は、私がよく交わす会話の一例です。 人物A:FacebookやGoogleは、巨大なモノリシックリポジトリ(モノレポ)を使っているんだってよ。 私:みたいだね。あれは本当に便利だと思う。 人物A:僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私:FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど( 濱野純(Junio Hamano) 氏はGoogle勤務だし)、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A:なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
この記事はAngular公式ブログ Version 5.0.0 of Angular Now Availableを元に翻訳、加筆したものです。 Angularのバージョン5.0.0、pentagonal-donutをリリースしました。このリリースは新機能とバグ修正を含むメジャーリリースです。Angularの軽量化と高速化、そして使いやすさにフォーカスしつづけています。 ここではv5における大きな変更について取りあげます。すべてを知りたい方はチェンジログを参照してください。 Build Optimizer5.0.0以降、CLIで作成されたプロダクションビルドではデフォルトでビルドオプティマイザが適用されるようになりました。 ビルドオプティマイザは、Angularアプリケーションのセマンティックな理解をもとにバンドルサイズを小さくするためのCLI同梱のツールです。 ビルドオプティマイザには2つ
jQuery のソースを呼んでいて、イベント登録のところが複雑だったので備忘録として記しておく。 バージョンは 1.2.1。 そもそもの目的 DOM 標準の removeEventListener は、element と type(click, submit, blur など) と listener の3つを指定する必要がある。 element.removeEventListener(click, listener, false); jQuery ではイベント解除に unbind という便利な関数が用意されている。 element, type, listener を指定して解除する(通常の removeEventListener と同じ)element, type を指定して全てのイベントハンドラを解除するelement から全てのイベントを解除する 例えば、 $("#foo").unbi
エンジニアブログを立ち上げたいんですけど、という話を相談ここ最近何件か立て続けに合ったので、なんかざっくりですがアウトプットしておこうと思います。 自分が過去に今の会社で立ち上げたときに社内に書いた文書をちょっとアレンジしたものです。何かの参考にしてもらえるとうれしいです。 なぜやるか会社の技術ブランディングを高めたいって、これに尽きるんだけど、技術ブランディングというのはつまり「この会社にはこんな技術出来る人がいるのか」と思われること「この会社の、公開されてるこの技術、超良いな」と思われること「この会社のエンジニアの環境、楽しそう」と思われること結果、「この会社、すごい人が集まってる」感を出すことそれにより、「その会社で働いてみたい」「その会社にいるこの人と働いてみたい」人が増えていくことなどなど、だったりしますでもそれだけじゃなくて、 エンジニアがプロダクトだけでなく、それに付随する技
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く