エスイーが要件定義でやるべきたったひとつのこと(実践編) - Qiita
元海岸沿い現西新宿SIerのまつい師匠(@nmatsui)の「良いコードとは」というスライド、お読みになられたでしょうか。まだの方は是非！ http://www.slideshare.net/nbykmatsui/ss-55961899 さて、そのスライド中で出てくる「ロジックをシンプルに保つ」という話、以前まついさんと社内SNSでディスカッションしたことがある内容で、その結果をまとめておいたのが、以下になります。 http://www.slideshare.net/kawasima/ss-26968240 デシジョンテーブルを簡略化すると、プログラムの複雑度を減らすことができ、なにより仕様が単なる記号でなくて、顧客の要求が浮き出てきて理解しやすくなるよ、というものです。 ただ、この中では非常に単純な例しか挙げていないので、もう少し実践的な仕様で、ご説明したいと思います。 出力が多値のデシ
テスト計画の立て方 - Qiita
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
究極のファイルダウンロード - Qiita
アップロードと比較するとタイトルは釣り気味なのですが、ダウンロードにまつわるパターンをまとめます。 ふつうのダウンロード アップロードほど考えなきゃいけないことは多くないですが、ハマりポイントはいくつかあります。 ファイル名 何も対策せず日本語をファイル名にすると、当然のように化けます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
