タグ

2018年7月3日のブックマーク (18件)

  • Logical Decodingを使ったCDC(Change Data Capture)の実現方法を考えてみる

    今年も風物詩である PostgreSQL Advent Calendar の時期がやって参りました。Day1担当のデータマエショリスト @snaga です。 PostgreSQL Advent Calendar 2016 - Qiita http://qiita.com/advent-calendar/2016/postgresql 去年もDay1を担当した気がしますが、それはさておき。 余談ですが、今年のAdvent Calendarは [学生さん・初心者さん大歓迎!]Xamarin Advent Calendar 2016 - Qiita http://qiita.com/advent-calendar/2016/xamarin-welcome にも参加しております。また、 C# チュートリアル 全部俺 Advent Calendar 2016 - Qiita http://qiita

    Logical Decodingを使ったCDC(Change Data Capture)の実現方法を考えてみる
  • 「5年以上使い続ける」は時代遅れ、データ活用基盤の新常識

    企業内外でデータ活用を支援する基盤を見直す機運が高まっている。IoT(インターネット・オブ・シングズ)の普及などで、企業が扱うデータ量が急増してきたのが一因。AI人工知能)などデータの活用技術も進化する今、新しいデータ基盤が求められている。 IoTやデジタル化の普及により、一般企業でもビッグデータを収集し、活用することが可能になってきた。同時にクラウドサービスの進化により、データ活用の基盤を構築するための製品やサービスの選択肢が急速に増えてきた。 ビッグデータを収集・蓄積し、AIを使ったデータ分析を可能にする新しいデータ活用基盤は、「1度構築したら5年以上は使い続ける」といった従来型のデータウエアハウス(DWH)とは全く異なる発想で構築する必要がある。 進化するクラウドサービスを活用し、自社に合ったデータ活用基盤の構築を追求する企業の1社が、牛の管理サービスを提供するファームノートだ。同

    「5年以上使い続ける」は時代遅れ、データ活用基盤の新常識
    komlow
    komlow 2018/07/03
  • 【Wi-Fi高速化への道】(第13回)推進役はIntelからQualcommへ、「IEEE 802.11ad」の興隆と失速【ネット新技術】

    【Wi-Fi高速化への道】(第13回)推進役はIntelからQualcommへ、「IEEE 802.11ad」の興隆と失速【ネット新技術】
    komlow
    komlow 2018/07/03
  • 『東京タワー』の建設フロー、PM視点でみてヤバすぎたので解説|Shoko Suzuki

    はじめに : Who I amこんにちは、建設×ITのスタートアップ「シェルフィー株式会社」でプロダクトマネージャーをしているShoko(@shokosuzuki1991)です。noteデビューしました!👏 先日参加した『建設職人甲子園』というイベントで、東京タワー建設時のエピソードが紹介されてたのきっかけに、『東京タワーができるまで』を調べれば調べるほど、すごすぎる!ヤバすぎる!となったので、今回はそのあたりをPM的な切り口でまとめてみました。 (※なるべく事実に忠実に書いてますが、一部わかりやすくする表現を優先しているところもあります。予めご容赦ください🙏) 1.構想の大胆さがヤバい 東京タワーが完成したのは1958年です。当時は爆発的なテレビの普及が予想される中で「このまま各局独自の電波塔が増えると、東京中が電波塔だらけになって景観が悪化する」という問題を抱えていました。 そ

    『東京タワー』の建設フロー、PM視点でみてヤバすぎたので解説|Shoko Suzuki
  • Bare Metal K8s Clustering at Chick-fil-A Scale

    At full scale Chick-fil-A will be running Kubernetes at the Edge in each of our 2000 restaurants. That means roughly 6000 devices at the Edge running Kubernetes. One of the biggest challenges associated with this is bare metal clustering on-the-fly, in-restaurant. While most Kubernetes deployments are in the cloud or benefit from skilled technicians that are physically located near their deploymen

    Bare Metal K8s Clustering at Chick-fil-A Scale
  • TLS の SNI 暗号化に関する Internet Draft を共同提出しました

    Eric Rescorla (RTFM), Nick Sullivan (Cloudflare), Christopher Wood (Apple) の各氏とともに、SNI を暗号化する TLS 拡張を提案する Internet Draft を提出しました。 Encrypted Server Name Indication for TLS 1.3 アナウンスのメールにあるとおり、すでに NSS / Firefox と picotls / H2O で実装作業が開始されており、今月開催される IETF 102 で相互運用試験を行うとともに、標準化にむけた議論を深める予定です。 スノーデン事件以降、広範囲におよぶトラフィックモニタリングによるプライバシー侵害の懸念が明らかになるとともに、できるだけ多くのインターネット上の通信プロトコルを暗号化することが求められるようになってきました (参考: R

    komlow
    komlow 2018/07/03
  • Linuxではじめる快適スレッドライフ

    概要 pthreadはクソだというのをひしひしと実感している…わけではないけど、 Win32のスレッドと比べると微妙な感じが拭えないので、Linuxのスレッドを使えばもっとハッピーになれるよ、というような話。 pthreadがクソな理由 pthreadは Win32 のスレッドに比べていくつか微妙だと思われる点がある。まずはその点について書こう、と思ったのだけど、大体[ここ]に書いてあったので、列挙だけしておく。詳細はリンク先を読んでね! Win32スレッドがWaitFor(Single/Multiple)Object(s)で全部待てるのに対して、pthreadは mutex、cond、semjoin のどれか、しかも一つだけしか待てない Win32のオブジェクトはシグナル状態を保持し続けるのに対して、pthreadの条件変数は、シグナル待ちになっていない状態でcond_signalを受

  • innodb_thread_concurrencyに関する話 | GREE Engineering

    こんにちわ。せじまです。今回の話は軽く書こうと思っていたのですが、長くなりました。まぁInnoDBの話なのでしょうがないですね。 はじめ 今回はinnodb_thread_concurrencyについてお話しようと思います。できれば、事前にInnoDB の mutex の話(入門編)を読んでいただいた方が、より深く理解していただけるのではないかと思います。 長いので、最初に五行でまとめます 現代において、ほとんどのケースでは、innodb_thread_concurrencyはデフォルトの0のままで問題ないと思います。なぜなら、最近のInnoDBはかなり良くなってきたからです。 それでもinnodb_thread_concurrencyをチューニングするとしたら、「高負荷状態になったときでもスレッド間の公平性をなるべく担保し、安定稼働させるため」と割り切って使うのが良いでしょう。 inno

    innodb_thread_concurrencyに関する話 | GREE Engineering
    komlow
    komlow 2018/07/03
  • 株式会社メルカリに新卒入社しました

    2018年4月に株式会社メルカリに新卒入社しました.職種はソフトウェアエンジニアで,Goでマイクロサービスを開発しています.ちなみに,入社したのはメルカリですが,メルペイに出向となったので現在は株式会社メルペイにいます.なんで4月じゃなくて,今書いているのかという話ですが,試用期間中だったので(入社エントリ書いて即解雇されたら辛いので...)書きませんでした.今日出社したら席がちゃんとあり,なんとかまだ在籍できているみたいなので,入社エントリを書きました. 入社するまでの経緯@b4b4r07さんのこのエントリがきっかけでした. このエントリ中で, 16 新卒は 6 人いて、今は 17⁄18 卒の新卒採用に向けて動いています。 採用会など、まずは話から聞いてみたいなという方がいましたら、僕経由で繋ぐことができるかもしれませんので興味があれば Twitter DM でもいいですし、コンタクト

    komlow
    komlow 2018/07/03
  • 多腕バンディットを活用したプッシュ配信の最適化施策 - ZOZO TECH BLOG

    こんにちは。VASILYに入社して、オシャレぶるようになったと周りにイジられているデータサイエンティストの金田です。 VASILYでは、プッシュ通知の開封数を上げるために様々な施策を行っていますが、その一つとして、多腕バンディット問題を応用し、複数の異なるタイトル文の配信比率を動的に最適化することで、開封数を高めるといった取り組みを行っています。今回は、なぜプッシュ通知配信の最適化に多腕バンディット問題を応用したのか、アルゴリズム選定にあたりどのようなポイントを考慮したか、また実用にあたってどのような問題に直面し、それをどう克服したのか、といった点について紹介したいと思います。 プッシュ配信最適化の背景 iQONでは、新着の雑誌記事やコンテストのお知らせをユーザーへ通知するため、1日に数回プッシュ通知を配信しています。プッシュ通知は、どのようなタイトル文を配信するかによって、開封率が大きく

    多腕バンディットを活用したプッシュ配信の最適化施策 - ZOZO TECH BLOG
  • RDBMSのモニタリングについて - そーだいなるらくがき帳

    dbstudychugoku.github.io 中身の薄い資料で登壇してきた。 speakerdeck.com 具体的な内容が知りたい人は末尾に関連リンクをまとめたのでそっちを見て欲しい。 資料には書いてないけど伝えたかったことをまとめる。 RDBMSの監視の勘所 RDBMSがどれくらいのトランザクションを捌けるかというのが大切な要素の一つ。 単純な処理が多くてキャパオーバーになったとき、多くの場合はインスタンスのサイズを上げるなどのスケールアップで対応できる。 これは費用対効果の高いケースが多く、有効な手段だ。 しかし ロックが原因の場合 はスケールアップしても問題が解決しないことが多い。 例えばバッチ処理で長時間テーブルロックを取り、それが起因でパフォーマンスが問題になっているときは単純なスケールアップで問題は解決しない。 よく見られる処理例は次のようなケース。 トランザクションを開

    RDBMSのモニタリングについて - そーだいなるらくがき帳
  • Kubernetes の ConfigMap を Immutable に管理する

    Kubernetes の ConfigMap を Immutable に管理する Jul 1, 2018 Quipper では Microservices 基盤として Kubernetes によるクラスタを構築し、もうすぐ番環境にリリースしようとしています。当は Deis Workflow で使う Kubernetes クラスタを既に番で運用していますが、Deis なしでの運用に変えようとしているのが最近の状況です。 そこら辺の背景は 2018/07/19 に行われる Quipper Product Meetup でお話しするとして、今は YAML の管理どうするかみたいなところから試行錯誤している状態で、基的には Pull Request ベースでレビューしてマージされたらデプロイ、みたいなことをアプリでもクラスタでもやる感じになっています。 今日は、その中でも ConfigMa

    Kubernetes の ConfigMap を Immutable に管理する
  • Why you should not use Google Cloud.

    FINAL UPDATE (25-March-2022): Because of this article, we often keep getting asked if we still use GCP and if we would recommend it to others. The answer is ‘YES, WE DO’, even more than before. GCP is an excellent service just like AWS and Azure (we use all three). Some of GCP’s products (BigQuery, CloudRun, Spanner, all of which we use) are insanely good and have no parallels (IMHO). You should t

    Why you should not use Google Cloud.
    komlow
    komlow 2018/07/03
  • Recruit-CSIRT流 Triage Tool For Linuxの紹介 | Recruit Tech Blog

    こんにちは、Recruit-CSIRT 市田です。 この記事では、Recruit-CSIRTが日頃サーバーにおける侵害調査の初動をどのようにやっているかをお伝えします。 サイバー攻撃時の初動、トリアージ もしみなさんが、「システムがサイバー攻撃を受けて侵害されていないか」を確かめるときどのようなことを行っていますか? 侵害(Compromise)とは、システムに不正アクセス、侵入をするという意味で捉えていただければと思います。 まだ、どうやって侵害されたのか・過去何が起こっていたのか・今何が起こっているのかが不明瞭であり、どのサーバーから手をつけたらいいか迷う状況にて、インシデント対応では「トリアージ(Triage)」という処置を行います。サイバーインシデントの復旧や対策の優先度を決めるための調査のことです。 これは、医療現場などでも使われている言葉で、救急救命の際に患者の容体を把握しどの

    Recruit-CSIRT流 Triage Tool For Linuxの紹介 | Recruit Tech Blog
  • コンテナとアーキテクチャを開発し、見えてきた世界 / why-we-create-our-container-and-architecture

    第2回HPC OPS 研究会 https://bit.riken.jp/2018/06/2nd-hpc-ops-mtg/

    コンテナとアーキテクチャを開発し、見えてきた世界 / why-we-create-our-container-and-architecture
  • スパム対策お焚き上げ

    NSEG #101 https://nseg.connpass.com/event/89567/ での発表プレゼン資料です。 以前自分が考案したスパム対策手法taRgreyのおさらいし、taRgreyの現在の状況ログからスパムの現状を話します。Read less

    スパム対策お焚き上げ
    komlow
    komlow 2018/07/03
  • Pointers Are More Abstract Than You Might Expect in C

    clanguage-lawyerpointer A pointer references a location in memory and dereferencing a pointer refers to the lookup of the value of the memory location the pointer references. The value of a pointer is a memory address. The C standard does not define the representation of a memory address. This is crucial since not every architecture makes use of the same memory addressing paradigm. Most modern arc

    komlow
    komlow 2018/07/03
  • 分散システムの限界について知ろう

    ↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤:たった一つのプロセスが故障しただけでも有限時間で合意できない 正:たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら

    分散システムの限界について知ろう
    komlow
    komlow 2018/07/03