AtCoder で水色になった (https://atcoder.jp/users/bouzuya/) 。 AtCoder Beginner Contest 199（Sponsored by Panasonic）で Highest を 1205 (+55) に更新して水色になった。 長かった……。 2019-03-30 からはじめて 2021-04-24 でようやく水色になった。丸 2 年かかった。 2 年の間でたくさんの問題を解いた。 Rust で 1221 AC で Rust の Language Owners の 6th に入るくらいだ (https://kenkoooo.com/atcoder/#/lang) 。これは 1221 問を解いていて Rust を使って解いた問題数で 6 位ということ。以前は PureScript を使って解いていたので JavaScript でも 13

Kyoto.js #11 で WHATWG Streams のことを話した。 『 WHATWG Streams をためした (HTML) 』 全体的な感想みたいの Kyoto.js #11 の connpass に資料はまとまっている。 どの発表もいろんな方向で面白い。JavaScript は括りにならないんだなって感じる。あとは食べながら飲みながら楽にやる感じは良い。 残念なのはすこし質問が少ない点。質問しづらい発表が多いのだろうか。……とは書いてみたものの KFUG など他の勉強会でもそんなに質問はされていないか……。 個人的に興味のあった発表 個人的な関心から言えば LT の generator と Cycle.js の Router に興味がある。 generator は以前にためした (2016-06-21) ことを書いたのだけど、結局あまり活かせてないから。 Cycle.js

RALLY がプランを改定した 。 前置き。ぼくは RALLY の開発者だが、ここはぼくの私的な blog だ。だから、ここではその所属とは関係なく、あくまで私的な意見を書く。 この改定を実質的な値上げだと感じる。こう書くと「値上げなんてひどい」と感じるかもしれない。あるいは「うまく収益が上がらなかったのかな」と考えるかもしれない。感想はそれぞれだと思う。実態がどうなのかを書くつもりはないし、ぼくの判断でそれを書くことはできない。先に書いたとおり、ぼくは開発者だ。ぼくは利害関係者だ。だからといって、ぼくはここで値上げの理由や言い訳などを書くつもりはない。ぼくがここで書きたいのは「お金を払う」ことへのぼくの見方についてだ。 結論から書こう。ぼくは「お金を払う」ことを投票だと思っている。何を生かし、何を殺すのかという投票だ。生きるのに必要なだけの票が集まれば生き残る。そうでなければ死ぬ。投票し

bouzuya/bbn-cycle で cyclejs/cyclejs 7.0.0 を試している。まだ途中だけど、現状での印象を書く。 v7 の変化としては次のような点が挙げられる。 JavaScript -> TypeScript RxJS -> xstream virtual-dom -> snabbdom TypeScript への変化は個人的には嬉しいのだけど、Cycle.js が TypeScript 化されてもほとんど影響がない。まず Cycle.js の API を直接的に使う場面はほとんどない。ぼくの認識では message 基盤の提供や event flow の制御をしているだけだからだ。それに Cycle.js の API は TypeScript 向きじゃない。Sources なども { [driverName: string]: any; } 程度にしか、型の補助を

@hiroqn が書いた『実例とともに学ぶECMAScript 2015 〜Generator〜 – NET BIZ DIV. TECH BLOG 』を TypeScript で写経して Generator について学んだ。 関連 Tweet は次のとおり。 良記事 / “実例とともに学ぶECMAScript 2015 〜Generator〜 – NET BIZ DIV. TECH BLOG” https://t.co/UUPy4Byahe— bouzuya (@bouzuya) 2016年6月17日 https://t.co/o1QzLNXVzZ を写経 & 問題を解いた。TypeScript だと問題のある記述がぱらぱらとあった。ぼくの解答は↓。https://t.co/srBiykQeOG— bouzuya (@bouzuya) 2016年6月19日 結果の Gist は https

bouzuya/beater 0.4.1 をつくった。 bouzuya/beater#7 で Node.js v4 で動かないという Issue が来たので対応した。次のように version を上げた。 bouzuya/beater -> 0.4.1 bouzuya/beater-cli -> 0.2.4 bouzuya/beater-cli-reporter -> 0.4.2 bouzuya/beater-html-reporter -> 0.1.1 bouzuya/beater-reporter -> 0.3.0 実装としては TypeScript -> Babel の多段変換にした。以前この多段変換をやめたという記事を 2016-03-15 に書いた。今回はその逆だ。以前より TypeScript の経験値が上がったからか、心の余裕があったからか、逆に多段変換を選択した。 Type

2016-03-11 に bouzuya/rally-rxjs へ適用した TypeScript -> Babel の多段構成の回避方法を書く。具体的には、型定義として ES2015 (ES6) を使いながら target を es5 にすることで回避した。当該 commit は bouzuya/rally-rxjs#47ff4ca6d5c673e14275f3fa5bf7579d08b71465 。 2016-03-14 に書いたとおり、ぼくは typescript & babel 構成で苦労していた。 こうなった理由は TypeScript にある。 TypeScript の compiler option を target: es5 にすると、Promise の型定義が見つからず compile できない TypeScript の compiler option を target:

bouzuya/beater をつくった。bouzuya's eater で beater 。bouzuya 版 yosuke-furukawa/eater だ。eater のことは 2016-06-04 に書いた。 beater で書かれた test code は次のような雰囲気だ。 import * as assert from 'power-assert'; import { test, fixture } from 'beater'; test('simple test', () => { assert(1 === 1); }); test('async test', () => { return new Promise(resolve => { assert(2 === 2); resolve(); }); }); const before = () => 3; // setup

hubot-scripts ga.jsをつくった。ga.jsはGoogle Analyticsの結果を取得するHubotスクリプト。 困ったこととか得た知識とかを軽く書いておく。 Google AnalyticsのAPIを呼び出すのに手こずった。いろいろポイントがあるんだけど、順番に書く。 ライブラリ。Google APIはNode.js向けにはalpha版としつつもクライアントライブラリが提供されている。ただ、サンプルは充実していないし、ドキュメントを読むか、慣れないと分かりづらい。 Google APIの呼び方。今回は次のような感じ。 Google Developers Consoleでプロジェクトを作る(課金の単位。無料枠で十分使える) API & Auth > APIs でAPIを有効にする API & Auth > Credentials でOAuth認証情報を得る Google

hubot-help-json をつくった。1 日 1 Hubot スクリプトの 109 日目。 hubot-help-json は Robot#helpCommands() を返すルーティングを定義する Hubot スクリプト。 Twitter のタイムラインで「コマンドの補完ができないのがつらい」というのが流れていた。そもそも、「 Hubot のコマンド」という考えかた自体が本質的にどうなんだというのはあるんだけど、実際問題、共有 Terminal として Hubot を使う人が多いのは事実だと思うし、bash / zsh に比べて補完がなくてつらいよねというのは分かる。結局、クライアント次第ではあるんだけど、実現できるように Robot#helpCommands() (hubot help で出ているアレ) を返す API を定義したらいいんじゃないの、ってのがこの Hubot スク

元同僚の結婚式用の動画に映りにいった。また hubot-iroiro をつくった。1 日 1 Hubot スクリプトの 102 日目。 元同僚が結婚するらしく式で使うための動画を撮影したいらしい。それを聞かされたのが数日前で「ひどく無計画だ」と思ったが、きっといろいろと事情もあるだろうと、諦めて、仕事終わりに大阪に向かった。 事前に何か準備が必要かを聞いたら何も要らないと言われたので、一発ネタ的に写真か何かを差し込まれるだけかなと思っていたのだけど、そんなことはなくて、現地で「 AKB48 のフォーチュン・クッキーのサビを踊れ」と要求された。「事前に言ったら来ないと思った」だそうで。分からないでもないが、他の方法はなかったのか、と。 適当に撮って、飯を食って、解散した。 真面目にダンスとか中学校？小学校？ぶりじゃないかな。手と足とを同時に動かせないのな。世間のアイドル様はすごいね。 さて、

hubot-qr をつくった。1 日 1 Hubot スクリプトの 100 日目。 hubot-qr は指定したキーワードから QR コードをつくって返す Hubot スクリプト。 あと Hubot 2.9.0 および 2.9.1 が出ました。 minor version なのに互換性がかなりなくなっている。具体的に、大きい部分で言うと、 hubot --create の削除。今後は generator-hubot を使う。 src/scripts の削除。今後は外部パッケージを使う。 という変更が入っている。 ぼくの愛用している hubot ping は標準に添付されなくなった。そんな互換性を切るくらいならまず coffee-script@1.6.3 を coffee-script@1.8.x にしてほしいんだけど。 で、さらにまずいことには、 generator-hubot がまともに

hubot-ping をつくった。1 日 1 Hubot スクリプトの 89 日目。 hubot-ping は外部からの ping に応答するための URL を提供する Hubot スクリプト。 これをつくった理由は、最近の Heroku にデプロイしている Hubot が idling するようになり、外部から ping を打つ必要が出てきて、そのための 200 OK を返す URL が必要になったから。 Heroku の idling 自体は以前から有名な問題で、Hubot を Heroku にデプロイした場合のあるあるのひとつと言っていい。従来の対応方法としては「環境変数 HEROKU_URL を設定する」のが正解だった。これは Hubot 本体が提供している Heroku の idling 問題への解決策である。この設定をすると 20 分ごとに Hubot が自分自身に ping

hubot-gravatar をつくった。1 日 1 Hubot スクリプトの 85 日目。 hubot-gravatar は指定した メールアドレスの gravatar 画像 URL を返す Hubot スクリプト。 アイデアが浮かばないとつらい。

hubot-coderwall をつくった。1 日 1 Hubot スクリプトの 82 日目。 hubot-coderwall は coderwall から指定したユーザーのプロフィール & バッジを表示する Hubot スクリプト。 coderwall の Profile API は非常にシンプルで拡張子を json に変えるだけ。トークンも要らなくて、非常に使いやすい API 。 つくるまえにもしかしてと思って調べたところ Hubot スクリプトは既にあって、公式の github/hubot-scripts (現在は org に移行中のため deprecated) にもあるし、bobwilliams/hubot-coderwall なんてのが coderwall から紹介されていたりもする。 そこで、今回は別 Hubot スクリプトの実験をかねてページングぽいインタフェースを試してみた

hubot-shutdown をつくった。1 日 1 Hubot スクリプトの 81 日目。 hubot-shutdown は Hubot をシャットダウンする Hubot スクリプト。 Hubot をシャットダウンする Hubot スクリプトとしては標準添付の ping.coffee に含まれる hubot die が有名 (あの去り際のセリフとかね) だろう。 だけど、hubot die はあんまり良くない。終了の方法が process.exit(0) でプロセスを殺してしまう。 brain.close() や adapter.close() をせずに一気に終了させてしまう。あんまりだ。 そこで Robot.shutdown() を呼び出す Hubot スクリプトを書いたのがこれ。というか、よく分からないのが、Robot.shutdown() が定義されているのに、それを呼ぶ手段がない

hubot-twada をつくった。1 日 1 Hubot スクリプトの 79 日目。 hubot-twada は「テスト書いてない」と言うと「お前それ @t_wada の前でも同じこと言えんの？」と返される Hubot スクリプト。 最近、RSpec をどんどん嫌いになっていて、テスト書きたくない病気にかかっている。見えない @t_wada の圧力で、テストを書くように意識するためにつくった。

hubot-mstr をつくった。1 日 1 Hubot スクリプトの 66 日目。 hubot-mstr は 飯テロ.in から画像を表示する Hubot スクリプト。 aozora0000/hubot-meshi に bomb をつけたいだけで、はじめは PR しようと思い、 fork したのだけど、いろいろ書き直したくなってこうなった。 できれば、 brain に書いたほうがいいのだろうけど、まあ 40 - 50 リクエストくらいだし、いいかなあと。 あと、ソードアート・オンラインを見終わった。まとめると、ネトゲに命かけてる廃人が主人公で、登場する女の子をほれさせる話だった。 もっと短く言い切るなら「 SAO は MMORPG というよりギャルゲー」。

hubot-alternative をつくった。1 日 1 Hubot スクリプトの 65 日目。 hubot-alternative はコマンドに別名をつける Hubot スクリプト。名前は hubot-alias にしようかと思ったのだけど、現状ではちょっとクオリティが低いので、もっと良いものをつくった時にその名前をつけようと思う。 この Hubot スクリプトには 4 つの制限がある。 robot.respond でしか定義できない TextMessage しか処理できない 引数を(固定値でしか)渡せない 設定値を保存できない 4 くらいは解決したほうがいいかとも思ったけど、面倒なので、シンプルな形にとどめておいた。 さて、ソードアート・オンラインの続きをみよう。

『 Arduino をはじめよう』をよんだ。また hubot-firmata-led をつくった。1 日 1 Hubot スクリプトの 62 日目。 『 Arduino をはじめよう』は表題どおり Arduino の初心者向けの本。 Arduino は "OPEN-SOURCE ELECTRONICS PROTOTYPING PLATFORM" らしい。要するに OSS で安価で小型で、アナログ・デジタルの IO や USB ポートを備えた、ちょっとした電子工作やプロトタイプ向けの基板、かな。 ぼくは電子工作に興味がある。理由は単純で、流行っているから。正しくは、流行っているように思うから。最近のサービスを見ていると、ソフトウェアだけではなく、ハードウェアにタッチしたようなものも見かける。スマートフォンもそうだけれど、ちょっとしたハードウェアを自作している例もある。そういう状況のなかで「ソ