はてなブックマーク

まとめ async/await 構文は、Promise で書ける処理のうち特定のケースしか表現できない 特定のケースとは、ある非同期処理の前処理と後処理がそれぞれ 1 個ずつの場合のみである async/await 構文は初心者に非同期処理を導入する際に適しているが、非同期処理を逐次処理として書けるという幻想を与えるので、どこかで知識をアップデートする機会を設けるべきである この記事はなに？ 少しバズったのでまとめておこうかと。 「async/await があれば Promise なんて難しいものは要らない！」とか言ってるウブな子に、複数の API に並列にリクエストを投げて一つ以上成功した時だけ先に進む、みたいな問題を与えて愛でてみたい。— Yuta Okamoto (@okapies) 2020年12月11日 async/await は Promise のネストを手続き的なコードに見え

先日はシンガポール政府が開発した接触者追跡技術 "BlueTrace" について調べたが、今日は引き続き、Apple と Google が共同開発中としている Contact Tracing API について調べてみる。 そもそも、現状では iOS 上での制限により実用レベルで Bluetooth ベースの接触者追跡技術を実装するのは難しく、Apple の対応待ちという状況であるため、事実上、本 API が本命になると予想する。 www.apple.com www.blog.google アーキテクチャの概要については下記のツイートに掲載されている図が分かりやすいので、この記事ではもう少し細かいところを見ていくことにする。読み違えている部分があるかもしれないのでツッコミ歓迎。 Google + Apple が提供する、COVID-19 の Contact Tracing（コンタクトトレーシ

自作キーボード向けのオープンソースファームウェアの QMK Firmware は、LT(layer, kc) という特殊なキーコードを用意している。これを使うと、通常のキーコード（A とか）とレイヤー切り替えキーを同じキーに同時に割り当てることができるので、例えば、レイヤー切替の LOWER キーと「無変換」を一つのキーに収容するといったことができる。 ところが、この LT キーを押してから離す操作を非常に素早く行うと、レイヤーの切り替えがうまく行われずに誤入力が発生する問題がある。これはキーマップ (keymaps) の設定ではどうにもならないが、代わりに keymap.c の process_record_user 関数に手を加えることで解決できる。 この方法はあぷろさんに教えて頂いたのだが、知見を共有する意味で記事として残しておくことにしたい。具体的な実装例は本文の最後に掲載する。

今朝、こういう話を見かけた。 tzdataの間違い見つけたかも。 1887年以前の日本時間を +09:18:59、東経にして139度44分40.9秒としていて日本の歴史上こんな位置を基準にしていたことはないんだけど、この地点は東京天文台だったんだ。麻布台。 1887年まで基準だったのは東京天「守」台。皇居。+09:19:01 が正しい。— 投機的実行《アクセラレーション・ブースト》 (@yuba) 2018年10月11日 tzdata (tz database) というのは、世界各地域の標準時（タイムゾーン）の情報を収録したデータファイルで、様々な OS やライブラリで利用されている。例えば、Unix 系 OS で環境変数 TZ に適当な地域を設定すると date コマンドが適切な時刻を表示してくれるのは、この tzdata を使っているおかげ。 $ TZ=UTC date 2018年 1

この記事は自作キーボード Advent Calendar 2017の4日目です。前日は、@mt_mukko さんの「Nyquistを組み立てた話。Pro Microもげもあるよ！」でした（この記事は ThinkPad T460s で書いてます）。 Let's Split を組み立てた @matsPod さんの Group Buy に参加して Let's Split のパーツを購入したものの、転職やら何やらでバタバタしていてようやく組み上げたのが 10 月…。 皆に遅れること数ヶ月、ようやく僕の #レツプリ が完成したでござる。RGB どうしようかと思ったけど、やっぱつけると綺麗ね。 pic.twitter.com/uGCEM2Zh1A— Yuta Okamoto (@okapies) 2017年10月21日 #レツプリ 組み立て中動画（ブログ用。 pic.twitter.com/Khtje

この記事は Scala Advent Calendar 2017 の三日目です。前回は @poad1010 さんの「JupyterでScala」でした。 Akka HTTP を使って REST API を叩いてみようと思って色々と試したメモ。基本的には下記のドキュメントを読めば良いのだけど、サーバ側はともかくクライアント側の使い方について日本語で書かれたものが少ないので、使う側の目線での話を書き残しておくのも良いでしょうという感じ。ここでは、最も簡単な API である Request-Level Client-Side API について話をする。 doc.akka.io 少し難しい話になるが、簡単に使いたい場合は、記事の最後にラッパーコードを貼っておくのでコピペして使ってもらうと良いかと思う。 HTTP ボディを取得する ドキュメントを見ると、初っ端からこういう感じで脅されるので嫌な予感が

