CとGoの世界の境界線をいったりきたり。
分かる人には簡単なんだろうけどgolang自体が初心者から抜け出せない。。。
コールバック関数をメンバーに持つstructをつくって、コールバックが動くと対応するgolangのfuncが動く感じになればいい。
直接GoからCにfuncを渡せないっぽいのでexternしたりラップしたりと面倒な感じになっていてイマイチ。
ようやく動いたと思ったらintっぽい値がoverflowしてるっぽい値になっているのでどこかでキャスト的なことが必要っぽい。
参考文献だけまとめておいて今日は終わり。
Go Tips Learned From Writing go-libxml2/go-xmlsec — Medium
cgo の基本的な使い方とポインタ周りのTips (Go v1.2) - LESS IS MORE
golang で string を []byte にキャストしてもメモリコピーが走らない方法を考えてみる - Qiita
アカマイ 知られざるインターネットの巨人<アカマイ> (角川ＥＰＵＢ選書)
積読消化に読んでみた。
内容は薄く広くという感じサラッとしているので2日くらいで読めた。
本書は「アカマイ」部分は半分で、もう半分は「インターネット」について書かれた本だった。
インターネットが好きだ。
インターネットで人生が変わったし、インターネットに対して感謝している。
そして、そんなインターネットに対して貢献したいと感じている。
ではどうすればインターネットに貢献できるのか。
どうすればインターネットに貢献したと言えるのか。
仕様の標準化グループに参加？awesomeなソフトウェアの開発？地味な技術研究？
自分が最も効果を出せることはなんだろうか。何をするのが一番効果的に貢献できるのか。
最近そんなことを考えている。
始まりはfacebookだった。
facebookでシェアされた何気ない動画。
普段なら「へ〜」で終わってページをスクロールすることがほとんどだけど、この動画だけは違った。
その動画を再生してから8分間、じっと見続け、再生が終わった瞬間二周目を開始した。
8分間のアニメと音楽が流れるだけの動画にこんなに心を奪われたのは初めてだった。
情報量、ネタのストライク感、音楽、何もかもがすばらしい。
これぞクリエイティブ。これぞコンテンツ。そんな感動がずっと僕の中をめぐり、次の日も続いた。
これがその元になった動画だ。
ここからは動画を見たことを前提でネタバレをガンガン話す。
事の発端は
Leslie Waiというミュージックアーティストが発表した曲を、Guy Collinsというオーストラリアのアニメアーティストがyoutubeで発見し、ミュージックビデオを作ったという流れのようだ。
ここまでヌルヌル動くアニメーションがおそらく個人？で作られてるのもスゴイ。
詳しくは知らないが、数々の作品を発表されているのでおそらく著名な方なのだろう。
こちらに投げ銭すると、動画中に登場した説明書や音楽、シークレットエンディングなどが入手できる。
シークレットエンディングはゲームの世界に自分も参加すると言えば聞こえはいいが、プレイは正直おすすめしない。
最後まで見たが、大変な時間と労力を割く割には得られるものがなにもなかった。
しいて言うなら「7a」は「z」、「6f」は「o」を表すということを覚えたぐらいだ。
ただの投げ銭と考えよう。
ループものというのは様式美というかジャンルと化しているけど、ループものはゲームと同じ、アクションゲームはループものだったんだと気付かされた。
ループものといえば知ったかするつもりはないので僕の知っている範囲だと、Dグレのミランダ編、エンドレスエイト、まどか☆マギカ、All need is killなどがある。
ゲームではアクションゲーム全般、ブレス オブ ファイアVも死んでおぼえて強くなるという点ではループものっぽい。(ブレス オブ ファイアVは僕のもっとも好きなゲームだ)
映画ルーパーはループもののようでループものではない(これも素晴らしい映画)
細かいところも作りこまれているのもいい。
最初の玄関の裏にはあるのはこの絵だろう
男性がゲームを始めると、テレビ画面に一瞬ラスボスが映り込む。
随所には日本語が散りばめられている。
映画マトリックスでもそうであるように、日本語は謎めいたものだったり、文字化けによって出てくる奇っ怪な物を象徴していたりするのだろう。
タイトル「孔明の罠」はどこが最初かわからないが、おそらくニコニコ動画のゲームチャンネルだ。
スーパーマリオメーカーが発売されるはるか前からマリオは"改造"されてきた。
そして初見殺しのトラップは「孔明の罠」としてしたしまれ、空中に突然現れるブロックはあまりに有名だ。
このブロックも、主人公が連続して死ぬ場面をよく見ると登場している。
また、動画作者自身も改造マリオのTAS動画を上げていることからなかなかのゲーマーだと思われる。
彼氏の攻撃を受けて飛ばされるシーンの裏側には「エアーマンが倒せない」の歌詞が描かれている。
なによりシンプルな絵柄ながらも決してあきらめない彼女の姿勢に、僕は感動したのだった。
素晴らしい動画コンテンツを作ってくれた作者に敬意を評し、ダウンロードパッケージ$5+作者へのチップ$5+このブログを書くことで貢献としたい。
thank you for never give up -
僕はHashが嫌いだ。
できるだけHashは使いたくない。
h[:foo]
とか
h.fetch(:foo)
とか本気で使っているのかね君たちは(今日は何となくこんな感じですすみませんすみません)。
Hashはとにかくデバッグが面倒だ。
設定やら多値を表現するためか生存が長くなりがちなくせに、 どこで生成されたHashなのか、どこで追加されたkeyなのかよくわからなくなる。
class名がないから何を表したいオブジェクトなのか、デバッグした時にわからない。class名でgrepもできない。
JSONを扱うプログラムではついついHash#[]やHash#fetchばかりのコードになりがちで、
エラーが起こったらHashのkeyをtypoしたんだか値がnilなんだかよくわからなくなる。
Hash#fetchでkeyを間違えるとKeyErrorが発生することで検知できるけど、「どんなkeyがあったかな？」と思っても正しいkeyは自分でコードを読むかp h.keysするなりして探さないといけない。
いまのところdid_you_mean gemもKeyErrorに対応していないので、typoにおびえてコードを書くか、ひたすらデバッグするかだ。
*1
なにより
h[:foo] h.fetch(:foo)
は長い。
Hashはどんなkeyが来るかわからない時だけ使うべきだ。 あと、「記述が少ない」「名前を覚えなくていい」という利点から、keyword argumentsのような引き数にも便利。 gemの外部APIとしては十分選択肢だと思う。
Structは好きだ。
どこで生成されたオブジェクトなのかclass名でgrepすればだいたいわかるし、key名を間違えてもNoMethodErrorで教えてくれる。 なんならdid_you_mean gemが正しそうな名前を教えてくれる。
「どんなkeyがあったかな？」と思ったらclassの定義を読めばいい。
s.foo
の方がシンプルだ。
golangやcrystalのようにJSONを特定のclassに属するオブジェクトに変換する方法があれば、Hash的な使い方でなく、Struct的な使い方ができる。
ようやく本題。
以前、keyword argumentsが使えてより厳しいStructということでTypeStruct gemを作った。
これをさらに推し進めて、hashからマッピングできるように実装してみた。
README.mdから引用すると、
Point = TypeStruct.new( x: Integer, y: Integer, ) Color = Struct.new(:code) Line = TypeStruct.new( start: Point, end: Point, color: Color, ) hash = JSON.parse(%({"start":{"x":3,"y":10},"end":{"x":5,"y":9},"color":{"code":"#CAFE00"}})) line = Line.from_hash(hash) p line #=> #<Line start=#<Point x=3, y=10>, end=#<Point x=5, y=9>, color=#<struct Color code="#CAFE00">> p line.start.y #=> 10 line.stort #=> NoMethodError
このように、key名とclassを設定すれば、HashオブジェクトをStruct(っぽい)オブジェクトに変換してくれる。
設定に違反するデータならエラーを出してその場で教えてくれるし、参照先のclassがTypeStructから作ったclassなら再帰的にオブジェクト化してくれる。
Structオブジェクトにも対応しているけど、Structの場合は値のclassを設定できないのでなんでも入れられて再帰的にオブジェクト化できなくなるが、既存のcodeで使いやすいようにつくってみた。
「値のclassを設定できる」を実現するために2つの記法を用意した。
たとえば「trueかfalseになるメンバをつくりたい」と思うと、Rubyの場合困ったことになる。
Foo = TypeStruct.new( bar: TrueClass, # or FalseClass??? ) Foo.new(bar: false) #=> TypeError
TrueClassとFalseClassに判別用のmoduleをincludeすればチェックできるけど、標準classを書き換えたくない人も多い。
そのため、独自のclassを用意してみた。
Foo = TypeStruct.new( bar: TypeStruct::Union.new(TrueClass, FalseClass) ) Foo.new(bar: false)
標準classを少しなら拡張してもよいという方のために、こんな書き方もできるようにした。
require 'type_struct/ext' using UnionExt Foo = TypeStruct.new( bar: TrueClass | FalseClass ) Foo.new(bar: false) Foo.new(bar: true)
Class#|メソッドを用意して、classをつなげて複数のclassを表現できるようにした。refinementsを使っているので、Class#|が有効になる範囲も限定できる。*2
メンバを配列にしたい場合もあるだろう。
Cだと
struct foo { int ary[]; };
golangだと
type Foo struct { ary []int }
みたいなやつだ。
その場合の表現方法も考えて、専用classを用意した。
Foo = TypeStruct.new( ary: TypeStruct::ArrayOf.new(Integer) ) Foo.new(ary: [1,2,3])
名前が長いのが玉にキズなので、これも短縮できるようにしている。
require 'type_struct/ext' Foo = TypeStruct.new( ary: ArrayOf.new(Integer) ) Foo.new(ary: [1,2,3])
もちろんUnionとArrayOfは組み合わすことができて、「配列の時もあるけどnilのときもあるメンバ」を表現できる
require 'type_struct/ext' Foo = TypeStruct.new( ary: ArrayOf.new(Integer) | NilClass ) Foo.new(ary: [1,2,3]) Foo.new(ary: nil)
これらの記法を組み合わせれば、かなり複雑な構造を持ったJSONでも、特定の名前のついたclassのインスタンスオブジェクトを作ることができるようになるので、お試しください。
rebuild.fmの#120を聞いて、jQueryの作者が始めた「毎日コードを書く」というやつを40日間やってみた。
John Resig - Write Code Every Day
毎日コードを書くというルールなので、 アウトプットは多くなった。
手持ちのリポジトリを大幅に整理したり、PRも10件ぐらい飛ばした。
毎日コードを書くと、コンテキストスイッチのオーバヘッドが小さくなるというのは本当で、 お風呂に入っている時にアイデアが思いつく事もあった。
無意識領域の脳リソースをうまく使うことができてるのかもなあと思った。
アウトプットのために使う時間を必ず確保するので、アウトプットからインプットへコンテキストスイッチするオーバーヘッドは増加したような気がした。
脳リソースをうまく使えているとはいえ、手持ちの情報からの構築になる。 なので新しいことをおぼえたり、本を読んだりといった時間がへった。
おおきいプロダクトのコードをしばらく読んでいたいだけなのに、どこかアウトプットのネタ探しがチラついて、 時間がかかりそうなコードリーディングはやめる傾向にあった。
想像していた通り、
序盤はよかったけど、中盤から「今日のノルマ」消化のために作業するようになっていた。
「今日のノルマを消化するために機能を追加する」 「今日のノルマを消化するネタ探しとしてコードを読む」
そんな考えが浮かび始め、だんだんとこのまま続けてもよくないなあという気持ちが増えていった。
コードをpushしてやっぱやめたとreset --hard HEAD~1してforce pushしても草がついたとき、 この活動はやめようと思った。
土日は一切コードを書かず、家の用事をすませたり、カフェで本を読んだりしてた。 おかげで「火星の人」を読み終えた。
TEDにはおもしろい話があって「学ぶことを止めよう」という内容のものだ。
学ぶことをやめ、自分で考えたほうがユニークな発想にいたることができるというものだ。
GitHub草運動を続けている方が、自分で考える状態に近いのかもしれない。
インプットがなく、自分の中のアイデアでなんとかしなければならないからだ。
「火星の人」でも主人公は手持ちの材料だけで戦った。それでも良いアイデアは浮かぶし、生き延びていけるのかもしれない。
しかし毎日一つ以上のアウトプットが強制されているので、ただアイデアを検証したり考えにふけったり休んだりといったことができない点が、違うように思った。
いいとこ取りをするアイデアはないだろうかなあ。
子供が生まれそうだったので新しい家を去年から探して回っていた。 10軒ぐらい見て2軒話を進め、最終的に1軒契約という形になった。
今年の前半はだいたいこれ。
今年の後半はだいたいこれ。
大変だったからなのかずっと家にいたからなのかで、あまり記憶が無い。 とにかく出来るだけのことはがんばった(なぞにほんご)。
写真を親族に見せるためのWebサービスも自作して、今も喜んでもらえている。
ほとんどはどうしようもないものだけど、ほんのちょこっとは誰かに使われている気がする。
あまり大したことしてないなあ。。。
RubyKaigi2015 LTした。
http://ksss9.hatenablog.com/entry/2015/12/12/231210
誰も使ってないよ。
ひとことで言うとしょぼい。。。
目標60冊、結果15冊。
壊滅的に駄目だった……。
1回ぐらいはやる。
ぞい
この記事は子育てプログラマ・ITエンジニア・Webデザイナー Advent Calendar 2015の20日目の記事です。
前回は@elcondorさんの背中を預けるということ、あるいは共働き家庭での子育てについて - condor's diaryでした。
僕はプログラマーとして働いていて、 はじめて子供が産まれてから今日でちょうど半年たち、 子供のハーフバースデーを迎えることができました。
これまで僕は子育てをしながら、ほとんどリモートで働くという生活を送ってきました。
この経験はそんなに一般的なものではなく(たぶん)、 エンジニアtypeさんにも取り上げていただきました。
もしこれから子供が生まれるんだけど、仕事との折り合いをどうしようと考えてらっしゃる方の力になれればと、 これまでの生活を書いていこうと思います。
子供が生まれる前から奮闘は始まっていました。
会社には、育休をとるかどうかも相談したのですが、 これからのことを考えると収入面での不安もあり、育休自体は断念しました。
そこで、子供が産まれてからしばらくはリモートで働けるように準備を進めていきました。
会社ではもとからリモートワーク可で、僕自身も入社時から週一程度の頻度でリモートワークを実施していました。
この頻度をもっと上げて、週4〜週5でリモートワークをこなした実績があれば、子供が産まれてからもやっていけるだろうと、事前に練習を重ねていきました。
妊娠後期の妊婦は、立ち上がるだけでも一苦労なため、 ささいな用事なら僕が立ち上がって、妻が立ち上がりたいときは毎回手を貸す用にしていました。
リモート勤務の恩恵はリモートワーク Advent Calendar 2015 - Adventarでも数多く語られていますが、
僕自身も、この時点で非常に恩恵を感じていました。
妻が産婦人科に入院してからも、リモートワークによって浮いた時間を使って、 毎日お見舞いに行っていました。
いつ生まれるかわからない状態なので、僕も小心者なため妻から「おなかいたい」とメッセージが来れば、 「産まれる！？」と取り乱してしまいます。 直ぐに病院に駆け込めるようになっていたのは安心できました。
子供が産まれてからは、初めてのことに手探りながらも、二人で十分話し合う時間をとることができたので安心でした。
妻は産後１ヶ月は安静にしていなければいけないので、仕事をしながらもこまめに子供のおむつをチェックしたりだっこしたりと、 仕事と育児が細かくスイッチして働く生活になりました。
僕自身は「プログラマーのフロー状態のためには十分な時間が必要だ」みたいなのはいいわけだと思っているので、 慣れさえすればよい仕事の気分転換になっていたので、そこまで作業に支障を感じませんでした。
一ヶ月もすると育児しながら働く状態にもなれてきて、生活のリズムも安定してきました。
子供は一瞬たりとも目が離せません。
そのため一人で子供を見るとなると、買い物に行くにも人が多い場所に行くため、感染症のリスクが高まります。
一人で歯医者に行くことさえできません。
家に二人いることで、片方が子供を見つつ片方が外出することもできるので、一人で子供を見ているよりもかなり行動の自由が広がります。
正直なところを言うとYESです。 妻の体力が尽きたり、たまたま出かけている時に大泣きしだしたりすると、僕も仕事どころではなくなってしまいます。
もっとも辛いのはそのタイミングとサービスの障害対応が重なる時で、 子供を片手であやしながら片手で障害の原因を調べてsshでサーバーのおもりをしてと阿鼻叫喚の絵になってしまうことがまれにありました。
ふれる仕事は他のエンジニアに任せたり、抱っこ紐をつけながらスタンディングでタイプしたり、膝の上で子供を揺らしながらテーブルでタイプするなど自分の姿勢を工夫したりして乗り切っていました。
子供が生まれると、最新技術のキャッチアップやプログラミングの時間が減ると言われますが、 たしかに自分のために使える時間は減ったと感じます。
家族のために時間を使うことは自身の幸せにつながるので苦ではないですが、 エンジニアとしての能力が下がってしまえば、今後のIT業界で生き残っていけなくなります。
このジレンマもリモートワークで浮いた時間が緩和してくれます。
いつもの通勤時間に当てていた時間は本を読んだり、コードを書く時間として過ごすことができます。
参考までに僕のGitHubでのPublic contributionsグラフはこんな感じ。
細切れになる作業時間にさえなれれば、キャッチアップの時間はなんとか取れていると思います。
がんばれば7日連続でgemを作ることもできるし、RubyKaigiでLTをすることもできます。
もちろんミートアップや勉強会などへの参加率は極端に減っていて、会社の飲み会さえあまり行かずにいるという面もあります。
育児とリモートワークの相性は最高だと思います。
自分の人生にとって、何が大切で何が大切でないか考え、大切なものに集中できれば自分の満足の行く生活がおくれるはずです。
このブログがこれから育児生活を迎える人のなにか助けになれば幸いです。
次は@chezouさんの「子供の風邪と戦う必殺アイテムについて」です。
