システムエンジニアのエレベータの乗り方 - Qiita
エレベータはシステムエンジニア思考を鍛えるよい乗り物です。 対象について注意深く観察し、エラーを起こさずスループットが最大化されるように設計・行動する力を付けましょう。 ボタンキャンセルの仕様を確認しておく メーカーによって異なります。 基本的にはダブルクリックでキャンセル可能ですが、扉が開いてないと有効にならないものがあるので注意が必要です。 混雑したエレベータで1Fから最後らへんに乗り込み扉付近に立ったとき 高速にエレベータ運用するためには、ここのポジションは重要です。 まず何階のボタンが押されているか確認します。 エレベータが各階に止まったとき、それが… 1F出発時点で押されていない階の場合、降りる人はいないはずですので、乗ってくる人のためにエレベータの内部方向に詰めます。 1F出発時点で押されている階の場合、降りる人がいるので、一度エレベータを降りて、出入り口のスペースを作ります。
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
業務を加速させるバーチャルキーパッド - Qiita
業務システムでは、入力の速さを求められます。一方で、本当かどうか分かりませんが、「システム利用者はリテラシーが低いこと」を前提に機能要求が積み上がることが多いです。 そんなIMEの辞書のカスタマイズによる入力速度の向上など期待しない中で、入力を速く行えるようにするには…と考えると、フォームごとに専用のキーパッドを用意するとよい場合があります。 また、タブレットで業務システムを使うケースも増えてきました。その入力のしにくさを考えると、やはり専用のキーパッドを用意するとよい場合があります。 keypad 色々、選択肢はあるのですが、カスタマイズしやすいものとなるとあまり見当たりません。jQuery keypadは割と老舗でカスタマイズに関してももよく考えられています。 http://keith-wood.name/keypad.html このjQuery keypadをベースに、キーパッドを設
[システム間連携]接続方向を逆転させるとうまくいく - Qiita
システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。 主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。 システム間の接続 非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。 だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、
![[システム間連携]接続方向を逆転させるとうまくいく - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9e6b26bad6ab3b6b40219c713c4e519da8866144/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgyJUI3JUUzJTgyJUI5JUUzJTgzJTg2JUUzJTgzJUEwJUU5JTk2JTkzJUU5JTgwJUEzJUU2JTkwJUJBJTVEJUU2JThFJUE1JUU3JUI2JTlBJUU2JTk2JUI5JUU1JTkwJTkxJUUzJTgyJTkyJUU5JTgwJTg2JUU4JUJCJUEyJUUzJTgxJTk1JUUzJTgxJTlCJUUzJTgyJThCJUUzJTgxJUE4JUUzJTgxJTg2JUUzJTgxJUJFJUUzJTgxJThGJUUzJTgxJTg0JUUzJTgxJThGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz02OWE5YmIzM2YxNTIyZTQ3YmNiYTczN2E1NmZlZTlhMQ%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBrYXdhc2ltYSZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODAyNDk1Y2IwNTFhMTYzMTFhM2NkYWE5OWU2NmJlYzQ%26blend-x%3D120%26blend-y%3D500%26blend-mode%3Dnormal%26s%3D8943a150f1c778f23b4d782e0d1d1e40)
至高のファイルアップロード - Qiita
システムエンジニアにとって頻出機能のひとつで、要件がモリッとしがちなファイルアップロードについてです。アップロードファイルもただの画像やPDFではなく、ExcelやCSVファイルをアップロードして、中身を読み取ってデータベースに格納する、あれを対象とします。 標準的なファイルアップロードでの設計ポイント ファイルのアップロード機能を実装しようとなると、以下のような点の設計を考える必要があります。 同期? 非同期? タイムアウトのリスクがあれば、非同期にする ブラウザのタイムアウト 通信経路(プロキシやファイヤウォール)でのタイムアウト Webサーバのタイムアウト ユーザがレスポンス返ってこないので、処理を中止するリスク 非同期の場合の実行方式 Webサーバ内でスレッドを新規に作る or 別プロセスへ処理をディスパッチする 流量制御のためリクエストをキューイングする Progress 長時間
サーバサイドで複数Web APIを呼び出すときのデザインパターン - Qiita
最近はエンタープライズのシステムでも、Web APIによるシステム間連携が増えてきました。そうしたときに、1リクエストで複数の連携先APIを実行し、結果をクライアントに返すということがままあります。 どう作りましょうか、という問題です。 前提として、サーバサイドでHTMLレンダリングせずに、Web APIの中継することとします。中継する意義は、流量やキャッシュをサーバサイドでコントロールできるところにあります。 クライアントから直接連携先のAPIにアクセスする設計にすると、リロードボタン連打などのDDoS攻撃うけたときに、自分たちでは対処できず、連携先に迷惑をかけてしまいますよね。特に「課金の関係などで直接APIをアクセスしなきゃいけないんだ」、とかでなければ、中継するように設計しておいた方がベターです。 Web APIの呼び出し 業務システムで使う場合は、ちゃんとリクエスト、レスポンスが
セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita
最近はハンドリングしくてもいいや的な、入力改ざんで発生するバリデーションエラーをそのまま500のHTTPステータスで返すと、攻撃者が「なんか攻撃成功しちゃいそう」って思っちゃうとかなんとかで、監査的なところから「500はやめろ」って言われることがあります。 一理ある ということで、安易に500を返さない方法を考えてみます。 HTTPステータスコードにあまり馴染みのない方は、こちら…ではなく、こちらをまず読んでください。 HTTPステータスコードの使い分け基礎 400 まず、ユーザの入力値、データの状態によってエラーになるケースは 400 Bad Request とします。エラーメッセージを表示して再入力を促すHTMLページを返す、一般的な入力エラー系の遷移は200 OKを返しても、実用上問題はないかと思います。 ユーザの操作が原因で、サーバ処理がエラーになった場合も400で扱うのはおかしい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
