Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/241: 1 2 3 4 5 6 7 8 9 »

What's the best way to collaborate an WebExtension-based addon with others? - Jul 28, 2018

When I migrated my addon Tree Style Tab from XUL to WebExtensions, I wrote some concerns about communication between addons. Let's share my knowledge around the topic.

Case 1: Request-response type API

TST provides some APIs for other addons. Some APIs are callable via browser.runtime.sendMessage() like as:

const kTST_ID = 'treestyletab@piro.sakura.ne.jp';
browser.runtime.sendMessage(kTST_ID, {
  type: 'expand-tree',
  tab:  2 // Tab.id
});

This example expands a collapsed tree belonging to the specified tab. As you saw, such a "request-resposne" type API is very easy to implement. The receiver addon (in this case, Tree Style Tab) just need to define a listener for browser.runtime.onMessageExternal like as:

browser.runtime.onMessageExternal.addListener((message, sender) => {
  if (!message || !message.type)
    return; // Ignore invalid type API call.

  switch (message.type) {
    case 'expand-tree':
      // Here is a code to expand specified tree.
      // If needed, you can return a promise to wait until the operation finishes.
      return Promise.resolve(true);
  }
});

Then there is one problem: when a client addon sends any message to missing server addon, it will be reported as an error like "Error: Could not establish connection. Receiving end does not exist."

Solution 1: an option to enable/disable integration with other addons

The easiest solution is: providing an option to activate/deactivate such an integration. Here is an example based on storage.local:

let enableIntegration = false;
browser.storage.local.get({ enableIntegration })
  .then(values => {
    enableIntegration = values.enableIntegration;
  });

function someFeature() {
  // ...
  if (enableIntegration)
    browser.runtime.sendMessage(kSERVER_ID, { ... });
}

But it introduces a new problem: which is the best default configuration, enabled or disabled? If enabled by default, users will see mysterious errors in the debug console. If disabled by default, users will need to activate the option manually to activate integration and some people won't realize there is such an option.

Solution 2: initialization based on management API of WE

Client addons can know that the server addon is installed or not via the browser.management.getAll(). Thus you don't need to provide such an option, instead you can activate the integration only when the server addon is available:

let serverIsActive = false;
browser.management.getAll().then(items => {
  for (const item of items) {
    if (item.id == kSERVER_ID && item.enabled) {
      serverIsActive  = true;
      break;
    }
  }
});

function someFeature() {
  // ...
  if (serverIsActive)
    browser.runtime.sendMessage(kSERVER_ID, { ... });
}

However, you need to add the management permission to the list of static permissions in your manifest.json. Sadly it is impossible to be listed in the optional_permissions. The installation prompt for your addon will show a new extra line like: "Monitor extension usage and manage themes". I think most people dislike any needless permission for an addon, so this can be an disadvantage to the previous solution.

Solution 3: simply ignore the error

Both solutions 1 and 2 have concerns. So I ordinarily do nothing - I usually send messages to server addons without confirmation. Those messages will be processed if luckily the server is activated, otherwise they will be ignored. Only some developers will look errors via the debugger console, but most people don't realize that.

And, for developers I sometimes providing an option to deactivate integration. Because they intentionally deactivate the integration, I believe that I have no need to notify existence of the integration feature again.

Of course you can suppressed such errors by an error handler like:

function handleMissingReceiverError(error) {
  if (!error ||
      !error.message ||
      error.message.indexOf('Could not establish connection. Receiving end does not exist.') == -1)
    throw error;
}

browser.runtime.sendMessage(kSERVER_ID, { ... })
  .catch(handleMissingReceiverError);

Case 2: Pure broadcasting is impossible on WebExtensions!

Anyway, on the other hand, there are more other type of APIs: "broadcast" and "publish-subscribe".

Very sad news, an WE-based addon cannot "broadcast" messages to other unknown addons due to WE API's restriction. browser.runtime.sendMessage() can send any message to other addons, but it requires the exact ID of the receiver. Thus a receiver addon must notify its ID to the broadcaster addon. As you know, such an API model is called as "publish-subscribe" (aka "pub-sub"). In short, we always need to implement any API to notify something information from an server addon to other client addons, as pub-sub model.

Case 3: Pub-Sub communications on WE addons

Don't worry, you can implement such pub-sub type APIs based on the technology same to request-response type APIs. The "subscribe" (and "unsubscribe") API will be implemented a simple req-res API like as:

const subscribers = new Set();

browser.runtime.onMessageExternal.addListener((message, sender) => {
  if (!message || !message.type)
    return; // Ignore invalid type API call.

  switch (message.type) {
    case 'subscribe':
      subscribers.add(sender.id);
      return Promise.resolve(true);

    case 'unsubscribe':
      subscribers.delete(sender.id);
      return Promise.resolve(true);
  }
});

And you just need to send messages to known subscribers like as:

async function doSomething() {
  // ... do something ...
  const message = { type: 'published', ... }; // The message to be published
  await Promise.all(
    Array.from(subscribers)
      .map(id => browser.runtime.sendMessage(id, message))
  );
}

Client addons will "subscribe" and receive published messages like as:

browser.runtime.sendMessage(kSERVER_ID, {
  type: 'subscribe'
});
browser.runtime.onMessageExternal.addListener((message, sender) => {
  if (sender.id != kSERVER_ID)
    return;    
  switch (message.type) {
    case 'published':
      // Handle published message.
  }
});

But there is one big problem. Any "subscribing" API calls will fail if client addons send them to the server before the server addon start to listen messages from others.

(Sequence Graph of Two Addons Combined with Messaging) (This figure is initially published as a part of the migration story of TST from XUL to WE.)

Such a situation will happen in cases like:

  • The server addon is installed after client addons are installed.
  • Both the server and client addons are installed, and Firefox starts. Clients are initialized at first and the server is initialized later.

Solution 1: trying "subscribe" by a client periodically

This is the easiest way.

const subscribeTimer = setInterval(async () => {
  try {
    const response = await browser.runtime.sendMessage(kSERVER_ID, {
      type: 'subscribe'
    });
    if (response) // Assume that the server returns "true" for subscribing request.
      clearInterval(subscribeTimer);
  }
  catch(e) {
  }
  // If there is no response or any error, retry with delay.
}, 5000);

But this is a bad solution because the addon will try to subscribe infinitely if the server addon is not installed or enabled.

Solution 2: notifying "ready to subscribe" message from the server

This is the one TST does. TST caches subscribers' ID to its private storage, and sends ready type message to them after TST's initialization process is completed. Subscribers just need to listen the ready message, then they will "subscribe" successfully like as:

(Sequence Graph of Successful Initialization Based on Cached Information) (This figure is initially published as a part of the migration story of TST from XUL to WE.)

Here is an example at a client addon to subscribe triggered by a ready message from the server:

