博多電光

blog.hkt.sh

祖母が他界しました

さる9月9日、母方の祖母が他界した。

穏やかな往生だった、と聞いている。かねてより病状の芳しくなかった祖母は市の療養所で長いあいだ治療を受けていたが、9月の初めごろから体調が急変、幽明の境を彷徨った。危篤の報を受けた母は直ちに実家に戻り、祖母を見舞った。一時は持ち直したものの、結局は看病の甲斐なく、9月9日の未明、祖母は2人の娘に見守られながら息を引き取った。享年81歳。

僕にとっては、人生で初めて経験した近しい親族の死だった。

盆に実家に帰った時に祖母を見舞ったばかりだった。その時の祖母はたどたどしくも会話ができ、食事に同席することもできた。ふくよかになった孫の姿を見て朗らかに笑っても見せた。が、祖母は傍目に見ても明らかに衰弱している様子だった。骨ばった手からは死相が透けて見えるようだった。病室を退去するとき、これが今生の別れかもしれないと思って祖母の手を握った。だからと言ってはなんだが、僕は祖母の死に関して思い残すことはなかった。祖母の凶報に接した際にも、どこか冷静でいられた。

祖母が息を引き取ったとき、僕はサークルの合宿で一宮に逗留していた。間が悪く連絡手段を喪失していたこともあって、僕がその訃報を受け取ったのは9日の夜になってからだった。父母と相談の上、翌晩に合宿を切り上げて葬儀と告別式に出席することになった。

ひとり帰路についた夜の10時半、僕以外に乗客のいない外房線の電車の中で、僕はおそらく初めて死について本気で考えた。明かりの少ない真っ黒な車窓と、親しかった肉親が失われたという事実は、これまでずっと目を逸らしてきた死という現実を、今まで接してきたどんな人物の死よりもリアルに突きつけてきた。

臨終の瞬間、祖母は何を考えていたのだろうか？　祖母以外の人間がそれを知ることは、絶対にできない。観測できないなら、存在しないのと一緒だ。それなら一体、なんの意味がある？

それまでに経験した記憶も感情も、死という圧倒的な一瞬によって強制的に断ち切られる。酒に酔って正体を無くしたり、寝ぼけて上の空になるのとは根本的に違う。酒に酔った人間は「今の自分は正常じゃない」と認識することができる。少なくともその余地がある。だが死はそうではない。「おらは死んじまった」などと、死を俯瞰するメタな視点を持った自分自身が存在しない。「存在しない」が存在するのではなく、「存在しない」も存在しない。虚無ではない。虚空ではない。まるで事象の地平面のように、僕の世界は死より手前までしか存在しない。宇宙の外側が真空なのではなく空間そのものが存在しないように、精神世界の観測は生と死に区切られた有限区間の中でしか成立しない。そんな絶対のボーダーライン、超えられないはずの彼我の境界面を、死はたやすく突き抜けていく。駅のホームで少し体重を傾けるだけで超えていく。それだけではない。日常生活においてすら、僕らの生命は完全に僕らの手中にあるわけじゃない。人間の命は常に誰かの手に握られている。飛行機の操縦士に。エレベーター技師に。天災に。人災に。誰かの悪意に。

怖かった。22歳の最後の夜、僕は本気で死を恐れていた。

死とはなんだ。死んだら僕の意識はどこへ行く。死んだら何もかもなくなるなら、それまでの人生になんの意味がある。今この瞬間、意識するいとまもなく刹那に僕の脳が吹き飛んだら、僕の主観はどうなるのか。その時未来は存在するのか。すでに通過し克服したと思っていた数多のドグマが僕を責め立てる。

死を連続する意識の終端と捉えるなら、死は眠りに落ちる瞬間と何も変わらない。僕らは毎夜々々死んでいる。そんなことはもちろん知っている。だったらどうして僕はこんなに動揺しているのか。眠りに落ちたあとの人生が存在しないことに、どうして震え上がるほどの恐怖を抱いているのか。それは純粋に本能ゆえか、それとも⋯⋯。

外房線のロングシートで揺られながら、僕はこれまでの人生で感じたことのない孤独と不安で気が狂いそうだった。科学に縋った弱い現代人は、宗教という心のシェルターから永遠に追放される。死への恐怖は、合理化し続ける社会が残した、人類への最後の呪いだ。