Disconnect という英単語を「切断」と訳すのは（特に IT エンジニアリングの文脈では）誤解の余地が大きいので良くないのではないか、という話。 Connect は「結線」しない Connect という英単語は、一般的に「繋ぐ」とか「接続する」と訳されることが多いと思う。connect は、元々「互いに結びつける」という意味のラテン語から来ていて、初期には「物理的に一つにする」という意味で使われていたようだ。しかし今日では: connect Bring together or into contact so that a real or notional link is established. Join together so as to provide access and communication. Link to a power or water supply. Put (

突然ですが、5月始めに出る「マストドン本」に寄稿させて頂くことになりました。後半の技術パートの導入として、Mastodon の技術的な基盤である OStatus の章を担当しています。 本書の執筆には、mstdn.jp のぬるかるさんや pawoo.net の中の人に加えて、界隈では誰でも名前を知ってるような面々が勢ぞろいで、まさに Mastodon オールスターといった趣であり、わし本当にこんな所に混ざっていいのか…。まぁ、ともかく現在予約受付中です、買ってね！ これがマストドンだ! 使い方からインスタンスの作り方まで (NextPublishing) 作者: マストドン研究会出版社/メーカー: インプレスR&D発売日: 2017/05/12メディア: オンデマンド (ペーパーバック)この商品を含むブログ (1件) を見る 思い返すになかなかの急展開ですが、最初、降って湧いた Masto

海外の自作キーボード (DIY keyboard) コミュニティで生まれ、近年は日本でもすっかり有名になった ErgoDox ですが、その ErgoDox と並ぶ人気を誇る "The Planck Keyboard" の DIY キットを手に入れて組み立ててみました。 どれくらい人気かというと、現在募集中の共同購入（後述）には開始から一週間で世界中から 1,700 件を超える応募があり、新しいカスタムキーキャップのメニューには大抵 Planck 専用セットが用意されるくらい。 過去の記事でも紹介してきた通り、僕は ErgoDox EZ キーボードを使っています。ErgoDox には大変満足していますが、一方でそれなりに細かい不満があるのも確かです。 ただ、普段使いの道具に対するこだわりというものは、突き詰めていくと極めて個人的なモノにならざるを得ません。必然的に、自分が真に求めるものと、汎

この記事は、技術翻訳 Advent Calendar 2016 の15日目です（枠が空いてたので勝手にお邪魔してます）。前回（6日目）は、id:msyksphinz さんの「個人が趣味で技術書を翻訳するという意義について」でした。 今回ご紹介するのは、昨年末に公開された Kris Jenkins さん (@krisajenkins) の "What Is Functional Programming?" です。日本語訳の公開については著者から承諾済みです。また、London Functional Programmers meetup での同タイトルの講演動画が公開されています。 関数型プログラミングの考え方は、世間ではどうも小難しい話だと思われている節があります。その理由の一つに、議論の抽象度が（比較的）高いことが挙げられるでしょう。例えば、以前このブログで紹介した「なぜ関数プログラミング

この記事は ErgoDox Advent Calendar 2016 の３日目です。今日は、皆さんのご家庭でもできる「簡単、Cherry スイッチの分解手順！」をご紹介したいと思います。 近況 突然の ErgoDox ブームから早９か月、皆さんのキーボードライフはいかがでしょうか？ 僕もブームに乗って、当時からこんな記事を書いて情報収集やパーツ集めに勤しんでおります。 okapies.hateblo.jp あと、meetup で LT もやりましたね。 https://eventdots.jp/report/20160610_588645eventdots.jp 正直なところ、使いこなしに情熱と労力が必要な部類のガジェットですし、商業ベースの分割キーボードが登場し始めた昨今、あえてコレを選ぶ理由も少しずつ減ってきている気もしますが、しかし、我が家にやって来た ErgoDox 君は今日も元気

先日買った ErgoDox EZ が届いたのでカスタマイズ中。GW に発注して一週間くらいで届いたので、かなり流通体制が整ってきている様子。 ergodox-ez.com いぢりがいがあるのは良いのだけれど、正直なところ「素人お断り」感がすごいですね*1。というわけで、調べたことをまとめていこうかと。随時更新予定。 ※記事中でリンクしているドキュメント類はかなり頻繁に場所が変わっているので、リンク切れの場合は頑張って探してください…。 ファームウェアのカスタマイズ 追記 (11/27): EZ 公式の GUI 設定ツールが登場しています。日本語キーの割り当てとかは部分的にしかサポートしてないっぽいですが…。 ErgoDox のキーマップを変更するには、本体ファームウェアの更新が必要。ファームウェアをカスタマイズするには、Massdrop の Ergodox Configurator を使う

だいぶ出遅れましたが、ScalaMatsuri 2016 の参加報告です。 scalamatsuri.org 発表者として 今回、CFP に応募して当選した「なぜリアクティブは重要か (Why Reactive Matters)」というタイトルで発表をさせていただきました。投票してくださった皆様、聞きにきてくださった皆様、ありがとうございます。 発表に使ったスライドは以下になります（発表は英語スライドでしたが日本語化しました）: なぜリアクティブは重要か #ScalaMatsuri from Yuta Okamoto www.slideshare.net あと、Togetter でまとめて頂いたツイートはこちら。 今回はプログラミングの話題に重点を置きつつ、〈リアクティブ・コンポーネント＋データフロー〉という構図が、非同期プログラムのコードから分散システムのアーキテクチャまで、様々なスケー

この記事は、Java Advent Calendar 2015 の 22 日目です。前日は、n_slender さんの「PlayFramework 2.4 Java Ebeanでのアプリ開発」でした。 今日の記事では、この半年くらいで仕様と実装が出てきている ReactiveSocket というプロトコル仕様についてお話したいと思います。 ReactiveSocket.io なぜ Java Advent Calendar でプロトコルの話を？ と訝しがっている方も多いと思いますが、基本的には以下の二つの理由です。 JEP 266 として JDK 9 に追加される予定の Reactive Streams と密接に関わっている Java 製のサーバサイド向けライブラリを多数 OSS 化している Netflix が中心になって仕様策定を行っており、参照実装も JVM 向けが中心 予定ではプロトコ

関数型プログラミング (functional programming) の利点を説く際によく持ち出されるのが、QuickCheck の開発者の一人である John Hughes が 1984 年に著した論文 "Why Functional Programming Matters" だ。「なぜ関数プログラミングは重要か」という題名で日本語訳もされているので、読んだことがある人も多いと思う。 要旨としては、冒頭の１章および２章で述べられている「関数型プログラミングが優れているのは、高階関数と遅延評価という、モジュール同士を貼り合わせる強力な『糊』を持っているからだ」という話がほぼ全てで、以降はそれを具体例に基づいて説明する構成になっている。ただ、その具体例として「数値計算アルゴリズム」やら「ゲーム用人工知能アルゴリズム」やらの話が延々と続くし、しかもコード例が Haskell の先祖にあたる

6月24日の JJUG ナイトセミナーで「Reactive Streams 入門」のタイトルで発表させて頂きました。最近話題の Reactive Programming、気がついたら一万人以上が署名している Reactive Manifesto、そして Java 9 で標準化という話が進んでいる Reactive Streams をまとめて俯瞰してみました、という感じの内容になっています。 かなり戦々恐々だったのですが、思いのほかご好評をいただきとてもとてもほっとしています。発表の機会を与えて下さった JJUG スタッフの皆様、会場をご提供頂いたオラクル様、発表を聴いてくださった参加者の方々、ありがとうございました。 発表でも触れましたが、"Reactive" という概念が何を指すかについては大きな混乱があり、様々な論者が異なる定義を提唱しているのが現状です。一方で、そうした定義の背景には

たいていのサイトで @okapies 名義です。 Mastodon: okapies (@okapies@fedibird.com) - Fedibird Twitter: Yuta Okamoto (@okapies) / Twitter GitHub: okapies (Yuta Okamoto) · GitHub LinkedIn: https://www.linkedin.com/in/yuta-okamoto-ba11882a/ はじめに NFT って何ですか？ ブロックチェーン上に記録された一意なトークン識別子をその保有者のアドレスと紐付ける情報、およびそれを状態変数として保持するスマートコントラクトのこと。 以上。 え、それだけ？ はい。 「デジタル資産に唯一無二性を付与するインターネット以来の革命」なんじゃないの？ これを読んでください: speakerdeck.com な

これは「関数型プログラマのための Rx 入門」の補足記事です（タイトル変えた）。 前編、後編とお送りしてきたこの記事だが、特に後編について「何を言ってるのか分からん」というコメントを何人かの方から頂いた。…なんというか、ごめんなさい。 繰り返しになるが、Rx を使う上で関数型プログラミングの知識は必ずしも必要ではないし、むしろ（関数型のコンセプトが基礎にあるのに関わらず）知らなくても使えるようになっている。ライブラリの作者たちは「過度な抽象化は害になる」ということを弁えているのだろう。 しかし、Rx と関数型プログラミングの関係を把握しておくと、非同期データストリームのビルディング・ブロックの作り方について大いに視野が広がるだろう。もし、貴方がこの記事の前提となる「関数型」のパラダイムに興味をお持ちなら、まずは「関数プログラミング実践入門」をお勧めしたい。 関数プログラミング実践入門 ──

前編では、Reactive Extensions (Rx) の機能を関数型プログラミングの視点で読み解いた。続いて後編では、前編で紹介した Rx が関数型的な機能を提供している背景、つまり Observable と他の一般的なコンテナの関係に対してスポットライトを当ててみたい。 あらかじめ断っておくと、本編の話題は、実際に Rx を使う上で理解している必要は（あまり）ない。とりあえず、 Observable は、List や Future と同じくモナドの一種である 以下の表に出てくるコンテナは、隣同士で互いによく似た（あるいは正反対の）性質を持っている: 単数 複数 同期 (pull) T/Try[T] Iterable[T] 非同期 (push) Future[T] Observable[T] …という話だけ記憶に留めてもらえば、ここで回れ右してもオーケー。とはいえ、興味のある人はこの

概要 『Observable は単なる非同期データストリームにおけるモナドのインスタンスだよ。何か問題でも？』 まともな概要 つまり、Reactive Extensions (Rx) って何だ？ ということでウェブをガサゴソと漁っていたところ、オンライン講義サービス Coursera の Principles of Reactive Programming に行き当たった。この講座では、Rx の主要開発者の一人である「双対おじさん」こと Erik Meijer 氏自らが一部の章を担当し、Rx の理論的側面を講義している。 この講座の大きな特徴は、Rx を（命令型プログラミングではなく）関数型プログラミング (FP) の側から解き明かしていくことにある。 こう書くと奇をてらっているように見えるかもしれないが、実際には Rx は FRP (Functional Reactive Program

この記事は Scala Advent Calendar 2014 の 15 日目です。昨日は id:qtamaki さんの”「関数プログラミング 珠玉のアルゴリズムデザイン」をScalaで実装してみる”でした。 今日は、先日に Tumblr が OSS 化を発表した Scala 製のノンブロッキング I/O (NIO) フレームワーク "Colossus" を紹介したい。”高性能なマイクロサービスを構築するためのフレームワーク”を謳っており、まだ OSS 化されて日が浅いものの Tumblr ではすでに production で使われているとされる。また、Colossus 自体がアクターフレームワーク Akka のアクターとして実装されており、それを使った独自のスレッドモデルを提供している点も興味深い。 Colossus Colossus: A New Service Framework

今年も開催される Scala Advent Calendar 2014 の 15 日目にエントリーしていて、ネタとしては先日 Tumblr が発表した "I/O and Microservice library for Scala" を謳う Colossus をやる予定なんだけど、前振りとして「なぜマイクロサービス化を進めるサービスは Scala を選ぶのか」という話をしてみるエントリ。ちなみに、Advent Calendar の前振りと書いたけど、とりあえず Scala をあまり知らない人向け。 そもそもマイクロサービスって何だっけ？ マイクロサービスへの移行と Scala なぜ Scala が選ばれるのか？ 1. JVM 言語である 2. Finagle の存在 性能 プログラミングモデル 運用ツールとの連携 3. 静的型付き言語である 余談 そもそもマイクロサービスって何だっけ？ こ

「非同期計算をモナドで合成し、依存関係に従ってパイプライン化する」というアイデアはいつ誰が提案したのか、というのを調べてみたけどよく分からなかった記録。網羅的な調べ方はしてないので、何か知ってる人がいたら教えてください。 明示的 vs. 暗黙的 id:xuwei さんに教えて頂いた Wikipedia の記事によると「まだ完了していない計算結果へのプロキシオブジェクト」というコンセプトが Future や Promise と名付けられたのは 1976〜1977 年頃らしい。 1976 年に出た Daniel P. Friedman と David Wise の論文や Peter Hibbard の論文で言及されていた Promise（あるいは Eventual）は明示的 (explicit) に使うものだった。つまり、Java の（Completable じゃない方の）Future のよう

一昨日くらいにホッテントリ入りしてた記事↓を見て、 風景から歩行者を消す手軽な方法（配電盤） Export["result.jpg", Image[Mean[Map[ImageData, Import["movie.mov", "ImageList"]]]]] このくらいのコードで済むなら Java/Scala でもすぐに書けるかも？ と思ってやってみた。 理想 ヤッター、こんなに簡単にできたよー＾＾ import opencv._ // ← ん？ System.loadLibrary(Core.NATIVE_LIBRARY_NAME) // ← んんん？？？ saveImage("result.jpg", loadVideo("movie.mov")(mean)) 現実 README.md: Isolator requires Java bindings for OpenCV. $ cu

TL でこんなのが流れてたので少し調べてみた。 Learn about the Reactive Streams initiative & how we're supporting a standard for asynch stream processing on the JVM http://t.co/5wUF0PjTBe— Twitter Engineering (@TwitterEng) 2014, 4月 17 Reactive Streams って？ Reactive Streams ”JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準の提案”（公式サイトより）。 ざっくり言うと、既にある JVM ベースの様々な非同期ストリーム処理フレームワーク実装の共通部分を括りだして API 化、SPI 化しようというもの。最終的には JSR での標準化を目指