// Try to subscribe at onload. This will succeed if the server is already active.
browser.runtime.sendMessage(kSERVER_ID, {
  type: 'subscribe'
});
// Subscribing triggered by `ready`.
// This is required even if the subscribing at onload succeeded, because
// the server addon can be reloaded and you need to subscribe again.
browser.runtime.onMessageExternal.addListener((message, sender) => {
  if (sender.id != kSERVER_ID)
    return;    
  switch (message.type) {
    case 'ready':
      browser.runtime.sendMessage(kSERVER_ID, {
        type: 'subscribe'
      });
      break;
  }
});

This is better than the previous solution, but still there are some problems:

  • The initial try of subscribing can fail if the server addon is installed but not initialized yet.
    • You can solve this problem by providing an option to deactivate integration or an initialization mechanism based on the management WE API.
  • The client never receives ready message from the server, when the server addon is installed after the client is installed. Then you need to reload client addons manually.
  • Too much code for initialization.

Solution 3: providing information of API dependencies by a central server

If the server addon was able to know the list of possible client addons, it was possible that the server addon send ready message to all possible client addons. Who does provides such a list? - No one yet. We addon authors need to start a repository project like the npmjs.com or the cpan.org. Addon authors will register their addons with API information to the repository, then addons can collaborate aggressively with others based on information provided by the repository.

But this idea introduces a new problem: the repository will become the SPOF (single point of failure). So I think this is a worse stupid idea.

Conclusion

I think that client addons may/should send API messages to server addons without any confirmation. And an option to disable such integration will help developers who don't want to see needless errors.

On the other hand, pub-sub communication of WE addons is really complex, and not perfect. The solution 2 for the case 3 looks better than others, but I still finding more better solution.

Tech系Podcast「しがないラジオ」ゲスト出演しました - Jul 03, 2018

「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」略して「しがないラジオ」というネットラジオ(Podcast)があり、マンガでわかるGit等で知られる湊川さんが出演されていたことで僕はその存在を知った(というか「Tech系Podcast」という物の存在自体この時知った)のですが、その後「インフラガール」で知られるナツヨさんも出演されたと知って、(マンガのペン入れなどの言語野を使わない)作業の時にBGM代わりに聞くようになり、いいなあ自分もこういう所に出てみたいなあと思いながらチラチラと感想ツイートを繰り返すなどの小賢しい消極的アピールを続けていた所に、シス管系女子3の発売というタイミングが重なりまして、「それで今日は何かお知らせがあるということで?」「はい、実は最近こういう本を出しまして……」みたいな定番のアレをやるなら今しかないと思って「出たい!」と自己申告し、押しかけでゲスト出演させていただきました。

自分はFirefoxやThunderbirdの法人サポートを業務でやっていますが、エンドユーザーからの問い合わせを直接受けるのではなく、SIerの方やBtoB/BtoC企業のシステム管理部門の社内SEの方がエンドユーザーから受けた問い合わせのエスカレーション先として回答する立場で、Podcastのタイトルからすると脱出を図られる方の分野に近しい所にいると言えます。IT業界への就職や転職を考えている方でSIerかウェブ系かという二者択一で考える人は結構多い印象がありますが、その二者択一に含まれない選択肢もあるんですよ、そんなにキラキラしてないIT業界でも命を磨り減らさずに自分にできる事で生きていく例はあるんですよ、という事を前半では話してみたつもりです。

(Show Noteの注記にあるとおり、クリアコードの立ち上げ時のメンバーは、Podcast中で言っている「3人」ではなく「4人」です。よりにもよって社長をカウントし忘れておりました。直前のタイミングで実施した社内ミーティング(社長欠席)の様子を思い浮かべながら話していたので……事前に準備していない話題をふられると弱いという事が露呈していますね。)

後半では、OSSにコントリビュートするってそんな難しい事じゃないし、やると得られる物がいろいろありますよ、OSS Gateに来て挑戦してみてね、という話や、シス管系女子を制作する時に心がけている事、分かりやすく説明するためのコツやその逆の「べからず」について、あと、自分が(技術のコミュニティ等で)老害にならないためにはどういう事に気をつけたらいいんだろうね、というような事を話しています。とりとめのない話を思いつくままにしているようで、それらの話題が根底では繋がっている、という事が最後まで聞くと明らかになる構成に図らずもなっていて、結構面白い話になっているのではないかと思います。

パーソナリティのgamiさんとzuckeyさんは僕より10歳くらい若くて、過去の出演者陣の中でも僕(35)は最高齢一歩手前なのだそうです。クリアコードは全員合わせても10人しかいないという零細なので特に「昇進」のような概念が無く、「上司」然として部下を率いるような立場になった事が無いので、いつまでも下っ端気分で若いつもりでいてしまいがちなのですが、こうしてはっきり数字で見えてしまうとドキッとしますね。自分が26とかの頃を思うと、10歳とか離れてる上の人は「大先輩のおじさん」みたいな感覚で、緊張して思うように喋れなかったものです。後編では「老害にならないためには」みたいな話をしていますが、いつまでも若いつもりでコミュニティに居座り続けて(経験の差から)俺TUEEEEEして悦に浸るというのもまた老害の別の形ではあると思うので、重々気をつけねばいけないという思いを新たにしました……

 

自分の声を聞く事はあまりないので、終始「ドュフフフフwwww」みたいな感じだったらどうしようと戦々恐々としていたのですが、いい録音機材で録っていただいたお陰なのか、音質調整が巧みなのか、そこまで赤面する事も無く安心して「いやーいい事言ってるなあこの人。誰だ。あっ僕だ」と新鮮な気持ちで聞き返す事ができました。パーソナリティのお二人にうまく誘導していただいた事もあり、終始気持ちよく喋らせていただいて、気付けば朝の集合から4時間近く喋り通しでした。調子に乗ってマウンティングじみた俺TUEEEEE話をペラペラ喋るという、これはこれでまた老害っぽさがものすごい事になっていないか心配だったりもしますが、楽しい時間を過ごさせていただき、自分は大いに満足しております。改めて、この機会を頂きありがとうございます。

凍結されても迷惑行為をやめない人にできる事はあるのか問題 - Jun 30, 2018

この事件に関する報道を見ていた感じでは、限りなく通り魔に近いような物だったという印象だった。迷惑行為を繰り返す→通報される→通報されて凍結とかBANとかの対応を取られる→またアカウントを作り直す→迷惑行為を繰り返す……という事をしていた人が、通報・凍結の頻度が上がって追いつめられてストレスを募らせて、そんな時にまた煽られて、たまたま手の届く距離に来た人がいたから暴発した、という。だから、Hagex氏が公然と通報を煽らなければ良かった、みたいに言う人もいるけど、「人生がうまく行ってる人を見て妬む」みたいなのだってあるわけで、「不用意な発言をしないように気をつけましょう」なんてのは何の役にも立たないアドバイスなんすよね。

 

