Burp Suite - Application Security Testing SoftwareHands-on web security testing Test, find, and exploit vulnerabilities faster with a complete suite of security testing tools.
Download Fiddler Web Debugging Tool for Free by Telerik
*Please be aware that Fiddler Classic is not in active development and offers no commitments for releases, patches ot tech support. By using this product, you assume all associated risks. We recommend upgrading to Fiddler Everywhere. Do More with Fiddler EverywhereGo beyond Fiddler Classic and try Fiddler Everywhere for free. Explore our easy-to-use and modern web debugging solution for Windows, M
ブランチメンテナンスの戦略 - 世界線航跡蔵
Ruby 1.9.1のメンテナンスを引き受けた当初、メンテナンスの指針として参考にできるものは多くはなかった。Ruby 1.8系のやり方を参考にしたくて、いくつか卜部さんに教えを乞うたりもした。そんなこんなで、メンテナンスする中で分かってきたこともあるのでメモする。 目標 まず、リリースブランチをメンテナンスする目標は何であるかをはっきりさせよう。メンテナンスによってどういった価値を提供するかと言っても良い。 安定した仕様の安全に機能するソフトウェアをできるだけ長期間提供すること、これが目標である。永遠に提供できれば良いのだけれども、そうもいかない。利用者が少なくなったバージョンをメンテナンスしてもメリットは少ない。メンテナンスに割ける人手も限りがある。開発されているtrunkとメンテナンスされているブランチが離れるほどにパッチの適用は難しくなり、対処すべき問題を共有することも難しくなる。
若い時にプログラムを書こう、必ず人生の豊かさにつながる
システムインテグレータ最大手NTTデータを率いる山下社長は若い頃、汎用コンピュータ用のデータベース開発に取り組み、プログラムを自ら作っていた。その経験から山下氏は「人生のどこかで手を動かしてプログラムを作る仕事を経験した方が絶対に面白い。20代あるいは30代の前半くらいまでに真水の仕事をどれだけやったか、それがその後の人生の豊かさにつながる」と同社幹部としては異例の発言をする。（聞き手は谷島 宣之＝日経コンピュータ編集長、写真は小久保松直） 2009年度、100億円近い投資を計画していると聞く。狙いは何か。 100億円のうち、40億円くらいかけようと考えているのが、「倍速開発」という案件です。これが一番大きい投資になります。我が社としてぜひともやらないといけないのは、お客様のお気の召すまま、ご希望のオーダーメード・システムを、パッケージ・ソフトを使った場合と同じスピードで作って差し上げる、
進化を諦めた保守などありえない - GoTheDistance
山本さんが刺激的なエントリを書いていらした。 場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 安全策が後手後手を生む - 山本大＠クロノスの日記 場当たりなので手間はかからないけどコードが汚染される 挑戦的なので手間もお金もかかるけどコードが綺麗になる それ自体は｢よくある｣葛藤だと思います。 山本さんはよほどの差で無い限り後者を選ぶとおっしゃられており、僕は極めて英断だと思っています。そのような｢英断｣を支持してもらうためにはどうすべきか、という視点で続きを書いていきます。 コードが汚染されてしまうと、システムが技術的負債を抱えることにつながります。とても可視化しにくいコストなのですが、｢ちょっと何かを変更するだけ
安全策が後手後手を生む - レベルエンター山本大のブログ
場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 ここで場当たり対応を選んでしまうことは、 「現実をみた大人の意見」のように思えるかもしれないが、 僕からすると、大事の前の小事にこだわるという、本末転倒の考え方にしか見えない。 保守で、既存プログラムの修正をやろうという後輩から相談を受けた。 既存プログラムのSQLの一箇所が違うだけのメソッドを作る必要があるとのことだ。 メソッドをコピーして重複したコードを書くことに後輩は納得がいかず、うまい方法は無いものかと僕に相談をしてくれた。 僕は、このメソッドの引数を追加して条件分岐できるようにし、元のシグネチャオーバーロードとして別途定義する案を上げた。 後輩は、我が意を得た
有料で使えるsubversionのホスティングサービスを調べてみる - ちきんブレインLABO
ちょっと個人的にプライベートで使えるsvnが欲しくなったので、無料サービスを調べ回っていたのですが、いかんせん無料サービスとなると基本オープンソースという前提があるので、仕事で使うには少々まずいことになります。仕事のデータをダウンロードさせるわけにはいきませんので。とは言え、自宅サーバーでとなるとなかなか管理が面倒だし、サーバー常時起動していないといけないということで、使い勝手がよろしくない。そこで有料でもいいので、使える有料のsubversionのサービスを探して比較検討してみようかと思いました。 自分的に求めた条件は以下の通り。上から順番に優先事項・安いところ ※高くても月５００円くらいがいいなぁ。。。・仕事で使うのでバックアップの機能があること・容量が最低でも１Gくらいあるところ ※複数案件をまとめて処理するにはそれくらい必要です。・tracなどのブラウザベースの管理機能があること
個人用に無料で使えるSubversionホスティングサービス3つ - takayukisの日記
個人用に使える = 非公開で使えるサービスです。 Beanstalk (10MB) Unfuddle: Free Source Control, Bug and Issue Tracking (15MB) Assembla (200MB) 10MB・15MBと言っても、コミットを繰り返すとすぐに使い果たしてしまうので、お試し用と考えた方が良いかもしれません。その点ではAssemblaは太っ腹の200MBなので、容量的には安心です*1。 同様のサービスでは、Subversionの他にWikiやTracなどが利用できます。Beanstalkではそれらを持たない代わりにBasecamp, FogBugz, Lighthouseと統合する機能があるようです。 Subversionだけ使っている分には問題無いのですが、いずれもユーザーインターフェースは英語です。日本語で使えるサービスとしては、Bac
プロジェクトの見える化を促進！課題管理ならCubo(キューボ)
課題管理・プロジェクトの見える化を促進する、Cubo(キューボ)のご紹介。ASP/SaaSサービスもございます。プロジェクトのタスクや不具合などの管理に最適な「トラッキング・バージョン管理システム」です。 「トラッキング・バージョン管理システム」とは、プロジェクトで浮上する様々なタスク、あらゆるオフィスドキュメント、クレーム・不具合データを一括管理、作業の進捗をプロジェクトメンバーで情報共有し、簡単にトラッキング（追跡）できるプロジェクトの「見える化」を促進する業務管理システムです。 これまでの、膨大なデータ管理や複雑な共有フォルダ、共有ファイル(Excel等)、電子メールによる処理を Cubo(キューボ) に切り替えるだけで、情報の一元化と見える化が実現されます。 作業効率を飛躍的に高めることが出来ます。 また、ソフトウェア開発現場で実際に利用されプロフェッショナル使用に十分対
どこでもプロジェクト管理バックログ
チームの業務を見える化してタスク漏れやスケジュールの遅延を防ぐ Backlogはシンプルな操作性と親しみやすい見た目で、誰でも直感的に使えるプロジェクト管理・タスク管理ツールです。 ※1：2023年12月末時点。サービス継続率は各前月の有料契約総数に占める解約数を引いた割合 ※2：スマートキャンプ株式会社主催 BOXIL SaaS AWARD 2024 BOXIL SaaSセクション プロジェクト管理・工数管理部門で受賞 ／「BOXIL SaaS」上に投稿された口コミを対象に、「使いやすさ」においてプロジェクト管理・工数管理部門部門で最も高い平均点を獲得したサービスをスマートキャンプ株式会社が選出（対象期間：2022年7月1日～2023年6月30日） ※3：ITreview主催 Best Software in Japan 2024 TOP50入選 Backlogでプロジェクト・タスク管理
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
分散プロジェクトの誤謬 - steps to phantasien t(2008-02-26)
タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
フロントローディングについて雑記 - Milestones to EVERPEACE 〜alius via〜
最近、僕の読んでいるブログに 「ソフトウェア開発におけるフロントローディング」 という話がよく出てくる。 フロントローディングは製造業の言葉で、製造の段階で見つかるミスをできる限り少なくするために、できる限り設計段階で作りこんでおこうというもの。 ソフトウェア開発におけるフロントローディングとは？ということを議論される際には、いわゆる 「ものづくり」と「ソフトウェアづくり」の違い がよく議論される。この「作る」というところと「何を」をしぼって、 「もの」と「ソフトウェア」の違い いったい何を製造して、何を設計しているのか？という点 を中心に議論される。 この2点目についてu1rohさんは興味深い点を指摘されている。 まずソフトウェアでは製造（＝コンパイル）は完全に自動化されている。昨今はコンパイルにさほど時間がかかることも少ない。設計（＝ソースコード）に間違いがあればコンパイラが瞬時にエラ
L'eclat des jours(2008-01-15) メモ
_ メモ ふと気づいたが、ソフトウェア産業＝工業という見方はよく反論の対象となるわけだし、実感としてもそれ（反対意見）は正しそうに思うのだが、実はやはり、その見方が正しいと言えるのではないだろうか。 レベルの設定が間違っているということだ。 工業は最初から、今の工業になったわけではない。 歴史の教科書的には、家内制手工業が来て（江戸時代末期の織物産業）、工員大量導入時代（明治の冨山あたりの時代）が来て、ベルトコンベア時代のオートメーションが来る。 それでいくと、単に、家内制手工業から工員大量導入時代のあたりにいる、というのを、ベルトコンベアと比較するからつじつまが合わない、ということではないか、ということ。 だから、専門的にもまだ近代の曙程度のレベルなんじゃないだろうか？ プログラマは設計をしているといっても、ベルトコンベアレベルに至っていなくて、せいぜい機織機を作っている程度に過ぎず従っ
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
つなぐ、つながる、そして未来へ Developers Summit 2009
http://suga.parfe.jp/td/index.cgi?date=20080520