Gitとブロックチェーンの関係 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ひょんな拍子に、Bitcoinやブロックチェーンについて調べ始めたのですが、すでに使っているものの中に、ほぼ同じようなものがあることに気づいてしまいました。 なお、この文章は「Gitは知っているけど、ブロックチェーンは何か知らない」というような人を前提としています。また、自分自身の理解が不十分な部分もありますので、マサカリも大歓迎中です。 TL; DR （広義には）Gitツリーもブロックチェーン Bitcoinには、分散系で取引履歴を改ざんされない仕組みがある マージ不能なフォーク Gitの根っこはブロックチェーン 最近、よく話題となっ
200行のコードへのブロックチェーンの実装 | プログラミング | POSTD
ブロックチェーン の基本的な概念は非常にシンプルです。分散型データベースで、順序付けられたレコードのリストが連続的に増加していきます。しかしシンプルとは言え、ブロックチェーンやそれを使うことで解決しようとしている問題について話をする際に、頭を悩まされることがよくあります。これは、 ビットコイン や イーサリアム といった、一般にもよく知られているブロックチェーンベースのプロジェクトでよく聞かれる話です。「ブロックチェーン」は、 取引 や スマートコントラクト 、または 暗号通貨 といったコンセプトと強い結びつきがあります。 そのため、本来シンプルであるべきブロックチェーンの理解がより困難になってしまっています。抜け目のないソースコードであれば尚更です。 そこで、 NaiveChain という、200行のJavascripitに実装した、非常にシンプルなブロックチェーンを紹介したいと思います
レイテンシーを計算する技術の話 - LINE ENGINEERING
こんにちは、LINEメッセンジャーのサーバーサイドとモニタリングプラットフォームの開発を担当しているフィ（@dxhuy）です。この記事はLINE Advent Calendar 2017の20日目の記事です。 今日は、モニタリングシステムでよく使うレイテンシーやその計算方法などについて紹介したいと思います。LINEでは、日々ユーザが楽しくメッセージを送れるように、システムの安定性を第一に考えています。安定したシステムを保つためにたくさんの指標を見守る必要がありますが、その指標の1つが「レイテンシー」です。 ウィキペディアでは、レイテンシーは以下のように定義されています。 デバイスに対してデータ転送などを要求してから、その結果が返送されるまでの不顕性の高い遅延時間のこと インターネットサービスにおいては、レイテンシーは基本的に「レスポンスタイム」のことです。つまり、リクエストを受けてからレス
わかりやすい画像のdiffを求めて - Qiita
どうも。フロントエンドエンジニアの @Quramy です。 さて、前回、1日10万枚の画像を検証するためにやったことで書いているとおり、reg-suitという画像に特化した回帰テストツールをメンテしています。 画像回帰テストという文脈において、差分の可視化方法はとても重要なファクターです。なぜなら、画像(=スナップショット)に差分が発生したからといって、それすなわち棄却、というわけではなく、その差分の内容を判断して、意図せぬ変更であれば棄却、意図した変更であればexpectedを更新する必要があります。すなわち、ワークフローに目視による差分のレビューが発生するのです。 そこで、少しだけ異なる2枚の画像について差分を効果的に可視化する、というテーマに向き合ってみました。 主にC++とOpenCVでの実装ですが、これらの知識が無くとも読めるよう、コードやAPIへの言及を少なくして、中間画像で説
Bing検索の裏側―BitFunnelのアルゴリズム - Hatena Developer Blog
はてなアプリケーションエンジニアの id:takuya-a です。 この記事では、Microsoft の検索エンジン Bing で採用された BitFunnel アルゴリズムを紹介します。 昨年のエンジニアアドベントカレンダーでは、文字列検索のアルゴリズム全般について紹介しました（文字列アルゴリズムの学びかた - Hatena Developer Blog）。今年はそのなかでも、インデックス（索引）を使った全文検索アルゴリズムについてのお話になります。 この記事の前半は全文検索の入門にもなっていますので、検索技術になじみがない方にも楽しんでいただけるのではないでしょうか。 逆に、「そんなのもう知ってるよ！」という方は、本題である「BitFunnel アルゴリズムの詳細」から目を通していただければと思います。 この記事は、はてなエンジニア Advent Calendar 2017の21日目の
ローグライク自動生成(区域分割法) - Qiita
#はじめに こちらはC++ (DXライブラリ)を使って、ローグライク的なダンジョンを作る記事です。 過去作品の掘り出し投稿となります。 〇〇勉強してみた Advent Calendar 2017に参加させていただきました。 今回は以前、ダンジョン生成を勉強してわかったことを書きだしていきます。 DXライブラリはこちらからダウンロードできます。 何か不備がありましたら指摘していただければ幸いです。 #概要 みなさん、"ローグライク"はご存知でしょうか？ 何だか知らない人にとっては分かりにくいかもしれませんね。 超簡単に言うと、入るたびに形が変わるダンジョンを冒険するゲームです。 この記事では、ローグライク的なダンジョンの生成方法を考えていきます。 #手順 《 注意!! 》 画像はかなり前に筆者がダンジョン生成を作るために作ったプログラムをスクショしたものです。 余計な部分も表示されていますが
意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて｜Rui Ueyama
プログラムを書いていると、素直に実装した結果として毎回特定の条件が満たされているけど、本来それは誰も保証してないという場面に出くわすことがよくある。保証されていない偶然の動作に依存することで生じるバグというのはかなり多い。 例えば最近では、ドラゴンボールZ ドッカンバトルというゲームで、2回SQL文を実行した結果が同じ順序で並んでいるという誤った期待をしているコードがあったせいで、ガチャの確率表示がめちゃくちゃになってしまって、運営が確率操作しているのではないかという騒動が発生したことがあった [1]。データベースでは空のテーブルにデータを追加してその直後に読み返すと、データを追加した順番に結果が返ってきたりしがちなので、問題のコードはきれいなテスト環境では偶然うまく動いてしまったのだろうと思う。 上のようなバグを防ぐために最近よく使われているのは、本来保証しないところをわざと壊すという方
デレステのタップ音からプレイ中の曲を推定する（eeic Advent Calendar 2017） – 愛のらくがき帳
この記事は eeic Advent Calendar 2017 の 4 日目の記事です。 今日はチノちゃんのお誕生日だけど、ごちうさネタなどいつものように思いつかないので今年もデレステネタで。 さて、デレステ（アイドルマスター シンデレラガールズ スターライトステージ）は今年で 2 周年を迎え、収録曲数も増え【秋風に手を振って】実装により 130 曲を迎えた。しかし研究室でイヤホンをしながらドカドカプレイをしていると、130 曲もあるのにスマホの画面を叩いている音だけでプレイしている曲がわかってしまう。 Trancing Pulseを感じる — すらゐ (@SLY_surawi) 2017年11月20日 これをコンピュータでできないか、すなわちスマホを叩いているだけの音声からどの曲をプレイしているかを自動推定できないか、と思うわけである。 1. 課題設定真面目に課題を設定していこう。ここで
SFC版風来のシレンの乱数生成アルゴリズムの話 考察編 - Qiita
この記事は続編です。 前回の記事で、SFC版風来のシレンのROMデータの解析内容を元に乱数がどのようにして生成されているかを解説しています。そちらを読んでからこの記事を読んでいただくと、より内容を理解しやすいかと思います。 前回の記事：SFC版風来のシレンの乱数生成アルゴリズムの話 解析編 SFC版風来のシレンの乱数の品質を調べる さて前回の記事でSFC版風来のシレンの乱数生成アルゴリズムが線形帰還シフトレジスタの一種であることが分かりました。 しかし乱数生成アルゴリズムは理解したものの、それによって生成された乱数が妥当な物なのかというのはアルゴリズムを見ただけでは分かりません。 シレンの乱数は偏りやすいと断言できるような目に見えて質が悪いものなのでしょうか。 この項でそれを考察してみたいと思います。 先にお断りしておきますが、本気で定量的・客観的に乱数の品質を検証しようと思うと本格的な統
分散ファイルシステムはブロックチェーンの夢を見るか | メルカリエンジニアリング
今年からメルカリでもMercari Advent Calendar 2017と称してAdvent Calendarを始めることとなりました。 初日は id:stanaka / @stanaka がロンドンよりお届けします。 分散ファイルシステムという言葉を聞くと、トラウマを刺激され、うっと頭を抱える人も多いかと思います。私もその一人で、以前にPBクラスまではいかずとも数TBのHDDを数百台並べたシステムのお守りをしたことがあり、日々壊れ続けるHDDに負荷に悲鳴を上げるメタデータDBなどネタには困らない状況でした。そういう時にAWS S3を触ると、「ああ、これは天国だ..」ともはや過去には戻れない思いをしたものです。 最近では分散ファイルシステムを運用しているところもめっきり減っていて*1もう過去の分野かな、と思っていたのですが、ここ数年で「ブロックチェーン x 分散ファイルシステム」という
ID生成大全 - Qiita
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
自分でコードを書きながらブロックチェーンを勉強した - mizchi's blog
マネーゲームとしての仮想通貨は興味はないのだが、技術的に興味があって自分で簡単なコードを写経しながら勉強した。 定義 ブロックチェーンの実体はブロックを繋いだリスト構造 ブロックはいくつかの入力値(生成日時など)と、自分自身のハッシュを持っている 前のブロックのハッシュ値と、入力値を元に自分自身のハッシュが決まる。その手順は公開されている。 要はハッシュ値とそのメタデータが連続するただの配列なりの LinkedList。面白いのはここから。 ネットワークに参加するそれぞれが任意に新しいブロックを追加することができる ブロックチェーンは検証結果が正しく、より長いものが信頼される なのでビットコインみたいな仮想通貨は、生成コストが重く、検証コストが軽いものが好まれる。 他のネットワーク参加者からブロックチェーンの更新を受け取った時、手元のブロックチェーンとそれを比較し、より長いものを自分のブロ
[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか （How a single PostgreSQL config change improved slow query performance by 50x）
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
SFC版風来のシレンの乱数生成アルゴリズムの話 解析編 - Qiita
SFC版風来のシレンの乱数について 私はローグライクゲーム好きなのでローグライク系ゲームの動画をニコニコ動画等でたまに見たりします。中でも、SFC版の初代風来のシレンはもう20年以上も前のゲームですが、完成されたゲームシステムと絶妙なゲームバランスにより、今なお根強い人気があります。 さて、そのSFC版風来のシレンの動画を見ていると、たまにゲーム上で「連続して攻撃を外す」「同じアイテムばかり出る」といった偏った現象が発生した時に「シレンの乱数は偏りやすい」といったようなコメントがよく書き込まれています。 人間の感覚というのものは偏った現象に気づきやすいものであり、この手の意見は大抵誤っている（特に最近ではソシャゲのガチャが操作されている！などとすぐに言われますね）のですが、風来のシレンはSFC時代のゲームという事もあり実際に質の悪い乱数生成ルーチンになっている可能性もあります。 そこで気に
【Unity】マリオっぽいゲームを作るのに必要な５つのこと - おもちゃラボ
ファミコンの横スクロールマリオの挙動をUnityで作ってみました。Physicsに全ておまかせ・・・というわけにはいかず、思っていたよりも大変です（笑）ということで、今回はそのレポートを書いてみます！ 今回の記事では、Unityでマリオの挙動を作るのに必要な項目を「ジャンプ編」「衝突判定編」「アニメーション編」「横スクロール編」「入力デバイス編」の５つに分けて紹介していきます。 ジャンプの挙動編 ジャンプボタンを押しっぱなしにしたときの挙動 ジャンプ後、落下の軌跡 空中で移動できる 当たり判定編 上方向の衝突判定 横方向の衝突判定 めり込み対策 アニメーション編 横スクロール編 コントローラ入力編 まとめ ジャンプの挙動編 マリオのジャンプは普通のジャンプとは異なる点が３つあります。 ジャンプボタンを押し続けると、ジャンプの高さが変わる ジャンプの軌跡は放物線ではない 空中で左右キーを押す
スケーラブルな採番とsnowflake — Kyrt Blog
snowflake は、Twitter 社が作成した、ユニークなID生成のネットワークサービスです。いくつかの簡単な保証で高いスケーラビリティを実現しています。Twitter 社が、MySQLから Cassandra に移行するにあたって、Cassandra にシーケンシャルな id 生成の仕組みが無かったことから作成したそうです。 snowflake についてはTwitter IDs, JSON and Snowflakeに書いてあります。 snowflake のコードは、Apache License, Version 2.0 でSnowflakeに公開されています。 スケーラブルな採番、背景的な話 Cloudでスケーラビリティのあるサービスを見据えてコードを書いていると採番に関する問題が必ず出てきます。従来、RDBの自動採番などに頼っていたのがコスト、スケーラビリティ、耐障害性の観点か
十分大きな乱数をユニークな識別子として使うのがなぜ安全なのか｜Rui Ueyama
いろいろなソフトウェアで、大きいランダムな値をユニークな値とみなすということが行われている。例えばユニークな識別子としてよく使われるUUIDはただの122ビットの乱数だ。gitもSHA-1ハッシュ値が160ビットの乱数のように扱えることを期待して、それをユニークな識別子として使っていた。実際にはランダムな2つの値が同じになる確率はゼロではないのに、なぜこれが安全なやり方だと言えるのだろうか？ それについてちょっと説明してみよう。 あるシステムが、乱数で生成された識別子の衝突のなさに依存しているとして、仮に衝突が発生した場合、相当悪い結果、例えば復旧不可能な形でデータベースが壊れてしまうとしよう。これはどれくらい危険なのだろうか？ 数学の問題で、学校のクラスの中で同じ誕生日の人が1組以上いる可能性は思ったより高いという話を聞いたことがあると思う。あるランダムに生成された値が衝突する確率という
異常検知ライブラリを作ってみた - Fire Engine
今回の記事は、前職消防士でゼロからプログラミングを始めた超未熟者の私が、異常検知ライブラリを作った話です。 なぜ作ったか マインド的背景 消防士を辞めてエンジニアに転職してから1年、いろんな技術に触れました。TensorFlow、scikit-learn、Dockerなどなど、必死になって使い方を覚えました。しかしだんだん、「これ、コマンド覚えてるだけで自分に何も技術身についてなくない？」という疑問や焦りが湧いてきて、自分は便利なツールを使いこなせるようになりたいんじゃなくて、いつの日かみんなが使って便利なツールを作る側になりたいんだ、ということに気づきました。そのような思いから今回初めてライブラリを作り、公開してみました。 データサイエンス的背景 世の中は時系列データで溢れています。ビジネスの場において、データの何かしらの変化の兆候を捉えて、いち早く意思決定をしたいという場面がよくありま
エレベータに見るアルゴリズムの性能と公平性のバランス｜Rui Ueyama
現実世界でもコンピュータの中でも、何らかの性能指標だけを追求すると参加者にとって極端に不公平になってしまうことがある。例えばエレベータとHDDは共通点がありそうに思えないが、この2つは性能特性的にとてもよく似ていて、リーズナブルな性能と公平性を両立させるために同じ制御方法が使われている。これについてちょっと説明してみよう。 1基しかない場合のエレベータの動き方は単純だ。一度上に動き出すと、上で待ってる人や降りる人がいる限り上昇し続ける。同じように、一度下に動き出すと、下で待っている人や降りる人がいる限り下降し続ける。これ以外の動き方をするエレベータはまず存在しないので、これが唯一の制御方法のように思えるけど、別にこうしなければいけないというルールはない。 エレベータの平均待ち時間を最適化することを考えてみよう。そうすると、一方向に動き続ける代わりに、エレベータが現在存在する階に一番近い人の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cache vs. Sync (Is a False Conflict) - steps to phantasien