それはそうと、東洋経済オンラインの記事は「加害者を追いつめすぎるな」という論調だけど、かといって「迷惑行為をさせるがままにして、他のユーザーは彼の迷惑行為の被害を我慢しなければいけない」というわけにもいかないじゃないすか。ごく少数の迷惑なユーザーのせいで、一般ユーザーが離れてしまっては元も子もないし。

AbemaTIMESの動画では、よく炎上する事で知られるウーマンラッシュアワー村本氏が「昔は罵倒してくる人をブロックしてたが、ブロックされた人が逆上して余計に罵倒してきていた。今はミュートするようになって、相手はその事を知らずにずっと罵倒し続けているから、自分は快適で相手もスッキリしてWin-Win」みたいなことを発言していて(うろ覚えです。詳細は違ったかも)、やっぱり、こういう迷惑行為からフツーの人を守る鍵になるのは「ブロックよりミュート」という考え方だと思うんすよね。

自分がブロックされる側になる事があんまり無いからか、多くの人が気付いてないんじゃないかと思うけど、ブロックって「拒絶・否定した」というメッセージを相手に対して表明する行為なんすよ。普通に生活してて、明確に拒絶の意思を表明される事ってそうそう無いじゃないすか。これは多分断られるだろうなあ、断られても仕方ないよなあ、みたいな心構えができてる時ならともかく、前触れも無しに拒絶されたらイラッとする人多いと思うんすよ(僕はそうです)。それまでニコニコしてた人が、NOを伝えた瞬間に逆上するってよくある光景じゃないすか。「自分は相手から否定された」という事をわざわざ相手に知らしめる事は、リスクなんすよね。

もちろん、やっちゃいけない事をした人に「それはやっちゃいけない事だ」と指摘して、行為を改めさせる事は大事です。でも、言ったからってやめる人ばかりじゃないし。むしろ、自分の中で反省する準備ができてない人は、何を言われても頑なになるだけで、反省なんかできるはずが無いし、行為だって改めないし、余計に攻撃的になる事だってあるわけじゃないすか(こういった話は、実際に刑務所等で犯罪者の更生に関わった人が書いた「反省させると犯罪者になります」という本が面白いのでオススメです)。行動を改めも反省もしない人に対して、「あんたはブロックされたよ」「あんたはBANされたよ」とわざわざ伝える事に意義なんて無いわけですよ。

「ミュート」の面白い所は、ここがデジタルというかネットというか非物理的なサービスの面白い所なんだけど、見る人ごとに違う物を見せる機能だという点なんですよね。ミュートしてる人からは、ミュートされた人がいないかのように見える。ミュートされた人からは、自分がミュートされているとは分からない、今まで通りの物が見えている。なので、僕はこう思ったのです。迷惑行為で通報された荒らしユーザーは、サービスを使用する権利を全面的に剥奪される代わりに、単に隔離されて、自分以外の全員からミュートされるようになってたらいいんじゃないのか? と。そうすれば、迷惑行為をはたらく人は今までと変わらずに迷惑行為(と主観的には感じられる行為)をしてスッキリできるし、他の人は迷惑行為から守られるし、Win-Win。もっと言えば、サービス運営者も「迷惑な人」一人分のPVを失わないで済むのでWin-Win-Winかもしれない。

ただ、相手の反応なんかお構いなしに暴れ回る人ならそれでいいんだけど、反応される事が自分の快楽ループに組み込まれてる人だと、「無視するんじゃねー!!」と逆上してしまいかねないという問題は残る。これをどう解決すればいいか。

スラドのように、他人からの評価がマイナスの人は「デフォルトでは見えない」「わざわざ見ようと思って見る物好きは見れる」というシステムになっていれば、何かしらの反応はある状態を維持できるかもしれない。でも、本人を逆上させないためには「自分の評価がマイナスという事を本人に知らせない」事が大事と考えると(スラドはそうはなっていない)、荒らしを自ら覗きたがるような意地の悪い物好きだもの、「あんた評価マイナスで見えなくなってるよ」とわざわざ告げ口しかねない。告げ口は無粋、黙って観察せよ、というスタンスの「ウォッチャー紳士」ばかりではない。だから「人に見させる」のはやっぱりリスクだと思う。

それで考えたんすけど、ここはひとつ、今流行りの機械学習でもって「荒らしがされたい反応だけを返す人」を演じるbotも用意して、「一般ユーザーが見てる世界」と「荒らし本人(達)と、それに反応するbotだけの世界」とを用意してみるというのはどうでしょうか。実際、自身が隔離されているという事を本人が認知できるという点を除けば、GTAタイタンフォールといったオンラインゲームにはそれに近い仕組み(違反者とNPCだけがいる、「負け犬サーバー」とか「チータープール」と呼ばれる物)があるそうだし。専用ワールドを維持するコストはかかるけど、Twitterやはてブのように人の悪意が増幅・拡散されやすい仕組みのSNSでは、人の命がかかってるんだから、社会に対する義務を果たすための必要経費として容認してもよいのでは? なんて思っちゃって。

……という事を考えてはみたんですが、自分で言っててすごいディストピア感ありますね。だって、何も言われずに隔離されて、その事に本人で気付けないって、自分で行動を改める機会を奪われるという事だもの。ある意味非常に冷酷で残酷な措置だ。主観的には幸せかもしれないけど、客観的には哀れですよね。というか、そういう物が既に実用化されていて、自分自身も既にそういう世界に隔離されてるんじゃなかろうか? と思うと、背筋が薄ら寒くなってくる。

 

もっと生産的に考えると、単に荒らしがされたい反応だけを返すbotにするんじゃなくて、カウンセラーのように振る舞うbotにするというやり方もあるかもしれませんね。つい最近、カウンセラーにも当たり外れがある(誰もが人間的にできたカウンセラーばかりでなく、未熟で技能的にも不適格な落第カウンセラーもいる)という話を見かけたけど、botだったら「自身の感情」に流されずにカウンセラー役を淡々と勤め上げられるでしょうから。どうでしょう。まだまだSFの世界の話すぎますかね?

セクハラを「軽い気持ちでやってしまう」人、の考える事:自分の場合の振り返り - Jun 28, 2018

このエントリは、女性エンジニアの権利を守りましょうとか差別よくないよねとかの社会に対する語りかけとは本質的には関係無い、個人的な述懐です。

女性エンジニアの差別やハラスメントの話と、それをきっかけに考えた差別やハラスメントそのものの話と、立て続けにクッソ長文を書いてしまったのですが、自分でもちょっとどうしたのと思う部分はあります。

「自分がやってる事まで一緒くたにされると困る」「下手したらこっちにまでとばっちり来そうだから先に釘刺しておきたい」みたいな自己保身、予防線というのも動機の一つではあったのですが(その割に、「シス管系女子なんてタイトルの物を作ってる奴がどの口で言うんだ」みたいな明らかに文章を読んでない反応もあったので、藪蛇にしかならなかったのかもしれませんが)、やっぱり最大の動機は、過去の自分を恥じる気持ちが強いからなんだと思います。

