品質におけるコメントの役割。あるいは、レビューとコメント - きしだのHatena
昨日のエントリでも書いたきょんくんとの会話なんだけど、なんとなく、コメントとテストは同じように扱えるんではないかという認識のもとで話がすすんでた。もちろん、コメント書けばテスト書かなくていいとかそういうのではなくて。 テストは、書きやすい対象と書きにくい対象がある。関数的に計算を行うコードの場合はテストが書きやすい。一方で、関数的ではなく副作用のあるコードはテストが書きにくい。データベースを扱ったり通信したりUIがあったり。 そして、そのようなテストを書きにくいときに、コメントはテストのように品質のために使えるんではないか。 で、問題は、どのように品質のために使うかということなんだけど、コードレビューのときの指針として使えばいいんじゃないかなと思った。 コードレビューのとき、コードだけを見ていると、名前付けとかコードの順番とか条件文の使い方とか、体裁的なものだけのレビューになりがち。そこで
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
「Javaエンジニア養成読本」養成読本 - きしだのHatena
「Javaエンジニア養成読本」でてます。 Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus) 作者: きしだなおき,のざきひろふみ,吉田真也,菊田洋一,渡辺修司,伊賀敏樹出版社/メーカー: 技術評論社発売日: 2014/11/11メディア: 大型本この商品を含むブログ (9件) を見る すでにもうみんな買って読んでると思うので、内容についてはここで書くまでもないと思います。 内容については、他の著者のエントリや Javaエンジニア養成読本が出ます！ - Challenge Java EE ! 「Javaエンジニア養成読本」が出るのです - 日々常々 Javaエンジニア養成読本が発売されました！！ - bitter_foxの日記 読んだ人の書評などで。 L'eclat des jours(2014-11-11) 「Javaエンジニア養成
プログラムの組みやすさが世界を変えるフェーズは終わったのではないか - きしだのHatena
2005年くらいから、コンピュータの性能には余裕があるので、プログラムの効率が多少わるくなってもプログラムが組みやすく人間の能力が発揮できるほうがいいという傾向が強くなりました。 プログラムはサーバーで動かすものであり、サーバーの制約はネットワークとストレージでCPUやメモリには余裕があったためです。 また、世の中は、ITのない世界からITのある世界への変化の中にあって、サーバーでの情報処理やネットワークをサービスとして提供することで、世の中が変わっていきました。 そういった状況であれば、プログラムが組みやすく、思ったとおりのサービスを思った時期に提供できるということが大切になっていました。どんなに未完成でも、新しいアイデアをいち早く見て触ってもらうということが大切だったからです。 しかし、もうすでに世の中は、ITがある世界に変わりました。 もちろん、より便利な情報処理サービスも今後でてく
Java8で強化されたMapと、書きやすくなったメモ化再帰 - きしだのHatena
Java8のlambda構文の話を書くと、旧来の書き方でいいというコメントがつくのですが、それでも便利になったMapの恩恵を受けることは多いんじゃないかと思います。 ※ 2018/5/31 Java9からはメモ化再帰には使えなくなっています ※ 2019/2/15 なんか問題ない？ Mapには、lambda式を使ったメソッドが多く追加されていますが、たとえばgetOrDefaultメソッドのようなlambda式を使わないメソッドも追加されていて、これも便利です。 そして、このようなlambda式を使わないメソッドも、間接的にはlambda構文サポートでの言語拡張のおかげです。 Mapはインタフェースなので、Java7までの構文でメソッドを追加しようとすると、Mapを実装しているすべてのクラスに新しいメソッドの実装を追加する必要がありました。そしてそれは現実的に不可能なので、今までMapなど
プログラムの生産性をあげるためには - きしだのHatena
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
プログラマ業界の二分化 - きしだのHatena
プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく２つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その２つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で
直列加算と並列加算でdoubleの足し算の結果が変わる話 - きしだのHatena
Javaに限った話ではないのだけど、Javaで並列加算が気軽にできるようになったので、気に留めておいたほうがいい話。 まず、次のようなコードを動かしてみます。 public static void main(String[] args){ double[] data = { 1.234E80, -1.234E80, 2, 3}; System.out.println(Arrays.stream(data).sum()); System.out.println(Arrays.stream(data).parallel().sum()); } 1.234×10^80と-1.234×10^80という、桁が大きくて符号の違う数を並べて、そのあとに2と3という1桁の数値を置いています。 これらを加算すると、1.234×10^80と-1.234×10^80は符号が違うだけなので、当然結果は0になります
勉強会に参加しないと不幸になる話 - きしだのHatena
昨日のOSC福岡2013の「勉強会x勉強会」セッションで飛び込みLTしたときのプレゼンに加筆して公開しました。 追記：福岡の人はFacebookの福岡IT関連勉強会に参加しておくと、勉強会情報が得やすいと思います。
今どきのJava Webフレームワークってどうなってるの？ - きしだのHatena
昨日のSeasar2のエントリについたコメントなどで、「とはいえ代わりに何つかうの？」みたいな話が出てたので、とりあえずJava EEのWebフレームワークについて簡単にまとめてみます。 Java SE 8+Java EE 7+lombokで書いていますが、基本的なところはJava SE 7+Java EE 6でも大丈夫です。 なので、今どきとは書いてますが、基本的には2009年12月のJava EE 6ということで、実はすでに4年近くたってます。 何も考えてない なんも難しいこと考えないなら、やっぱJSPが楽ですよね。 なんでも書けちゃう。 <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content=
勉強することで何がいいのか実力者がいないことでデメリットはあるか - きしだのHatena
「この辺を勉強してどういう良いことがあったか教えて欲しい。」というコメントがついてた。 良いこととして、一番は、まあ勉強するのが楽しくなった、ということなのだけど、それは循環してるので置いておいて。 実務的に一番いいのは、プログラムを組むのが楽になったということ。 とくに、本質的な間違いが少なくなっていくので、後戻りが減るというのが楽。組んでみたけど動かない、途中でそれ以上組めなくなる、というのが少ない。まあ、ミスはあるので、そこの修正はするけど。 あと、できないことができないとわかりやすい。そのデータの持ち方でそのデータ数でその処理ではその精度の要求は満たせない、ということが原理的に判断しやすくなる。なので、むだな努力をしない。そして、どの条件を緩和すれば要求が満たせるかにも気づきやすい。 初見のライブラリや言語、ツールの理解が早くなる、とかも。 もちろん、前のエントリにも書いたように「
アルゴリズムの勉強のしかた - きしだのHatena
この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基本的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういう本で勉強すればいいか、ぼくの知ってる本からまとめてみました。
Java SE 7のjava.nio.file.Filesがとても便利な件 - きしだのHatena
とても便利。 たとえば、あるサイトからHTMLをダウンロードしてファイルに保存する場合。 try(InputStream is = new URL("http://www.google.com/").openStream()){ Files.copy(is, Paths.get("C:\\Users\\kishida\\Downloads\\google.html")); } ファイルの内容を一行ずつ読み込んで処理をする場合。 for(String s : Files.readAllLines(Paths.get("C:\\Install.log"), Charset.defaultCharset())){ System.out.println(s); } まあ、直接文字列でファイルパスを渡せなかったり、デフォルトCharset使う場合でも引数が省略できなくて、まだるっこいコードになってし
SIは面白くないけどエンタープライズは面白い - きしだのはてな
ここんところ、SIという業態はもうダメという話になってます。 で、エンタープライズ(=企業向けシステム)というのは、SIという業態で開発されるので、エンタープライズ=SIという前提で、企業向けシステムは面白くないという話になっています。 そこから、企業向けアプリは面白くないからサービスを作りましょう、という流れになって、GREEやDeNAなどに人材が流れてます。 実際は、サービスや企業向けというアプリケーションの種類と、SIや内製、パッケージという構築側の業態は独立なので、別に語るべきです。 たとえば、このインタビューを見ると、ゲーム業界もSI化していて、面白くなくなっていそうなことが伺えます。 稲船敬二氏は，何を思い，何を考え，何を目指してカプコンを辞めていくのか。渦中の氏に直撃インタビュー また、GREEやDeNAが提供するゲームは急激に大規模化していて、おそらくSI形態での開発が増え
プログラマならいつかは読んでおきたい(と言っておけばかっこいい)本10冊 - 2010-11-26 - きしだのはてな
昨日の技術力をあげたいプログラマが読んでおかないと話にならない本10冊は本自体にはあまり意味がなくでその技術分野が大事で、あとエントリーレベルのものが多かったので、今日は読み甲斐のある本を。 本棚に飾っておくとかっこいい本です。あと、本屋でまとめて買って持って帰れるなら、値段的にも重さ的にも、尊敬します。 ぼくが持ってない本や持っててもほとんど読んでない本がかなり含まれてます。「この人こんな本も読んでるんだー」などと無用に尊敬したらダメですよ。むしろ、そのように誤解させて尊敬させるための本です。 アルゴリズムデザイン 作者:Jon Kleinberg,Eva Tardos共立出版Amazon読んで面白いし、アルゴリズムカタログじゃなくて設計方法の解説が多いので、とてもいい本です。途中までは読んでるので続きを読まねば。 あとアルゴリズムの本としてはアルゴリズムイントロダクションが定番ですが、
2010-11-25 - きしだのはてな - 技術力をあげたいプログラマが読んでおかないと話にならない本10冊
ここにあげた本じゃなくてもいいので、同じ分野でなにか読むとか、本に書いてあるほど詳しくなくてもそれなりに知識をもっておくべき本。 アルゴリズムクイックリファレンス 作者: George T. Heineman,Gary Pollice,Stanley Selkow,黒川利明,黒川洋出版社/メーカー: オライリージャパン発売日: 2010/04/26メディア: 単行本（ソフトカバー）購入: 11人 クリック: 656回この商品を含むブログ (72件) を見る まずはアルゴリズム。クイックって書いてあるけどぜんぜんクイックじゃないｗ。各言語で書かれた入門書を読んでもいいと思う。 実際のプログラムにアルゴリズムの知識を活かすということを知りたいならプログラミングコンテストチャレンジブックがおすすめ。 プログラミングの基礎 ((Computer Science Library)) 作者: 浅井健一
「オブジェクト指向は教えないでください」ってなんてよくわかった会社だろうか - きしだのはてな
よく分かってる会社だ。 次世代の基幹系オープンシステム開発に利用されるプログラミング言語は？ - forest book 先日、SIer の友人が新人研修の講師として Java を教えるというお話を聞きました。会社側からは「Java を教えるのではなく、"プログラミング" を教えてほしい。オブジェクト指向は教えないでください。」との指示を受けたそうです。 プログラミングにおいて、現場での「オブジェクト指向」の優先度が低いってことですよね。 そして、理論的にも優先度は低い。アルゴリズムとか関数的ななにかとかをちゃんと扱えるようになるのが先決ですね。 関数+制御構造がやはり基本だし、その範囲がちゃんと扱えないで「オブジェクト指向」がちゃんと活用できるとは思えないし。 ただ、そうしようとしてもJavaではオブジェクト指向のための構文を知らざるを得ないので、その範囲のオブジェクト指向の知識は必要に
エラー処理の方針とString#equalsの書き方 - 2009-02-19 - きしだのはてな
String#equalsを使った文字列リテラルとの比較の書き方として、str.equals("リテラル")と書くのがいいか、"リテラル".equlas(str)と書くのがいいかという論争がありました。 そこで、この問題について、エラー処理の方針と絡めて考えてみようと思います。 エラー処理の方針として、エラーパッシングとエラーリカバリーという考え方があります。 エラーパッシングは、エラーがあってもそれを無視して処理を行うという考え方です。例えば音楽データの再生時に、データの一部が欠けていたとしてもそこを適当に補完を行って再生を続けるような考え方です。 人間相手の処理では、エラーによって処理が止まるよりも、それなりの対処を行って処理を続けることのほうが求められるので、ユーザーインタフェースやコンテンツのプログラムではエラーパッシングで考えることが多いと思います。 エラーリカバリーは、エラーが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
