タグ

2017年11月2日のブックマーク (4件)

  • 読みやすいコード(僕にとって) - Mitsuyuki.Shiiba

    最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク

    読みやすいコード(僕にとって) - Mitsuyuki.Shiiba
  • Googleが開発する最新ビルドツール「Bazel」を使ってみよう | さくらのナレッジ

    Bazelの特徴2:ビルドによってディレクトリを汚染しない Bazelでは、ソースコードやテストデータなどが格納されているディレクトリとは別のディレクトリでビルドやテストなどを行う仕組みになっている。makeコマンドでは意図的に設定や操作を行わない限りソースコードと生成物が同じディレクトリに混在する事態になることが多いが、Bazelではこういった問題が発生しない。 また、ビルドやテストはデフォルトではサンドボックス化された環境で行われるため、ビルドやテストがそれを実行しているシステムに影響を及ぼす可能性が最小限に抑えられている。 Bazelの特徴3:並列ビルド 大規模なソフトウェアではビルド対象が増えるため、ビルドにかかる時間も増える傾向がある。Bazelでは生成物どうしの依存性を自動的に把握し、可能な限り並列でビルドを実行する仕組みになっている。これにより、ビルド時間の短縮が期待できる。

    Googleが開発する最新ビルドツール「Bazel」を使ってみよう | さくらのナレッジ
  • モノリシックなバージョン管理の利点 | POSTD

    以下は、私がよく交わす会話の一例です。 人物A:FacebookやGoogleは、巨大なモノリシックリポジトリ(モノレポ)を使っているんだってよ。 私:みたいだね。あれは当に便利だと思う。 人物A:僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私:FacebookやGoogleエンジニアたちも小さなリポジトリには精通しているだろうけど( 濱野純(Junio Hamano) 氏はGoogle勤務だし)、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A:なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ

    モノリシックなバージョン管理の利点 | POSTD
  • 会社のエンジニアブログを書くこと

    エンジニアブログを立ち上げたいんですけど、という話を相談ここ最近何件か立て続けに合ったので、なんかざっくりですがアウトプットしておこうと思います。 自分が過去に今の会社で立ち上げたときに社内に書いた文書をちょっとアレンジしたものです。何かの参考にしてもらえるとうれしいです。 なぜやるか会社の技術ブランディングを高めたいって、これに尽きるんだけど、技術ブランディングというのはつまり「この会社にはこんな技術出来る人がいるのか」と思われること「この会社の、公開されてるこの技術、超良いな」と思われること「この会社のエンジニアの環境、楽しそう」と思われること結果、「この会社、すごい人が集まってる」感を出すことそれにより、「その会社で働いてみたい」「その会社にいるこの人と働いてみたい」人が増えていくことなどなど、だったりしますでもそれだけじゃなくて、 エンジニアがプロダクトだけでなく、それに付随する技