自分が言及した記事の反応(の一部)僕の書いたエントリへの反応(の一部)なんかも、見てるとほんと辛いんですよね。憤慨してる人がいる一方で、何が悪かったのか全く分からないという人がかなりいて、それが過去の自分にものすごくそっくりに思えて。なので、「過去こういう中の一人だった自分だからこそ、こういう人達に届く表現ができるのではないだろうか?」と思って、色々な言葉でなんとか表現してみようとしたのでした。結果はお粗末でしたが。

続きを表示する ...

差別性・ハラスメント性は「どこかの極悪人」だけの物じゃなく皆が持つ物なんだよという話 - Jun 24, 2018

1つ前の女性エンジニアうんぬんの話のエントリの反応を見ていて、「これは差別だ」「これは差別ではない」という軸での対立が見られる事に気がつきました。

そもそも僕が書いたエントリ自体もざっくり言えば「これは差別だ」派に属しているわけですが、それに対して「これは差別ではない」派の方からの言及があり、その対立軸を自分自身がよりはっきりと意識する機会になりました。

  1. Y社のエンジニア炎上について思ったこと -「女性エンジニア少ない問題:元増田
  2. Y社のエンジニア炎上について思ったこと 続き:僕の1つ前のエントリへの言及
  3. それへの僕のコメント
  4. 僕のコメントへの返信

このやり取りを見ると、僕が長文で書いた事の諸々のうち大筋では「これはよいこと」「これはよくないこと」という認識が双方で共有されているものの、「元発言が差別か否か」という点で決定的に認識が対立しているようである事が読み取れます。

自分としては、「こういう点で問題があるから避けよう」「こういう理由で問題無いからこのままやろう」という線引きが明らかになる事で、同様の「やらかし」が世の中から少しでも減りつつ、「なんか炎上しそうだから……」という漠然とした不安からの萎縮も減ってくれる事が望みなので、敢えてこれ以上の事を続ける必要も無いかなとも思うのですが、その一方で、肯定派と否定派の対立が一点に集約されるのも興味深い話だと思ったので、自分の思う所を改めて記しておこうと思います。

あと、自分はこれを「差別」と「ハラスメント」の両方にまたがる話と捉えており、両者は同じ物事の異なる面であって不可分と考えているので、このエントリでは「差別」と「ハラスメント」をワンセットで取り扱う事にします。

続きを表示する ...

女性エンジニア少ない問題を解決する話、の何が問題なのか - Jun 22, 2018

自分の観測範囲で「女性エンジニア少ない問題」を解決するために、機械学習で男性エンジニアを女性に変換する - ログミーTech(テック)という記事が話題になっていたので見たら「アチャー……」としか言いようがなかった。

概要を説明すると、技術職の男性の発表で「職場に女性がいないとやる気が出ない」「女性エンジニア増やしたい(※文脈的にはITエンジニアという意味のようでしたが、ITに限らず言える事のようなので、以下の文でもそのまま単に「エンジニア」と表記します)」「本物の女性エンジニアを増やすのは人材育成のコストがかかる」「なので機械学習で声質変換を実現した。男の声で喋った内容に対応する女声の音声を出力する仕組みを作った。」という話です。技術的には多分大したことなんだと思う(自分は機械学習には詳しくないのでよく分かってない)けど、その発表の「掴み」のための話が技術の良さを台無しにしていると思いました。

これに対して、自分の観測範囲では「懲戒処分ものだ」とか「この程度で過剰反応しすぎ」とか色々な反応が見られましたが、賛否どちらにしても「何が問題なのか」という点がきっちり共有されていない印象を受けたので、その点にフォーカスして覚書を残しておきたいと思います。「なんかよくわからんけど、この辺の話題は怖いから触れんようにしとこ……」みたいに腫れ物扱いして萎縮してしまわないで済むよう、こういう根拠でこう言えるからこれは改めようとか、こういう根拠でこう説明できるからこれはそのままでいいとかの、明確な判断をするための材料の一つとして読んでもらえたら幸いです。

 

最初に明記しておきたいのですが、僕はこの発表を行った彼個人をやり玉に挙げて個人的な責任を問うべきとは思っていません。詳しくは後述しますが、これを通過させたチェック体制の方だったり、社風だったり、あるいは社会の風潮だったり、そういう事の方にずっと重い責任があると思っています。(そして、彼の所属組織にもイベントの主催団体にもメディアにも自分は全く関係ありませんが、別の所でその責任の一端を自分も負っている、と思っています。)

(28日追記)また、この件を非難している人は必ずしもジョークを解していない訳ではないという事も、本題に入る前に明記しておきます。恐らく発言者の彼にとっては「女性エンジニア云々は技術の本題に入る前のただの枕のジョーク」という認識だったと思いますし、擁護している方も「ただのジョークじゃないか」と思っている様子が窺えますが、批判している人の多くはこれを「悪質なジョーク」として批判しているのだという事は、最初に押さえておくべきポイントです。

続きを表示する ...

私達はここまで来た - Jun 06, 2018

昨年10月のFirefox 57リリース直前の時期に、アドオンのWebExtensionsへの移行を主導してきたAndy McKay氏がそれまでの歩みを述懐して書かれたブログ記事の勝手訳です。


私はMozillaに在籍してきたこの7年の間に色々な事をやってきました(訳註:Mozilla Add-onsに始まり、Firefox OS用のマーケットプレイスとその支払いの仕組みに関わった後、Mozilla Add-onsとWebExtensionsに戻ってきた、とのこと)。 ほんの2年前、私はアドオンコミュニティをWebExtensionsに移行させるという、Mozillaに参加して以来で私にとって最大のプロジェクトを任されました。 あと3週間ほどのうちに、Firefox QuantumはすべてのFirefoxユーザーの元に届けられ、WebExtensionsはFirefox 57においてアドオンを実行するための唯一の方法となります(訳註:その後、2017年11月14日にリリースされた)。

これは、物事を変えると決めて一緒に取り組んできたMozillaの人々の素晴らしいチームによる、2年間の努力の成果です。 私はその最初の数週間、何でこんな事になってしまったんだ?という、とんでもない恐怖の感情に駆られた事をはっきりと覚えています。 多くの人がこのプロジェクトにおいて私を助け支えてくれましたが、特に私が思うに、Kev Needham(訳註:Mozillaでプロジェクトマネージャを務めている人)が我々を導いてくれなかったら、私達は救いようのない状態に陥っていたでしょう。 私がその最初の数週間のパニックと恐怖に陥った時に、Kevと何度か対話した結果もう少しマシな状態に戻る事ができたというのは、その好例です。