仮にジャネーの法則を信じるならば、僕は既に人生の半分以上を体感で過ごしたことになる。だけど足りない。僕はまだ全然生き足りない。こんな僕がもし天寿を全うしたとしても、死に臨み、「もう十分生きた。もう飽きてしまった」と本気で思えるのか、相当に疑わしい。

翌朝、黒いスーツに着替え、新幹線で神戸に向かい、親族と合流した。この日は奇しくも僕の誕生日だった。葬儀、告別式、読経、献花、出棺、火葬、骨上げ、繰り上げ法要、何から何まで初めてのことばかりで、ちゃんと祖母を見送ってあげられたか自信がなかった。僕は死化粧をした祖母の顔を直視することができなかった。棺に花を添えるとき、皆がそうするように祖母の顔を撫でるのが怖かった。骨上げのとき、ひび割れた肩甲骨を拾う箸が震えた。

告別式で、喪主である祖父が挨拶を述べた。20代で結婚し、苦楽を共にし、人生を分かち合った二人が、艱難辛苦を乗り越え、ついに添い遂げた瞬間だった。常に飄々とし、芸術と神戸を愛し、そして何よりも祖母を愛していた祖父の、耳慣れない嗄れ声を、僕はその時初めて聞いた。

「ついに、この日がやって参りました。妻との思い出は、思い出せば、限りがありません。ですが、それを語ることは、もう、できません。さようなら。さようなら。」

祖父が口にした、およそ挨拶らしからぬこの最後の別れの言葉が、今もショッキングに僕の耳にリフレインしている。きっと一生、それこそ、この身がああして焼かれるまで忘れられないだろう。

人事は棺を蓋いて定まる。

いつかこの長い昼が閉じ、僕の棺が永遠の闇に覆われるとき、はたして僕の人事は平穏に定まっているだろうか。祖母の霊柩が閉じられたとき、そんなことを考えていた。

僕は、ついに祖母の遺体に触れることができなかった。

人生を有意義に生きることは難しい。そもそも意義なんてないかもしれない。それでも前を向いて生きよう、なんて、今の僕には言えない。ただ、生きている僕らには容赦なく朝がやってくる。この世界には大切なものが多すぎる。僕はまだ死ねない。死にたくない。たとえ臨終の時まであと半分しか残されていなくても、たとえ意味はなくても、生きることをやめることはできない。宇宙の全てが決定論に支配されていたとしても、現在という時間的特異点に存在する僕の思惟だけは、決して泡沫じゃない。そう信じて今日を生きた。明日も生きるだろう。死ぬまでそんな調子かもしれない。

最後に。

祖母の訃報に際し、忌引などでご迷惑をかけた皆様、慰めの言葉をかけてくださった皆様に深く感謝申し上げます。祖母は浄土真宗に帰依していたため忌中・喪中はありませんが、個人的心情により四十九日の間は喪に服し、慶事・祭事の類はお断りさせていただこうと思います。よろしくお願いします。

パズルゲーム「MNEMO」を製作しました

この記事は TSG Advent Calendar の13日目の記事です。

f:id:hakatashi:20161213205431p:plain

こんにちは、博多市です。今日はサークルTSGが製作するゲーム、「MNEMO(ニーモ)」の紹介をします。

MNEMOは、パズルゲームです。プログラミングを意識した内容になっており、算数を習いたての小学生からガチのプログラマーまで、広い世代の方に楽しんで頂けるゲームになっています。

百聞は一見にしかず。MNEMOはズバリこんな感じにパーツを組み合わせて、条件を満たす回路を組み立てるゲームです。

試行錯誤を繰り返して目的の回路を組み上げたり⋯⋯。

後半になるとこんな複雑な回路を作ったり⋯⋯？

とにかく楽しいゲームです！　ブラウザゲームなのですぐ開いて気軽に遊べます。ランキングもあります。

みなさんもhttps://mnemo.pro/からぜひ遊んでみてください！

あ、できれば Google Chrome でプレイしてください。Safariでもそれなりに動くと思います。それからスマホでも一応遊べますがまだちゃんと対応してないのでできればPCからお願いします。

MNEMO製作記

はい、では一通り宣伝をしたところで、MNEMO開発に至るまでの経緯についてお話します。

