サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
builderscon.io
Abstract 昨年のクリスマスに、 AIとIoTを駆使して黒髪のメガネ女子とマッチングするデバイスを作りました。画像取得 -> AI(API) -> 判定 -> サーボ制御 -> スマホを押す機構の一連の仕組みについて、その概要をお話します。
Abstract 岐阜県神岡の地下に設置されたニュートリノ検出器「スーパーカミオカンデ」。 検出器本体は直径 40m 高さ 40m の水槽に 50,000 トンのタンクとそこに蓄えら れた超純水、そして約 12,000 本の光電子増倍管。純水中で電荷を持った高速の 粒子がつくり出す微弱な「チェレンコフ光」を光電子増倍管で観測することで、 ニュートリノを観測したり陽子崩壊の兆候を探そうとしています。 光電子増倍管は常時微弱なノイズをだしているため、約 12,000 本の光電子増倍 管から収集されるデータ量は 300MB/s 以上。このノイズの山から欲しい「事象」 を選びだし、記録するシステムが必要となります。 太陽や空気(大気)で作られるニュートリノは常時観測できますが、超新星はこの 銀河中では30年から50年に1回だけ。いつとんでくるかわかりません。また、陽子 崩壊もいつ起きるかわかりませ
Abstract 私(@hoddy)は形式手法の実用可能性についてDeNAで研究をしています。 形式手法を使うと、MySQLのdeadlockの検知や、非同期処理の設計ミスなど、 人間が考慮しづらい部分のバグに、設計段階で気づくことができます。 形式手法とは 形式手法とは、仕様を明確に記述したり、記述された設計の性質を機械的に検証する手法の総称です。 形式手法にもいくつか種類がありますが、いずれも数学に基づく科学的な裏付けを持ちます。日本での導入事例は多くはないですが、世界的に見ると多くの導入事例が観測できます。 解決できる課題 開発では、日本語で書かれる仕様の不備(考慮漏れ、記載漏れ、矛盾など)により、大きな手戻りにつながることが多いと思います。形式手法を使うと、仕様をより厳密に書けるようになるため、仕様不備が起きにくくなります。 また、システムがとりうる状態を網羅的に探索することができ
Abstract 概要 twitterに何かあるたびに話題になるmastodonのような非中央集権型マイクロブログサービスが構成するネットワークは"fediverse"と呼ばれますが、これらは主にActivityPubというプロトコルで接続されているので、このプロトコルに従ったサーバアプリを作ることでネットワークに参加できます。 しかし、ActivityPubは大枠を定めているだけであり、実際にmastodonに接続するには単にプロトコルの仕様書を読む以上のノウハウが必要になります。 このセッションでは、Perl版ActivityPubサーバ"Actub"を自作した経験から、ActivityPubのうち主にmastodonに接続するサーバアプリを作成するために必要なノウハウについて概説します。 想定聴講者 新たにfediverseに接続するアプリを作ってみるためのとっかかりの情報がほしい方
Abstract 近年、日本でもキャッシュレス社会に向けた動きが活発化しています。 様々な事業者によるQRコードによる決済が誕生し、コンビニや大手家電量販店でもQRコード決済で支払い出来るようになったり、ニュースで「キャッシュレス」という言葉を聞く機会もかなり増えたのではないでしょうか? まさにスマホ決済元年・キャッシュレス元年といえる2019年ですが、そういった盛り上がりの一方で各事業者ごとのQRコードの技術仕様や業務フローの対応については加盟店、消費者双方への負担が課題になっています。 こうした負担を解決するための動きとしてキャッシュレス推進協議会が統一QR(JPQR)仕様を策定しており、このJPQRを使った実証実験が2019年8月から岩手県、長野県、和歌山県、福岡県の4県で行われる予定です。 今回、私はこのJPQRの仕様について解説しつつ、JPQRが実現する未来についてお話させていた
Abstract メルペイでは新入社員向けにアーキテクチャ研修をやっており、Super Kazegusuri Time(SKT)と呼ばれています。 メルカン記事: https://mercan.mercari.com/articles/2018-12-07-181647/ 研修ではメルペイがどのような技術スタック、アーキテクチャ、思想で開発しているかを伝えています。 今回はメルペイ立ち上げ当初から重要視している、決済・金融サービスとして安定していて安全なサービスを提供するために行っていることを説明したいと思います。テーマは「あんしん・あんぜんのために技術的に取り組んできたことを知ってもらう」です。 決済と聞くとトランザクション管理の重要さと難しさが真っ先に思い浮かぶと思いますが、実際には他にも多くの不可欠な要素があります。これらの要素について紹介しつつ、メルペイがどう解決しているかを説明し
Abstract Elixir というプログラミング言語をご存知でしょうか? Ruby に似たモダンなシンタックスをもつ言語であり、Erlang という言語にコンパイルされて、Erlang VM の上で実行されます。 Erlang には 20 年以上の長い歴史があり、古くは電話交換機から、インターネットの膨大なトラフィックをさばくスイッチ、数億人規模のメッセージングアプリなどで採用されています。最近では、Nintendo Switch 向けのプッシュ通知システムに採用されたことでも話題になりました。 採用されている事例からも分かりますが、大量のアクセスをさばく必要があり、高可用性と耐障害性が求められるシステムにうってつけの言語です。Elixir (Erlang) で書かれたシステムは「落ちない」とまで言われるほどです。 では、Elixir (Erlang) の高可用性と耐障害性は、どのよう
宣言的UI for React, Vue.js, SwiftUI, Jetpack Compose, Flutter accepted Abstract 2019年のGoogle IOではAndoirdのJetpack Compose、WWDCではiOSのSwiftUIと新たなUIフレームワークが登場しました。 何故これらのフレームワークが誕生したのでしょうか? 単に新しい言語に合わせたフレームワークをリリースしただけでしょうか? そうではありません。 Webの世界で実証された「宣言的UI」を実現できる待望のフレームワークが登場したのです。これにより今まで複雑であったGUIアプリケーションをよりシンプルに実装できるようになります。 そこで本セッションでは、この宣言的という言葉を中心に過去のUIアーキテクチャを振り返り、今後アプリ開発で主流となる宣言的UIを紹介します。 更にそれを踏まえて今
Abstract 概要 新卒二年目エンジニアの私が去年一年間で遭遇したサーバーサイド開発における問題と、その問題をどのように解決してきたかについて事例ごとに紹介します。 このセッションでは、私が一年間働いてきて起こしてしまった失敗の戒めと、これからサーバーサイド開発を始める方の参考となるように自分が遭遇した問題の原因を掘り下げて再発を防ぐための知見を共有します。 対象者 サーバーサイド開発に興味がある人 サーバーサイド開発あるあるを踏み抜いてきた人 新人の失敗を一緒に笑い飛ばしてくれる人 紹介予定の事例 (一例) main関数が2回実行されてシステムが落ちる現象 単体テストのCoverageが5%のシステム N+1クエリが原因の本番障害 並列処理とトランザクション スケーリングしない複数台構成 キーワード Java, Kotlin, Spring boot, RDB, Unit test,
Abstract プログラミング言語Rubyはバージョン2.6でJust-In-Timeコンパイラを搭載し、Ruby 2.0に比べて2.5倍も高速になりました。言語処理系が2.5倍高速化するためにどのような魔法が使われたのか興味はありませんか? evalや動的なメソッドディスパッチなど、Rubyは高速化が困難な問題を多数抱えていますが、これらは実行時の情報を利用して最適化を行なうことによってエレガントに解決することができます。 このセッションでは、RubyのJust-In-Timeコンパイラがいかにしてそのような言語の高速化を実現しているかのエッセンスを、RubyやJust-In-Timeコンパイラの前提知識がなくてもわかるように解説します。 もしあなたがRubyを使うことがなくても、このセッションを聴けば、あなたが使う言語でどのような言語機能を使うと最適化の妨げになるかが理解しやすくなる
Abstract トピック 暗号技術 / ブロックチェーン / 秘匿化技術 / ゼロ知識証明 / Rust / Go / substrate TL; DR ブロックチェーンの秘匿化の解決する課題とは何か?世の中的な意義は? 暗号実装素人のウェブエンジニアがブロックチェーンの先端を理解するための試行錯誤&ハマったことは何か GoやRustでの実装を交えながら秘匿化技術を深く紹介する 概要 仮想通貨の投機的ブームが一段落し、金融領域で着実に応用例が生み出されつつあるブロックチェーンにはアカデミックな暗号学の分野で研究されている理論や技術が多く使われており、世界中で盛んに研究開発が行われています。将来的に何が技術的な勘所になるのかをR&Dが本業でない門外漢が追いかけるのは大変です。ハッシュ関数や公開鍵暗号は普段使っているものの、ブラックボックス化された実装の詳細は知らないし、何が実装上簡単で何が
Abstract The internationalization of the application is not just only translating texts used in it. In this talk, from the view of both developers and users, we will see the technical knowledge, difficulties, and solutions for the internationalization of the application, based on the experiences of the development of the iOS applications used in a variety of regions in the world. This talk is for
Abstract CI・CD、クラウドインフラ、DDD、Docker、Unit・E2E testing、git・github、etc...。 15年以上、システム開発に携わってきましたが、15年前はこれらのツール/手法のほとんどは世に出ていなかった一方で、今ではなくてはならないものになってきています。 「なくてはならない?こういうのが取り入れられるのは、イケてる自社サービスを持っているところだけなんじゃないの?」 いえ、うちは10名に満たないどこにでもあるような受託開発がメインの会社です。 メンバーだってCTO経験者の集まり、みたいな特殊なものではありません。 その当社をして「なくてはならない」と捉えている開発ツールや手法について、実際の活用方法や前提条件、必須度とその理由などを交えつつ紹介します。 こんな方向け 冒頭に例示したようなツール/手法を一度は導入してみたが、失敗したことがある
Abstract 本セッションの目的は、ずばり モナド (monad) に対する 初心者の心理的障壁を取り除くこと です。モナドはプログラミング言語 Haskell と関連して言及されることが多く、世間では何か得体のしれない難解な概念だというイメージが先行しています。しかし、実際にはどのプログラミング言語にもある「処理」の概念を一般化しただけで、プログラマにとっては顔見知りの相手に過ぎません。 本セッションでは、実際の使用場面から逆算してモナドを再発明することでその必然性を体感し、必要以上に強調された神秘性を引きはがすことを目標とします。受講後には、セッション内で扱わなかった Haskell の基本文法を少し補うことで、モナドを利用した単純なプログラムならすぐに書けるようになるでしょう。 そもそも、なぜモナドや、それを用いる Haskell にはこんなにも怖ろしげなイメージが先行しているの
Abstract 概要 あの計測野郎が帰ってきた!次はパフォーマンスを改善していくぞ!buildersconに身体をビルドする話をする人がいないならば私がするしかない!筋トレと科学的知見でよりよいエンジニアライフを約束します。 解説 このセッションでは筋肉を成長させるための最新の知見の紹介。正しい手法の実践などを登壇者の実践をもとに解説していきます。また正しさを手助けする筋トレログアプリを制作し、その過程も解説します。 正直なところ、私は人に自慢できるほどのトレーニーではないため、他に適任がいるんじゃないか。というのが正直なところです。しかし、中学高校とそこまで運動をしてこなかった人間でも、継続して筋トレすることで平均値を超える筋量を得られるということをお伝えできると思います。 なぜやるか 質の高い生活を送り、より良いコードを書いていくためには運動、筋トレが欠かせないことは皆さんご存知だと
Abstract アプリケーション開発の現場では価値検証のためにスピーディな開発が求められています。 しかし、フロントエンドとバックエンドの開発が同時に行われるケースでは、フロントエンドの開発を行うためにバックエンドの API が必要になる場合があります。 こういったケースに対してフロント側では、一時的にモックを置く、バックエンドは最初はないものとし後で組み込むことで開発をすることもできますが、通信部分の処理まで確かめられず実際の動きを確認するまでが後回しになってしまいます。またモックを組み込むコストもあります。 一方のバックエンド側では、API を早く用意しなければならないものの、1個1個しっかり作っていては時間がかかり、フロントエンド側の開発で必要なタイミングでタイムリーに実装をしていくことが難しいです。 これらの問題に対し、プロジェクトの開始からそれぞれのエンジニアがフルパワーを発揮
Abstract 本セッションでは、形式手法 (formal methods) を用いた分散システムの設計および実装について解説します。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。受講対象は予備知識を持たない初心者を想定しており、具体例を通して形式手法の基本的なアイデアを知ることを目標とします。 分散システムのメリットとデメリット 近年、複数のコンポーネントが非同期的に連携して動作する分散システムは決して珍しいものではなくなりました。正しく設計された分散システムは、集中システムとは比較にならないフレキシビリティとスケーラビリティを発揮します。人気 OSS の中にも分散型の設計を取るものは多数見られ、一昔前のように一部の専門家だけに任せておくだけでなく、すべてのエンジニアにとって一種の基礎教養になってい
Abstract AIブームと言われて久しい昨今ですが、ソフトウェア開発の現場でも、実際に仕事で機械学習を扱う機会というのは徐々に増えていくだろうと思います。 一般的にソフトウェア開発プロジェクトは不確実性にいかに対処するか、という観点を強く意識してマネージメントしていくことになるわけですが、機械学習プロジェクトでは大きく考えて2つ不確実性がとても高いポイントがあります。 1つは、アルゴリズムを選定するまでの工程。 もう1つは、本来完了の定義を明確に定めたうえで実施されるべきテスト工程です。 特に、テスト工程における不確実性というのは一般的なソフトウェア開発プロジェクトと大きく異なる部分であり、機械学習プロジェクトを仕事として進めるために最も注意が必要な部分です。 わたしたちは、Mackerelというプロダクトに「ロール内異常検知」という機械学習技術を用いた機能を実装しました。 そこでのマ
Abstract 交通需要予測、タクシー迎車など交通システムをITで最適化することは、現在開発が盛んな領域です。 交通システムのIT化にあたっては、車輌位置推定問題や最短経路問題を解くアルゴリズムが必要になります。 ・ノイズの多い GPS のデータから、その時どこの道路の上を走っているか、どのように推定しましょうか? ・目的地点から目標地点へ移動したいとき、どのように最小の時間や距離を見つけ、またどのようにその経路を見つけましょうか? 本セッションでは、これら交通システムの最適化を実現するITサービスで必要となるアルゴリズムのうち、車輌位置推定問題や最短経路問題をご紹介します。それに加え、論文に紹介されていない、実装上の工夫やチューニングをお話します。 またサービスを実現する上で、実際にどのようにクラウドサービスを利用し、位置情報というビッグデータの分析基盤を構築したかご紹介いたします。
Abstract 日本は今年5月に令和元年を迎えました。 元号をデータとして保存していたシステムは改元を乗り越えられたのでしょうか。 新元号が改元のわずか1ヶ月前に発表されるという事態に、システム業界が騒然となっていたことは記憶に新しいかと思います。 この前例から、元号をデータで保存すべきではないと、我々は学ぶことができます。 この学びは当たり前のことで既知のように思われるかもしれません。 しかし、例えば5年前の時点において、サマータイムが日本に導入される可能性を想定できたエンジニアが一体何人いるのでしょうか? 時間・時刻・日時の概念は現実に存在し、覆すことが不可能な絶対の仕様なのです。 タイムゾーン?サマータイム? うっ、頭が…! 詳細 サブスクリプションと呼ばれる定期購読型のサービスが普及してきました。 Adobe Creative Cloud、Google Drive、iCloud、
Abstract 「AI幻滅期」と言われている昨今ですが、ブームが落ち着く一方で私たちITエンジニアの実業では機械学習技術の導入や導入検討が増えており、また堅実な事業活用も進んでいると感じます。 本セッションでは、話者が約2年半に渡って機械学習とデータサイエンスの基盤に携わってきた経験から、機械学習基盤で必要となったセキュリティとエクスペリエンスについてお話しします。 また直近2〜3年に渡る機械学習プロジェクトの増加と50名超から成る機械学習研究者・データサイエンティスト・DevOps/ML Opsの混合組織が成長する中でいかに軽量に研究開発や検証を行い、セキュリティを保ち、エクスペリエンスを向上させるか、これらを念頭に置いた基盤の変遷についてもご紹介します。 【機械学習基盤のセキュリティ】 機械学習基盤ではカメラ映像や位置情報といったデータを一般的なWebアプリケーションとは異なったシス
Abstract SVGやCanvasなどのWeb標準技術の拡充により、Webページ上にインタラクティブなグラフやチャートを描画することは身近になりましたが、データの特性や表現手法、描画プロセスなどへの理解が深まれば、より効率的・効果的な可視化表現が可能になります。 本セッションでは、ブラウザ上でデータを可視化するにあたって配慮すべきポイントを紹介します。 現在ではデータ可視化のためのJavaScriptライブラリが数多く存在し、それらはとても強力で便利なものです。しかし、手元のデータに合ったものを選べなければ、データの直感的な理解に役立たないばかりか、ブラウザに不必要に負荷をかける結果にもなりえます。効果的な可視化を実現するには、データの特性やサイズ、データの前処理、ライブラリの特徴、ブラウザがレンダリングを行うタイミングやイベントハンドリングなど、様々な事柄に配慮しなくてはなりません。
Abstract 「インフラをコードで管理できる!ごっつ幸せ!」 パブリッククラウドの普及により、インフラをコードで構築する、いわゆる「Infrastructure as Code」は一般的になってきました。うまく使いこなせば、インフラ構築からアプリケーションデプロイの生産性を爆上げできますが、その効果の反面、副作用が大きいのも事実です。 「コンソールなら一瞬で終わるのに、コードだと、どこが変わるかわからん」 「あれ、applyしたらクラスタ全部なくなった…なんでやねん」 「こわい、コードでやるのこわい。もう手で変更して良いよね?リリース迫ってるねん!!」 IaCは突き詰めすぎると、逆に融通が利かなくなってしまいがちです。 元々IaCでやりたかったことは何か?これは本当に幸せな未来なのか?このセッションが、皆さんの日々のシステム運用のヒントになれば幸いです。 【話すこと】 AWS環境におけ
Abstract サービスメッシュについて理解し、適切に活用ができるようになるためのセッションです。 サービスメッシュというアイディアが業界に登場し、その技術を活用した事例が共有され、近年注目が高まっています。これからサービスメッシュを導入したい、という組織も多いのではないでしょうか。しかし、新しい技術を理解し適切に利用することは一般に学習コストが高く、サービスメッシュも例外ではありません。 このセッションでは、サービスメッシュというアイディアが登場した背景や、解決しようとしている技術的課題、各コンポーネントの技術的詳細、いつかの特色ある導入事例を解説する予定です。特に、急速に普及が始まった技術によくある「業界での銀の弾丸化」を防ぐべく、「サービスメッシュを導入しない判断ができる知識を得る」という点にも重点を置きます。 このセッションは、聴者が次のような情報・知識を得ることができる内容にな
Abstract HyperLogLog (以下HLL)は、与えられたデータセットのdistinct element countを省メモリで高速に推定するアルゴリズムです。 RedisやPrestoなど様々なミドルウェアにHLLを利用するための機能が組み込みで用意されていますし、現在のビッグデータ解析において無くてはならないものとなっています。 HLLではデータセットをsketchとよばれる省メモリな表現に変換したのち、そこに保存された値を集計して推定値を算出しますが、このsketchには興味深い特徴があります。 まず、異なるデータセットに対して作られたそれぞれのsketchをmergeして、unionのdistinct countを推定することができます。 そして、HLL sketchの構築と推定値の算出は独立したステップであるため、推定に影響を与えることなくsketchのバイナリ表現を
Abstract 株式会社Kyashは、ウォレットアプリ「Kyash」の開発・提供を通して得た知見を活かし、国際ブランドVISAのカード発行、決済処理、管理機能をAPIとして企業向けに提供する「Kyash Direct」をローンチしました。 「Kyash Direct」では、「Kyash」の、主にサーバーサイド開発におけるノウハウと反省を最大限活かすべく、敢えてスクラッチ開発することを選択しました。 セッションでは、主に設計に関するトピックを軸に、「Kyash Direct」がどのようなアーキテクチャにもとづいて構築されているのかについて、実体験(良かったこと・辛かったこと)を交えてお伝えしたいと考えています。 取り上げるトピックは以下のようなものになる予定です。 求めていたもの・困っていたこと 実践したこと(@golang/AWS) DDD Clean Architecture Micr
Abstract インデックスが使われているか実行計画を調べる事はできる。しかし、インデックスが使われているにも関わらず遅いSQLがあった場合にチューニング方法がわからないという悩みはありませんか。 私が実際に経験してきたいくつかの問題のSQLを例にしてどのように解決するのか話をします。 RDBMSはSQLでどのようにデータを抽出しているのかをrubyの擬似コードを使って解説します。※rubyの知識は無くても構いません このセッションが終わった時に下記の状態になっている事がこのセッションのゴールです。 ・インデックス構造の理解ができる ・実行計画を見てデータを取得するアクセスパスのイメージが想像できる ・SQLのボトルネックとなる条件を判別し、代替え案を模索できる この話には次のようなことが出てきます。 ・オプティマイザ ・実行計画 ・統計情報 ・クラスタインデックスとセカンダリインデック
Abstract 創業20年を迎えたある会社に、1台のLinuxサーバに Redmine, Subversion, Git, Nopaste, IRCd, Gyazo 等々の開発支援ツールが同居し、大変便利に使われているものがありました。元は2011年にSVNリポジトリサーバーとして立てられたものでしたが、便利なツールをいろいろ(主に自分が)インストールしていった結果、お世辞にもモダンとはいえない構成のまま令和時代を迎えたレガシーです。 現代において、このような開発支援サーバを自前で維持するメリットは少なく、将来的には外部のサービスを利用することで引退させるべきでしょう。とはいえ会社の資産でもあるTB級のリポジトリや、5年以上続くサービスのユーザサポートチケット、ドキュメントを背負い込んだ既存サーバをいきなり廃止することはできません。 このトークでは、どこの会社にもある(ありますよね?)、
Abstract データベースはアプリケーションよりも寿命が長くリファクタリングもしにくいため、初期の設計に失敗するとのちの開発スピードに大きな影響を及ぼします。 しかし、B2B SaaSの場合は馴染みのない業務に関するシステムを作ることが多く、どこまでデータベースの設計をすれば充分なのか判断しづらいのではないでしょうか。 このセッションでは吉祥寺.pmで発表した「はじめてのB2B SaaSデータモデリング」の内容を掘り下げ、開発したB2B SaaSのα版を0から作り直した私の経験を例に出しながら以下についてお話します。 ドメインの深掘りができているかのチェック方法 (例)Null許可カラム、イベントとリソースの区別、外部キーから考えるデータの登録順 SaaS特有のデータモデリングの仕方 (例)マルチテナントアーキテクチャ、データの所有者 ドメイン知識の豊富なメンバーから情報を引き出す方法
次のページ
このページを最初にブックマークしてみませんか?
『builderscon 2024』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く