最初の数週間は私達のエンジニアリングチームにはKumar McMillan、Stuart Colville、Matthew MacPherson、そしてKris Maglioneがおり、外を出歩いて更なるエンジニアを見つける事が、その月の私の主な目標でした。 その後すぐにChristopher Grebs、Mathieu Pillard、Mark Striemer、そしてLuca Grecoが加わってくれました。 私達が働き始めた最初の週には、2016年のベルリンにMatthew Wein、Andrew Swan、そしてBob Silverbergもいました。 後にShane CaraveoとAndrew Williamsonが参加してくれたのも、私達にとってはとても幸運な事でした。 様々な分野の知見と技術力を備えた彼らエンジニアの能力は誇張するまでもなく、彼らが成し遂げられた事は驚くべき事です。 私は彼らがなした事のすべてをこの記事に列挙したかったのですが、それをすると記事がとんでもなく長くなってしまうでしょう。 私達がやった事やWebExtensionsのアドオンを書く事に関する多数のブログ記事をぜひ読んで下さい。

私にとっては、個人としてこのプロジェクトを受け入れないという選択は取り難かったのですが、この決定に反対する人達も大勢いました。 彼らは様々な異なる方法で定期的にその事を私達に知らしめようとしました。 私がMozillaに在籍するようになってから、これほどまでに激しい反対に遭った事はありませんでした。 Mozillaの他の人達が取り組まなくてはならなかった色々な事に対し、私は本当に感謝しています。

それらの懸念の声の周りを進む事は非常に大変で、時には私は舵をうまく取れず、その体験自体も助けになりませんでした(訳註:苦労したわりに得られる物が無かったという事か?)。 学習曲線がそうであるように、最初からはうまくいかない物です。

その一方で、この決定に同意してくれた他の人達による手助けは素晴らしい物でした。 ちょうど先週トロントで、複数の人々が私達の方にやってきて、私達がやり遂げた変革に対して感謝を述べてくれました。 助けてくれた皆さん、本当に、本当にありがとうございます。

私は今も、これが私達がFirefoxに対してできる最善の事の一つだったと強く確信しており、成し遂げた事を私は誇りに思っています。 それは大きな変革であり、リスクと不確実性を伴う物でした。 控えめな表現をすると、これが今後どう進んでいくかについて、やや神経質になっている部分はあります。

でも、私達はもうここまで来ました。3週間後にはFirefox Quantumがリリースされ、そこにはもうレガシーなアドオンは存在し得ません。


以上、Andy McKay氏のブログ記事の訳でした。

WebExtensionsへの完全移行に伴うレガシーアドオンの廃止については、アドオン作者や一般ユーザーから強い反発がありましたが、Mozillaの外からだけでなくMozillaの中からもそういった反発があったというのが興味深いです。

氏はその後、今年の3月にGitHubに移籍されています。そのGitHubが今度はMicrosoftに買収されて、間接的にMS資本の元におられる状態になっているという事で、不思議な運命を感じますね。

1つ前に訳したroc氏のブログ記事では、「Geckoを捨てWebKitに移行するべきだ」という破壊的な提案が述べられていましたが、そちらは実現する事はありませんでした。それと、このレガシーアドオンの大量死と大混乱をもたらしたWebExtensionsへの移行という大転換との間には、「最後までやり遂げて実現させたか、させなかったか」というだけの違いしか無いのかも知れません。

ただ、XULの中にはXPCOMと密に結合した部分も多々あり、XULの一切合切をWebKitの上に移植するのは現実的ではなかったのでしょう。仮に本当に互換性を保つ形でやるとしたら、相当に分厚い互換レイヤがWebKitの上に乗っかる事になり、そのオーバーヘッドは無視できないレベルだったのではなないでしょうか。あるいは、オーバーヘッドをなくすためにGecko上のXPCOMやXULとの互換性を犠牲にしていたら、結局それに合わせるための作業がXULアプリやアドオン側にも発生するわけで、それだったら最初からWebKitに親和性が高い形で作った方がなんぼかマシという事になっていたでしょう。いずれにしろ、roc氏の予想にあったような「WebKitの高性能さとXULの資産のいいとこ取り」は絵に描いた餅に過ぎなかったのだと僕は思っています。

Andy氏には、2016年のAll Handsにお声がけを頂き、現地でお会いした際には、グループディスカッションの場では英語のやり取りが速すぎてついていけなかったので、その後一人になられた時を見計らって捕まえて、「アドオン同士の連携を取れる事が大事なんだ」という事をつたない英語で一生懸命伝えた(同じような事をLuca氏にも言った)のを覚えています。

自分はこの記事が書かれる1ヵ月弱前にツリー型タブのWebExtensions版をリリースしましたが、「もうグダグダXULにしがみついててもしょうがない、やるしか無い」と腹を括って重い腰を上げ、他のアドオンとの連携を意識したAPIも備えた物をリリースするに至った背景には、その時Andy氏やLuca氏等と直接話して感じた「ああ、この人達は本気で物事を良くしようとしてるんだな」という心意気……みたいな? そういうのを感じて、こちらも相応の物で応えねばなるまいと思ったから、というのも心のどこかにあったのだと思っています。

1つ前の翻訳記事にも書きましたが、WebExtensionsによってFirefoxとアドオンが明確に切り離された事は、FirefoxおよびGeckoの抜本的改革を進める上でプラスに働いているという事を最近とみに実感します。 実際、Firefox 59からFirefox 60にかけての間でも、タブバー周りの実装からXBLが取り除かれるなどのかなり大きな変化がありました。 今までであれば(WebExtensions版より前のツリー型タブなどの)アドオンの互換性が損なわれたという事で大騒ぎになっていた(僕がグダグダ噛み付いていた)かもしれません。 そういった一切がWebExtensions APIの向こう側に隠蔽された事によって、アドオン作者は安心してアドオンの開発に集中できるようになっているという現実を見るに、レガシーアドオンの廃止とWebExtensionsへの移行はやはり必要だったという事を改めて感じる次第です。

(2018年6月8日追記。大袈裟だ、WebExtensions移行を正当化したいだけのこじつけだ、と思う人もいるかもしれませんが、最近実際にあったFirefox 61での後退バグとその原因の例を見るに、XULアドオンの仕組みのデメリットは色々あったという事は否定できないと思っています。)

というか、最近久しぶりに仕事でレガシーアドオンを触る事があって、「もうこんなの作りたくない……WebExtensionsで書かせてくれ……」と思ってしまいました。最初あれだけ渋ってたのに、今じゃすっかり骨抜きですよ……

古代のブラウザ戦争の歴史:MD5ハッシュ化された投稿の機密解除 - Jun 06, 2018

Robert O'Callahan氏(Mozilla内では愛称の「roc」でもっぱら通っていたようです)が1月に公開されたブログ記事をえっちらおっちら勝手に訳してみました。多分誤訳してる所があると思うので、間違いを見つけた人は指摘して頂けると幸いです。