まず、TSGとは、東京大学のサークルであり、主にコンピューター系の活動を行っています。僕も(なぜか)4年ほど在籍しています。

TSGの晴れ舞台は、年に1回開催される東京大学の学園祭、駒場祭です。部員はこの日に向けて、各々が持つ技術と誇りを賭けて、来場者向けの展示物を作る⋯⋯はずだったのですが、今年は少し違いました。

今年8月、東京大学工学部丁友会主催の科学イベント、TechnoEdgeの第3回が開催されました。東大に興味を持つ学生が「工学に親しむ」ためのイベントなのですが、今年はこれにTSGも声をかけていただいたので、喜び勇んで出展することになりました。そして本番に先駆けて、TSGでは恒例の夏合宿を行い、内部イベントとしてミニハッカソンを開催しました。この時にTechnoEdgeに出展するための企画案として製作されたのが、MNEMOです。

当初はプロトタイプということで、現在よりもだいぶ簡素なデザインでしたが、ゲームの構想やルール自体は今とほとんど変わっておらず、この時点でも遊んでいてかなり楽しいものでした。*1

f:id:hakatashi:20161213232250p:plain

MNEMOという名前もこの時つけられました。名前の由来は、アセンブリ言語で用いられる「ニーモニック(mnemonic)」の頭の部分です。簡単な命令を組み合わせて複雑な回路を作るというアイデアが低級言語を彷彿とさせたので、こう名付けました。命名者は僕です。

なので読み方は「ニーモ」です。一部で「エムネモ」と呼ばれており部内でも浸透していますが正式には「ニーモ」です。「ニーモ」なのです。

そして迎えたTechnoEdge当日、無事MNEMOを見せられるレベルまで完成させ、来場者からそれなりに好評を得ることができました。MNEMOのライブパフォーマンスも行われました。

本来はこのTechnoEdgeのためだけに製作されたゲームだったのですが、MNEMOのパズルゲームとしての単純さと奥深さにポテンシャルの高さを感じ、そのままTSGの部内プロジェクトとして開発を進めていくことになりました。その後の地道な開発や駒場祭における展示を経て、本日パブリックリリースと相成りました。

そんなこんなで、TSGメンバーがそれなりに頑張って作ったゲームです。ぜひぜひ楽しく遊んであげてください。よろしくお願いします。

また、MNEMOはオープンソースプロジェクトです。改善してほしい点や追加したいステージなどありましたらぜひGitHubまでお寄せください。

最後に、以下は2016年12月現在のMNEMOのContributor一覧です。ありがとう!

f:id:hakatashi:20161213234912p:plain

*1:ちなみに、TechnoEdge前日までこのデザインのままでした。

EEICの過酷な課題生活を支える(願望)技術

この記事は eeic Advent Calendar 2016 その2 の3日目の記事です。

qiita.com

←2日目: Android アプリ解析基礎 その2 -PC編-　4日目: チノちゃんと寝る→

博多市は、東京大学の2016年度進学選択で、工学部電気電子工学科に内定しました。内定に至るまでの経緯についてはこの Advent Calendar の22日目でもう少し語ろうと思うので、今回は割愛します。

工学部電気電子工学科は、隣接学科でありほぼ同じカリキュラムが適用される工学部電子情報工学科と合わせて、EEICと略されます。名前の通り電気と電子を扱う学科であり、量子力学から論理回路、高級プログラミング言語に至るまで、電子技術を支えるあらゆる学問について手広く扱う学科です。

そんなEEICは、工学部の中でも指折りのスパルタな学科であると(少なくとも学科内では)言われています*1。かくいう僕も、EEIC内定から3ヶ月の間に随分思い知らされました。

まあ大体こんな感じです。

さて、そんなEEICで、博多市はWeb長*2を引き受けています。EEICにおいてはサーバー管理やNASの管理、ウェブサイトの管理、Slackの管理など仕事の多いWeb長ですが、相互扶助の精神が育まれるEEICにおいて僕も何かWeb長として人々に貢献できる仕事がないかと探した結果、eeic2017botというslackbotを制作することにしました。

EEIC2017のSlackについて

EEICでは学年内での連絡やコミュニケーションにSlackを用いています。今年度の内定生はなんと学科ガイダンスが行われる以前から自主的にSlackチームが組織されており、ガイダンス時点ですでに半分が加入している状態でした。現在の学年Slackは僕がこれを引き継ぐ形で受け取ったもので、チームとしてはガイダンス以前に組織されたものがそのまま使われています。

