  |
はてなキーワード:Snowflakeとは
会社が倒産する主な原因だと分かり切っているRuby on Railsは決して開発で使用してはいけないと言う重要な話をしようと思います。
Railsは、メリットは、開発スピードは速く、開発していて楽しいが、
デメリットの方が遥かに大きく、ソースコードの分析は開発者本人にしか分からないので、
チームでの共同開発やメンテナンスに向かない、他人がソースを分析出来ないのでメンテナンス不能。
ですから、もし、Railsで企業の重要なシステムを動かしている場合は、メンテナンスや改善の必要が出た場合には、システムの設計書を元に、無ければ担当部署やお客様にヒアリングして調査して回って、必要なら最新、最先端の技術書や医学書などを調査したり専門家に意見を聞いたりなどをして、新たに、設計書を作り、PythonのFastAPIで開発しなおす需要と言うかニーズはかなり増加しております。
PythonのFastAPIは、Go言語のGinフレームワークと同等の高速性が御座います。しかも、Snowflakeと互換性があり相性が良いです。しかしシングルスレッドのマルチプロセスでしか動作しないと言うデメリットもあるので、将来のPythoのバージョンアップで、Ｖ言語の高速性をベースに中身とバックグラウンドはＶ言語で、見た目と構文はPython、セキュリティの脆弱性問題は発生しないと言うRustの様な仕様でトライブリッドの様なハイブリッドな仕様とするのが一番良いでしょう！
Python/Djangoも、PHP/Laravelも、Ruby on Railsも低速なので、世界中から大量アクセスの大規模なシステムには向かないと言うデメリットが大きいので、今から開発するなら、PythonのFastAPIが御勧めで御座います。
たとえば ↓
https://www.launchexcel.com/what-jobs-use-excel/
https://www.fdmgroup.com/news-insights/advanced-excel-skills
ジャップランドで起こりがちなことはアメリカでは無いのかAIちゃんに尋ねてみたらこう言ってたよ
ワイ： 質問:2024年において、アメリカの大企業および中小企業の間で、より一般的なデータ管理の方法はなんですか？検索して最新のトレンドを教えてください。 -方法A:内部データベースからCSVファイルとしてデータをダウンロードし、Excelで修正してから、
ETLツール（例：InformaticaPowerCenter、TalendOpenStudio）、BIツール（例：Tableau Prep、MicrosoftPower Query）、
または他のデータベース（例：OracleDB）などの他のシステムにインポートする。 -方法B:Excelのステップをスキップし、内部データベースを他のシステムに直接接続する。 -方法C:レガシーシステムや複雑なシステムには方法Aを使用し、その他のシステムには方法Bを使用する。状況やシステム要件に応じて使い分ける。 質問のポイント:-大企業におけるExcelの使用:大企業はデータクリーニングのためにExcelを使用するのを完全にやめましたか？それとも、古いメインフレームシステム、ERPシステム、または特定の業務プロセスの問題のためにまだ使用されていますか？ -方法A、B、Cのシナリオ:各方法の具体的なシナリオと製品名を教えてください。 -2024年におけるCSVファイルのダウンロード:2024年現在、ETL/BIツールやクラウドベースのDWHを利用できないどころか、OracleGatewayなどの接続手段も利用できないデータベースの使用は完全になくなりましたか？
もしそのようなデータベースが2024年にもまだ存在する場合、直接的なデータ連携が困難なため、CSVファイルでのデータ抽出が唯一の方法となることがあります。
企業は膨大なコストがかかるために移行を延期していますか？それともすでに段階的に対応していますか？ -Excelを使い続ける理由: 内部データベースを他のシステムに直接接続した方がシンプルなのに、なぜ一部の企業はデータクリーニングのためにExcelを使い続けているのですか？
↓
2024年には、大企業の間でメソッドB（直接接続）へのシフトが顕著になっています。しかし、特定のシナリオに応じてメソッドC（ハイブリッドアプローチ）も採用されています。中小企業においても、直接接続の利便性と効率性が認識され、その採用が徐々に増加しています。しかし、リソースとコストの制約により、Excelを使用したデータクリーニングやハイブリッドアプローチが依然として一般的です。
使用状況: この方法は、中小企業、レガシーシステム、複雑なデータ構造を含むシナリオで依然として一般的です。Excelはその柔軟性と使いやすさから、データ操作のための多用途ツールとして広く使用されています。
シナリオ:
製品:
具体的なシナリオ:
使用状況: この方法は、大企業や技術に精通した中小企業の間でますます一般的になっています。直接接続を利用することで、データワークフローが効率化され、手動エラーが減少します。
シナリオ:
製品:
具体的なシナリオ:
使用状況: 多くの企業が、レガシーシステムや複雑なシステムにはメソッドAを、その他のシステムにはメソッドBを使用するハイブリッドアプローチを採用しています。この柔軟性により、既存の制約と近代化の努力をバランスさせることができます。
シナリオ:
製品:
具体的なシナリオ:
データ管理ツールの進歩にもかかわらず、Excelは大企業におけるデータクリーニングと操作のために広く使用されています。これは主に以下の理由によります：
ETL/BIツールやクラウドベースのDWHと直接統合できないシステムに対して、データをCSVファイルとしてダウンロードすることは依然として一般的です。企業は高コストと複雑さのために移行を遅らせることが多く、段階的に対処しています。
しかし、直接接続はより効率的で広く採用されており、長期的にはデータ管理におけるExcelへの依存が減少すると予想されます。
クラウドベースのデータ統合ソリューションの台頭により、データ収集、クリーニング、統合がAI/ML技術によって自動化され、手動作業が減少し、データの一貫性と精度が向上しています。AI/MLアルゴリズムは、異常検出、欠損値の補完、パターン認識などのタスクを効率的に処理し、データ品質を向上させます。リアルタイムデータ分析の利点が明らかになるにつれ、直接接続の採用が増加し、より迅速かつ正確なビジネス意思決定が可能になります。
データセキュリティ、コンプライアンス、およびデータガバナンスの重要性が増すにつれ、このトレンドは続くと予想されます。
#ヨーロッパの主要都市におけるソフトウェアエンジニア向けベストカンパニー
ヨーロッパの各都市でソフトウェアエンジニアにとって最適な企業を探しているなら、以下のリストが参考になるでしょう。
Google,Facebook,Snap,NVIDIA,Microsoft,Apple,Oracle, Snyk, GetYourGuide,UBS, Swisscom, DFINITY,Cisco.
Google,Facebook,Snap,Jane Street, Stripe, Coinbase,Apple,Amazon,HudsonRiver Trading, Citadel, ByteDance,TwoSigma, Palantir,Bloomberg, Revolut, GSA Capital, Marshall Wace, Quadrature,FiveRings, G-Research, Starling, Personio,DeepMind, DRW, Millenium, BlackRock,MANGroup,Jump Trading, DE Shaw, AQR,Maven Securities, Point72, IMC, Optiver, Susquehanna (SIG), XTX, OldMission, Squarepoint, Qube Research & Technologies (QRT),Yelp.
Uber, Databricks, Bitvavo, Booking,Miro, Flexport, Atlassian,Spotify, Optiver, IMC,Amazon, Adyen,Google, Stripe,Flow Traders, MessageBird,Reddit,Box,JetBrains, Personio, Elastic,GitHub, Catawiki,Tower Research,Radix Trading, Headlands Technologies, Tomtom.
Google, Meta,Datadog, Criteo,Microsoft, Stripe,Airbnb,Amazon, Atlassian, Hubspot, Workday, Ankorstore,Red Hat, Algolia,Alan, 360Learning, ContentSquare.
AWS,Amazon,Microsoft, Wayfair,Google, Meta,Apple, HubSpot, Stripe,NVIDIA,Snowflake, Personio, Databricks,JetBrains.
AWS,Microsoft,Google,Mastercard, Workday,Salesforce, Meta, Stripe,VMware,LinkedIn,Etsy, Personio, ByteDance, Coinbase, Hubspot.
Google,Apple,Microsoft,Nvidia,Adobe, Workday, Celonis,BMW,Salesforce, SIXT,SAP,Huawei, Personio,Intel,JetBrains,IBM.
Google,Snowflake,Netflix,Pinterest, Rippling,Oracle, Waymo,AMD,Samsung,NVIDIA,Box, Warner Bros,Visa,Amazon.
Amazon,Apple, New Relic, Stripe, Rippling, Revolut, Skyscanner,Microsoft, N26, Criteo,Adobe,Thoughtworks,Oracle, Glovo, Personio.
Apple,Amazon, Roku,Arm,Microsoft,Qualcomm,MathWorks,AMD.
Amazon,Oracle,Microsoft,Flutter,Unity, Skyscanner,Huawei.
Databricks,Microsoft, Nutanix, Rivian,Foursquare,Yandex,JetBrains, Nordeus, Luxoft.
Amazon,Datadog,Microsoft,Apple,Google, Personio,Twilio, Glovo,VMware, Meta,Oracle, Revolut.
Klarna,Spotify, Netlight,PayPal, Ericsson,Ubisoft, Warner Bros,King,Google,Oracle,AWS,Microsoft, Wolt.
Google, Rippling,Oracle, Revolut,Uber,Amazon, Deliveroo,IBM,Splunk.
Crowdstrike,UIPath,Google,Adobe, Stripe,Microsoft,Oracle,IBM,Amazon,Electronic Arts (EA).
Microsoft,Maersk, Zendesk, Workday,Unity.
Productboard,Pure Storage,Apple, Workday,Oracle,Microsoft,JetBrains, Proton, Parrot.
Bolt,Wise,Microsoft,Twilio, Wolt.
Microsoft,Cisco, Aker Solutions,Arm,Mastercard, Meta, Kahoot, Autostore, Remarkable, Netlight.
これらの都市は、ソフトウェアエンジニアにとって多くの機会を提供しています。それぞれの都市が提供する企業は、エンジニアが自身のキャリアを発展させるための多くの選択肢を提供しています。それぞれの企業が提供する機会や文化は、エンジニアが自身のキャリア目標に合わせて最適な選択をするのに役立ちます。 [
はてなの皆さん、増田の皆さんたくさんの反応ありがとうございます。
どうしたもんかと悩んでる状況の中で、エージェントの人に話してもあまりピンと来ない反応が返ってくるし、周りに相談出来る人もいないしで、かなり勇気づけられました。
とりあえず今時点で返せる分だけお返事返しておこうと思う。
恥ずかしながらこんなサービスがあるのを知りませんでした。
今の状況では1000時間学習してから転職ってのは難しいんだけど、転職活動終えたら利用してみたいなという気持ち。
開発に夢見すぎ
自己評価低い
その通り、かもしれない。
技術記事とか書いてアウトプットしてる同世代以下の優秀な技術者たち見てて、自分とのスキルギャップに絶望してたところだったんだ。
5年弱ぐらいローコードじゃなくて、コーディングで実務経験積めてたらなあって。
後悔してもどうしようもないのは分かってるんだけども。
私のキャリアについて言葉を選ばず相談するので、言葉を選ばずレスポンスしてもらいたい。
鞭歓迎。
ありがとうございます。登録させてもらいました。
弊社来ない?
すごくめちゃくちゃたいへんありがたいお誘いなんですが、
増田に相談してそれで就職してっていうのがとんでもなく恥ずかしい。
でも、本当にありがとうございます。
あと色々突込み入ってた「作りたいWebサービス」については実際にdjnango使って手を付けてる段階です。
何てことない内容なので、確かにこれを作るためにわざわざ転職する必要はなさそうだ...。
・30歳
・単身
ETLツール(ローコードの開発ツール)を使ってデータ連携基盤を作成するための開発エンジニアとしていくつかプロジェクトに参加してきた。
年収400~500ぐらい。
平均的な残業時間は30hぐらい？少人数で本番稼働と運用保守のトラブル対応してた時は100時間は優に超えてたぐらい。
・特定のETLツールについての知識(前社の人員の中では最も実装/設計/開発の能力があった。と思う。)
・DBの浅～～～い知識(基本的なDDL,DML,DCLなら全て書ける程度。チューニングとかはやったことないので分からない。)
・BashやらPowerShellやらの浅～～～～い知識(プロジェクトで簡単なスクリプトを作成した経験があってその時に色々調べた程度。)
・開発チームのリーダーをやっていたのでそのあたりのマネジメント経験(PM/PLは未経験)
・Pythonとそのフレームワークの入門書籍一冊分ぐらいの知識
・Linuxの入門書籍一冊分ぐらいの知識(資格取得に向けて勉強中)
・作りたいWebサービスがあるので、プライベートでそれ作りたい
基本的なプログラミングの部分を全く業務で触ることなく仕事してきた。
前職を辞めて、出来上がったのはローコードの開発ツールの経験しか持っていない、市場価値のない化け物だった。
でも、前職みたいなローコードツールを使った開発から離れたいのよ。つまらないし、同じことの繰り返しだし、地味だし。
技術的に未熟な部分が多すぎて一足飛びに理想の企業に勤めるのが無理なのは分かってる。
とはいえ、年齢的にももうデッドラインが近いんじゃないかと焦ってる状態。
色々エージェント登録して求人見ながら自分でも出来そうな社内SEのポジションに3つほど応募した。(結果はまだ)
前職の経験踏まえたコンサルのオファーが来るが、給料は魅力的なものの「開発とか技術とかからは遠のいちゃうんじゃないか」って足踏みしてる。
SESと前職に似た開発,PM/PLポジションのオファーもたくさん来る。
化け物が「いつかこんな風になりたい」を実現するためには実務経験のためにSESで基礎から3年ほど実務経験を積んでからって思ってるんだけど悠長すぎる？
諦めて別の道、もしくは元の経験を活かせる道を探したほうが良い？
特定避けるために端折っている部分も多いけど、不足していて伝えたほうが良さそうな情報がありそうだったらあとで追記する。
Permalink |記事への反応(19) | 14:03
男はちっちゃい頃から老人に至るまで鈍感になる訓練を積んできてるから、その成果が出てるんだわ。
上半身裸になっても恥ずかしがるもんじゃないし、ちょっとやそっと怪我しても大騒ぎするもんじゃないし、仕切りのない小便器で隣にちんちん見られながらおしっこしても平気であるべきだし、男は一人で行動しても怯える必要はないし、肉体労働をするべきだし、危険な職業になるべきだし、他人に警戒されてもしかたないし、同情は買いづらいし、などの扱いによって鈍感になる訓練を積んでいる。
「リベラル」とか「フェミニスト」とかの人らはこれを悪しき性役割だの抑圧だのと批判するけど、それは繊細さん（海外風に言えばFragileなSnowFlake、雪の結晶のように脆い精神）を増やして不幸をもたらす考え方だ。
男だけが粗末な扱いをされるのは、確かに男性差別だ。だが、鈍感さ・タフさを身に着ける良い訓練でもある。
だから、女も幼少時からある程度粗末に扱うことで差別ではなくし、かつ女も鈍感力を鍛えるべきなんだよね。
これに「はあ？」って言いたくなる人もいるだろうが、女にも鈍感さが必要な好例として、先月話題になった女湯窃盗のニュースがある。
https://www.fnn.jp/articles/-/437217
https://b.hatena.ne.jp/entry/s/mainichi.jp/articles/20221110/k00/00m/040/171000c
男湯の脱衣場は七割に監視カメラがあるが、女湯は監視カメラがつけられないので、窃盗のターゲットになるって話。
でも幼少期からの鈍感訓練のおかげで我慢できる。そして窃盗被害にあうよりは脱衣場に監視カメラがある方がずっといい。
俺は強さや男らしさから落ちこぼれた人間だが、それでも多少のタフさが身についていることについてはプラス評価せざるを得ない。
しかし、今のヘンテコな正しさは、まるで弱いことが良いことかのように扱って、弱さや繊細さからくる問題は見ないふりだ。
「男性が受ける差別とは、警戒されることと、信頼という名目で粗末に扱われることです」のブコメ（https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20220908185524）も、男性差別にならないように男を粗末に扱うのはやめようってのが当然のように並んでる。
なんでだよ。性差別をなくすんだったら、男だけじゃなく女も雑に扱うことで、タフさや鈍感さを身に着けましょう、共感性は弱めましょう、って考えた方がいいだろ。
鈍感訓練がいい効果を発揮する例は、他にも沢山ある。
キャンプなど野外レクリエーション経験のある奴ならよく知ってるだろうが、トイレの回転が速い（最悪トイレがなくてもいい）とか、川で転んで服が濡れた時に脱いで乾かしやすいとかも、男の鈍感訓練が成果を出してるところだよな。
それから、「男なら虫は平気で退治できるでしょというのは性差別です、男の子だって虫を怖がっていいんです」みたいなのがポリコレ的に正しいとされるけど、そんじゃあ現実問題として家や職場に発生した虫を誰が退治するんだって話だよ。
虫を怖がる弱さは尊重してあげましょうって社会だと、虫が出た時にたまたま平気な奴がいてくれる確率がどんどん下がってくぞ。
「男だけが虫は平気であるべきというのは性差別です、男も女も虫くらい潰せるべきと考えて、性別問わず虫が苦手な子供にも幼少期から慣れさせていきましょう」の方が適応力のある生きやすい人間が増えるだろうが。
殺虫剤屋さんにテクノロジーで頑張ってもらうからいいのか？ いつどこで虫が出ても大丈夫なようにスマホに殺虫機能でもつけてもらうか？
SDGsを気にすることが善だとしている一方で、虫を叩ける鈍感さを鍛えるのは悪だから資源を消費して殺虫剤を作るのが善だってのも、現代社会のおかしさだよなぁ。
もちろんこの虫退治の話は、3K仕事のストレスや傷を我慢してくれる鈍感でタフな奴らのおかげで社会は回ってるってことと繋げられる。
そして男オタクが検索避けを必要としないのも、鈍感訓練の成果だよ。
男は幼少期から鈍感訓練をしてるから、内向的で「男らしく」ないと揶揄されるオタク達ですら地雷を踏んでも我慢できるやつが多くて、検索避けだの村ルールだの注意書きだのは定着しない。
どうしてもムカついた時は、直接批判して叩き合う。
女ジャンルだと、マナー啓蒙だのルール決めだのを勝手にしようとする風紀委員みたいなツイートをした繊細さんに、なぜか「そうだそうだ」「知りませんでした気をつけます」みたいに賛同する人が多いが、男ジャンルに発生した繊細さんはたいてい変な奴扱いされて終わりよ。
（ただし、百合好き男オタクとか、女性上位好きのM男は、比較的繊細さんが多いので学級会になる率が少し高い。百合に男を出すな議論や、おねショタでショタに逆転させるな議論がそうである。
だがその繊細さんたちのジャンルでも、M男向け創作では「逆転なし」タグなどのという、魅力アピールになるポジティブ表記が使われつつあるのはなかなか効率的だと思う。
検索避けとか注意書きとか村ルールといったネガティブ表記は、こういうのを不快に思う人がいるから気遣いしましょうという空気やマナーで縛ることで不快を回避しようという対策だが、息苦しさが漂い、しかもそのルールについて無視or無知な人間がいると破綻する。
一方で「逆転なし」タグをつけるというのは、創作者のアピールポイントとしての積極的な情報発信により、消費者も積極的に検索できてお互いに快楽を追及できる前向きさがあり、かつ無知な人間がいても破綻しづらいよい方法だ。
もっとも、この手のタグが普及しすぎて20個も30個もつけたくなったらどうするんだという問題は、長すぎ注意書きと共通だが。
女ジャンルのpixiv小説で主に使われている「♡喘ぎ」タグも似た感じに評価しているが、こちらはまだ苦手を避けるための配慮という空気もそこそこ支配的なようでもあり、もっとアピールポイントとして自信を持ってもいいのにと思う……まあこれは余計なお世話か）
とにかく、男は鈍感になる訓練を幼少期から積んでるおかげで、耐えられる鈍感さが身につき、他者に感情移入しすぎる共感性は小さくなり、傷は増えるが気楽で自由だし、本人にとっても社会にとっても様々な利便性がある。
性ホルモンが違うから仕方ないって考え方は、このポストでは採用しない。採用していいんだったら、有害な男らしさも女らしさも有益な男らしさも女らしさも性ホルモンだから仕方ないで終わらせるけどな。
マジな話、女も男も同様に、鈍感になる訓練を幼少期から積んだ方がいい。
そうすれば男性差別じゃなくなるし、女は強さを手に入れられて女性差別も起きづらくなるし、女湯窃盗を減らすための監視カメラも設置できるし、トイレもさっさと終わるし、息苦しく迂遠な学級会も減ってわかりやすい叩き合いがメインになる。
女がタフで鈍感訓練をしないシワ寄せとして男が責任や孤独を負って死に追い込まれているわけで、女も鈍感になって一緒に負担を負えばきっと今より状況はマシになる。
結局この世界ってのは、現時点の文明レベルでは、不快な作品は作られるし、雨は降るし風は吹くし災害は起きるし、犯罪者は出るし、荷物は重いし、全ての人間の苦痛を無くすだけの資源はないし、人が死ぬことは防げないわけじゃん。
鈍感になる訓練は辛いからやめましょうと唱えたって、世界の過酷さをなくしたことにはならないんだわ。消火訓練を止めれば火事をなくしたことになるか、ならないだろ。
二十代や三十代になって、世界には消せない過酷さがあって繊細さが自分の足を引っ張ってると気づいても、育て直したり保護してくれる人は少ないんだよ。
理解のある彼くんとか、優しい家父長さんとかを見つけられて、かつそいつらに庇護される生き方をヨシとできるなら別だけどな。
そうじゃない俺ら（性別問わず）は、繊細でかわいこぶっても他人は愛してくれねえし守ってもくれねえんだから、せめて鈍感でタフでなきゃやってけねえよ。
100年前に比べれば解決された問題は色々あるが、それでもまだまだ世界は過酷だ。
それにも関わらず、弱さを尊重しようという無責任に甘い道徳が正しいとされ、現実は過酷なままなのに男女ともに繊細さが増し、男オタクにも不毛な学級会が増え、自由をもたらすはずのインターネットで被害者度合いとかわいそうランキングを競い合っている。
そしてこういう話って、「じゃあ戸塚ヨットスクールとか軍隊教育がいいのか」みたいな反論が来やすいんだけど、そんな極論はむなしい。極論が好きなら、命には必ず苦痛が発生するから存在しない方がいいとかまでいって反出生主義でもやっててくれ。
マッチョイズムの支配を脱しようとするあまり、強さを疎んじて弱さを貴ぶのは愚かなことだ。
＞増田が繊細さんじゃん、みたいな指摘
あっ………たりまえだろ！ インドアのインターネットオタクではてなで長文書いてておねショタ趣味があるんだぞ？ ついでに性別違和持ちでメンヘラで元フェミニスト。現代思想の影響を受けて男らしさからドロップアウトした繊細な男だから、不条理を黙って我慢できずこうやって文句を言っている。
Permalink |記事への反応(26) | 20:36
2016年7月13日19:41に下記のツイートがされている。
これがトリックだと仮定すると、すぐに思いつくのは、投稿日時をあとから書き換えるハックだと思う。
いくつかの解説記事によると、id は以下のような 64ビット整数であるようです。
+--------------------+--------------------+-------------------+
timestamp (42bit) worker-id (10bit) sequence (12bit) +--------------------+--------------------+-------------------+
それぞれの意味は以下の通り。細かいことはsnowflake のソースコード*2を見て確かめました。
sequence: 同じミリ秒枠内での衝突を回避するためのシーケンス番号（ミリ秒ごとに 0リセット）
worker-id: このid を発行したサーバ固有の番号 *3
timestamp: System.currentTimeMillis() -1288834974657L の値。（2010-11-0410:42:54 頃からの経過ミリ秒）
753177564164653056÷2^22 = 179571524659 (ms)
２．ミリ秒を日に換算
179571524659 (s) = 2078.374128 (day)
３．2010/11/410:42:54 の 2078.374128日後を計算する。
（エクセルだと、日付は１日が1なので、単に足し算すれば良い。）
結果は、……なんと2016/7/13 19:41になった！
ということで、ツイートのURLとタイムスタンプは一致していた。びっくりだ。
もし、ツイートのタイムスタンプを後から改ざんすることで前述のツイートを作成したとすると、タイムスタンプと同時にURLも改ざんする必要がある。
人によっては今更だけれど某/.の記事で知ったので、ちょいと調べてみた。
このあたりの定数と式がコアな部分かな。
53bit超えの精度で計算出来ない事が意外と多い。googleも計算してくれなかったりするのでWolfram|Alphaを使う。
twitter.com/#!/quolc/status/156410708081377280twitter.com/#!/quolc/status/156409454324232194twitter.com/#!/quolc/status/156407150216884224twitter.com/#!/quolc/status/155965255229509632twitter.com/#!/quolc/status/155964655032991744twitter.com/#!/quolc/status/155964103226167296twitter.com/#!/quolc/status/155953308895412224twitter.com/#!/t_n_tommy/status/157348397970493440twitter.com/#!/t_n_tommy/status/157133936789692416twitter.com/#!/t_n_tommy/status/157132545325142016twitter.com/#!/SoVeryAwkward/status/157247986714423296twitter.com/#!/SoVeryAwkward/status/157232924117315586twitter.com/#!/SoVeryAwkward/status/157215634772594690twitter.com/#!/ddlovato/status/157314029247938560twitter.com/#!/ddlovato/status/157308852327563264twitter.com/#!/ddlovato/status/157274729412165632
http://www.wolframalpha.com/input/?i=156410708081377280+%25+%28+2+%5E+12+%29
いくつか2だが、あとは0。探すと奇数のもあって1だったりするから、1がないのはたまたまかな？
sequenceのカウンタ部分は以下だが、これが回ることがあるのはさすがtwitter。
http://www.wolframalpha.com/input/?i=%28+156410708081377280+%3E%3E12+%29%25%28+2+%5E+5+%29
若干動く感じ。概ね0-4かな？
http://www.wolframalpha.com/input/?i=%28+156410708081377280+%3E%3E17+%29%25%28+2+%5E+5+%29
これは全部1。地域差があるのかと思ったけど同じだった。
twitter.com/#!/koizuka/status/145146329490927622twitter.com/#!/musuka__bot/status/145146343462154244twitter.com/#!/Royal_Host/status/145146355013267458twitter.com/#!/SNOOPYbot/status/145146357689225220
sequenceはさすがに回り気味だが、意外にもworkerId、datacenterIdは相変わらずっぽい。
まあ、25千tpsらしいので、キューで均されてsequence*workerが5*5くらいあれば回せるという事なのかな？
ちなみに日時の計算はこんな感じ。確かにその通り。
日時はソース通り、datacenterIdは1、workerIdは0-4、sequenceは、平時なら概ね0、回っても2まで。
今の所それが自然っぽい。
