西暦1年は閏年か？ - プログラマーの脳みそ
閏年（うるうどし）の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる？」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。本当にそうだろうか？ そう単純な話なのだろうか？ プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月（太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ）をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法（ちじゅんほう）は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年（つまり2月
キャッシュ機構 TinyLFU のアーキテクチャと、それを支えるアルゴリズム - 好奇心に殺される。
Computer Science キャッシュ機構 TinyLFU のアーキテクチャと、それを支えるアルゴリズム TinyLFUの論文を読んだので概要と、それを支えるアルゴリズムを紹介します。 Overview TinyLFU はアクセス頻度を近似し、軽量でハイパフォーマンスに設計されたキャッシュアルゴリズムです。最近、Database Internals を読んでいて TinyLFU を知ったのですが、Database Internals では TinyLFU の詳細が書かれていなかったので、TinyLFUが提案されている論文を読んでみました。その内容をザックリ解説してみようと思います。 論文はこちらです。 TinyLFU: A Highly Efficient Cache Admission Policy いきなりTinyLFUの紹介を始めると混乱するので、ベースとなる技術やアルゴリズム
LINEのストレージ効率化を支えるJPEG↔HEIF変換プロジェクト「Antman」開発記
Joonsick Baick2020-02-26Joonsick is in charge of media processing for LINE's MediaPlatform. はじめに 最近、ユーザーが作成したメディアを保存するためのクラウドサービスがかなり人気を集めています。Google フォトやNAVER nCloudなどのサービスがその例です。LINEでも、ユーザーの写真をサーバーに永久保存していつでも閲覧できるようにしたアルバム機能を提供しています。LINEのアルバム機能は、2013年9月にオープンして今年で6年を迎えます。たくさんのユーザーが活発に利用しているため、サーバーに蓄積されるデータ量も膨大になっています。 写真や動画などのLINEのメディアデータは、すべてLINEのメディアプラットフォームが運営するメディアストレージ「OBS（Object Storage）」で管
データ構造とアルゴリズム - Qiita Advent Calendar 2019 - Qiita
データ構造とアルゴリズムに関する話題なら何でもOKです。 メジャーなものからマイナーなものまで様々なトピックを好きなように書きましょう！ カレンダーの愛称は「デーアルアドカレ」でお願いします！ 関連： 以下は「文字列アルゴリズム Advent Calendar」を含みますが、実態は何でもありで様々なデータ構造とアルゴリズムが紹介されています。 文字列アルゴリズム Advent Calendar 2016 - Qiita 文字列アルゴリズム Advent Calendar 2017 - Qiita データ構造とアルゴリズム Advent Calendar 2018 - Qiita データ構造とアルゴリズム #2 Advent Calendar 2018 - Qiita
アプリケーション・リソースと同時接続数の試算例 | 外道父の匠
ずっとKubernetesについて書いてきましたが、ここらへんでコンテナのリソース…… つまりアプリケーション・サーバーとしてのリソースの試算について考えてみます。別にコンテナじゃなくてインスタンスでも考え方は同じなので、タイトルからEKSとか抜いてシンプル回帰しております。 ぶっちゃけ、リソースの試算と一口に言っても、実際には色んな要素が入り混じって変化するので、色んな考え方があると思います。なので最初に明記しておくと、今回は特定の項目に着目し、面白半分、もう半分は真面目に計算したコンテンツという感じでよーそろーです。 はじめに なぜこんな試算をする気になったかというと、コンテナの設定をする上で、１インスタンス（Node）あたりのリソースがこれくらいなら、１コンテナあたりにどのくらいのリソースを割り当てて、コンテナ内部のアプリケーション用プロセスは１プロセスあたり何メモリだったら、何接続
Zoom-blc.com
This Domain Has Expired, To Renew Please Contact Your Provider.
プログラマの採用面接で聞かれる、データ構造とアルゴリズムに関する50以上の質問 | POSTD
情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。
“究極の名寄せ”を実現する、サーバーレスアーキテクチャの作り方
2018年4月17日、レバテック株式会社が主催するエンジニア向け勉強会「ヒカ☆ラボ」にて「高トラフィック＆大規模データを扱う事業会社ならではの開発のノウハウとは？」が開催されました。Sansan、bitFlyerの2社が登壇した本イベントでは、それぞれ社員が2名ずつ登場し、自社の大規模サービスにおけるシステムの裏側を語りました。プレゼンテーション「究極の名寄せのためのサーバーレスアーキテクチャ」では、Sansan株式会社の高橋洸氏が登場。同社が手がける名寄せサービスにおけるアーキテクチャ設計について紹介しました。 エンタープライズシステムと連携して顧客データを継続的に名寄せ 高橋洸（以下、高橋）：みなさんこんばんは、引き続きSansanの高橋が「究極の名寄せのためのサーバーレスアーキテクチャ」と題して、発表いたします。よろしくお願いします。 自己紹介、高橋と申します。 前職が中堅のSIer
みんなのデータ構造
紙書籍をお届けします（PDFがついてきます） PDFのみ必要な場合は、こちらからPDF単体をご購入ください 紙書籍は通常、ご注文から2～3営業日で発送します 年末年始や大型連休など、1週間から10日程度、配送のお休みをいただく場合があります。詳しくはお知らせをご覧ください 配列、リスト、木、グラフ、それぞれの理論的な特性を知り、実装まで理解するためのガイドブック Pat Morin 著、堀江 慧・陣内 佑・田中 康隆 共訳 288ページ A5判 電子書籍の形式：PDF ISBN：978-4-908686-06-1 2018年7月20日 第1版第1刷 発行 正誤情報 データの格納方法を工夫するだけで、魔法みたいにアルゴリズムが導出できる。うまくデータを整頓するだけで、画期的に計算が速くなる。仕事で直面している問題がなかなか解決しないのは、問題に対する適切なデータ構造を知らないから、というだけ
Apache Arrow東京ミートアップ2018 - Apache Arrow #ArrowTokyo - 2018-12-10 - ククログ
Apache Arrow東京ミートアップ2018を主催したした須藤です。会場提供・飲食物提供などSpeeeさんにいろいろ協力してもらいました。ありがとうございます。 私はApache Arrow本体のことを網羅的に紹介しました。データの配置のことなど日本OSS推進フォーラム アプリケーション部会 第10回勉強会では触れなかった技術的な詳細についても紹介しています。 関連リンク： スライド（Rabbit Slide Show） スライド（SlideShare） リポジトリー 集まりの目的 この集まりは勉強会ではありません。勉強をする集まりではなく開発者を増やす集まりです。開発対象のプロダクトはApache Arrowだけでなく、Apache Arrow以外でもデータ処理に関わるプロダクトであればなんでもOKです。 そのため参加枠は次の2つにしました。 開発に参加したい気持ちがある枠 開発に参
Dive into Apache Arrow（その１） - KaiGaiの俺メモ
Arrow_Fdwを作るモチベーション 昨年、かなり頑張ってマルチGPUや拡張I/Oボックスを使用してシングルノードのクエリ処理性能10GB/sを達成できた。ただ一方で、PG-StromがPostgreSQLのデータ構造をそのまま使えるという事は、トランザクショナルに蓄積されたデータをそのまま使えるという手軽さの一方で、どうしても行指向データに伴う非効率なI/Oが処理速度全体を律速してしまうという事になる。 昨年の10月頃から直接お会いした人にはお話していたが、現在、PG-StromでApache Arrow形式のファイルを扱うようにするための機能強化に取り組んでいる。目標としては、３月末には動かせる状態にしたいと思っているが。 Apache Arrow形式とは、Sparkの人がよく使っているデータ形式で、大量の構造化データを列指向で保持する事ができる。特定の行を更新したり削除したりといっ
Silo - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? In-Memory DBのアーキテクチャは数多く提案されてきたが、特にパフォーマンスに直結するトランザクション周りでのボトルネック改善は需要の高い研究領域である。 これから紹介するStephen TuらのSOSP'13は大きなメモリと多くのCPUコアを活用してより高い性能を発揮するために考案された新しいトランザクションアルゴリズム：Siloを提案している。 In-Memory DBの問題点 昨日書いたように、In-Memory DBではページ単位でのバッファプールの管理やWALやUndoログが不要となり、トランザクション内でページを書き
AsakusaとOLTP（RDB）とバッチ処理 - 急がば回れ、選ぶなら近道
Asakusa Advend Calnderの最終として 現状 2018/12月の現在の自分のタスクは、DBのMVCCでのTX制御の理論・アルゴリズムの設計になっている。要するにDBを作りましょうということで、そのコア部分をどうにかしなさい、ということになっている。それで、その前提として、今回のDB-Prjでの最大の眼目の一つを「Writeの強いRDB（OLTP）」ということにしている。 現在のRDBはそもそも原理的かつそのツールとしての特性上WriteというよりもReadにパフォーマンスが振られている。結果として、一般に、書き込みヘビーの業務系大型バッチ処理がRDBでまぁほぼ全敗になる。これは常識のまま、そろそろ30年くらいになるし、この辺が改善する見込みはほぼない。ということで、大規模（といってもさすがに最近のトレンドの規模感からはそう簡単には大規模とは言いがたいが）で複雑な一貫性を担
異常検知システム開発の難しさ
はじめに 「異常検知したい」と考えている人は多いと思います。もはや囲碁ですら機械が人間を上回る時代となったので、システムの故障を発見したりクレジットカード詐欺を見つけたりという異常検知システムも、データサイエンスを使えば人間以上に優秀なものを作れるのではないか？と考えるのも自然でしょう。 一方で、実際に異常検知システムの開発に乗り出してみたものの、意外と上手く完成まで辿りつけなかったり、せっかく作ったけれども結局誤検知だらけでお蔵入りしたり、というケースもあるのではないかと思います。この記事では実際に異常検知システムをゼロから開発してみた経験からいくつかの点について書いてみたいと思います。 この記事にはアルゴリズム的な、技術的な知見は含まれていません。「もし居酒屋で異常検知をネタに呑むとしたら、このへんで盛り上がるかな」的な記事として書いてみましたので、お時間あるときに気軽に読んでいただけ
多腕バンディットを活用したプッシュ配信の最適化施策 - ZOZO TECH BLOG
こんにちは。VASILYに入社して、オシャレぶるようになったと周りにイジられているデータサイエンティストの金田です。 VASILYでは、プッシュ通知の開封数を上げるために様々な施策を行っていますが、その一つとして、多腕バンディット問題を応用し、複数の異なるタイトル文の配信比率を動的に最適化することで、開封数を高めるといった取り組みを行っています。今回は、なぜプッシュ通知配信の最適化に多腕バンディット問題を応用したのか、アルゴリズム選定にあたりどのようなポイントを考慮したか、また実用にあたってどのような問題に直面し、それをどう克服したのか、といった点について紹介したいと思います。 プッシュ配信最適化の背景 iQONでは、新着の雑誌記事やコンテストのお知らせをユーザーへ通知するため、１日に数回プッシュ通知を配信しています。プッシュ通知は、どのようなタイトル文を配信するかによって、開封率が大きく
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
メモリとスタックとヒープとプログラミング言語 | κeenのHappy Hacκing Blog
κeenです。 今回の話は別にRustに限ったものではないのですが、よくRustを始めたばかりの人がスタックとヒープが分からないと言っているのをみかけるので少しメモリの話をしますね。 厳密な話というよりは雰囲気を掴んで欲しいという感じです。 メモリは配列 プログラム（プロセス）のメモリには実行するプログラム（機械語）やグローバル変数/定数、関数の引数やローカル変数、その他プログラムで使うデータ領域などを置きます。 プロセスに割り当てられるメモリというのは、1つの巨大なのっぺらな配列みたいなものです。サイズも決まってます。64bit OSなら2^64 byteです。 0 2^64 +--------------- ----+ | | | | | ~~ | | +--------------- ----+ これは仮想的なメモリなので実際の物理メモリに2^64 byteの配列がドンと確保される訳
Engadget | Technology News & Reviews
How to watch Polaris Dawn astronauts attempt the first commercial spacewalk
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
量子コンピュータでも解読が困難な新暗号方式が国内で開発
一人トランザクション技術 - Qiita Advent Calendar 2016 - Qiita
