タグ

ブックマーク / qiita.com/kawasima (13)

  • ID生成大全 - Qiita

    セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

    ID生成大全 - Qiita
  • チーム力向上のためのエトセトラ - Qiita

    この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと

    チーム力向上のためのエトセトラ - Qiita
  • システムエンジニアのエレベータの乗り方 - Qiita

    エレベータはシステムエンジニア思考を鍛えるよい乗り物です。 対象について注意深く観察し、エラーを起こさずスループットが最大化されるように設計・行動する力を付けましょう。 ボタンキャンセルの仕様を確認しておく メーカーによって異なります。 基的にはダブルクリックでキャンセル可能ですが、扉が開いてないと有効にならないものがあるので注意が必要です。 混雑したエレベータで1Fから最後らへんに乗り込み扉付近に立ったとき 高速にエレベータ運用するためには、ここのポジションは重要です。 まず何階のボタンが押されているか確認します。 エレベータが各階に止まったとき、それが… 1F出発時点で押されていない階の場合、降りる人はいないはずですので、乗ってくる人のためにエレベータの内部方向に詰めます。 1F出発時点で押されている階の場合、降りる人がいるので、一度エレベータを降りて、出入り口のスペースを作ります。

    システムエンジニアのエレベータの乗り方 - Qiita
  • マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita

    先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。

    マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
  • マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita

    マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ

    マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita
  • Excel方眼紙を支える技術2016 - Qiita

    POIを使ったExcel帳票の出力は、システムエンジニアにとっては日常茶飯事、おちゃのこサイサイであります。 takezoen先生による2015年版はこちらになります。 ここで紹介されている、S式からExcel方眼紙を出力するライブラリaxebomber-cljは、こちらをご覧ください。 特筆すべきはaxebomber-cljでは、Excelにありがちな文字切れが起こらないというところです。そもそもExcel方眼紙は、入力文字列が自動改行されない制約を設けて、利用者が意図的な位置で改行をコントロールするために発明されたフォーマットであります。しかし、その特異な見た目が災いし、単に敬遠される存在にとどまっております。axebomber-cljは、文字幅とセル幅を計算し、文字切れしない位置で自動的に改行するようにしています。これにより、Excel方眼紙の文字切れしにくさを活かしつつ、煩わしさを

    Excel方眼紙を支える技術2016 - Qiita
  • サーバサイドで複数Web APIを呼び出すときのデザインパターン - Qiita

    最近はエンタープライズのシステムでも、Web APIによるシステム間連携が増えてきました。そうしたときに、1リクエストで複数の連携先APIを実行し、結果をクライアントに返すということがままあります。 どう作りましょうか、という問題です。 前提として、サーバサイドでHTMLレンダリングせずに、Web APIの中継することとします。中継する意義は、流量やキャッシュをサーバサイドでコントロールできるところにあります。 クライアントから直接連携先のAPIにアクセスする設計にすると、リロードボタン連打などのDDoS攻撃うけたときに、自分たちでは対処できず、連携先に迷惑をかけてしまいますよね。特に「課金の関係などで直接APIをアクセスしなきゃいけないんだ」、とかでなければ、中継するように設計しておいた方がベターです。 Web APIの呼び出し 業務システムで使う場合は、ちゃんとリクエスト、レスポンスが

    サーバサイドで複数Web APIを呼び出すときのデザインパターン - Qiita
  • メールのトランザクション設計 - Qiita

    3日目で息切れしてきたので、今日は軽めな内容です。 データベース更新とメール送信の一貫性 商品購入の完了ページなど、よくデータベースを更新して、メールを送信してデータベースをコミットするという仕様があります。 データベース登録出来てないのに、完了メールを送るわけにはいかないので、これらを1トランザクションにできなきゃいけません。が、SMTPプロトコルにコミット/ロールバックの概念はありません。 さて、どう設計しましょうか、というお話です。 方式 A.DBトランザクション後にメールを送る 同一トランザクションはあきらめ、データベースを先にコミットし、その後でメールを送る、という設計です。 メール送信でエラーになったら、データベースには書き込めているので、メールだけ再送するように仕組みを作ったりします。 以下のようなイメージです。 public class OrderController {

    メールのトランザクション設計 - Qiita
  • 多い日も安心設計 - Qiita

    アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ

    多い日も安心設計 - Qiita
  • RubyistのためのClojure入門 - Qiita

    PuppetがRubyからClojureへ乗り換えていくようです。 そんなRubyistが他にもいるかもしれないので、Rubyist向けにClojureだとどう書くか、みたいなガイドを書いてみます。 イディオム jnchitoさんのRubyイディオム記事をClojureで書くとどうなるか、まず説明したいと思います。 後置if で行数を減らす

    RubyistのためのClojure入門 - Qiita
  • jagridを支える技術 - Qiita

    個人的にはaxebomber-cljのサブプロジェクトのつもりで作ったjagridですが、全国のExcelホウガンサーに喜んでいただけたようで、作ったかいがありました。 基的には、position: absoluteで、絶対座標をmargin-top / margin-leftに変換するだけなのですが、細かいところで工夫してありますので、多少解説しておきます。 garden rubyにおけるSCSSと同じ問題領域に、clojureではgardenがあります。 スタイルシートをS式で書けるスグレモノですが、現段階では引数をとる擬似クラスや子セレクタ(>)に対応する機能は無く、ちょっと物足りない感はあります。しかし、CSSをS式で書ける喜びは何物にも代えがたいですね。 [:.jagrid {:border-width (px 0) :line-height (px cell-size) :p

    jagridを支える技術 - Qiita
  • Incanterで3D円グラフを描く & マルチメソッドの拡張 - Qiita

    3D円グラフは、使うと死が待っています。 その錯視が、どんなものか分からないと殺せるものも殺せないので、3D円グラフを描いてみることにします。 IncanterはClojureの統計解析ライブラリですが、肝心の3D円グラフは描けません。 ですが、中で使われているJFreeChartは、3D円グラフReadyです。(サイトのロゴが3D円グラフなのは皮肉なものです) これを拡張します。通常の円グラフは以下のように書けます。

    Incanterで3D円グラフを描く & マルチメソッドの拡張 - Qiita
  • パスワード問合せシステムを作る (clojureのreducers) - Qiita

    現在のパスワードを教えてくれるからといって、「平文で保存してる!くぁwせdrftgyふじこlp‎」と脊髄反射してはいけません。 JALの6桁数字パスワードがどう格納されているか? 古いシステムなのでMD5でハッシュ化していると想定しますが、もちろんsaltは付けているでしょう。 さて、そんなパスワード保管方式で、現在のパスワード問合せに応答するシステムを作ってみます。 パスワードを「567890」、saltを「hoge」として、データベースには"hoge$567890"のMD5値"4b364677946ccf79f841114e73ccaf4f"が格納されているとします。 総当りしてみましょう。 (ns six-length.core (:require [clojure.core.reducers :as r]) (:import [java.security MessageDigest

    パスワード問合せシステムを作る (clojureのreducers) - Qiita
  • 1