roc氏はFirefox以前から長くMozillaに関わっておられていた重鎮中の重鎮の一人で、現在もFirefoxの日本語入力関係のコードを手がけておられる中野さん曰く、「何かGeckoで分からん事があったらとりあえずrocに聞けば答えが返ってくる」みたいな、Mozillaの低レイヤ周りの生き字引とも言えるような方です。roc氏は2016年にMozillaを退職されたのですが、最近になって、回顧録的に上記リンク先のブログ記事を公開されました。10年くらい前の、WebKitが登場してきてめちゃくちゃ持て囃されてFirefox(Gecko)から一気に人気をかっさらい始めた時期の、ライバルのキラキラした様子を横目で見ながら、クソコードの山だったGeckoにそれでも関わり続けないといけなかったやるせなさから来る、ヤケクソな感じが吐露されていて興味深いです。

「ブラウザ戦争」と題されていますが、これはIE6の牙城を崩すべくFirefoxやChromeやOperaが競っていた頃の、第二次ブラウザ戦争と言われたり言われなかったりする物の事です。MosaicとNetscapeとIEが争ってた頃の方は第一次ブラウザ戦争で、そっちはそっちでまためちゃくちゃ面白いので、「マイクロソフトへの挑戦 ~ネットスケープはいかに してマイクロソフトに挑んだのか~」や「Webの創成」あたりを読むといいと思います(どっちも絶版ですが)。


2007年から2008年はMozillaにとって興味深い時期でした。 市場において、Firefoxは健闘しており、IEの牙城を着実に崩しつつありました。 その一方で、技術面においてはそううまくいっていませんでした。 WebKitが性能面と機能開発の迅速さで私達を追い越していたのです。 Geckoが設計上のミスと技術的負債に悩まされている一方、WebKitはOSS開発者達の心を掴んでいました。 私達はGoogleがWebKitベースのブラウザを開発中だという事も、それがWebKitの市場シェアの少なさという問題を解決するだろうという事も知っていました。 私は強い懸念に囚われ、しばらくの間、MozillaはGeckoを捨ててWebKitに全面移行する事に挑戦するべきだという意見を持っていました。 私がこういう事を大声で言うとプロジェクトに深刻なダメージがあるだろうと思い、私はこの事をごく少数の人にだけ話していました。 公的には、私は不公平な攻撃からGeckoを擁護していましたが、私自身の全体的な判断と矛盾しないように気を配っていました。

私だけがGeckoについて悲観的だった訳ではありません。 Mozilla内部では、「Mozilla 2.0」というお題目を掲げ、自動リファクタリングツールによる分析のような、私達の技術的負債を減らすための近道になる方法を求めて、かなりの時間を費やしていました。 Mozilla外部においては、ライバル達はエンジン開発の面で私達を早急に追い越す事を目指していました。

蓋を開けてみると、私達はほとんどすべての事について間違っていました。 私達は銀の弾丸を見付ける事はできませんでしたが、ただただ大変な頑張りによって、Geckoはライバル達を驚かせる程度には地位を保っていました。 また、時間の経過と共にWebKitの弱みも明らかになってきました。その場凌ぎの省略によって性能は底上げされ、いくつかの互換性テストの上で優位に立ってはいたものの、それらは同時にWebKitにとって技術的負債にもなっていました。 GoogleはWebKitプロジェクトを加速させましたが、AppleとGoogleの軋轢は問題をも生み、最終的にはBlinkというフォークが生まれる結果となりました。 Firefox 57への市場の反応は、FirefoxOSに対する誤った投資という大きな迷走の後においても、Geckoが今日においてもまだ競争力を持ち続けている事を示しています。

ここでの1つの教訓は、内部にいる人は古いコードベースに基づく見通しから、過度に悲観的になり得るという事です。 献身的で有能なスタッフの長年に渡る働きは奇跡を生む事があり、その一方で、あなたのライバル達は彼ら自身で問題を生み抱え込んでしまう事もあります。

もう1つの教訓として、2007年から2008年にかけて私はIE(そしてFlash、WPFも)を倒す事に過度に集中しており、全てのオープンソースのブラウザがたった1つのエンジンの実装を共有する事になったとしても、それはWebにとってそれほど大きな問題ではないと思っていました。 でも今では私はすっかり意見を変えました。 エンジンにおいてより多くのコードを共有する事は、不具合の共通化までをも招くため、真に独立した実装を持ち続ける事は非常に重要なのだと。

私は、Brendan(訳註:Brendan Eich。Netscape時代からの古参でJavaScriptの開発者だが、同性婚反対の運動への寄付がきっかけとなって2014年にMozillaを追われた)や他の人達が、私の意見を取り入れなかった事によって、Mozillaを誤った道へと導くという過ちを私に犯させずに済ませてくれた事に、非常に感謝しています。 もしそうなっていれば、それは誰にとっても大きな災いだったでしょう。

鬱憤ばらしと、記録を後世に残す事を意図して、私は2007年から2008年にかけて、私の考えを説明する4つのブログ記事を書き、それらのMD5ハッシュだけを公開していました。 Firefox 57のリリースの成功の余波がある今は、それらのブログ記事を無害な状態で機密解除するのにちょうどいい時と言えるでしょう。 くれぐれも、私は既に意見を変えているという事を心に留め置いておいて下さい。

続きを表示する ...

「ツリー型タブ」が、Firefoxのアドオン管理画面にオススメとして表示されるようになりました - Jun 04, 2018

標題の通り、ツリー型タブが、Firefoxのアドオン管理画面にオススメとして表示されるようになりました(メールインタビューでやり取りしたScottさんが教えてくれた)。一定期間で入れ替わるやつなのでそのうちまたどっか行くと思うけど、記念に記録を残しておきます。 (証拠画像:英語版) (証拠画像:日本語版)

最初に書いておくと、このエントリはただの自慢です。こういう所に注目してくれる人はどこにもいないので、自分で解説して「僕TUEEEEEE」とアピるという物です。


統計データ上ではFirefoxの全ユーザーの中でアドオンを使っている人は意外と多くなくて、せっかくアドオンがいろいろあるのだから認知を向上させたい、というのがMozilla的には一つの課題のようです。2016年のAllHandsで既に、「アドオンをインストールするまでのハードルを下げたり、アドオンのインストールというよりも機能のON/OFFのように見えるようにしたりするといいのでは?」という方向でリニューアルを進めているということが通達されていて、現在のMozilla Add-onsやアドオン管理画面はその時見たモックほぼそのままのデザインが踏襲されています。

その時見た「機能のON/OFF」の選択肢の中に自分が作ったアドオン、特に「ツリー型タブ」が登場しているというのが、何とも感慨深いです。

というのも、WebExtensions版を作った時の苦労話の冒頭に名前が出てくるTBEより若干マシになってはいたものの、ツリー型タブもアドオンとしての「お行儀の悪さ」はなかなかのものでした。Firefox本体の関数をガンガン置き換えるわ、eval()で関数の行単位でモンキーパッチを当てまくるわ……なのでMozilla Add-onsのレビューポリシー的に「一般向けのアドオン」としては認められず、サイト上の検索結果等には表れない「開発者向けアドオン」の地位に長く留まっていました。TBEやツリー型タブのせいで(互換性を壊すとクレームがMozillaの方に来るから)Firefox本体の大規模な改修が阻害されていた、という部分ももしかしたらあったかもしれず、恨まれたり疎まれたりしていてもおかしくないくらいです。