例えば、以下のようなチャンネルが存在します。

  • #general: 真面目な話をする部屋
  • #random: 真面目じゃない話をする部屋
  • #assignment: 課題について相談する部屋
  • #programming: プログラミングについて質問する部屋
  • #competitive-prog: 競技プログラミング勉強会の話をする部屋
  • #examination: 試験中(!)に使われる部屋
  • #party: コンパや懇親会の連絡をする部屋

このうち、EEIC生にとって生命線となるのは #general と #assignment です。#general には休講情報や落とし物情報などが流れ、#assignment ではシケ対が解いたレポートの解答や課題の解き方について流れてきます。

eeic2017botは、そんな #assignment チャンネルでEEIC生に日々課される課題をお知らせする仕事をしています。

eeic2017botのおしごと

f:id:hakatashi:20161202023039p:plain

これがeeic2017botです。

ひと目見て分かる通り、カオスです。「EEICたん」は僕がeeic2017botに勝手に付けた名前、アイコンは電気系の民なら誰でも知っているルートヴィッヒ・ボルツマンの肖像です。気がついたら誰かが設定してました。きっと課題のやり過ぎで精神を病んだEEIC生の仕業に違いありません。

EEICたんは、先ほどの画像のようにEEIC生の誰かが登録した課題情報をお知らせしたり、

f:id:hakatashi:20161202024449p:plain

週の初めにその週に提出する課題の一覧をお知らせしたり、

f:id:hakatashi:20161202024457p:plain

前日まで課題をやらないうっかりさん*3のために課題締切前日にお知らせを流したりしてくれます。

eeic2017botの仕組み

eeic2017botのソースコードはGitHubで一般に公開しています。オープンソース最高。

eeic2017botがお知らせする課題の一覧は、EEICのWikiの「課題一覧」というページを参照しています。WikiはEEIC生なら誰でも編集できるので、課題情報の更新が誰か一人に頼り切りにならなくて運用が楽です。

f:id:hakatashi:20161202025145p:plain

一番最初に引用したツイートで呟かれている「EEICで1ヶ月のうちに課された課題の一覧」は、実はこのページの目次を参照しています。

そして、BOTのプログラムはHeroku上で動いています。Heroku Scheduler で動かせば、BOTが眠ることもないし消費するDynoも低く抑えられるので楽ちんです。11月の消費Dynoは10.8時間でした。

プログラムはNode.jsで書かれており、Heroku Scheduler で10分おきに実行されるごとにEEICのMediaWikiにアクセスし、APIを叩きます。ページを取得するとそれを気合でパースし*4、登録されている課題の一覧を取得します。

取得した課題はRedis上にキャッシュされ、新しく追加された場合はSlackに通知、そして指定時刻になったら該当する課題を引いてきてSlackに通知します。新しく追加された課題を検索するとき、RedisのSDIFFを使うと高速で便利です。

ちなみに、このプログラムはコミットログを見るとわかりますが電気回路理論の授業中に作成され、その日のうちに運用開始しました。課題を通知するために課題がおろそかになるとは皮肉なものです(適当)。

EEIC生を支えるその他の技術

EEIC生の過酷な課題生活を支えるのはeeic2017botだけではありません。

EEIC2017のシケ長は専用のTwitterアカウントを持っており、課題や試験の情報を逐次お知らせしてくれています。

twitter.com

それから、EEICの試験問題やシケプリは過去のものも含めてすべて専用のWebDAVサーバーに蓄積されています。こちらはEEIC全学年共用のストレージになっており、ブラウザ上でアクセスできるフロントとしてPydioを採用しています。

f:id:hakatashi:20161202173101p:plain

まとめ

というわけで、EEICのB2の課題生活とそれを支える技術について紹介しました。EEICに内定してから3ヶ月、学科生専用のサーバーがすでに構築されていたり、レポートが出されたその日のうちにシケ対がレポートの解答をSlackに上げたりと、EEICの学生の真面目さ(とクソ真面目さ)には驚くばかりです。

みなさん、#進振りはEEICへ。

明日は@Ishotihadusさんの「チノちゃんと寝る」です。お楽しみに。

