GitHub Package Registry使ってみたけど見送った

GitHub Packages: Your packages, at home with their code

分かったこと

少なくとも npm package の registry 追加、変更はあんまりカジュアルじゃない

  • rubygems なら source 書き足すだけでいいけど、package.json にそういう記述がない
  • .npmrc で registry の設定を変更することはできる。これを npm.pkg.github.com にしておくと、存在しない package を自動で npmjs.org から取得するように fallback できる。が、yarn には影響しない

GitHub 側の問題じゃなくて npm の仕様の課題かなー。rubygems は昔からカジュアルにミラーサーバ用意できたんだけど、npm とか yarn とかめんどいね。

Google Cloud Functions Emulator動かしてみた

なんかいろいろあって Google Cloud Functions 試そうと思って、まずは Emulator 使ってみようと思ったんだけど、試すというよりは動かすまでで力尽きたのでそのメモ。

–local-pathオプションが消えててハマった

Cloud Functions ローカル エミュレータ  |  Cloud Functions のドキュメント  |  Google Cloud

なんかプロジェクトっぽくディレクトリを切って作業する場合、普通はカレントディレクトリにいきなりコード置かないよね。で、その状態だとどうしても deploy できなくて、いろいろ試した結果、

–local-path という option は beta から消えてる

ことが分かりましたとさ。

