javascriptプログラマのレベル10 : tech.kayac.com - KAYAC engineers' blog
週末料理をしていて足を切ってしまいました。agoです。 以前Perlは書いていたんですが、その頃以下の記事を読んで非常に感銘を受けました。 Perlプログラマのレベル10 - Perlプログラミング救命病棟より - naoyaのはてなダイアリー 当時あまりコミュニティとのつきあいがなかったので、「自分のスキルの絶対位置」、「次のレベルへ行くために必要なもの」を知ることで非常に安心感を感じた記憶があります。 いま確認したところ、「JavaScriptプログラマのレベル10」はないようなので書いてみました。 Perlプログラマ Schemeプログラマ Rubyプログラマ （本家に直接リンクできるURLが無かったため、参照ページへリンクしています） haskellプログラマ 堕落したCプログラマ HTML知識レベル プログラマレベル 企業法務 JavaScriptの業務スキルレベル 判別表 （５
こんな仕様書は読む気がしない - rabbit2goのブログ
ソフトウェア開発において、受け取っても読む気が失せる仕様書の例： 文字ばかりで図表が無い 機械、電気、建築など他のエンジニアリングでは図面でのやり取りが普通なのに、ソフトウェア開発ではなぜ文章に頼った意思疎通が多いのだろうか？確かに文章にしなければ表現できない内容も有るけれど、UMLのような図面を使う方が一目で分かりやすいし、「全てのケースでの考慮漏れがないか？」を知るためには表を使って条件を網羅的に整理するのが確実だろう。文章だらけの仕様書は「何か記載されていない項目があるのではないか？」という疑いを晴らすことが出来ないように思う。 背景説明が無い やたらと詳細な仕様が書かれているのに、「全体構成」や「概要」が記載されていないので、一体何についての資料なのか全体像がなかなか理解できない。書き手にとっては「アタリマエ」のことだろうけど、それを読み手に伝えるのが仕様書の役割だろう。仕様書は、
評価を高める仕事術（2）「先が読めない」人は損をする
この連載では、「ダメに見せないことで評価を高める」ための仕事術を扱っている。前回は、ダメ評価につながる11のネガティブ特性について説明した。ネガティブ特性は以下の通りである。 先を読まない、深読みしない、刹那主義 主体性がない、受け身である うっかりが多い、思慮が浅い 無責任、逃げ腰体質 本質が語れない、理解が浅い ひと言で語れない、話が冗長 抽象的、具体性がない、表面的 説得力がない、納得感が得られない 仕事が進まない、放置体質 言いたいことが不明、論点が絞れない、話が拡散 駆け引きできない、せっかち、期を待てない 今回から、11のネガティブ特性の具体的な説明と対策を説明していく。一つ目は、「先を読まない、深読みしない、刹那（せつな）主義」である。 現状起こっていることだけに反応する 「先を読まない」とは「将来に向けて起こりそうなことを予想しない」という行動特性を指す。筆者の経験では、意
TDD Boot Campのコード - @katzchang.contexts
というわけで、晒します。 前半は@katzchang・@kozy4324のペア。後半は@katzchang・@yugoriのペア。 Eclipseは独自に履歴を持っているので、2パターンを引っ張り出してきました。クラス宣言部にカーソルを当てて右クリックからLocal History。たぶん20セーブくらいしか保持してないけど、たまに助かることもあります。 仕様変更直後くらい ということで、仕様変更直後くらいのセーブから。大体の時間で取っているので、REDな組み合わせかも知れません。 基本的には、テストコードは下に順に追加していっています。上にある項目から順に、プロダクトコードを作り込んでいったってことです。 第一の仕様変更（キャッシュサイズを変更できるようにする）まで対応済、第二の仕様変更（一定時間が経過したデータはキャッシュから消える）に対応しようとしたら、既存機能にバグの疑いがあり、バ
TDD Boot Campの感想 - @katzchang.contexts
「一番大事なことは最初に言う」とのことなので、大事なことから順に書きます。 反芻してるうちに思い出したら、追記するかもしれません。 ペアプロの前半のパートナーである@kozy4324とともにミルズ賞を受賞しました。 「前半のペアでコードが綺麗だった。私はJavaはわからないが、何が書いてあるのか、どう動くのかがわかった。後半にペアを変えても、それぞれのペアで綺麗なコードを書いていた。」とのこと。最大級の栄誉です。 個人的な理由の一つは、「いわゆるJava」っぽくないJavaが好きなので、Javaに慣れていない人向けなコードを書いていたこと。もう一つは、TDD読書会で存分に予習できていたことです。 @kozy4324はもちろん、TDD読書会のメンバーにも感謝です。 TDD Boot Camp Hokurikuを企画中です。3月予定。コーチ役としてid:t-wadaは欠かせないでしょう。Mic
TDD Boot Camp の参加報告とか読んで - ぐるぐる～
TDD Boot Camp には行っていないんだけど、参加者のエントリを色々読んで触発されたので思っていることをちょこっと書いておきます。 日曜日は id:a-hisame に無理言って色々と聞いた*1しね！ 以下引用が多くて微妙に長文。 アクセス修飾子 デモ：coberturaに機能追加する*1 テストできそうな箇所を小さい範囲にメソッド抽出 さらに、副作用がある箇所をprotectedメソッドに抽出 サブクラスで副作用メソッドをオーバーライドして無効化 テストのために、検出用変数をprivateからpublicに変更 検出用変数にアクセスして、assertを記述 *1: この辺ちょっとうろ覚え。もし間違っていたらご指摘ください。 TDD Boot Campに参加しました - @ikikko のはてなブログ これの 4 と 5 なんだけど、個人的には package private でい
EclipseやSpringで使われている基盤技術OSGiとは (1/3) - ＠IT
読者の皆さんは、「OSGi」という技術を耳にしたことはありますか？ ソフトウェア統合開発環境の1つ「Eclipse」のコア技術というとピンと来る方も多いと思います。本稿では、ここ数年さまざまなアプリケーションの（SpringやJBoss、GlassFishでも）基盤技術として採用されているOSGiについて解説します。 日本企業も多数参加している「OSGi Alliance」 OSGiを一言でいうと、「Javaモジュールの動的追加や実行を管理するための基盤システム」です。この基盤システムの仕様をOSGi Service Platform仕様として、非営利団体であるOSGi Allianceが規定しています。 このOSGiの仕様を規定するOSGi Allianceは、1999年に「Open Service Gateway Initiative」という名称で設立されました。「Gateway」とい
Evernote - メモ管理システム - Fumihiro Kato / 加藤 文彦
知的労働者にとって，メモ管理は悩ましい問題です．私はアイデアや文章の断片などの情報を日々記録するようにしていますが，複数台のパソコンで作業したり，手帳に書いたりもするので，意識して管理しないと分散してしまいます，そして，しばらくするとどこに何を書いたかを忘れてしまうのです． メモ管理用のシステムとして，Palm+Windows/Linux用デスクトップクライアント，Wikiなど，様々な方法を試みましたが，結局サーバ上のEmacsでChangeLog memoやhowmを使い，リモートで作業するという古いスタイルに落ち着いていました．出張が多くなってからはオフラインでも作業をする必要があったので，howmディレクトリを適宜サーバーへrsyncするという方法に変えましたが，rsyncは行うのを忘れやすく，また，複数台で作業しているとどれが最新なのかわからなくなって困るという事態が度々起こりまし
プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」
一兵卒は必携、プロジェクトの腐臭を嗅ぎとれるようになる一冊。むしろ、「アドレナリンジャンキー」だったわたしに読ませたい 「アドレナリン・ジャンキー」とは、モーレツ社員（死語）、もしくはモーレツ社員で構成された組織のこと。すべての仕事は最優先で、全ての送信メールは、【！緊急！】で始まる。作業の順番は重要性ではなく、切迫度によって決められる。したがって、長期的な見通しは存在せず、全ての仕事は、ある日突然、「緊急」になるまで放置される。 こういう人や組織があることを知っておくと、「そこに染まりやすい」危険性も予測できる。だから、回避も可能だ。そもそも知らなければ、回避する／しないの判断をすることなく、あなたもアドレナリン・ジャンキーの仲間入りとなるだろう。 あるいは、「死んだ魚プロジェクト」。人は結構いるのに、妙に静かなオフィス。入ったばかりのあなたに対し、チームメンバーは気の毒そうな顔で応ずる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
