愛知県内の男性（３９）が、自作プログラムで図書館ホームページから新着図書の情報を集めたところ、サイバー攻撃を仕掛けたとして逮捕された。しかし、朝日新聞が依頼した専門家の解析によると、図書館ソフトに不具合があり、大量アクセスによる攻撃を受けたように見えていたことが分かった。同じソフトを使う全国６カ所の図書館でも同様の障害が起きていたことも判明。ソフト開発会社は全国約３０の図書館で改修を始めた。 この問題は同県岡崎市立図書館で起きた。ソフトには、蔵書データを呼び出すたびに電算処理が継続中の状態になり、電話の通話後に受話器を上げたままのような状態になる不具合があった。一定の時間がたつと強制的に切断されるが、同図書館では１０分間にアクセスが約１千件を超えると、ホームページの閲覧ができなくなり、大量アクセスを受けたように見えたという。 男性はソフトウエア技術者で、岡崎市立図書館から年に約１００冊
GUI なコーディングしてると必ず出てくる「スクリーン座標とクライアント座標の変換」。環境によって名前がバラバラで思い出すのに時間がかかってしまうのでメモしておく。環境変換方法ActionScript3DisplayObject.globalToLocal(pt:Point), DisplayObject.localToGlobal(pt:Point)JavaScriptevent.screenX, event.screenY, event.clientX, event.clientYJavaScript (prototype.js)Position.positionedOffset()Win32ClientToScreen(), ScreenToClient(), GetWindowRect()WinFormsControl.PointToClient(), Control.PointT
1 行でブラウザ判別を行うスクリプト (IE 用の日本語紹介記事、Firefox、Safari 用の日本語紹介記事) を発端に、SpiderMonkey の判別とブラウザ判別: Days on the Moon や JavaScript でのブラウザ判別 - 「仕様の盲点」ではなく、「プロパティの有無」を使う方がマシ - 2009年2月 - Blog - EOFなどの記事があがっています。 ここでは少し実際的なケースごとにサンプルコードを紹介していきたいと思います。(サンプルコードは適当に書いているので、不正確な箇所があるかもしれません。ご了承ください。間違い等ご指摘いただけると助かります。) なお、これらは汎用的なJavaScriptライブラリを使っていれば意識しなくても良いケースがほとんどです。 分岐する必要がないケース 分岐する必要がないなら、ケースとしてあげる必要はないと思われるか
写真で振り返る京都旅行 先日文学フリマ京都8に参加するため初めて1人で京都へ行ってきました。随分時間が経ってしまったのでもうブログにまとめなくていいか、と思っていましたが、せっかくなので写真をメインに記録しておこうと思います。 出発▷▶︎▷▶︎わくわく新幹線！ 新幹線初心者すぎてか…
Ruby信者の特徴Matzは神であり神による実装であるRubyこそが唯一絶対の言語である他の言語（特にPerl）は存在自体が悪である他の言語を使っているのはRubyを知らないからであるRubyを布教することでそのような不幸な子羊たちを救済することこそが正義であるどこかの世界宗教のようですね。 「Perlベストプラクティス」まとめ を読んでふと「Ruby使えばいいのに」と思った - World Wide WalkerPBPより先に、Perlを選択する時点で、RubyよりもPerlを使いたいという前提があることを考えて欲しい。その上でPerlをよりよく（という言い方もあまり好きじゃないけど、ほかにいい言い方が思い浮かばない）運用する方法がPBPなんだろ。それに対して「それRuby（略」っていう発言は場違いであると思わない？ Perl の There are many ways to do it
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
ちょっと書いてみる最近、PMBOKだかを読むような人も増えてると思うけど、いくら読んでもデスマは解決しないのは、PDCAを滝に対して垂直に回すから。PDCAと滝の関係はP設計D開発CテストA修正と水平に回るべきなのに、今はこうなってる。PDCA設計PDCA開発PDCAテストPDCA修正つまり、垂直に回っている。設計に対していくらPDCAをまわしてみても、せいぜい誤字脱字、書式が正しくない、更新日付が間違ってる、と言ったことしか見つからないし、こいつらは、プログラムに対してまったく関係がない。まったく関係がないミスをいっぱい見つけて、はい、これで完璧です。次のフェースに行きましょう。って言ってるのが現状。で、開発になってこの設計ではうまく行かない点が見つかって大騒ぎになっている。何でだ設計書は完璧なんだろう？はい完璧に誤字脱字はありません。ギャグですかと。テストになってバグがいっぱい見つかっ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