そういう背景を持つツリー型タブが今、Mozilla Add-onsのバリデーションでエラーも警告も一切無く、Firefoxを使っている人がアドオン管理画面を開いたら目に入る位置に、広告ブロック等の桁違いのメジャーな選択肢に紛れて表れている現状を見ると、「ずいぶん立派になったもんだ……」と思うわけです。


ところで、苦労話に書いた通り、ツリー型タブのWebExtensions版は同様のWebExtensionsベースの縦長タブバー型アドオンとしては最後発と言っていいくらいに遅れて登場しました。いま自分が把握してるだけでも、サイドバー内に縦型のタブバー風UIを表示するアドオンは他にもこれだけあります。

それらを差し置いて何故ツリー型タブがおすすめになっているのでしょうか。選考過程は関知していないのであくまで憶測ですが、「これらの中ではツリー型タブが一番クソ真面目にFirefoxのタブバーを真似てるから」ではないだろうか、と自分は考えています。

実際に自分自身で上記の縦型タブバーアドオンをいくつかを試してみると、「みんな意外と適当だな……?」という印象を受けました。例えば以下のような具合です。

  • 見た目・配色がまずFirefoxのタブと大きくかけ離れている。
  • リンクをサイドバー内にドラッグ&ドロップしても、タブとして開かれない。
  • リンクをサイドバー内にドロップすると、ドロップ位置ではなく常にタブバー末尾に開かれる。
  • コンテキストメニューが無い。
  • コンテキストメニューがあるが、項目の並び順がFirefoxのタブバーの物と違う。
  • 音声をミュートしたタブの表現の仕方が独特。
  • Firefoxのタブバー上のタブの並びとサイドバー内での並びが一致しない。

ツリー型タブはどうかというと、基本的に見た目も挙動も全部Firefoxのタブに合わせるようにしています。技術的に不可能な事以外は、Firefoxのタブバーでできることは全部ツリー型タブでも同じようにできるようにする、という方針です。何故かというと、平たく言えば「そうじゃないと自分が使えないから・使う気にならないから」です。だってイヤじゃないですか、たかが個人開発のアドオンごときのために今まで覚えた物全部捨てて一から順応しなきゃいけないなんて。

もう少し格好を付けて言うと、度々述べていますが、UIの実装時には既存の何かに合わせるのが鉄則で、必要のない中途半端な自己主張はユーザーにとっては邪魔でしかない、と僕は考えています。コンテキストメニュー項目の並び順にせよミュート状態の表示の仕方にせよ、「Firefoxのタブと違う」という事それ自体が学習コストを引き上げ、使い勝手を悪くします。メニュー項目の並び順などはその典型で、人は普段よく使うメニュー項目を「だいたいここら辺」というような視覚的な位置で記憶しているようで、並び順が違うとそれだけでもう目当ての項目を見つけられなくなります。まったく違うならそれはそれで覚え直せばいいのですが、中途半端に似ていると、両方の記憶が混ざって余計に悲惨な事になります。似せるなら半端に似せないで完コピする、「俺の考えた最強のUI」を披露したいというエゴは捨てる、というのが、既存の何かに対する「改良版」と言える物を作る時に必要な心がけだ、と僕は思っています。

こういう所って、頑張れば頑張るほど違和感が無くなって既存の物に溶け込んでいってマジで誰にも気付いてもらえなくて報われなくて、それだけならまだしも、こういう事を頑張る事の価値自体が認識されなくなって誰もこういう所を頑張ろうとしなくなるんじゃないかということを心配してるので、ダサいとは思いつつ折に触れてアピっておく次第です。


また話は変わりますが、Google Chrome向けにもツリー型タブの代替になりそうな拡張機能はいくつかあるものの、どちらも自分にとっては「コレジャナイ」感が強くて、Chromeへの移行を考える材料にはなりませんでした。

どのあたりが「コレジャナイ」なのかは上手く言語化できないのですが、上記のような点が理由なんじゃないかなあとなんとなく思っています。Chrome全然使ってないから憶測ですが。

今見てみたところ、これを書いている現時点でのTabs Outlinerのユーザー数は13~14万人くらい、ツリー型タブのユーザー数は12万人くらいらしいです。Firefoxより圧倒的にユーザー数が多いはずのChrome用拡張機能ですから、ユーザー数に何倍も差があってもおかしくなさそうですが、実際にはこのように案外健闘しているようだというのが興味深いです。元々こういうタイプのUIに順応できる人やこういうUIを求めている人の絶対数がそのくらいという事なんでしょうか? とりあえず今のところは、「Chromeユーザーの中でこれらの拡張機能を使ってる人の割合より、Firefoxユーザーの中でツリー型タブを使ってる人の割合の方が多いという事は、ツリー型タブの方がユーザーに選ばれているという事に違いない!」と勝手に自慢しておこうと思います。


という、最初から最後まで自慢でしかないエントリなのでした。

技術書典4に参加して「まんがでわかるLinux シス管系女子3」とかグッズとか頒布しました - Apr 23, 2018

去る2018年4月22日、東京・秋葉原UDXにて開催された技術同人誌オンリーイベント技術書典4に、サークル「シス管系女子会」として参加してきました。無駄にパトロン枠での参加でした。

毎度、シス管系女子の草の根的な営業活動とファンサービス、あと〆切を設けることで何か新作を作るモチベーションにするという目的で参加していますが、今回も結果のほどを記しておこうと思います。なお、技術書典、技術書典2の結果、および技術書典3の結果は過去記事をご参照下さい。

数字的なこと

今回の数字は以下の通りでした。一般的な技術同人誌のサークルというよりも、一般書店で購入可能な商業出版物メインの企業参加者の例という感じで見て頂いた方が良いと思います(申し込みは自分が個人的にやっていますが、商業出版物は日経BPの委託販売という形で、売り上げもそっくりそのまま渡しています)。

技術書典2の時に作成した、サンプルを兼ねたチラシ形式のリーフレットも持ち込んではいました。ただ、こちらは前回に引き続き今回も積極的にばらまかなかったので、数としてはほとんど出ていないと思います。

今回特筆すべきは、本の持ち込み分が早々に完売してしまったという事です。特に「シス管系女子3」は、当初持ち込み分60部は11時の開場から12時50分頃までの間に払底してしまい、途中で日経Linux編集部にあったという19部を急遽追加してもらいましたが、14時30分の頒布再開後14時58頃までの間になくなってしまいました。本が無くなって以後も何度か「3を……えっもうないの」的な反応を頂いていて、数だけは多く用意できるはずの商業出版物であるにも関わらず、せっかく来ていただいたのに申し訳ない限りです。一応、Amazon等の通販や書泉ブックタワー等会場近くの書店でも普通に入手できる旨は案内させていただきましたが……

