サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
wp.jmuk.org
前回の記事で書き忘れてたこと。 本には主要登場人物というべき何度も登場する人がいく人かいるのだけど、その中の一人がBob(”Crazy Bob”というあだ名がつけられている)という人だ。本書では9章の「コアライブラリ」の章で初登場する。BobはDanger/Be/WebTV人脈ではなく、もともとGoogleでAdsの一員として働いていたところからAndroidに移籍した人だが、コアライブラリとしてApache Harmonyを移植したりしてランタイムの基盤を整えたりといった大きな貢献をしている。それだけではなく本書の結構いろんな箇所で登場していろんなコメントを残している。インタビューに応じてくれて多くのコメントを残してくれたのだろうと想像される人物である。 それ自体はふーんでおしまいなんだけど、その初登場の節からちょっと後で、BobはやがてGoogle自体をやめてSquareのCTOになっ
Chet Haase氏の書いた”Androids“を積んでたのを思い出したので読んだ。面白かった! Chet氏は2010年にGoogleに入り、Androidの、特にUIフレームワーク周りの開発を主導してきたエンジニアだ。同時にAndroid開発コミュニティではさまざまな講演などでもお馴染みの人でもあり、Android Developers Backstageというポッドキャストのホストも長いことこなしてきた。 そんなChet氏が、Androidの初期の事柄を記録しようということでさまざまな人にインタビューを行い、それをまとめたのが本書だ。創業からGoogleの買収を経てSDKの公開、1.0、そして最初のデバイス(G1)の発売である2009年ぐらいまでのことについて、関係者の声や思い出話をまとめ、紹介している。これが面白いのだ。 面白さの一つには、出てくる個別のエピソードがそれぞれいちいち
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
ちょっと前にblueskyで見かけた話題。もとは「GraphQLのスキーマではintが32ビットしかなくて、64ビット整数とかないのがイケてない」といった話だったかなと思う。直感的にはこれは「Javascriptではすべてが倍精度浮動小数点数だから64bit intがないから」ということになるが、よくよく調べてみるといろいろややこしい歴史的事情があるようだ。 たしかにJSにはもともとひとつのNumber型しかなく、いわゆるdouble型(倍精度浮動小数点)だけで数値を表現してきた。IEEE754の倍精度浮動小数点数は仮数部が52ビットあるので、実際には32ビット整数ていどであれば全て誤差なく表現できる。なので32ビット整数または倍精度浮動小数点数がどちらも使えるというふうに理解されてきた。 そうはいっても不便なので、現代のJSにはBigIntがある。ES2020で導入されたらしい。ただし普
fediverseにちょっと書いたけど、仕事でちょっとハマって数時間悩んだ話。 とあるコードを書いていて、どうもテストが安定しなくてflakyになる。つまり、通るときは通るがたまに失敗する。が、理由がよくわからない。 こういうとき、Goでよくあるのはmapのイテレーションの順序が意図的にランダム化されているというパターンだ。mapは(内部的にはハッシュテーブルが使われているので)イテレーションの順序は不定であるし、不定であるべきなので順序に依存するコードを書くべきではない。現実的にはたいていの言語ではこのへんは「実装依存である」ということになっていて、うっかりすると言語のランタイムバージョンが上がったり、キーが一個増えたり減ったりするだけで順序が狂い、突然テストが死ぬみたいな現象によくみまわれる。Goでは意図的にこの問題に対処するために、言語のバージョンが変わらなくても毎回イテレーションの
ElonがTwitterを買ったことは自分にとって思った以上にショックだった。彼のやろうとしていることがうまくいくか、それがいいことなのかどうか、というのはまあ興味深い話ではあるが、それはそれとして個人的に私はElonを支持しないので、彼の支配下のTwitterの利用を段階的にやめてみることにした。このブログは自動連携でtwitterに出てくるようになると思うし、アカウントを止めるわけではないが、基本的には投稿はしないし見るのも減らしている。 と言っても、まあ完全に止められるかはわからないし、数ヶ月後に何事もなかったかのように利用を再開することもあるかもしれない、と予防線ははっておきます。自分はsocial addictなので……。 さてそういうわけでどうするかということで、ひとまず個人的なこととかはFacebookに書いてみたり、5年前にアカウントを作ったっきり放置していたMastodo
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない(複数の経路から同じ
http://lise-sophia.net/kktm/Essay/xx-shi.htm このエッセイが面白かった。動詞に-erや-orをつけるような名詞は「◯◯子」「◯◯機」「◯◯器」などといった接尾辞がつけられる。特に抽象的な概念などの場合には「子」がつけられがち。例えばoperatorを「演算子」と呼んだりidentifierを「識別子」と呼んだりするように、と。 プログラミングの世界ではまさにそういう「抽象的な概念」であるが-erや-orがついた名詞というのはたくさんあるような気がする。どうなっているだろう? constructorについては、「構成子」という訳語があるかな、と思ったが、「構築子」という用語もあるようだ。どちらも現存するらしい(前者は例えばJIS規格のFortran、後者はJIS規格のC#で使われている)。さてFortranのことは全く詳しくないが、C#くらいモダン
ここ最近またMetaverse (メタヴァース)という言葉が話題になってて、もう何度目かとおもいつつ、いい機会かもしれないと思って Neal Stephenson の “Snow Crash” を読んだ。 “Snow Crash” は1992年に発表されたSF小説だが、作中のオンライン世界の名前がMetaverse。本作はとくにアメリカのハッカー・ソフトウェア業界では有名で、多くの人が読み影響を受けたことを表明している。Metaverseが話題になったこともこれまで何度もあった。邦訳も1998年に出ていて、ぼくは2001年にでなおしたハヤカワ文庫版を持ってたんだが、なんとなくずっと読みそびれていたのだが、ようやく重い腰を上げて読んでみたというわけ。邦訳版は渡米のときに手放してしまったので、今回は原語で読んだ。 作品そのものについて あらためて読んでみたら、これが面白かった。意外というかなん
要約:決定版はとくにない。 kzys氏のシェルスクリプトを書かないという記事は面白かった。 https://blog.8-p.info/ja/2021/09/15/bash/ シェルスクリプト、ごくたまに書くことはあるが、ほんともう細かい話とかはすべて忘れているし、覚える価値を感じない。いまさら覚える必要のない技術だなと感じる。が、その一方でなかなか代替品がないようなニッチでもある。 自分は必要に応じてPythonかRubyか、といったあたりを使うことが多いが(perlはもう書けなくなった)、なかなかこれという感じには思い至らない。なにがいいんだろうね?という。 前提条件:インタラクティブな環境(REPL)はなくてもいい。そこはもう既存のシェルでいい。自動化したシェルスクリプト的なタスク記述を目標とする。bashの置き換えという意味では「どこにでもインストールされていることを前提にしないと
Facebookなどではステータス更新を済ませたが、6月末にグーグルをやめて新しくスタートアップに転職した。すでにそのスタートアップで働いて、いま2週間くらいというところ。 グーグルには13年以上勤務した。いろんな面でずいぶんお世話になりました。自分の意思でやめたけど、実際のところ、とくにすごく嫌なことがあってやめた、というわけではない。ややこしいこととかが皆無というわけではないけれど、あの規模の会社としてはずいぶん頑張っているだろうし、総合的にとてもいい会社だと思う。部下のいないヒラエンジニアとしても待遇もよかった。やっていたプロジェクトも意外と(?)インパクトのある製品だったし。 今回は、たまたま自分にとって絶妙なタイミングでお声がけいただいたのと、こういうシリコンバレーのスタートアップに入るのは得がたい経験だろうしいい機会かもしれないなと思った、という次第です。 新しい会社は、まだ入
数ヶ月前にzig言語というやつの存在を知って、これはちょっと面白そうだなと思ったので、勉強がてらなにかやってみよう、と思っていた。ある日、tomlのパーサはどうだろうかと思い立ってしばらくやっていて(Ghost of Tsushima で作業が中断したりしつつ)、まあまあ出来上がってきたと思うので、現在のところのソースコードをgithubに置いておいた(https://github.com/jmuk/zig-toml)。 というわけで、zig言語をちょっと書いてみた感想を残しておく。なお、利用したのはzig 0.6.0なので、今後いろいろ変わってくる可能性もあることは強調しておきたい。 zig言語のよいところ・興味深いところ 型の扱いがzigでは興味深いところだった。zigはかなりいろんなところでcomptimeというマーカをつけてコンパイル時にコンパイラが事前処理をするようなことができる
2018年から、Misreading Chatというポッドキャストをやっている。とりあえずこれまでのところの感想を書いておこうと思う。 Misreadingはコンピュータサイエンス系の論文を紹介するという体裁のポッドキャストだ。メインのホストは同僚の森田で、わたしは共同ホストという体制ではあるが、実際にはまあにぎやかしみたいな立場な気がする。毎回、わたしと森田とで交互に一本ずつ論文を読んできて紹介する。 ポッドキャストそのものやコンセプト、アイディア等は森田による発案なので、どういう考えからこういうポッドキャストをはじめたか、とかいったことについては、わたしが話せることはあまりない。こまかな編集作業や加工も、じつは森田が行っているので、わたしはポッドキャストの場でしゃべるだけ。いつもすんません。 Misreadingは、よくあるポッドキャストからすると(たぶん)珍しい点がいくつかあって、ひ
マイクロソフトによるgithubを報じた日経新聞の記事のタイトルにおいて、githubのことを設計図共有サイトとよんでいて、開発者のみなさん総ツッコミ状態のようですね(現在は開発者向け共有サイトとなっている)。 個人的な感想としては、ソースコードを設計とみなすアナロジーはあって誤りであるとはいいがたいし読者層を念頭におけば気持ちはわかるものの、設計図共有サイトねぇ……という気持ちはないでもない。まあしかし、それ以上とくになにもいうことはない。 ただこれに対応して気になるのは、英語メディアではどのように紹介されてたのか、ってことだ。天下のマイクロソフトが$7.5Bもの額でユニコーン企業を買収となれば、一般紙でも紹介されるだろう。どんなふうに紹介してたんだろうか。 適当にgoogle newsで引っかかったテックメディアでない系の記事を眺めてみた。 Forbes。https://www.for
https://turingcomplete.fm/12 を聞いていて、モヤイ像について昔ちょっと調べたのを思い出したので掘り起こしてみる。 Unicodeに収録された絵文字のなかに「モヤイ像」というものがある。これ、モアイ像ではなくて “Japanese stone statue like Moai on Easter Island”、つまり「イースター島にあるモアイ像みたいな日本の石像」として定義されている。ちなみにモアイ像の絵文字というものはないのであった。マジで? マジで。 モヤイ像というのは東京の渋谷駅のランドマークになっているアレであって(細かく言うと色々あるのだがそれについては後述)、イースター島のモアイ像とは似せたようなかんじであってもまあ違う。髪もあるし。上述リンクの図像もまさに渋谷のモヤイ像のような見た目になっている。どうしてこんなことになっているのだろうか? いっぽう
2007年10月1日に入社したので、10年が経過したことになる。10年! ずいぶんな長さだなあ。すっかりグーグラーとして慣れてしまったような気がする。渋谷ではたらいていたころ、まさか自分がシリコンバレーに移住するとは微塵も思ってもいなかった。 それなりにいろんなチームでの仕事もしてきた。はじめはモバイル検索のことをやってて(モバイルといってもフィーチャーフォン向けの検索ですが)、Google日本語入力、ChromeOS。一瞬のAndroid業を経て、いまはクラウド。 ひとくちにグーグルといってもそれぞれ仕事の内容や扱うテクノロジは違っていて、検索のころはmapreduceを書いてデータパイプラインをうんぬんしていたりウェブページや自然言語を相手にしていたわけだし、Google日本語入力は多少の自然言語処理と動作プラットフォームの知識、ChromeOSのころはおもにUIでウィンドウマネージャ
最近、メインの仕事ではGoで書かれたサーバをいじっていて、ビルドするのにBazelを使っている。使っているとBazelなかなかいいやつだな、と好感を持つのだけど、でもGoの場合、標準ツールとの相性というのがなあ、という微妙さもある。 その辺の個人的な雑感です。 Bazelとは Googleが公開しているオープンソースのビルドシステム。もともと社内に存在していたビルドシステムのオープンソース版という位置づけ。社内版と何がどう違うのかはよく知らない。BUILDという名前のファイルにビルドレシピを書く。構文はそこそこ簡潔で、わりと宣言的に書ける。ちなみに構文はPythonのサブセットなのだけど、Bazel自体はJavaで書かれている。なぜ……いやまあそれはべつにいい。 社内版ビルドシステムと構文が同じなので、社内版プロダクトがわりとそのまま(もしくは構文解析後のノードの簡単な書き換えによって)オ
PS5のSpider-Man 2をクリアした。かなり面白かった。今回も良作。ただ総合的な満足感は前作の方が上という気がした。 PS4にあったゲームの続編で、ニューヨークを舞台にしたオープンワールドゲーム。今回の主なヴィランはKraven the hunterとヴェノム。Kraven the hunterっていうヴィラン初めて見たんだけど、ゲーム内でのデザインはよくできててかっこ良くはあるものの、「君ちょっと世界観違くない?」という気がする見た目だったのがすごく気になった。オープニングシーンとかちょっと笑っちゃった。 ゲームとしてはそんなに難しすぎないしやっていて楽しい。スパイダーマン的な動きが色々できたりアクションも派手。ゲームメカニズムとしては基本的には前作そのままでやることもそのままだが、色々追加要素(糸を渡したりとか)もあり、そこそこ複雑化していて楽しくはなっている。空飛ぶアクション
概要 tensorflowの練習に、英単語(アルファベット文字列)を入れると、その読みとなるカタカナを出力するという機械学習課題をやってみて、まぁいちおう動いているなという程度のものができた。 学習結果をブラウザ内で実行できるよう移植して http://www.jmuk.org/en-ja/ に置いといた。 本文 tensorflowを勉強したのはいいのだけど、なんらかの練習課題をやってみたい、なにかいい課題はないだろうか、と思っていた。個人が趣味でやってみる課題では学習データの準備をどうするかが気になるところだけど、それも簡単にそろうやつがいい。データの手動のタグ付けをしない課題がいい。 などと考えているうちに「英単語を読ませてカタカナにする」という課題を思いついた。たとえば “google” という入力文字列から “グーグル” という文字列を出力させたい。そういう問題になる。 これを学
グレッグ・イーガンの『クロックワーク・ロケット』を読んだ。 面白かった。が、疑問もあった。が、最近のイーガンとしてはヒット。面白かった。 異世界の回転物理学 この作品の妙味はやはり、その特異な世界設定であると思う。 この作品の舞台となる世界は、ミンコフスキー時空ではなくてユークリッド時空にもとづいた世界になっている。ミンコフスキー時空ではないので時間軸は特別な軸ではなく、ほかの空間軸と交換可能だし、我々の時空とはまったく異なる世界が描き出されている。 これがどういう意味を持つかというと……というのは板倉さんの巻末解説が詳しい。ぼくは物理学については素人だし、あんまり深く考察はしていないが、これは面白いなあと思った。それに、様々な観測的現象とつきあわせて登場人物が科学的発見をしていくのは読んでいて面白い。 私は『白熱光』はあまり評価していないのだが、その理由のひとつに、私達にとって既知である
私は北米在住なので、WiiUも北米版だしスプラトゥーンも英語版をやってる(日本語設定ができないので……)。そういう状況なので、英語版の単語に慣れているが、英語版は日本語版からチョクに単語を置き換えているのではなくて、そこそこ文脈に沿っていろんな訳が作られている。 これってけっこう面白いし、翻訳(ローカリゼーション)とはこうしたものなのだなぁと思ったりもする次第。 たとえば、Inkopolis News(ハイカラニュース)ではSquid Sisters(シオカラーズ)はけっこう違うことをしゃべる。動画を撮ってみたのでこちらをどうぞ。 ブキなどの名称もけっこう違う。対訳表のスプレッドシートがあるので、こちらも興味があったら見てみて欲しい。 面白いなと思うあたりを個人的にピックアップするとーー ガロンはgalなのでデコってる .52ガロン、.96ガロンはそれぞれ.52 gal、.96 galとい
このページを最初にブックマークしてみませんか?
『Jun Mukai's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く