*1:しかし、東大には2年冬から授業が全て本郷で行われる学科や、一度でも授業を欠席すると留年が確定する学科があったりするので侮れない。

*2:東大用語。主にクラス/学科のメーリングリストやウェブサイトの管理などを行う役職。

*3:つまり僕

*4:MediaWikiにはaction=parseというAPIがあるようなのですが、使用したAPIラッパーが非対応みたいなので使えていません。いつかラッパーを捨てて対応したい⋯⋯。

6月のコミットまとめ

hakatashi (Koki Takahashi) · GitHub

f:id:hakatashi:20160705005359p:plain

コミット数が単調増加の傾向にある。どういうことなの……

今月は技術書典があり、執筆も全てGitHub上で行ったためコミット数が大幅に増えた。あと Google Summer of Code への取り組みで多少コミット数を稼いだ。

主な成果

awesome-prml-jaを作成

サークル活動でPRML勉強会に参加しているのだが、インターネット上に散逸する過去のPRML勉強会の資料をまとめたサイトがないので、少し前に流行ったawesomeの体裁でGitHubリポジトリを作った。作ってみて思ったが資料多すぎである。正直本買わなくてもこれだけで独学できてしまうのではないだろうか。

awesomeの統括リポジトリに登録申請するか迷ったが、日本語だし適切にフォーマットされてないのでやめた。

slack-ikkuを作成

アルバイト先のSlackで遊ぶために一晩で作ったどうしようもないネタBOT。後ほどブログを書く予定。

general-category 1.5.0 をリリース

ファイルサイズがさらに小さくなった。それからREADMEのサンプルコードを自動でテストするようにした。

あと1.4.0で使用したファイルサイズを小さくする技術について社内LTで発表した。各方面の技術を結集した謎スライド。

HakataFeedをQiitaとGithubに対応

個人的に使用している、WebサイトをスクレイピングしてAtomフィードに変換するやつ。もとはpixivの新着フィードを変換するためだけに動いていたが、様々なサイトを統一的に扱うためにクラス継承の仕組みをちゃんと整えた。あと取得したCookieがファイルシステム上に永続するようにした。疲れた……。

LINE for Node.js

ネタで作ろうかと思ったが--line--というモジュール名が取得できなかったので諦めた。仕様だけ書いてある。

5月のコミットまとめ

hakatashi (Koki Takahashi) · GitHub

f:id:hakatashi:20160603043015p:plain

かなりcontributionしたと思った先月を軽く超えていてビビる。

Privateなcontribution数もプロフィールに表示できるようになったので、なかなか彩り豊かになって幸せである。

主な成果

mochifyに--browser-fieldオプションを実装

この画像には見えないが、mochifyに--browser-fieldなるオプションを実装したプルリクがマージされたのが一番の成果と思われる。他人のリポジトリにマージされたプルリクとしては、規模的にも自分史上最大のものになった。しばらく放置されていたので不安だったが、マージされた時は軽く小躍りしてしまった。

いまはGSoCの真っ最中である。自分の仕事がちゃんとマージされるようにがんばらなくては。

Sugoi Converter をアップデート

1.7.2 から 1.8.16 になった。新機能は以下のとおり。

  • Quoted-Printable の変換を実装
  • 各種依存パッケージのアップデート
  • 各種deprecatedパッケージの駆逐
    • JadeをPugに
    • ついでにGulpをベータバージョンの4にアップデート
  • Google Analytics を導入

npmモジュール general-category をアップデート

npmモジュール asianbreak のテストフレームワークをmochaからInternに変更

はい、GSoCの課題の一つです。

ついでにカバレッジも取れるようになって最高。

takuboku-project

おや、どうしたんだろう?

シンタックス・ハイライト機能で対応してほしい言語

お題「シンタックス・ハイライト機能で対応してほしい言語」

LiveScriptをリクエストするしかない。

require! 'prelude-ls': {unfoldr, map, concat}

export integer-array-to-buffer = ->
  it |> map ->
    it |> (+ 1) |> unfoldr ->
      if it is 0 then null
      else
        modulo = it %% 128
        base = it .>>. 7
        modulo .|.= 2~1000_0000 if base is 0

        [modulo, base]
    |> map (.^. 0xFF)
  |> concat
  |> buffer-from

