サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
cnaos.hatenablog.com
少し前の話なのですが、winnyを介しての情報流出が会社で問題になっていまして、 全社員に対して個人所有のPCでチェックツールを実行して、 結果を報告するようにとのお達しがありました。 私はそんな格好ばかりの対策など無意味で、 個人への余計な干渉だと思っていたため、突っぱねるつもりだったのですが、 会社のやり方はさらにその上をいっていました。 チェックツールはCD-Rで一定のグループに1枚配布され、 各自持ち帰って自宅PCで実行する手順になっていたのですが、 そのCD-Rにでかでかと「社外秘」と印刷されていたのです。 「まて、これは孔明の罠だ。 情報管理の教育がちゃんと出来ているか確認するために 社外秘と印刷してあって、これに対してどのくらい問い合わせがあるのか 確認しているに違いない。」 と思って対応部署に 「これは社外秘と書かれていますが、自宅のPCで実行してもよいものですか? このツ
SIerの常識:「この画面のソースのステップ数は●●●だから、テストケースを最低●●ケース用意しろ」 こんな寝言を真っ昼間から堂々と言ってくれるSIerが多くて辟易します。 テストケース数とステップ数には何の相関もありません。 プログラマの常識:「ステップ数なんかクソ食らえ、テストケースは機能のインターフェースなどから算出されるべき」 日立はなぜデスマばかりおこすのか3【ポリリズム♪】より 219 :非決定性名無しさん:2009/01/15(木) 16:36:28 アホの日立はステップ数で、開発の何から何までを掌握できるつもりでいるみたいだね。 俺のところでは、アホ日立リーダーが 「この画面のソースのステップ数は●●●だから、テストケースを最低●●ケース用意しろ」 なんて言ってきたよ。 ふつー、テストケースは画面の入力項目の数や、その入力桁数や入力臨界値、入力パターン などから考えてい
javaでファイルの種類を判定する場合、mime-utilというライブラリを使うと便利らしい。 詳細は元のサイトを参照していただきたい。 2010/3/17追記:開発元のサイトが見れないので、sourceforge.netのリンクも追記しておく。 Mime Type Detection Utility download | SourceForge.net 検出アルゴリズムは次の通り ExtensionMimeDetector MagicMimeMimeDetector OpendesktopMimeDetector TextMimeDetector WindowsRegistryMimeDetector ExtensionMimeDetector ファイル名の拡張子から、MIME-typeを予測するもっともシンプルな検出アルゴリズム。 MagicMimeMimeDetector UNIXの
最近のJunitでは例外のチェックが前よりは簡単になったけど、JDaveの匿名クラスを使った記述方法と比べていまいちだなと感じていた。 例外のチェック方法の比較 JUnit4での例その1:@Testのexceptionを使う場合。 「JUnit Cookbook」より @Test(expected= IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0); } JUnit4での例その2:@Ruleを使う場合。 「http://kentbeck.github.com/junit/javadoc/latest/org/junit/rules/ExpectedException.html」より。 // These tests all pass. public static clas
前回のエントリで、対策が具体的でなかったのは、SHA-1などのハッシュ関数を使っても問題ないか自信が持てなかったためです。すみません。とりあえず自分で納得できる対策が調べられたと思うので書いておきます。 twitterIDをそのままSHA-1などの暗号学的ハッシュ関数にかけただけでは弱いので避けるということは知っていましたが、単なる固定文字列のsaltを付け加えるだけだと、常に同じ値が生成されるのでこれでいいのか自信が持てませんでした。 で、調べてみたら自動ログイン用のクッキーの値に必要な特性は、セッションIDの特性によくにていて、値の生成は「ユーザIDや時刻等の情報と擬似乱数とを混ぜ合わせた文字列に対してハッシュ関数を使用する」で問題なさそうだということが分かりました。 また、管理方法もに似ていて、「ログインごとに認証用のキーとなる値を新しい値に更新しなければいけない」ということも分かり
「OAuth を使ってソーシャル・ネットワーキング Web サイトにアクセスする: 第 2 回: OAuth 対応のWeb 版 Twitter クライアントを作成する」のサンプルをいじくっていて気づいたんですが、TwitterのOAuth認証を使ったサービスを開発する場合、AccessTokenの管理方法に注意が必要です。 あんまり自信がないので、誤りがあればどんどん指摘してください。 以下の条件が成り立つ場合、サービス内でなりすましができてしまいます。 サービス(Consumer)がtwitterIDとAccessTokenをひもづけて保管している。 サービスがブラウザへ渡すcookieにtwitterIDをそのまま保存している ブラウザからサービスへtwitterIDを含むCookieが渡された場合、twitterIDをキーとしてサービス内に保存しているAccessTokenを検索し、
mavenレポートプラグインをてんこ盛りにしたpom.xmlの設定例です。 以下のレポートプラグインを使います。 org.apache.mavenのプラグイン maven-site-plugin プロジェクトのサイトを作成する maven-jxr-plugin クロスリファレンスを作成する maven-surefire-report-plugin テスト結果のレポートを作成する maven-checkstyle-plugin checkstyleのチェックレポートを作成する。 maven-pmd-plugin PMDでのチェックレポートを作成する。 org.codehaus.mojoのプラグイン findbugs-maven-plugin findbugsのチェックレポートを出力する。 cobertura-maven-plugin Coberturaを使ってカバレッジレポートを出力する。ビ
「Java の冗長性を排除する手軽な方法」で紹介されていたlombokというライブラリが便利そうだったので、NetBeansで試してみた。 一言で言うと、lombokはJavaBeanのsetterやgetterを省略可能にして記述量を減らしてくれるライブラリ。JavaBeansのメソッドはIDEで機械的に生成できるけど、このくらいの単純な仕様にして欲しかった。 ふつうのライブラリとちょっと違うのは、IDEのコンパイラがアノテーションを処理できるようにインストールが必要なこと。javacで扱う分にはjarがクラスパスに入ってればいいらしいけど。 lombokのインストール手順 Project Lombokをブラウザで開く lombok.jarをダウンロードする lombpk.jarを実行する(lombokのインストーラが起動する) WindowsでJREがインストールされている場合はjar
「javaプロジェクトを簡単に単一jarファイルで配布する - lime55の日記」から 「One-JARでアプリケーションの配布を単純化」経由で 「Google Code Archive - Long-term storage for Google Code Project Hosting.」を見つけたので試してみる。 One-Jarの仕組みをごくおおざっぱに説明すると、 Jarの中にJarが入れ子で入っている。 外側のJarのMainクラス=外側のJarに含まれる特別なクラスローダが起動される 入れ子になっている内側のJarをロードする 入れ子のMainクラスを起動する という感じ。 これまで、「Mavenで配布用zipファイルを作成する - Sacrificed & Exploited」でいろいろな配布パッケージを作る方法を試したけど、jar一個ですむならそっちの方が楽だし。 one
slim3-archetype-quickstartと、maven-gae-pluginを使ってNetBeansでslim3のMavenプロジェクトを構築してみました。 この手順でできるのは、アーキタイプで作成されたプロジェクトをローカルで動かして動作確認するところまでです。デプロイはまた後日。 2010/4/30追記 つぎのようなデメリットがあることに気がつきましたorz。ばりばり作っていきたい場合はeclipseで開発した方がいいかも。 HOTリローディングできない。(確認したわけじゃないですが、maven使ってるのでおそらくムリでしょう。) controllerやmodel、serviceを手動で作成しなければいけない。(slim3が提供しているblankプロジェクトの場合は、antスクリプトでやってくれます。) 1.slim3-archetype-quickstartでプロジェクト
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない!! プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
普段使ってるeclipseプラグインを書き出してみる。 使っているeclipseのバージョンはPleiades All in Oneのjavaパッケージ(Pleiades All in One Java), pleiades-e3.5-java_20100226.zipです。これが出来たおかげで、ずいぶん楽になりました。 プラグインを入れすぎると不安定になったり、重くなったりするので、必要なものだけ入れておくのが良いみたいです。 プラグインをインストールする際の注意 eclipse環境のバックアップを作る もし、あなたがeclipseを開発に使っているのなら、プラグインをインストールする前に、必ずバックアップを取ってください。ディレクトリをまるごとコピーしておくだけでもいいです。 相性の悪いプラグインをインストールすると、eclipseが起動すらしなくなり、eclipseを再インストールす
皆様お疲れ様でした。 イベントレポートって何をかけばいいんだろ?とりあえず、個人的な感想とふりかえりを中心に書きます。 また、勝手な解釈が混じっている事を先にお詫びします。イタリック青字の部分は私の考えなどです。 見た感じ、スーツ率高い、参加している人はプロジェクトリーダ/マネージャが多いみたい。また、実際に現場でアジャイル開発に取り組まれている方が多いような感じがしたけど、実際のところどうだったんだろう。 私の立場 Javaプログラマ(現在無職) 無職じゃなければ平日のイベントには参加できなかっただろうな。 ウォーターフォールがちがちのプロジェクトは何かおかしいと思って、開発プロセスを現場の人間が改善出来る環境を探求中。 プロジェクトのマネージメント経験なし トム・デマルコ信者ではあるが アジャイル開発の経験なし。 ウォーターフォールベースで、仕様が確定しておらず、随時変更されるという似
SIerの常識:「誰が書いても同じソースコードになるように、詳細な実装方法の記述された設計書を書かなければならない」 プログラマの常識:「誰が書いても同じソースコードになるような設計書は書くだけ無駄、誰が書いても同じ振る舞いをするように、詳細に振る舞いを記述した設計書を書かなければならない。」 プログラムを作るうえで設計書や、仕様書の類は欠かすことができない だが、設計書や仕様書をちゃんと作っているプロジェクトでもよくデスマーチに陥っている。 なぜか?「設計書に記載するべき内容が間違っている」からだ。 (設計が間違っている場合も多々あるが。) 間違ったことをまじめにやっても良い結果は得られない。 「誰が書いても同じコード」は大事なことなのか - yvsu pron. yas 昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、そ
詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと1対1に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容(内部の処理の実装方法)の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、
プログラマ35際定年仮説には、2つのとらえ方があって、1つは、表面的な仕事の内容と人月計算の利益が見合わなくなるため、プログラマの定年になるという話、もう1つは、技術に追いつけなくなって、やっぱり定年になるという話。このエントリでは後者の技術的に追いつけなくなる場合について述べる。 かなり乱暴なたとえだし、ソフトウェア開発は製造ではなく設計や研究開発に近い性質を持っているというのを承知したうえで言うが、ソフトウェア開発業におけるプログラマは、半導体製造における製造装置のようなものではないか。 というのは、定期的に投資して更新していかないと市場の要求を満たさないレベルの設備しかもてず、仕事が先細りになっていく部分が似ているのではないかと考えたからだ。 プログラマに対しての投資というのは、新規の要素技術やフレームワークなどを実際に使わせてみて、その技術についてのノウハウを少しでもいいから蓄積す
mavenで依存ライブラリや設定用ファイル、バッチファイルなどを含んだ配布用zipファイルを作る方法をメモしておく。 配布物のディレクトリ構成 以下のような構成の配布物を作成します。 +bin/ +sample.bat <----起動用バッチファイル(windows用) +sample <----起動用バッチファイル(unix用) +config/ +config.xml <----設定ファイル +config.xsd +backlog.xml <----backlogの設定ファイル +lib/ +sample-0.0.1.jar <----実行対象のjar +依存しているjar 実行方法のバリエーションについて jarに格納されたクラスを実行するには、以下のようなバリエーションがあります。 依存ライブラリを統合した実行可能なjarを作成し、-jarオプションの引数に指定して起動する。 依
オフショア開発のテストに投入されてえらい目にあわされたことがあったので、原因を考えてみる。 ちまたでは、やれ品質意識が違うだのなんだのと言われてるが、俺がえらい目に遭ったオフショア開発では、仕様書の作成からオフショア開発させていた。 そりゃデスマーチ化するって。だいたい、どんな品物が欲しいのかを詳細に言わずに、希望にぴったりの品物が得られるわけが無かろう。*1 極端なたとえ話だけど、形状のみが書かれていて、寸法が書かれていない本棚の設計図をもとに、「この図面のとおりに板を切ってくれ」って業者にたのんだらどうなると思う? 国内の業者なら、寸法の書かれていない本棚の設計図に、常識で考えられる範囲の寸法、例えば、文庫本が収まるサイズとかを当てはめて、それなりの寸法で板を切ってくれかもしれない。また、棚いっぱいに本を並べたときに壊れない程度の厚さの板をつかうかもしれない。 海外の業者ならどうだろう
ポリモーフィズムを使ってないひどいコード設計を見たので、どうリファクタリングするべきだったのかを書いておく。 やばい匂いのするコード そのシステムでは、複数の銀行とのやりとりを行うため、銀行コードに基づいて処理を分岐していた。そうこんな風に void 入金(銀行コード, ユーザID, 金額){ if(銀行コード==0001){ // A銀行用の処理 ... } else if(銀行コード==0002){ // B銀行用の処理 ... } else { // エラー } } void 出金(銀行コード, ユーザID, 金額) if(銀行コード==0001){ // A銀行用の処理 ... } else if(銀行コード==0002){ // B銀行用の処理 ... } else { // エラー } } ここでは2つしか出してないけど、実際はもっと数が多いと思って欲しい。30個くらいはあった
継続的インテグレーションとか、デイリービルドとか、そこまでやる時間やリソースが無い場合でも最低限守って欲しいリリース用のビルド手順について勝手に述べます。 もちろん、継続的インテグレーションやデイリービルドができるのなら、そちらの方が望ましいですが、会社の宗教上の理由などによって禁止されていたりする場合もあるので、そういった場合のためになにかしらの参考になれば幸いです。 デイリービルドやインテグレーションビルドについて聞いたことがなければ、以下のページを参考にしてください。 http://japanese.joelonsoftware.com/Articles/DailyBuildsAreYourFriend.html - 継続的インテグレーション �\�¬ŠÇ—��@ŽÀ‘H“ü–å�@‘æ1�Í �\�¬ŠÇ—�“ü–å�@‚Í‚¶‚ß‚É 特に「�\�¬ŠÇ—��@ŽÀ‘H“ü–å�
ビルド手順書だったり、モジュールの配備手順書だったり、そういった手順書を書くときに気をつけている事を勝手に列挙します。 はじめに 手順書を実施するうえで、最大の敵になるのがヒューマンエラーです。 ヒューマンエラーをなくすには、完全に自動化してしまえばいいんですが、そこまで出来ない場合でも最低限守った方がよい事をのべます。 よくあるパターンが コマンドの入力ミス 手順を飛ばした 配布先を間違えた などです。 1.手順書の実施順序は最初から最後まで一方向に読めるようにしておく たとえば、同じ手順を複数の箇所で実施させる場合、 ここでXXページの○○手順を実施する。 などといった前の手順に戻って実施させるような記述は避けましょう。 途中で手順をさかのぼって実施させると、いまどこの手順を実施しているのか分からなくなり、ある手順がスキップされてしまう確率が上がります。 めんどうですが、コピーペースト
転職のためにいろいろな会社で面接をうけているのだが、よく落ちるw。エンジニアとして誠実であろうとすると、会社の方針と反してしまうというのが理由の一つらしい。 面接をしている人事担当者が言うには、「エンジニア視点というよりは、経営者視点で物事を考えて欲しい。」とのことなのだが、この経営者視点が具体的にどういうことかというと、 プロジェクトで利用することになっている自社製品があまり使い勝手や性能の良くない製品であり、代わりの良い製品を知っていても自社に利益が出る場合は、口をつぐんでいる必要がある。 ということらしいw あるいは、 間違った開発手法、開発プロセスが取られていても、それはお客様の意向なので、信頼を得るためには従わなければならない。 たとえ、ソースコードの履歴をコメントアウトで残すような手法であってもだ。 とかw そりゃエンジニアが軽視もされるし、疎ましくも思われるだろう。正論を述べ
「コードレビューって意味あるの ?」 - カレーなる辛口Javaな転職日記とそのブクマを読んで思った事を2つ 1つ目 コンサルタントの道具箱より レディングの読書の法則:「読む価値のないものは読むな」 ケアリーのゴミ警報:「やる価値のないことは、きちんとやる価値もない、ゴミにのしをつけるな」 フリーブルの感覚フィルター「やるべきでないことは、いっさいやるべきではない。以上。」 をそのまま使える。ゴミコードは読む価値すらない。ゴミコードをいくらレビューしてもゴミにのしをつけるようなもの。 2つ目 fusionstar「ふと思ったんだけど、コードレビューを受託でやってる会社とかないのかなぁ。 2009/06/29 」 と言ってるけど、ソースコードチェッカにかけて、その結果をレポートしてくれる会社はあります。 ただ、人間がレビューするとなると、そのゴミっぷりにレビュアーの方が音を上げる可能性が非
文書ドリブン開発 詳細設計文書編 (1/2):システム開発プロジェクトの現場から(26) - @ITより このV-モデルを見ると単体テストは詳細設計文書をインプットにして作成されることが分かると思います。もしあなたが単体テストの仕様書をプログラムコードから起こしているとしたらそれは間違いです。もしも誤りのあるプログラムコードからテスト仕様書を起こして単体テストを実行した場合、仮に動作結果が「書かれたとおりに動いた」としてもそれは「正しい結果」とはなりません。単体テスト仕様書とは本来は詳細設計文書をベースとして書かれるべきものなのです。 この部分には同意する。 ソースコードから単体テスト仕様書をつくっても品質は上がらない。 テスト技法を大きく分けるとブラックボックステストとホワイトボックステストに分類できますが、このホワイトボックステストのテスト仕様書を書けるようなレベル感が詳細設計文書の目
ソフトウェアの規模は、ハードウェアの規模がそうであるように生産量ではなくスペックである。実現方式が違えば生産量の定義が変わる。そんなバカなことはない。プレス加工だろうが、鋳造だろうが、生産量の定義が変わるはずがない。ソフトウェアの規模を生産量扱いするというのは、加工方法が変われば生産量の定義が変わるというようなもの。これでは、異なる加工方法間での生産性の比較ができず、生産性の大幅な改善は期待できない。ソフトウェア開発の生産性が向上しないのも、生産量の定義が間違っていることによるものが大きい。 ソフトウェアにおける開発はハードウェアにおける設計 - 酔狂人の異説 に触発されてこのエントリを書きました。 はじめに これまで、私はウォーターフォール型の開発プロセスを使った現場でプログラマをしてきました。 しかし、いくら設計書をちゃんと作っても、バグが無くなったり、 進捗管理を厳しくやっても、スケ
以下の資料を参考にさせてもらいました。 XPのネットワークブリッジが使えない時の覚え書き | 道具眼日誌:古田-私的記録 http://www.microsoft.com/japan/windowsxp/expertzone/columns/crawford/02april22.mspx netshコマンドのヘルプを表示してみる コマンドプロンプトを開いて「netsh bridge」でブリッジ設定用に使うコマンドのヘルプが表示されます。 このコンテキストのコマンド: ? - コマンドの一覧を表示します。 dump - 構成スクリプトを表示します。 help - コマンドの一覧を表示します。 install - 現在のコンテキストに対応するコンポーネントをインストールします 。 set - 構成情報を設定します。 show - 情報を表示します。 uninstall - 現在のコンテキストに
このページを最初にブックマークしてみませんか?
『Sacrificed & Exploited』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く