最近、一意な識別子について検討することがあったのでその検討メモ。 一意な識別子とは つまり、重複しない、ユニークな識別子（Identifier, 以下id）のこと。ここではRDBのテーブルにおける主キーとして使うことを想定かつ前提としている。したがって、主キーの要件であるユニーク性を持ったidをどうやって生成していくか。 そんなのDBの連番でいいじゃんて話もあるがここではその話はせず、あくまでも一意な識別子をどう生成するかの話に絞る。 選択肢 一番有名だと思われるUUIDを筆頭にいくつかの選択肢がある。 UUID ULID CUID Nano ID 他にもTwitter発のSnowflakeとか今はDeprecatedになってるshortidなどがあるが、キリがないのでここでは上記の4種類だけで簡単に比較した。また、実際にはUUIDはバージョンによってSpecが異なるがここではバージョン4
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
2018/3/18 追記 TISさんのreactive system meetupで発表する機会をいただきました。ありがとうございます。発表資料をリンクしておきます。 Distributed ID generator in ChatWork from TanUkkii 18桁になったメッセージID ２０１７年５月２８日をもってチャットワークのメッセージIDは１０桁から１８桁になりました。みなさんお気づきでしたか？ これはメッセージリンクを取得してみることで確認できます。 それまでは32bitでかつ連番のIDでした。今は64bitになり、また単調増加性だけを保証し、連番ではなくなっています。 この記事では新メッセージIDとそれを発行するシステムについて記述します。 枯渇しそうだったメッセージID チャットワークのメッセージ数は２０１７年３月時点で１８億を突破しました。 lp.chatwork
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
きっかけ 友「IDの採番にMySQLのAUTO INCREMENT使ってるけど、インサートしないとIDが作れないから面倒。」 友「UUID v1で採番するのってありだと思うんだけどどうだろう」 俺「けどUUIDってシーケンシャルじゃないからMySQLに格納するなら相性悪いで1」 友「UUID v1ってタイムスタンプとMACアドレスから生成するからシーケンシャルだと思うけど」 俺「え、そうなん？」 というわけで調べたらシーケンシャルじゃなかったんだけど、せっかく調べたのでUUID v1なIDの作り方をまとめる。 UUIDとは？ UUIDはこんなID で、形式はこれなんだけど生成方法が5種類あって、よく使われるのはversion1と4。RFC4122で規定されている。このエントリではv1の方の作り方をまとめる2。 生成アルゴリズム UUIDのフォーマットは4つハイフンで区切られた5つのセクショ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? スマホのアプリを開発する上で端末を識別するのに何が使用できるのか調べたのでまとめておきます。 各識別子 Android/iOS共通 ・MACアドレス ネットワーク機器に一意に割り当てられるアドレス。 通常変更はできないが、脱獄などしている場合はできる模様。 ネットワークアダプタが搭載されてない場合や無効になっている場合は取得できない。 ・IMEI(International Mobile Equioment Identity、国際移動体装置識別番号) 携帯電話など通信端末に付与される番号。15桁の数字。 通常変更はできるものではないが、
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
「findViewById」にイラつくことがなくなりそうなプラグイン「Android Layout ID Converter」 Androidデベロッパーのみなさん、「findViewById」にイラっとくることありませんか？ そんなイライラをライブラリなしですっきり解決する Android Studio プラグイン「Android Layout ID Converter」のご紹介をします。 プラグイン導入 なにはともあれ、プラグインをインストールしましょう。 Preferences... > Plugins > Browse Repositories... とたどっていき検索するとプラグインが表示されるので、[install plugin]ボタンを押します。 いつも通り Android Studio を再起動しろと言われて「は？」っと思いながらも再起動するとプラグインが有効化されます。
Note: The content of this post no longer represents current Android best-practice. Learn about the latest best practices for unique identifiers here. [The contents of this post grew out of an internal discussion featuring many of the usual suspects who’ve been authors in this space. — Tim Bray] In the Android group, from time to time we hear complaints from developers about problems they’re having
クレジットカード会社からの電話で発覚した「不正な取引」 2013年1月27日(日)、まったりと自宅で休日を過ごしていた時のこと。突然携帯電話が鳴る。見たことがない電話番号だったので、いったん電話を取らずスルー。5分後、再び同じ番号から電話がかかってきたので、電話を取ってみた。 「こちらは○○カードのセキュリティセンターですが、お客様のクレジットカードで最近のご利用についてお伺いしたいのですが、最近AppleのApp Storeでのご利用はありましたか？」 何のことかと思えばそういうことか。App Storeで結構利用もしてるし、電話のあった前日も利用したばかりだったので「あーはいはい」という感じで答えていたら、どうにも様子がおかしい。 App Storeでの利用があまりに短期間で連続しているので、カード会社の警報システム（そんなのがあるんですね）が作動したので、念のために連絡した、というこ
8. ツイートID生成システムSnowflakeとは l ユニークなIDを生成するネットワークサービス l ツイッターのツイートID(ステータスID)の割り当てに使われている l ツイッター社がOSSで公開中 (*) l 特徴 l 64 bitのIDを生成 l ざっくり時刻順 l 速い l 10000 ID/秒 のスピードでIDを生成できる(1プロセスあたり) l レスポンス 2 ms (+ネットワークのレイテンシ) l スケールする l 複数のマシン・プロセスで協調動作しない l 並べただけスケールする(はず) (*) https://github.com/twitter/snowflake 8 9. Snowflakeが開発されるまで l ツイートの流速増加とツイッターのシステム移行 l 5億ツイート/日(約6000ツイート/秒) (*1) l 2012年1
前回はUDIDに起因するセキュリティの問題について紹介しました。今回は引き続き、UDIDに起因するプライバシーの問題、特に名寄せの問題について述べていきます。 前回は、UDIDに起因するセキュリティの問題について紹介しました。今回は引き続きUDIDに起因するプライバシーの問題について述べていきます。 「プライバシー？ 関係ない」とはいえない時代 学生時代にSNSにアップロードした写真が元で就職活動の際に不利な状況になってしまったり、知人しか見ないと思っていたつぶやきが実はWeb全体に公開されていたために自分の生活パターンなどが公にされてしまうなど、SNSに関係するプライバシー侵害事例が増加しています。 一方で、ビッグデータやライフログなどと呼ばれる技術も発展しています。1つ1つには大した価値がないデータでも、それらを大量に集め、こうした技術を用いて解析した結果、個人の趣向などを詳細に知るこ
ご利用サービスのログイン方式は旧方式のためログインできません。 ご利用サービスのシステム管理者にお問い合わせください。 ※旧方式（OpenID 2.0方式）は2021年5月31日をもちまして終了しております。
本来先月末までだったはずのPush通知を使ったAndroidプロトタイプアプリ開発は、一昨日ようやく検収を完了することができました。C2DMは相変わらず意味不明な存在ですが、さっさとGoogle Labsから卒業してくれるのを待つほかないのかもしれません。 まぁ今回は別の話題。上記のアプリはAndroid OS 2.2(SHARP IS03)が対象なんですが、試しにモトローラ社のXOOMというタブレット端末(OS 3.0)で動かしてみようとしたら端末固有IDが取得できないんですわ。よくよく調べてみたら今回のプロトタイプでは以下のように取得してたんですけど、これじゃ電話番号と紐付いてない筐体の端末固有IDは取れないようになってるみたいです。 // 端末管理クラスの起動 TelephonyManager mng = (TelephonyManager)getSystemService(Cont
連番になっているリソースファイルをいちいちソースコードに書いていくのは邪魔くさい。て、人にオススメな方法。 genディレクトリ下にあるR.javaファイルを直読みさせればおｋ 方法 R.javaファイルのパスを指定し、読み込みたいリソースファイルのある内部クラス*1を指定するとResouresIDが取得できます。 getResources().getIdentifier("リソースファイル名", "Rファイルでのクラス名", "Rファイルのパス名"); 例 ここでは upload_0, upload_1, ... などの画像ファイルをforで回して取得する事を想定してます。 getResources().getIdentifier("upload_" + i, "drawable", "jp.ne.hyoromo.android.switchwallpaper"); *1:resource
Android AppWidget の PendingIntent で putExtra するときの注意
AppWidget 上のボタンをタップしたときに編集画面を開いたりする場合、RemoteViews を使った次のようなコードがよく紹介されています。 RemoteViews remoteView = new RemoteViews(context.getPackageName(), R.layout.appwidget); Intent intent = new Intent(context, WidgetConfigure.class); PendingIntent pendingIntent = PendingIntent.getActivity(context, 0, intent, 0); // or // PendingIntent pendingIntent = PendingIntent.getService(context, 0, intent, 0); // or //
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 携帯電話に搭載されている固有IDが波紋を呼んでいる。 問題の発端は、NTTドコモが開発者向けに開示した情報だった。公開されたのは、同社のスマートフォン向けコンテンツ開発に関する情報で、ドコモがスマートフォンにプリインストールする「メディアプレイヤー」アプリが、動画を再生する際にIMEIと呼ばれる端末一意の固有IDを送信する、というものだった。 この記述自体はその後、マイクロソフトの「PlayReady」と呼ばれるDRMを使った動画の再生時に「ライセンスが確認できない場合」のみ送信され、1回ごとにユーザーに送信の可否を問うダイアログが出る仕組みであると説明が追記（修正）され、問題自体は終息している。 しかし、これをきっかけに、スマートフォ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