general-category/util.ls at 4e494d9347d95471cce63d10a8c2dbdf0775beb9 · hakatashi/general-category · GitHub

HaskellにもCoffeeScriptにもなれなかった悲しい言語。

Google Summer of Code 2016 参加記 その1 応募編

f:id:hakatashi:20160528200323j:plain

今年の4月、Google Summer of Code 2016 に応募し、無事選出された。

それから2ヶ月も経過したが、何も音沙汰なしというのも殺生なので、軽く現時点での参加記を書いてみようと思う。

特に、ウェブ上で検索してもGSoCに参加する日本人のためのアドバイスがあまり見つからないので、そのあたりを頑張っていきたい。

Google Summer of Code とは

Google Summer of Code

ひとことで言うと、「Googleが主催するリモートワークのインターン」。もう少し詳しく言うと「著名なオープンソースソフトウェアのために3ヶ月間フルタイムでコミットし、報酬として$5500を受け取る、大学生のためのプログラム」である。

長いので略してGSoCと呼ばれることが多い。読み方はよく分からない*1。オープンソースコミュニティの活発化のため、またコーディングに興味を持つ学生の育成のためにGoogleが全面的にバックアップするプログラムであり、2005年に開始されて今年で12回目になる。詳しくは Google Summer of Code の紹介ページを参照してもらいたいが、公式ページには、今までにこのプログラムでなんと5000万行のソースコードが生産されたと書いてある。

GSoCは今年全面的なリニューアルを行い、システムが全面的に刷新されたようだ。ウェブページは殺風景なデザインからマテリアルデザインに切り替わり、ロゴも新しくなった。去年見た時よりもだいぶ分かりやすくなっていて個人的には大歓迎である。

期間は、例年5月中旬から8月中旬にかけての3ヶ月間。これらのコーディング期間に加えて、その前に1ヶ月ほどの Community Bonding Period が存在する。これは米国の一般的な大学の夏休みに合わせたスケジュールである。

プログラムの流れは次の通りである。まず、Googleは学生を受け入れることができるオープンソース団体を募集する。選考でGoogleに承認された団体は学生に取り組んでほしいタスクのリストを予め用意しておき、学生は各団体のそれを読んで自分に合った団体と課題を決める。学生はその内容を提案書(Proposal Paper)と呼ばれる文書にまとめ、自分のやりたいこと、スキル、課題のスケジュールなどを盛り込んで提出する。各団体がそれを読んで選考を行い、無事選考通過した学生には参加する団体から1人か2人のメンターを配属され、全期間を通してメンターの指示と指導のもと、互いにコミュニケーションを取りながら各々の活動を行っていく。全プログラムを無事終了した暁には、総額$5500の報酬金が受け取れるという仕組みである。

例年全世界で5000～6000人ほどの学生がこのプログラムに応募し、1000人あまりの学生が選考を通過して Accepted Students となる。考えてみると応募率は5倍であり結構高いが、マニュアルをよく読んで真面目に提案書を書けばかなりの確率で通過できるのではないかと思われる。

日本人の参加について

GSoCには例年日本人も若干名ほど参加しており、統計情報によると今年は自分も含めて12名参加とのことである。

日本人が参加する際の一番のハードルは、やはり世界の大学との学事暦の違いだと思われる。一般的な9月入学2学期制の大学では春学期が5月に終わるため、そこから3ヶ月間みっちりと課題に取り組めるが、日本の大学では5月は夏学期のど真ん中である。GSoCでは通例週40時間のコーディングが要求されるため、やはり特別な事情がないと日本の大学生が参加するのは難しいと思われる。*2

第二に言語の問題がある。GSoCでは、書類選考やメンターとのコミュニケーションなど、当然だがすべて英語で行わなければいけない。大学生であれば英語はある程度読み書きできることと思われるが、自分も含めてそこまでのコミュニケーションを行う自信はついていないというのが正直なところである。また去年GSoCに応募した友人によると、選考過程でSkype越しの面接を要求され、言葉がうまく出ずにキョドって落とされたという話である。このあたりの選考過程は団体によって異なるが、もし面接を課せられていたら自分も落とされていたかもしれない。

逆に言えば、上の2点さえクリアできれば誰でも参加できる。