1.0.0-beta.1 (#177) · GoogleCloudPlatform/cloud-functions-emulator@04ec0b0

なるほど。deploy できるようになって確認すると、マジで急に local-path という「オプション」だけが消えてて、functions list と打った時に出てくる情報としてはやはり Local path のままなので、明確なポリシーじゃないのかな?

この変更は2月に入ってるのにドキュメントが追いついてないし、2018-06-04 時点でまだ Functios Emulator は世界的にも使われてないのか? option が変わるって割と大きな変更だと思うんだけど、話題を見ない。

とりあえず Google には Feedback しといたので、そのうちドキュメントかコードかどっちか分からないけど直るんじゃないかな。

Functionの名前をexportsしろ

Functions のサンプルコードって、こんななんだけど、

exports.helloHttp = (req, res) => {
  res.send(`Hello ${req.body.name || 'World'}!`);
};

Node.js のコードは基本的に書いてこなかったので、exports で名前を明示するのを見る機会が全然なく、なんだこれと思ったわけ。1

で、試してみると名前を明確に exports しないと

$ ./node_modules/.bin/functions deploy hello --trigger-http
ERROR: Error: Node.js module defined by file index.js is expected to export function named hello

という感じで怒られる。

deploy したい function の名前と exports する名前を合わせておけ

というルールらしい。なるほど。

global installはzshと相性が悪い

これは単純にこういう話

$ which functions
functions: shell built-in command

functions-emulator もあるのでそっちが使えるんだけど、すげー長い。じゃあ alias かというと話なんだけど、そこまでやらないといけないってのもちょっとなぁという感じ。

  1. require する側が自由に名前を決められるのがメリットなんだと思ってた。 

Windows + 公開鍵認証でCapistrano

できた。ハマるポイントがいくつかあったのでメモを残しておく。

確認したのは

  • Windows Vista/7
  • Ruby 1.9.3-p429
  • Capistrano というか net-ssh 2.6.7
  • Putty 0.6.2

password認証ならたぶん何も考えなくていい

でもねぇ。

経路にもよるけど公開している ssh サーバにパスワード認証で繋がないでしょ?

proxyは試してないのであしからず

ということです。

cygwinでやれるならそれでいいかも

Windows 環境とは別個の閉じた環境で Ruby も ssh(正確にはopenssl) も利用できれば openssh の公開鍵認証が普通に利用できるはず。

少なくとも mingw Ruby + cygwin + openssh 鍵の組み合わせならパスフレーズを聞かれて普通に認証できた。ただ、なぜこのような動作になったのかはイマイチ合点がいっていないことと、deploy のためだけに cygwin を入れるのはまったく目的に合ってないのでこれは深追いしていない。

cygwinなしの場合はpageant頼み

これはそもそもそういう設計になってる。

  • Net::SSH::KeyFactory の理解できる鍵は OpenSSL で理解できる鍵
  • PLATFORM を判別して :win32 の場合は pageant で処理するコードが読み込まれる
    • pageant とは Windows の API を通じてやりとりしているので要は起動してりゃオッケー。PATH が通っている必要なし。試したところ 32bit/64bit どちらでも同じように処理できるみたい。

というツクリになっている。まとめると

Windows では pageant に丸投げ

である。

Rubyは1.9以降で

Ruby 1.8 では OpenSSL 周りのエラーが出てまともに動かなかった。Windows では 1.9 の方が明らかに速いはずなので、素直に 1.9 以降を入れればいいと思う。

自分が試したのは RubyInstaller for Windows の 1.9.3-p429

:keysの設定が必須でしかもなんか変

config/deploy.rb で

ssh_options[:keys] = ["'~/.ssh/id_rsa'"]

あるいは

ssh_options[:keys] = %w('~/.ssh/id_rsa')

のように設定が必須だった。注意すべきは以下の3点。

  1. OpenSSH の鍵認証の場合は正しくデフォルトの鍵を認識してくれる
  2. OpenSSH の ssh-agent を使っている場合はそもそも鍵のパスを与える必要がない(サーバ側の公開鍵とのペアを agent が覚えている中から自動で探してくれる)
  3. :keys には「文字列の文字列の配列」を与える必要がある。

1, 2 は OpenSSH で十分な経験がある人がハマる罠。

3 は Ruby に慣れてる人がハマる罠。

コードを読んでみたが、なぜこのような挙動になるのかは理解できなかった。無念。

公開鍵がないことが原因ではない

上の設定をミスっていると

ArgumentError: Could not parse PKey: no start line

というエラーが出る。これの回答として対応する公開鍵がないからだというものが github などに上がっているんだけど、すでに見たように

公開鍵がないからとは限らない

ので注意が必要。

ViewSourceWith なんてものを見つけた

ViewSourceWith :: Add-ons for Firefox

実は最近ずっと困ってたんですよ。

  • いつの頃からか Thunderbird 2.x と External Editor の組み合わせがまともに動いたり動かなかったりするようになった1
  • 自宅の IntelMac に限って It's All Text ! でエディタを開くと一気に55個とかエディタが起動してうんざり。

でもいっぺんに解決! ViewSouceWith っていう名前からは想像できなかったけど、これは Firefox でも Thunderbird でも外部エディタ起動用拡張として使える。

ただし、外部エディタ起動専用の拡張ではなく、

今フォーカスの合っている部分のソースを指定したアプリで開く

ためのものなので少し注意が必要。

textarea の編集に使いたければ textarea にフォーカスを合わせておかないといけないし、メールの編集に使いたければまずメールの送信画面の本文のところにフォーカスを合わせておかないといけない。

いつ何時でも「長文を書くために外部エディタを開く」という形で使えるわけではない点だけ分かれば、Firefox でも Thunderbird でも使えるというのはとてもありがたい。二つの問題が一気に解決してしまった。素晴らしい。

  1. 具体的にはメールを書いていたエディタを拡張が見失ってメール作成ウィンドウにフィードバックできなくなる。そのくせエディタを閉じないとメール作成ウィンドウは閉じれませんとブータレる。実際にはエディタは終了しており、このダイアログを強制的に閉じる手段もない。つまり Thunderbird そのものを強制終了する以外に回復方法がない。 

Emacs 22.1 リリース

えと、このバージョンナンバーは要するに 22 の stable が出ましたよ、という意味ですね。今までの最新はたぶん 22.0.50 だったような気がしますが、嘘言ってるかも。Emacs は本家情報ほとんど確認してないんで。

しかしあれですな。2001年の 21 のリリースのときはこんなにニュースサイトで情報を見なかったような気がしますけど、どうですか?(誰に聞いてる。)

やっぱあれですか、世の中 Emacs 流行ってるんですか。Web 2.0 でギークな人たちが使っているともっぱら評判の Emacs(ぷ) 使わないと人生の8割を損するという、何かの訪問販売ですかそれな超絶エディット環境 Emacs. 無敵の要塞 Emacs. イケイケ Emacs.

知らない間に FSF のサイトも GNU のサイトもモダンな感じに変身しててちょービビった。

近場にローソンなんかねえっ

Ticket | Event | Lightweight Language Spirit

今年こそは行こうかと思ったがこんなところにも都会と田舎の格差がぁっ。

とか。

いやどっかにはあるんだけどねぇ。普段行くところにはないんだよな。

こっちはね、結構減っちゃったんですよ、ローソン。昔はもっとあったんだけどね。

blog の飲み会ヨタ話的機能

Hiroaki Suzuki's Blog: なんか不思議な一致だ (via otsuneさんとこ)

最近思うのは、blog は酒場のヨタ話にどんどん近づいているのかなということ。

これにはいい面も悪い面もあって、持たざる者が持つ者をやっかむなんてのは悪い面と言えるだろう。

本来酒場の席で持つ者をやっかむってのはガス抜きとして有効なのだが、残念ながら blog は公共空間であり、しかも声の大小はソーシャルブックマークの介在などによってどんどん無関係になりつつある。1そのうえ物理的な空間の制限を越えてそうしたやっかみの声というか「心」を数多く集めることが比較的容易に起こってしまう。負の連鎖というか。時に、出る杭を打つという、ある意味マスコミの悪い機能と言えるものまでを獲得し得る。

※ もちろんそうした現象をウォッチすることで逆にああこういう分野でも格差の拡大が起きているのか、これはまずいなぁと「問題」として昇華させることはできるかもしれないが、それは別に負の連鎖を待たなくてもできそうな気がする。負の連鎖が起きるといろいろいやな思いをする人が増えたりするので、起きずに済むなら起きない方がいいように個人的には思うし、blog で観察できる分野はまだかなり偏っているので積極的に利用するべきではないだろう。

いい面ももちろんある。

恐らくリンク先で blog を高等教育に利用するというのは学会の懇親会が24時間365日 Web 上で行われているような、そんな感じ。これが酒場のヨタ話的いい面の一つ。いやそんなのメールでもええやんと思うかもしれないが、Web は開けた空間。要するにみんなの前で立ち話をしているのと同じなのだ。この立ち話状態、あるいは広い座敷でみんなで飲んでる状態はつまり誰でもその話に割り込める状態なわけで、これはとても面白い状況と言える。2

関心領域の近い人同士によって議論の輪が大きくなるかもしれないし、逆に関心領域そのものは近くないけれど、お互いの領域で起きているストーリーの展開が似ている、あるいは似ていないという話で盛り上がることがあるかもしれない。まぁ酔った勢いでお前の言ってることは間違ってんだよ!と説教することはできないが:-P

もっとも、こうしたまっとうな利用方法を、しかも高等教育機関で行おうとすると、最初の場の演出によっては酒場のヨタ話にまったく向かわずに、カタいジャーナリズム的な利用に向かってしまいかねない。まぁ向かってもいいのかもしれないけど、それで blog を続けるのは苦痛以外の何者でもないだろう。好きで始めた草の根ジャーナリズムならともかく、この場合は授業やゼミによる強制的な blog なんだから、場の演出に十分に心を砕かないと、小テストやミニレポートの提出を毎日無言のプレッシャーのもと強制されてしまう状況になる。これはきついだけだ。そして、きついだけという状況から問題意識や問題定義が生み出されるとはちょっと思えない。

私が酒場のヨタ話という言葉にこだわるのは、「自由闊達な議論」というものをイメージしていると言い換えると分かってもらいやすいかもしれない。official と unofficial の狭間というか、そういう場をイメージしているのだ。エモーショナルな問題意識を言語化するためにはこの中間的な場がとても大事なのではないか。3

しかし、単位がほしいだけで別にたいして興味ない授業の場合、こんな方法が採られたらすげー困るだろなぁ。


ちなみに、ツールというか技術的な話に絞ると、blog がベストなのか?という疑問はなくはない。blog は文章を公開する場であって、文章を練るための道具として使いやすいわけではない。自分だけが閲覧、編集可能な Wiki と組み合わせるといいかなという感じか。4SNS はどうだろうとも思うけれど、コミュニティを作るのが目的ではないのだから、これは外れるだろう。

また、仮に授業やゼミで blog を利用するならそれはひとまず閉じておいた方がいいと個人的には思う。つまり IP アドレス、あるいは ID, pass によってアクセス制限を設けるということである。というのも授業やゼミによる blog の利用というか、「発言」は半ば強制的なものであり、かつ参加者は学習の途中であるから、未熟な発言が紛れ込むことはおおいにあり得る。これを例えば大学のサーバを利用して外部に公開してしまうのはややこしい問題を生みかねないし、無自覚な当人が「攻撃」対象になってしまうこともあり得る。まぁ簡単なイメージで言うとはてなグループをプライベートに運用するとか、そういう方法がいいんじゃないかと。で、登録する際のメールアドレスくらいは各教育機関で用意する、と。5

これらは安全性の問題でもあるし、上に書いたエモーショナルな問題意識を言語化するための装置としての配慮でもある。もちろん学生個人が自分の意思で自分の blog を持つことはまったくの別問題ね。

  1. 本人がそれほど声高に言ったつもりがなくてもソーシャルブックマーク、2ch の祭りなどの拡声器によって知らない間にみんなに声が届いていたりする。 

  2. メールはメールでまたアリでしょうけど。いわゆる「往復書簡」みたいなやつね。 

  3. 最近はネットが間に入った方が直接の対面コミュニケーションよりも気楽に行えるという傾向があるので、要らぬ心配かもしれないけど。 

  4. 手元でメモ帳や Word でやった方がいいとも言える。ただ参加者が全員自分専用の PC を持っているかどうか分からないなら Wiki を用意しておくのは有用だろうと思う。最近の自分の感覚ではローカルの、特にファイルベースのデータは管理がややこしいからいやだなぁと思っちゃうんだけど、その辺は自分で自由に Web ベースのツールを準備できるからとも言えるな。また「道具の持ち替えが面倒くさい」という感覚もあるのだけれど、逆に学習者に対してはあえて持ち替えを発生させることで公共空間である blog との違いを意識させた方がいいとも言えるかな。 

  5. どこまでプライベートにできるのかよく分かってないし、こうした運用も規模と期間次第によって適宜判断が必要だろう。教育機関側で有料サービスを申し込むというのがいちばん妥当なところか。ただ、授業やゼミ単位でお金を出すのは手続き的にややこしそうだし、今回のプロジェクトのような話では当然自前であれこれ用意するだろうから、有料オプションの使いどころってのも案外難しいのかもしれないけど。 

terminal の色設定厨

先日 ck の半透明バージョンを設定して以来、今まで特に疑問を感じなかった terminal の色の設定を細かくいじり出している。うーん、やり始めると長くなるな、こりゃ。

とりあえずこんな感じ

background#fefefe
foreground#202020
color1#E92E2E
color4RoyalBlue2
color12MidiumBlue
color14#00E4E7

基本は Emacs なので、vim 使いには使いやすくないと思う。コメントの赤と、キーワードとしてよくハイライトされるシアンや、Linux 系の w3m でリンク色としてデフォルトで設定されている青がまぶしいのでその辺だけシックに。

真っ白、真っ黒もまぶしいので避ける。

HTML メール

まったく正反対の内容の記事が同じコーナーで立て続けに載るのも面白いもんですな。このことだけで HTML メールの置かれている状況がよく分かるというものです。

自分はもちろん反対派です。なくなればいいと思っています。

販促効果? プレーンテキストのメールを HTML にしただけで効果 10倍なんて、そこらの雑誌でよく見かけるダイエット商品くらいに疑わしいものですよ :-P 誰だ、そんな適当なこと言ってるやつは。

日本のソフトウェア技術者の今後

国際競争力回復へ、ソフト技術者の教育強化が急務

ということなのですが。。。

むしろ情報を専攻していない方が対人スキルや説得、説明などのスキルに長けているような気がしないでもないのですが、現実的には

情報理論も分からなければ対人スキルもないようなばかばっか

ということなのでしょうか? まー大学の教育に期待するのは難しいと思いますけどねぇ。現場のできる人間を引っこ抜いてこない限り無理でしょう。そんなところと大学がパイプを持っているのかなぁ。。。

社内の教育に金掛けろというのは諸手を挙げて賛成しますが、どこに金を掛けたらいいのか判断できる人材は居るのか、という問題は。。。

それに、(Web や Windows 界隈のように)技術の流行り廃りの激しい分野では海外に外注に出す方が難しいような気がしないでもないのですが、そんなことないんすかね? こちらの定番スキルとあちらの定番スキルが食い違うってのがしょっちゅう起きるような…。むしろ日本国内のスキル格差よりマシ?

読み方が絶望的すぎますか。そうですか。

About

例によって個人のなんちゃらです