持ち込み部数は前回までの実績を踏まえて検討した結果だったのですが、晴天に恵まれてのべ参加者数が倍増した事と、今回の新刊である「シス管系女子3」が4月19日発売でこれ目当てに来て下さった方が相当数いらっしゃったようだという事から、全く想定外の売れ行きとなりました。新刊が多めに出るのは想定の範囲内でしたが、既刊も前回参加時より多く出ており、全ての本が15時台にはなくなってしまいました。やはり天候の効果は大きかったようです。グッズも、ステッカーは頒布価格が高めだったので10〜20ほど出ればいいくらいかなと思っていたのですが、気がつくと半分程なくなっていました。タイツは……元々あしピタが本命の物なので、まあこちらは想定の範囲内ですね。

スペース設営のこと

今回は商業誌3冊に加えてグッズも並べる必要があったのですが、今までのやり方だと確実に場所が足りなくなるので、どうにか縦方向にディスプレイする方向で工夫してみました。

まず本を縦にディスプレイする方法ですが、既製のイベント展示用の雛壇を調達しました。できれば何度も使える耐久性の高いプラスチックや金属や木の物を調達したかったのですが、ちょうど良さそうな物は品切れだったり、微妙にサイズが合わなかったりしてなかなか良い物が見つからず、最終的に選んだのはIGARASHI PROというメーカーの段ボール製組み立て式雛壇でした。本来はイベント毎に使い捨て前提の製品のようですが、それは勿体ないので、両面テープで固定する部分をマジックテープで置き換えてバラして持って帰れるように改造しました。また、結構奥行きがあってこれを置くと平積みのスペースを確保できないため、一番手前の段を潰すことにしました。

タイツは普通に置くと滑り落ちて危ないので、普通の店舗でワゴンセールになってる物のように縦にしてケース(たまたま家にあった未使用の不織布製収納グッズ。ある程度の柔軟性がある)に詰めて、その後ろに背の高いディスプレイでサンプルを展示する形にしました。高さを出すための物は最初は段ボール工作を考えていたのですが、もえじら組の最初のイベント参加の時に買ったスチレンボードの残りが出土された(10年以上前の物……)ので、それを切り貼りして適当に作りました。

後ろ側は紙製の簡易スタンド(同人誌の見本や値札を立てかけるために使われるような物)ですが、高さがある分倒れやすいので、後ろの方に足を延長してバランスを取ってみました。

POPは、タイツがネタグッズなのでそれに合わせる形でヴィレヴァン風POPの作り方を参考にそれらしい物を作ってみました。手書きでやる自信が無かったので、青地の部分をたぬき油性マジック、それ以外の部分をふい字Pで「手書き風」にしました。ロゴは、フォントの形状がヴィレヴァンのロゴの物に似ているとして紹介されていたHelvetica Ultra Compressedベースで作成しています。

(POPのひとつ。「ステッカー MacBookでなくても貼ってええねんで? 800yen」の表記あり。)

本物のヴィレヴァンPOPには値段は書かれていないようですが、今回は値段も一緒に入れてしまっています。

「完売しました」のお知らせをその場で書いたりするのに、何も書かれていない白紙の状態の物も用意しておけばよかったなあ……と思いましたが、後の祭りでした。

物を作るモチベーション維持のこと

技術書典への参加目的の1つは何か作る事へのモチベーションを高めるという事なのですが、今回はちょうど「シス管系女子3」の作業とタイミングが重なったため、これをモチベーションに作業を進めていました。

まんがでわかるLinux シス管系女子3 (日経BPパソコンベストムック)
Piro(結城 洋志)
日経BP社 (2018-04-19)
売り上げランキング: 1,552

元々は、この1週間後くらいの発売予定で作業スケジュールが組まれていたのですが、そうなると技術書典の直前くらいは作業の大詰めで何も他の事ができそうになく、技術書典合わせの何かコピー本を用意するという事ができない&「シス管系女子3」も間に合わないという最悪の事態になってしまう事が予想されたため、〆切を早めてもらって発売日をイベントの前に変更、イベントにも新刊として持ち込むことができました。冒頭のプロローグの構成をギリギリで変更する事になったり、目立つ所では裏表紙の大野先輩のスカートのテクスチャが抜けた状態になってしまっているなど詰めの甘い箇所が残ってしまったりと、心残りもいくつかありますが、本来の価値である技術の本としては申し分ない物にできたのではないか……と自画自賛しています。

また、〆切が手前にずれた関係でイベント直前に2週間ほどの余裕が生まれ、コピー本は無理でしたがグッズを用意することができました。

なお、グッズ類は現在BOOTHで通販もしています。会場に来られなかった方や、会場で見落とされていた方は、こちらからご注文いただければと思います(あんしんBOOTHパック利用のため、こちらに個人情報が伝わる事はありません)。グッズがなければBOOTHを使ってみる事もなかったので、これも技術書典がきっかけで活動の幅が広がったという事だと言えそうです。今後は、過去に少数だけ生産したブックエンドもラインナップに加えられたらなあと思っています。

会場での反応のこと、新刊への反応のこと、今後のこと

毎度書いている気がしますが、会場では読者の方に何度もお声がけをいただき、大変ありがたかったです。紙媒体の商業出版物でしか読めない連載ということもあってか普段あまり感想を見聞きする機会が無く、こういう場で「1も2も持ってます」「3をずっと待ってました」のようなありがたいお言葉を頂けると、大変励みになります。

また会場外でも、今回の「シス管系女子3」についてはWeb上、というかTwitter上で今までにない量の反応を頂けている印象があります。2年前にWebサイトTwitterアカウントの運用を開始して以降、自分にできる範囲で地道なプロモーションとも言えないようなプロモーションを続けてきましたが、その間湊川さんや沢渡あまねさん、ビタワンさん、ナツヨさん(※今回イラスト内のキャラクターの使用許可を頂いた方々)、他にも数多くのフォロワーの方々に度々告知やアピール文を拡散していただけていて、その影響がこうして目に見える形で表れてきたという事なのではないかと思っています。皆さんのご厚意に感謝するばかりです。

正業の傍らでの短いページ数の連載、しかも掲載媒体の日経Linux誌が月刊から隔月刊になったということで、今まで以上にページ数が溜まるスピードが落ちる事が予想され、次の本が出るとしたら一体どのくらい先になってしまうのか全く見えない状況ではありますが、今のこの気持ちを忘れないで、腐らず歪まず続けていければと思っております。皆さん本当にありがとうございます。(……と感謝の意を激しく表明すると「最終回」っぽさが漂ってしまいますが、別にそんな事はなく実際これから次の回の作業に入らなくてはいけないので、今後とも見守っていただけましたら幸いです。)

余談

どういう訳か、スペースにお越しの方に「マンガで分かるGitのスペースはどこですか」と訊かれてしまいました。それは僕じゃなくて湊川さんなんです……タイトル似てますが別作品です……

Page 1/241: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき