つよつよエンジニアからは「ネットの技術記事より公式リファレンスを読め!」って言われるけど、公式リファレンスを見ても変な記号や英語がたくさん出てきて全然意味がわからない・・・という初心者Rubyプログラマのみなさんに向けて、公式リファレンスの読み方を丁寧に解説します。
QUIC とは QUIC は、今年 5 月に RFC 9000 や他いくつかの RFC によって標準化された、次世代のインターネットにおける通信プロトコルです。HTTP/3 では、この QUIC を下位層として使うことになっており、今後のより高速なインターネット通信において QUIC の占める役割は非常に大きなものとなるでしょう。 QUIC is now RFC 9000 | Fastly この記事では、QUIC による通信が始まる第一歩であるところの、Initial packet を Ruby で受けとってみることにします。 はじめに この記事内では、いくつかの外部の記事を参照しています。それらは QUIC の、ある時点での draft を参考に書いてあるものもありますが、この記事では RFC となった QUIC version 1 に対しての内容となります。 記事内の誤り、誤字脱字等は
parallelを使うとKenrel#forkやThreadを駆使するのと比べて簡単に並列処理を書くことができます。parallelは拙作のBestGems.orgによると、合計ダウンロード数で151位、デイリーダウンロード数は100位前後で、現時点で非常にメジャーなGemとなっています。 この記事ではparallelの基本的な使い方と、実際に使ってみて感じた注意点をTipsとして整理したいと思います。 parallelはREADME.mdが親切に書かれています。 加えて主要な部分は500行程度の小さなGemです。 利用する場合は公式のドキュメントとソースコードを確認されることをおすすめします。 前提ソフトウェア ソフトウェア バージョン 備考 ruby 2.5.1 - parallel 1.12.1 - rails 5.0 - 使い方 インストール gem install paralle
ある問題で、Redis からデータを読んで、中身に書いてあることをやって(sleepするとか)というものがあった。その発展系では、並列でやるようにしろと言うものだった。だいたい処理を並列にさせたい時は、parallel gem を使っている。とっても簡単で、仕事でもよく使っている。 任意のスレッド数、またはプロセス数はを指定して、#map #each などのメソッドを使ってブロックで囲むと、内側が並列で動作するようになる。本当に簡単なのでおすすめ。 require 'parallel' Parallel.each((1..12), in_threads: 3) do |i| # Parallel.each((1..12), in_processes: 3) do |i| puts "[Worker: #{Parallel.worker_number}] #{i}" end $ ruby p
ParallelというGemで並列処理を試してみました。 github.com インストール インストールはBundlerを使いました。 source "https://rubygems.org" gem "parallel" 使い方 使い方は下の通りです。 1,2,3を引数にしたブロックを並列に実行してくれます。 require 'parallel' puts 'Start' Parallel.each([1, 2, 3]) do |i| puts i end puts 'End' 結果は下の通りです。 並列なことを確かめるために、下のようにiが2の時に1秒待つようにしてみました。 require 'parallel' puts 'Start' Parallel.each([1, 2, 3]) do |i| sleep 1 if i == 2 puts i end puts 'End'
mixiグループアドベントカレンダー2016 1日目です。 今回は、自分が今まで利用したRubyでの並列処理を書くためのgemとか知見を紹介します。 機運 先日のRubyKaigi 2016で、Ruby3ではGuildという新しい並列処理のモデル*1が、導入されるというセッションがあったり、concurrent-rubyというgemの開発が流行り初めて居たりと、Ruby界隈でも何となく並列処理がブームきているように感じます。 マルチプロセス/スレッド しかしRubyで並列処理するのは言語の仕様としてそれなりに制限があり、他の言語のようにThreadをバンバン立ててマルチコアで計算!爆速化!!みたいなのは難しいです。 というのも、Ruby1.9からネイティブスレッドは導入されたものの多くのC拡張を使ったgemのスレッドセーフ性が問題となるため、GIL(Global interpreter l
上記URLにやり方が記載されているのですが、Rubyに関してはSDKが存在しないため自前で実装する必要があります。 https://github.com/fschuindt/firebase_id_token こういうgemもあるのですが、Firebaseが公開している証明書をキャッシュするためだけにRedisが必要なので、Redisを使っていないプロジェクトではこのためだけにRedisを用意するのは過剰です。 JWTの検証に関してはこの記事が非常に参考になりますが、証明書のキャッシュ部分だけはRials.cacheに依存していてイマイチ。またHTTPクライアントはFaradayを利用したかったこともありFaradayを使ってなんとかいい感じにできないかと考えていたところ、いい感じのFaraday Middlewareがあったのでその紹介をします(本当はJWTの検証部分も解説しようと思った
ID トークンを確認する | Firebase にあるように、Fireabse Authentication によって発行された ID トークンを正しく検証することにより、そのユーザの user_id を確認することができます。 Firebase Admin SDK が提供されていればそれを使うことで簡単に検証できるのですが、Ruby 版は提供されていないので Rails から使いたい場合などは自分で検証処理を書くことになります。 検証すべき内容は ID トークンを確認する | Firebase に書いてあるのでそれに沿って書いていきます。 要: JWT gem # @see https://firebase.google.com/docs/auth/admin/verify-id-tokens?hl=ja # # Usage: # validator = FirebaseAuth::To
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Rubyで Firebase で認証を行う実装のサンプルが見当たらなかったので業務で実装したものをまとめてみました。RubyでのFirebaseの活用例が増えれば幸いです。 Firebaseでの認証 Firebase Auth REST API を利用してユーザー登録、認証、セッショントークンの管理を行います。 Firebaseの uid からJWTを生成し、クライアントとの認証はJWTを介して行います。 Firebase Auth REST API のラッパーとして firebase-auth が便利だったので利用しています。 なお、Firebaseを利用した認証はセッションレスで常にJWTを介してリクエストを処理します。 トークンの有効期限が切れる毎に認証操作が発生するのを防ぐためにはクライアント側で発行されたJWTを保持する必要があります。 Firebaseのセッショントークンの有効
概要 Java や Node などは Firebase Admin SDK を使用することで、Firebase Authentication の操作をサーバーサイドで行うことが出来ますが、ruby には gem が用意されていません。 そのため、google-apis のライブラリを利用する必要があります。 その使い方のメモです。 利用可能なAPI github のレポジトリ の generated/google-apis-identitytoolkit_v3 にライブラリのソースコードが配置してあります。(v3 部分が変わっているかもしれません) https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google-apis-identitytoolkit_v3 [lib/google/apis
こんにちは! SmartHRエンジニアの @tei-k です。 SmartHR ではインフラに AWS の Elastic Beanstalk (以降 EB ) を使っています。 Rails アプリですので、去年までは Ruby Platform 上で動いたのですが、今年から Docker Platform へ切り替えました。 ここでは移行するまでの工夫をご紹介できればと思います。 EB の概要 EB は、インフラストラクチャーを意識せず簡単にアプリケーションの構築、デプロイ、Auto Scaling などをマネジードしてくれる PaaS となります。 Ruby、Go など様々な言語や Docker にも対応しているため、すべての言語のアプリを EB 上で動かせるでしょう! 詳細は公式ドキュメントご参考下さい。 移行の背景 Ruby Platform には以下の制限や要望がありました。 最
Extended outer memory module for my poor native memory. Posts: 2026/01/06 前回記事から4年が経過しました、現状報告 2022/02/13 クラビスの CTO になりました 2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った 2020/09/13 ISUCON10 の予選を 7 位で通過した 2019/12/01 Puma の内部構造やアーキテクチャを追う 2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む 2019/04/29 InnoDB の B+Tree Index について 2019/04/29 InnoDB における index page のデータ構造 2019/04/28 InnoDB はどうやってファイルにデータを保持するのか
RubyでFirestoreからデータを取得したり追加したり 今回は、RubyでFirestoreからデータを取得する際のクエリ発行してくれるコードやデータを追加するコードに関してまとめます。 Firestoreとは Firebaseが用意しているNo SQLのクラウドデータベースです。 用語 Firestoreにおける用語はとりあえず、下記の3つを知っておけば大丈夫だと思います。 Cloud Firestore データモデル コレクション データ(ドキュメント)を格納する大枠。FirebaseコンソールのサイドバーにあるCloud Firestoreをクリックすると、画面の1番左にあるのがコレクションになる。1つのコレクションに、それに関するデータ(ドキュメント)が保存されていく。 ドキュメント コレクションに格納されていくデータ。データは一意のドキュメントIDというもので管理されており
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
Thread(スレッド)とは? Thread(スレッド)とはプログラムの一連の処理のまとまりのことです。 複数の処理の流れ(スレッド)を持つプログラムをマルチスレッドのプログラムと呼び、複数の処理を並行して実行させるプログラミングのことを並行(concurrent)プログラミングと呼びます。 RubyのThreadクラスはこの並行(concurrent)プログラミングを実現するために使用されます。 Rubyでマルチスレッドを作成する。 プログラム開始時に生成されるスレッドはメインスレッド、現在実行中のスレッドはカレントスレッドと呼ばれます。 RubyではThread#mainを用いる事でメインスレッドを確認できます。 また、Thread#listでプログラム上に存在するスレッドが配列で表示されます。
この記事では、並列処理に関する入門的知識を解説する。 さらに、Rubyで開発されている新しい並列実行単位Ractorにも言及する。 まず、この話題をする上で混同しがちな用語についてまとめる。 並列処理(parallel)と並行処理(concurrent)について 並列処理 では、ある瞬間に複数の処理が同時に走る。 並行処理 では、複数の処理を時分割で順に処理する。並列処理とは異なり、ある瞬間に同時に走る処理は1つだけ。 ある複数の処理が実行されているタイミングを時系列で示すと、下図のようなイメージになる。 (青い線がある部分のみ処理が実行される) この記事では並列処理の動作について扱うが、並列処理のコードを書いても結局並行処理のように動いている場合もあることには注意。 (例えば、1コアのCPUでは2つ以上の処理を並列に動作させることはできない、など。) この辺りはOSやVMなどが良い感じに
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く