コーディング能力はあまり問われない。GSoCにはコーディングレベルに応じて様々な参加形態があり、簡単なタスクから複雑なタスクまで、自分に合った課題を自分で設定することができる。ほとんど初心者に近いような状態でも、学習しながら参加することもできるという話である。

日本はGSoCの本拠地であるアメリカから遠いが、これも問題にはならない。そもそもリモートワークなのでコーディングに地理的な距離は関係ないし、Googleからのいくつかの郵送物は、時間がかかるがちゃんと届く。報酬金はPayoneerを通して支払われ、ちゃんと日本の銀行口座に引き落とすことができる。

タイムゾーンの違いによるコミュニケーションの難しさは若干あるが、今のところ大きな問題にはなっていない。

5月から8月にかけて時間を取れる大学生は、ぜひGSoCに参加してみてほしい。

応募編

f:id:hakatashi:20160528191008p:plain

Googleの夏は3月から始まっている。GSoCに参加する場合には3月の応募期間中に提案書を書ききり、諸書類と一緒に提出しないといけない。どうせ夏だと思ってぼやっとしてるとあっという間に過ぎてしまうので注意が必要である。*3

そして更に重要なのは、GSoCの公式マニュアルによると、応募期間以前からの活動が最も大事とのことである。提案書はなにも提出する時まで内緒にしておくことはない。提案書を作る前にどういう内容に取り組みたいかということを団体に相談し、フィードバックを受けながら書いていくのが最も良い書き方である。僕はこの文面を見落としていたため若干出遅れてしまったが、読者諸兄にはくれぐれも早め早めの行動を促したい。

僕の場合、応募期間が開始してから団体リストを眺め、得意なJavaScript関連のプロジェクトを探した。自分が知っているプロジェクトに応募するのが一番良いというのは聞き及んでいたことなので、めぼしいところで Mozilla, jQuery, Fedora, ownCloud などが候補に挙がった。

Fedora Project など、どの辺りがJavaScriptなのだとも思ったが、Idea List を見ると、意外といろいろな種類のタスクが挙げられている。このあたりはちゃんと読んでみないとわからないものだと感じた。

迷った末に、jQuery Foundation にある、Internというテストフレームワークの Create a sandbox interface for all Intern tests というタスクに応募することにした。Internというソフトウェア自体はあまり有名ではないが*4、個人的に Software Testing に興味があったのと、リストのだいぶ下のほうにあって誰も応募してないだろうという目論見により応募することにした。

f:id:hakatashi:20160528192358p:plain

そうと決めたらマニュアル通り開発者に連絡を取り、課題についていくつかの質問をした。そうして得た回答をもとに、提案書を書き進めた。提案書は、自分のやりたいことを明確にわかりやすく、そして誤解のないように書くことを心がけた。特に、取り組みたい課題の解決がなぜ必要とされるのかという点に重点を置いた。このあたりは、開発者とのコミュニケーションを通して得た、「今回は具体的な実装方法に関しては提案段階では考えない」という方針が基となっている。また、先程述べたような日本の大学の事情やタイムゾーンの問題なども、後から辛くならないようにここにしっかり書き記しておく必要がある。

ヒイヒイ言いながら慣れない提案書を書き上げ、最初のアップロードを行ったのが応募期間終了の3日前。期間に余裕がある場合はこの段階で団体側のフィードバックを待つことができるのだが、今回はギリギリだったのでフィードバックを受けることができず、応募期間終了前日に最終提案書を送信した。*5マニュアルも “Submit early” を何度も強調しているように、とにかくGSoCの応募は早めの行動が重要である。読者には同じ轍を踏まないようにしてもらいたい。

提案書は複数応募することもできるのだが、1個目の提案書を書き上げた時点で完全に疲弊していたし、マニュアルにも「そこそこの提案書を複数作るよりもハイクオリティーな提案書を1個作れ」と書いてあるのでここで切り上げた。

選考通過のメールを受け取るのは、提出から1ヶ月後、4月23日のことである。

「選考通過～Community Bonding Period編」に続く。

*1:個人的にはjeesockと読んでいる

*2:ちなみに博多市の場合の「特別な事情」は「2回目の留年中であり取るべき授業がほとんどない」というものである。

*3:博多市も去年は「いつの間にか応募期間が終わっていた」という悲しい経験をした

*4:実は僕もこのGSoCで初めて知った

*5:ちなみに何度でも再アップロードできる。