Subscribed unsubscribe Subscribe Subscribe

ろじかるんるんものがたり

病人が特に何も書かない。無駄だからだ。

わがまま

頸肩腕症候群 ポエム

自明なことなんだけれど、もうずっとわがままばかり言っている。

まず仕事からして、ボクのわがままである。部分就労の許可も出ていない。良くなる傾向もない。病状から言えば大人しくしとけという話である。

祖父の病状が悪化したりなくなったりというのもあったけれど、そもそも実家へ帰れという話もある。はっきりいって、一人でまともに生活できる状態ではない(日が多い、体調良い日は人並みだと思う)

この前の Lycee フェスタも当たり前だけどわがまま。おかげで今週は今日何とか外出予定済ませた以外は何も仕事できていない。

そうでなくとも前回のお仕事同様、仕事請けて二か月くらい経った辺りから、気持ちに体がついてこなくなることはわかっていたのに、まあダメダメである。

他にもまあいくらでも思いつく。一々書いてるとキリがない。

そんな調子で世間様に迷惑ばかりかけている。生きてれば大なり小なり迷惑はかけるものだけれど、ボクは控えめにいってもかけすぎている。

どうにかしたいんだけれど、どうにかできるんだったらとっくにどうにかなってるだろうし、まあどうしようもない。横になってると悪いことばかり考えていけない。

Remove all ads

東京リセフェスタ参加記録と雪の話

このブログにしては珍しく、TCG の大会参加したよという記事です。

Lycee overture の公式大会、東京のリセフェスタに参加してきました。

宙雪でした。ちなみに宙雪の使用者は一名、自分だけだったそうです。当たり前だよなあ?旧 Lycee のメインデッキが雪だったので、どうしても雪を使いたかっただけ、それだけです。勝ちに行くなら日使ってたと思うんですが、旧 Lycee の頃から勝つことより自分の好きな色のデッキでなんとか頑張ることに価値を見出すタイプだったので…日全盛期に雪でぎりぎり止めきって勝ったとかあったなあ懐かしい…

いきなり雪的に絶望的な話。攻めとしては dmg4 とテンポアド、守りとしては 2 ハンド AP 3 ブロッカーが大切という環境に対して、雪単では全く勝ちの目が見えませんでした。旧 Lycee に比べて除去のハンドが重くなってる上に、テンポアドを取れる、相手のテンポアドを削げるカードがない。「荊軻」なんて抜くことすら考えましたが、AP3 なので DP2 のアタッカーに合わせても良い、DMG2 とはいえ殴れる、当然除去もできる、ということで結局採用しました…が、ようは器用貧乏ということでしかないよなあ、と当日になって気づきました。優秀なドローソース追加されるか、コストからタップが消えでもしない限りは現環境ではただただ遅いとしかいいようがない。でも抜いたら本当に雪使う意味がなくなるね???

最初は混色が作りやすい花と合わせて花雪を作っていましたが、いかんせんデッキパワーが足りない。というか花単のほうが安定して強い。花のコンセプトに対して、雪が特にプラスにならないんですね。除去で穴開けて 5 点通ったよーわーいみたい悠長なことやってられる環境じゃないし。

最終的に、フェスタ二日前に宙雪とかいう気の狂った混色に走りました。宙も雪も今のカードプールだと混色には向かない色です。当然のごとく不戦勝覗いて全敗したんですが、コンセプトは貫けたのでよし。一戦目は、相手がラストターンハンドゼロ枚からのトップディスティニードロー「アーラシュ」のサポート効果追加一点で詰められてなければ勝ってたし…あれは悔しかったなあ。四戦目(だったっけ)も、事故って即投了したんですが、その後空いた時間でやったフリーでは普通に勝てたし…気の狂ったデッキでも、コンセプト通り動くことができれば一定強いという、当たり前の話なんですが。

ということで使ったデッキ。レシピは公式に提出したのがあったので雑にリンクで済ます。コンセプトは「ヴラドおじさんの打点を通し続ける、通らなかったら能力で対面飛ばして代わりに清姫に五点出してもらう」です。理想としてはヴラド清姫並べて毎ターン 8 点、できたら 10 点。まだ調整の余地はあるんですが、正直コンセプト通り理想通り動けてやっと勝負できる、程度のデッキパワーなのでもう調整もしないと思います。次の公認大会何ででようかな…体調的に出られるか怪しいけど…

SR マシュは採用していません。代わり(?)に R マシュが採用されています。理由は簡単で、日も宙も止められない、止めきれないからです。日は合わせたところで盤面を動き回るので、後ろから埋めるような動きしないと、半端に守るのでは意味が全くない。宙は除去が間に合わない。殴り合い宇宙です。

どうせ止められないなら、打点レースを遅延させるほうが筋が良いだろうと考えました。考えましたというか、昼食以外全勝の誰かさん(誰だろうね!)に言われて、確かに~となったので採用しました。毎ターン受けるダメージが 1 下がるのは旧 Lycee プレイヤーなら分かってもらえると思うのですが、特に今のような殴り合い宇宙環境だと大きいです。いきなりマシュ出すわけには行きませんが、出すべきタイミングで出せれば、1, 2 ターン分はゲームが伸びます。伸びた分だけ、除去を打てる可能性、宙のオダステアタッカーで後ろスタートで相手テンポ削いでオダステパンチ、等をできるチャンスがでてきます。相手が宙だと遅延してもあんまり意味ないんですが、どうせ日だらけだろうと思っていたので。蓋を開けたら割とそうでもなかったのでびっくりしました。

同じ DMG を下げる能力持ちだと、宙に「ダビデ」がいるんですが、タップに宙 2 点は重すぎます。タップだけなら採用したなあ。でもタップだけで 2 点減らせるって強すぎるか…

「実力行使」は不採用です。AP4 とテンポアドがものをいう環境で、除去のためにハンドを抱えて…なんてことはできません、こっちも初手からもアタッカー可能な限り並べます。ドローソースもないので当然除去打てるほどハンドに余裕ができることなんて、単色でも中々ないのに、混色でコスト足りるわけがありません。ので不採用。

一方「ガンド」は採用で、これは軽くて割と打てるというのと、ヴラドおじさんの対面に出てくるのが基本的に 2 ハンド AP3 の AP ブロッカーだからです。清姫が出ていればワンチャン 5 + 5 の 10 点出すぞオラーという…決まれば強いですよ、決まればね。早々決まらないけど。

ヴラドおじさんと言えば、弱点の DP2 を補う宙の「カルデア戦闘服」ですが、混色にしていることで雪の「宝具解放」も採用の目が出てきます。ヴラドおじさんが「宝具解放」で SP3 になると、清姫をサポートすることで AP 6 までもっていけます。5 と 6 は花相手だとかなり違うので大きいです。DP で真面目に守ってこない花以外の色にはあまり意味ないけれど…あと、なんだかんだ雪の DMG4 アタッカーの「アルトリアオルタ」も DP2 で同じ弱点を抱えています。ということでアイテムはどちらも採用。試しに両方 4 積みで回したら、当たり前ですが、サーヴァントが出ない事故が起きることが分かったので、コストバランス見ながら適当に減らしました。

DMG2 DP2 アタッカーは各色にいるのですが当然対策されていて、ガンド抱えてツーハンドこいやーとか思ってたら、日の 3 ハンド AP 4「メアリー・リード」をいきなりおかれて、うへーってなったり(混色ってばれてたので、ヴラドの能力打たれない可能性そこそこあるので普通にあり)、そうでなくても「割り箸」とか…あと大会参加賞の「フランシス・ドレイク」がヤバイ。ドレイクは二種類とも大概な性能してます。ネロも二種類とも大概な性能してるし、日は化け物が多すぎる…

これ以上だらだら書いても仕方ない気がするので、とっとと結論出してしめます。

結論、現環境では雪に勝ちの目ほぼないと思います。以上です。

以下蛇足。入賞者の方も何人か壇上でいわれていましたが、Lycee が復活してくれたことが兎に角嬉しいです。病人なのに無理してフェスタでたおかげで、月曜火曜と死んでて(今も体中が痛い…)明日も多分死んでるので、社会人としては完全にダメなんですが、出られてよかったです。大好きだった TCG が復活したのに最初の大型大会に出ない手はない…とはいえ…えー、お客様各位、本当にすいません…いやほんとシステムパクってシャドバみたいな感じでどこかが出さないかなーと思ってた矢先の復活だったのでもうね本当にうれし(略)

追記:もうちょっとフェスの中身に触れよう。

自分の記録とかまあどうでもいいし、折角見てたので決勝の話。

日単のらじおさん対宙単のふうげつさん。このマッチアップだと基本的には日単有利なんですが(というか今、日単に有利取れるデッキが日単みたいな状態だと思う)、どの色をメタるかで割と変わってきます。軽めの日単対ヴラドメインじゃない宙単だと、割と宙単有利だと思う。初手ヘラクレス出せるといいですねコストきついけど。

結論からいうと、らじおさんは普通に玉藻の前を採用していました。宙単に対しての日単は、ヴラドが濃いかどうかで変わると思うんですが、基本的には、環境に除去ないし(バウンスはあるけど)ファッティにはファッティ理論で玉藻の前採用が正義な気がします。即カルデアスでバウンスされて泣くこともあるでしょうが…

まず、じゃんけんはふうげつさんが勝ち。テンポアド命な今の環境では、先行が取れるかどうかは本当に大事です。ずっしり構えて後ろから埋めつつオダステで攻める回し方する宙単の場合も、さすがに日相手だと先行がいいんじゃないかな…

続いてマリガン。手元見えなかったけれど手札良くなかったらしく、らじおさん、ふうげつさん二人ともマリガン。

先行のふうげつさんのハンドがかなり厳しい感じに(ふうげつさん側から見てました)。先行 1 ドローも振るわず辛うじて二体展開の苦しい初手。これに対して、後攻のらじおさんが SR ネロ、P ネロ、玉藻の前という、役満みたいな返し。見てる側ですらうわあという感じだったので、ふうげつさんの絶望度合は凄まじかったと思う。

盤面を動き回る三体が殴って殴って 9 点を通し続け、時にはネロが下がって一列止め(宙は SP が基本的に 0 なのでサポートで突破できない)…いや本当に、ネロどうかしてますね。ドレイクとネロはおかしい。なんで相手ターンにまで自在に動きまわってるんだよほんと。

らじおさんは初手以降、ハンドをチャンプブロックくらいにしか使わず、つめろの場面もしっかりネロでつめて勝ち。正直、さすがに一方的すぎて、決勝卓でこれは辛いなあ…という感じのゲームでした。らじおさんの初手がマリガン後と 2 ドロー含めて本当に役満だったので、仕方ないんですが。

ドロップはしなかったんですが、途中不戦勝したときに覗いた上位卓も、日単が矢張り多くて日単強いなーという感じでした。日単に有利取れる可能性あるの宙単くらいだと思うんですが、日単は日単で宙単をメタった構築にできるし、仮に日単ミラー想定して組んでても宙単に不利かといわれるとそこまで…だと思うし、日単ヤバイなあ…と改めて思わされる決勝戦でした。

ScalaMatsuri 2017 に参加しました

しました。感想とかそういう感じの記事になります、遅くなりましたすいません。

色々あってそもそも CFP 応募してなかったんですが、結局二日目のアンカンファレンスで発表させてもらいました。

アンカンファレンスは、一日目にまず話したいことを適当に大きめの付箋紙に書いてホワイトボードにはり、聞きたい人たちが付箋にマーカーを付けて、マーカーが多いのを二日目にやる、という感じなのですが、たくさんマーカー頂けたのでこれは頑張らないといけないぞという感じで、大変でした。

タイトルは "What is Composability in Scala" で、発表スライドは以下に。兎に角時間がなかったので、口頭で補足しまくる感じの作りになってしまいました、スライドだけ見てもよくわからないと思います。

slides.com

Scala のオブジェクトシステム使えば ML 系のモジュールプログラミングができるよ、知らず知らずのうちにモジュールプログラミングをやっているんですよ、Haskell だけでなく ML からも学べるところはあるのでやっていきましょう、みたいな話でした。

実際 ML のモジュールを使ったプログラミングというのはプログラムの Modularity を向上させる上でとてもよく、なんで皆 OCaml じゃなくて Haskell から入門しちゃうのかなあといつも思う。

思えば self-type annotation について ScalaMatsuri で話すのは二度目な気がします。この言語機能はとても有用な割に、いまいち正しく使われていないというか、そもそもあんまり使われていない、と思う。

実装継承は is-a 関係でないし、実装詳細が外部に見えてしまう、ので所有(aggregation)を使いましょう、DI しましょう、みたいなことが古くから OOP 界隈では言われてきているわけですが、Scala の self-type annotation は、これに対する言語としての一つの回答になっていると思います。

あと、self-type annotation は最終的に具象化されるタイミングで、要求しているものが実装されていればよいのに対し、コンストラクタ DI とかだと、クラス A を要求するクラス B を要求するクラス C を要求するクラス D …みたいなので wiring が大変冗長になる。なので DI 「コンテナ」(DI と DI コンテナを混同する人が多いので強調しておきます)使おう、となるわけですが、DI コンテナは強力な反面、適切に使わないと、逆に依存関係スパゲッティができあがりがち。DI コンテナを使っていたつもりが DI コンテナに使われていた、みたいな…現在進行形で請けているお仕事のコードがそんな感じで、どうしたものかという心持ちなのですが。

abstract method(member) でいいじゃないか、という声もあるかと思います。それはそうです、自分だってなんでもかんでも self-type annotation にはしません。目安として、abstract member が 3 つを超えたら、基本的には別 trait に分けていいと思います。他の評価軸としては、自明に妥当な名前をつけられるなら別 trait に分けていいと思います。

self-type annotation のメリットは他にもあります。例えばメソッド定義 A、A のための抽象メソッド宣言 B、メソッド定義 C、C のための抽象メソッド宣言 D…みたいに、抽象メソッドが具象メソッドに埋もれてしまっていると、何を実装すればいいのかぱっと見でわからなくなってしまう。抽象メソッドをまとめてクラス定義の一番上や一番下にまとめるという手もありますが、self-type annotation なら要求されている型を見ればすぐにわかる。命名がしっかりしていれば要求されている型の定義を見なくてもコードが読める。適切なモジュールの切り分けと命名による可読性の向上ですね。

最近の IDE は賢いですから、定義がまだないものを列挙しといて、なんなら中身空っぽでメソッド定義書いといて、みたいなことがサクッとできるわけですが、IDE で常にコード読むわけではないので。

あとは実装「だけ」を継承する記法、というか言語機能があればなあと思うんですが…mixin して instantiation したオブジェクトは、そのままだと型推論で mixin の情報全部残るので(A with B with C みたいになっちゃう)、基本的には型注釈をちゃんとつけてあげるわけですが、object とかはそういうわけにもいかない。package object で val わざわざ使ってやるしかない。大変だるい。

発表内容にもありますが、(abstract) type member の存在も非常に大きいですね。話すと長くなるので略。

あとは first class module が自明に実現できているのが地味に大きいのではないかと思います。逆説的に、ScalaOOP で当たり前にできていることが、実は ML 系では難しいということになるので、なかなか面白いですね。first class module 実現するために必要な型チェッカの修正が大変らしいので、仕方ないけれど。

他には、自分の発表の一つ前の発表 "Poor man's type classes revisited" で色々と補足させて頂きました。Haskell の型クラスがどういう風にコンパイラに解釈されて翻訳されるか、みたいな話をしました。Haskell は thunk を使って評価していくので、型クラスの辞書のようなよく評価されるものはパラメタの頭にあるといいので、パラメタの頭に辞書を持ってくるわけですね…とか書いても、当日あの場にいた人間にしか伝わらないか。この話は終わり。

というわけで ScalaMatsuri お疲れ様でした。まずは今年も問題なくカンファレンスを実現、成功してくれた運営の皆さんに感謝。でも寿司バー瞬殺だったのは次回改善して欲しいですスシウオーウオースシ。次に、チケットを譲って頂いた、侍スポンサーの Dazzle 様にも感謝。今契約中のお客様です。



チケットを譲って頂いたということで、ここからは社の宣伝をしたいと思います。

Dazzle 様はウェッブサイトにもありますが、(自社製品としては)VR をやっていく感じの会社です。前述のウェッブサイト見てもらうのが早いので、詳細は略。

個人事業主の自分が何をやらせてもらっているかというと、ざっくりといえばコンサルに相当するようなことをやらせて頂いている、と思います。コードレベルで、ここはこうしたほうがいいんじゃないでしょうかと突っ込んだり、設計レベルで文句…もといアドバイスをしたり、自分でコードを書くこともあります。こういうの欲しいけど作るの難しいよね〜→ヨッシャ任せんしゃいみたいな。ただの便利屋な気もします。今はリリース前なので、進捗に影響出ても悪いし、レビューやツッコミはほどほどに、リリースに関係ない作業を細々とやっています…例えばこれ書いたり…仕事の範疇…だと思う…

うちのブログ見てる人は大体知ってそうですが、自分は結構面倒で重い症候群を患っている病人なので、一日に四時間程度が稼働時間の限界です。基本的に在宅じゃないと厳しく、出向なんてすれば着く頃には体力をかなり削られる、といった始末です。この前なんて社に出るだけ出て半分くらい寝てました。我ながら酷い…そんな感じで、色々融通を効かせてもらって、なんとか働けています。これは自分に限ったことでなく、社員さんにも基本在宅の方とか、たまに在宅作業する人とか、普通にいます。

所謂「自由な社風」が実現されていると思います。「自由な社風」を謳う会社の多くの、許容する働き方の狭きことといったら本当にもう…Dazzle 様はその点、働き方に関して融通がかなり利くと思います。自分だけでなく、社員さんも自由な感じです。勿論普通に働いている人もいます、というかそっちが多数派な気はする。一方で、コアタイムさえ出ればええねん〜みたいな感じでやっていく人もいますし、前述した通り今日は集中したいので在宅で〜みたいなこともあり。本当に自由です。あと、変わっていることというと、一日八時間じゃなくて七時間です、珍しい。といったような自由な社風を実現する一方で、無法地帯化したりということはなく、ちゃんと注意されるべきことはされますし、守られるべきことも守られるよう各位ちゃんとしています。良いことだと思います。

もう少し規模の小さいスタートアップとかなら、このくらい自由なところは他にもありますが、大きいところで実現されている所はあまり知らないです。

ファシリティは…紅茶党には厳しいです。コーヒーメーカーしかない。辛い。あと人が増えてきて机が足りなくなり、ついに基本的に在宅の自分の席はなくなってしまいました。かなしー。他にも色々書けるといいのですが、基本在宅なので正直あまり詳しくないです。

ScalaMatsuri の侍スポンサーになるくらいなので、Scala を業務で採用していますし、Scala が書ける人材を募集している、はず、です、多分。正直にいって、Scala native がいない状況なので、Scala native な社員さんが欲しくてたまらないんだろうなあ、という感じです。Scala を業務で書きたい人は是非。native くらいのレベルの人が入ったら、自分も多分楽になるし…!自分がお仕事させてもらうことになったのも、現場に Scala native がいないから、というのが一番だと思います。正直これは〜〜?と思うコードは、レビューしてるとそこそこ出てきます。腕の見せ所ですね、出来てるかは兎も角。Scala 関連のことから、プログラミング一般に言えることまで、色々です。あと C++ とか MSVC のビルド設定とかもやっている気がする。自分の業務がなんなのかわからなくなってきた。

Scala 以外だと Javascript(node.js) だとか色々。求人サイトなりを見てもらう方が早いと思うので省略。

ところで、書いていて思ったけれど、Scala native って何をもってして native といえるんだろう…言語機能 8 割知っていて 6 割使いこなせて有名どころのライブラリ一通り触ってれば native か…?まあ良いか、兎に角 Scala 書ける!Scala 書きたい!という人は是非ご一考を。今ならボクが業務でマサカリ投げます!(嬉しくない)

Wantedly にも求人出してるそうですが、Wantedly へのリンクは宗教上の理由で貼れません。ぐぐったら出てくると思うのでそれで。Wantedly 以外の求人サイトにも求人は出ていると思います。Facebook もあるはず…

追記:ファシリティについて、お茶が知らぬ間に増えたそうです。求人に関してはコーポレートサイトが最新とのこと

とある社が矢張りなくなってしまうことが決まってしまった。

経緯を知ってしまっているし、関係者を大体知っているので、色々思うところはあるんだけれど、兎に角残念というのが一番。

仕事を取ってくるっていうのは本当に大変なことなんだな、というのを個人事業主になってから少しは分かった…と思う。自分の場合、病気を患っているという点で、普通よりはるかに厳しいというのはあるんだけれど。
まで書いた時点で、去年やってた案件は、なくなる社にいた人からの紹介だったことに気づき、また大変複雑な気分になった。
その点、ボクが体壊した当時いた社は、今でも何か普通にあるし、やっぱ産総研とずぶいと強いですね。ボクが体壊す必要なかったよな。いや今更社に怒ってるわけではなく単なる事実として…

兎に角色々な気持ちがあり、こうして記事を書こうと筆をとった(キーボードです)のだけれど、とても残念ですということと、お疲れ様ですということと、ボクにお仕事を紹介してくれる各位や、ボクの拙い営業に応えてくれる皆様に感謝するしかない…自分のことで精一杯だ。というか自分の事が今できてるのかといわれたら、怪しい。

うーん、うーん…仕方ないよなあ…頑張ろう…本当に残念だ。

今請けてる案件とは別に動いてる話があって、それがもう少し具体的な形になった時に、自分一人ではさすがにできない話なので、都合があえばお仕事を回させて貰おうかなとか考えていた矢先だったので、そういう意味でも辛い。

すごく当たり前なんですが、どんなに優秀な(一般的な社に比べれば優秀だと思う)人材のいる社でも、仕事を取ってくる、ないし仕事を発生させる人間がいて、初めて社は生きていけるのだという事実は、なんというか、なんですかね、こう…この先の身の振り方とか…当然考えてはいますが…辛いなあと…(普通の人間だってエンジニアとして働き続けるのは大変なのに、病人の自分が 10 年後もエンジニアできてるなんて思ってないです、できてるかもしれない程度、普通に実家帰ってあとはただの病人として余生を過ごすことになるかもしれない)

全然纏まらないな、お疲れさまでした。

Remove all ads

Rust は何が新しくないのか

Rust Programming

disclaimer

追記で注意書き足すのはどうなんでしょうね。ということで追記です。

  • 別にギョムでガンガン書いてるとかではないです。
  • ノミコンの方も含めてドキュメント全部読んだ、API 一通り眺めた、型推論というかリージョン推論部分の概要眺めた、関連する論文読んだ、言語触った、程度の人間が書いてます。
  • 正しくない、不正確な部分もあると思います。
  • 雑です、すいません。

TL;DR 的には、C++ 置き換えるための言語として作られたので当然 C++ にあった概念引き継いでますよみたいな話です。

以下追記前の元の全文。

以下の記事が結構人気と聞きました。

Rustは何が新しいのか(基本的な言語機能の紹介) - いもす研 (imos laboratory)

ここでは、記事中の「新しくない」部分を historical な話を交えて説明する形で何か書きたいと思います。

記事を否定するようなものではないです。寧ろよくまとまっていると思うのですが、綺麗にまとまりすぎていて「分かっている人にしか分からない」部分があるかな、と思い、筆を(キーボードーですけど)取った次第です。対象読者は GC のある言語でしかコードを書いたことが無い人、なのかな。

「Rust のプログラミング言語としての立ち位置」補足

元記事では、言語の今と未来について書かれていますが、ここでは昔話をしましょう。

Mozilla は様々なプロダクトを過去 C++ で実装してきました。巨大なプロダクトが多く、開発には自作の静的解析ツールが利用されていました。

しかし、問題が起きます。静的解析ツールが利用していた C++ をパースするライブラリがバージョンアップされず、C++11 辺りから使えなくなってしまいました。そも、以前から作者はもうメンテナンスしておらず、Mozilla が確かメンテナンスをしていたんだったっけ…ここ嘘かも。

Mozilla(の開発チームの一部)は、言語処理系のプラグインとして静的解析ツールを実装できないか、と考えました。結果、生まれたのが gcc compiler plugin とコンパイラプラグイン Dehydra です。が、gcc の AST(抽象構文木)は、ツールを作るには位置情報等があまりにも不足していました。少し話がそれますが diagnostic を大切なものとして設計された clang の AST は、その辺りかなり配慮のある設計がされています。また、gcc の mangling のタイミングが安定しておらず、コンパイラプラグインにわたってくるタイミングで何故かシンボルが mangling されていたりいなかったり、といったバグもありました。そもそもコンパイラプラグインなんて想定せず開発されていたのでバグともなかなか言いづらいのですが。

自分が見ていた範囲では、上述のようなことを Mozilla は行っていました。clang もコンパイラプラグインの仕組みを持っていたのですが、Mozilla は「代替言語を作る」道を選びます。それは勿論 C++ を捨てることを意味します。

結果として誕生したのが Rust です(Cyclone の話は割愛します)。大規模 C++ プロダクトのコードを置き換えられるような言語でなければいけませんでした。そして、Rust は十分にそれを果たせているように思います。

「スマートポインタが生まれるまで」補足

C++ には GC が存在しません。少なくとも今は。生のアドレス値をポインタ型を使って扱うことができます。逆にいうと、GC がやってくれる「ゴミ捨て」を(GC には compaction 等の仕事もありますが割愛)自分でしなければならない、ということです。GC のない言語を利用したことがない人には想像がなかなかつかないと思うのですが、常にリソースの管理をしながら本来の処理も記述しなければいけない、というのはかなり大変です。

大変ですから、その仕事を楽にしようと仕組みが作られます。元記事で言及されている unique_ptr 以前から、C++ にはスマートポインタが存在しました。様々なライブラリが独自に色々作ったりしていましたが、標準ライブラリからは auto_ptr が提供されていました。これは、Rust に同じく(Copy trait の話は割愛)代入演算子が move となるようなポインタ、のように振舞うクラスでした。しかし、代入演算子が通常はコピーとして使われていた当時、auto_ptr の semantics には多くの開発者が混乱させられました。結果として auto_ptr は「使うな」と言われてしまいました。使うなと言われてはしまいましたけれど、この頃から move semantics は(標準ライブラリレベルで)存在したわけですね。

言語サポートが入ったのは、元記事にある通り C++11 ですが、それ以前から Boost ライブラリ等でもスマートポインタやスレッド(スレッドは所有者が一人でなければならないリソースなので、move が必要です)に対する move のサポートはありました。また、lifetime(寿命)の概念についても Boost scoped_ptr や shared_ptr の頃からライブラリレベルで示されていました。認知度は…兎も角…

「Rust の言語機能」補足

どの機能も、何かしらの既存の言語に存在するものですが、C++ にはなくて辛かった、みたいな機能ですね。一応書いておくと、generics と template は似ているようで全く異なる言語機能です。

結局何が新しくないのか

lifetime や move semantics は C++ に元より存在する概念でした。そも、言語のサポートのあるなしに関わらず、raw pointer を扱う言語であれば、意識しないといけないものです。皆さんも C でこんなコードを書いた経験があるのではないでしょうか。

struct string {
  char *ptr;
  void (*free_fn)(char *ptr);
};
void free_string(char* ptr) { free(ptr); } // malloc などで生成された char* のための開放関数。
void do_nothing(char*) { ; } // リテラルなどで生成された寿命を持たない、もしくは寿命がスタックに管理されている char* のための何もしない解放関数。

デストラクタによる自動解放こそないものの、これはまさしく C++ のスマートポインタにおける custom deleter ですね。結局言語サポートがあるかないかだけで、C だろうが C++ だろうが同じことをやるわけです。ちなみに、このような複数の lifetime を同時に扱う仕組みは、Rust もちゃんとサポートしています。Cow trait だっけ、違ったらすいません。

長くなりましたが、つまり新しくないのは、lifetime や move semantics の概念です。C++11 以降も加えると、move semantics の言語サポートも新しいものではありません。

結局何が新しいのか

消去法で残ったの出すだけです。新しいのは lifetime と linearity の言語サポートです。

Rust では変数の寿命をコンパイラがチェックしてくれます。それは参照も同じです。C++ の参照はごく稀に「この参照触ってる間に死んだりしないよな…」と心配になることがあります。ownership を意識してコードを書いていれば大丈夫なんですが、外部ライブラリとか使ってると信用できませんからね…Rust の借用は、lifetime がコンパイラに管理されている参照です。参照が生きていることはコンパイラが保証してくれるので、安全に利用することができます。

また linearity、雑にいうと変数が一回しか使われてないかどうか、触っちゃいけないもの触ってないか、もチェックされます。これで死んだオブジェクトを触ってアチャーという事故も静的に検出し、防ぐことができるようになります。

Rust の新しい部分は、結局の所メモリなどのリソースを管理する上で、C++ で足りなかった、あって欲しいなと皆が思っていたものと言ってしまっていいでしょう。

C, C++ の話多すぎてわからないんですが

Rust は最初に書いた通り、MozillaC++ で書かれた巨大プロダクトのコードを置き換えられる言語でなければいけませんでした。C++C++ なりに色々頑張っていたので、Rust はそこから良いもの(lifetime, move semantics)を取り出し、足りない部分(lifetime と linearity)を補いました。のでどうしても C++ の話を出さざるを得ません…というかぶっちゃけ Rust って C, C++ 使いがやったーという気持ちになる言語だと思うので、そうでない人に良さ伝えるの、無理ですねこれ(諦念)。

一応諦めずに説明頑張ってみよう。GC のある言語でも、不要になったらこのメソッド読んでね、というようなメソッドを持つクラスはあります。あれを適切なタイミングで呼ぶの、自明なようで大変ですよね。不要になったと思ったら別スレッドでまだ使われていたとか、そういううっかりをやったことがある人はそれなりにいるんじゃないでしょうか。そういったことを常にやらないといけないのが C, C++ で(C++ は頑張ってますが)、それを全力でサポートして、危険なコードにめっしてくれるのが Rust、でどうでしょうか。やっぱり駄目か。

で、全力でサポートしてくれるので、リソース管理を GC に任せっきりで生きてきた人が Rust を書くと、大抵変なコードができあがるわけですが…まあ当然ですよね…

まとめ

話が散漫としすぎたのでまとめます。

  • Rust の lifetime の概念や move semantics の言語サポートは C++ 等で以前よりあった、特別新しいものではない。
  • Rust の lifetime や linearity の言語サポートは(研究用の言語とか除けば)新しいものである。
  • Rust の motivation に C++ が絡むので、C++ 知らないと Rust の嬉しさを真に理解するのは難しい。
    • C++ での lifetime の概念や move semantics の言語サポートですら難しいのに、それにまだ言語サポートが増えるんだから当然のこと。でも、安全なコードを書くためには必要で、(C++ を書いていた)皆が望んでいたもの。

うーんやっぱり Rust の良さ、新しさを C, C++ を書いてこなかった人たちに説明するのって難しいですね…雑におわります。

追記:みんなが望んでいたものとか書いてるけれど世の中にはスマポ使わない派とか free しない派もいるので多様性です。

近況

頸肩腕症候群 ポエム

12 日に大事な打ち合わせがあったのだけれど、気圧による体調不良で欠席の連絡もできずに(かろうじて DM 送ってくれた h 君のおかげでほぼ無意識に何か DM 返事してて体調不良だということは伝わったっぽい)死んだりした。

昨日は起床失敗してお薬切れて死にかけ状態から、気合いでお薬マシマシしてなんとか回復後即仕事→ダメージ回復しきってなくて今日またダウン。無理はよくないですね。まあでもそこまで重くないので夕方には落ち着くかな…

受託している案件が一件、話進めてる案件が一件、生活保護が未だに受けられていなくてこれの対応もしないといけない。三つも抱えていることになる。
生活保護の件は NPO の人にあとはメールで~と言われて一か月くらい放置されて、reminder メールしたら忘れられてたっぽくて返事きた。同伴するので役所にいくなといわれてたので、当然進展はない。働いてるのにまた借金するはめになりそうというか多分なるので相談中。厳しい。

フリップフラッパーズがとても面白かった。スタッフトークショーにも行った。体調的にも金銭的にも行ってる場合じゃないんだけれど、何のためにわざわざ生活保護やめて働きだしたかって、色々あるけどちゃんと楽しく生きたいねということなので、行って良かった。
体調は兎も角、精神的にはまあ安定していると思う。前の案件と違って一歩引いた立ち位置から見てるからかな。どう考えても炎上案件だーと思いつつ、契約通りメインのギョムーにはバグ対応とか以外あまり手を出さない。自分が頑張れば色々一時的には改善できるとわかっていてもやらないというのは結構しんどいんだけれど、まあ契約内容が契約内容だしと無理矢理納得する。それでもこの前請求書作るために働いた時間計算したら、働きすぎてたんだけれど…

大変ですが頑張って生きていきましょうというようなあれです。仕事その他でいっぱいいっぱいで、最近正規言語のお勉強ができてないのでワオワオワーという感じ。他にも数学の本(今度は確率論だよ、これなんで学ぼうと思ったんだっけ。SVM について survey してたからちょうどいいけど)頂いたのに。忘れないうちに正規言語の pumping lemma のまとめ書かないと。あと去年読んだ論文のうち面白かったのも紹介したい。

何にせよ焦らずやっていきましょう。お金がないどころか赤なので、生活保護の件だけは焦りましょう。貰えるはずの 60 万くらいを貰ってないんだよなあ…焦りましょうっていうか、役所に水際作戦されて、NPO の人に相談したら忘れられて、なんかもう誰を頼ればいいんだ状態なんですが。reminder 送ったらちゃんと対応してくれたし、あとは同伴で役所に GO すれば…

そんな日々です。

Remove all ads

年を越したりなど

した。
実家にも帰れなかったし、年越し感が殆どない。めでたさを感じられていない。今度神社へいっておみくじでも引いて来ようと思う。おみくじは、好きなわけじゃないけれど、正月関係なくたまに引く。人生ガチャ。

2016 年は色々と失敗だった。失敗というか、甘かったし、災難だった。病人がリスクを抑えつつ働いていくためには…みたいなことを、きちんと考えないままふんわりやっていたのがよくなかった。そもそも個人事業主になった経緯が経緯なので、仕方ない気もする…好きでなったわけではない…現状他に選択肢もないので今後も暫くは個人事業主として働くことになりそうだけれど…暫くが具体的に何年なのかはわからない。先のことは、分からないことばかりだ。

昨年は、6 月末にお仕事の契約切られてから、二か月程休憩期間ということで休んでいた。実際前のお仕事で結構疲れていたので、一か月くらい休むのは順当だったと思うけれど、二か月は休み過ぎた。ここで休まずに、きちんと次のお仕事探しをしていれば、貯蓄が尽きる前に仕事が見つかっていたかもしれないし、見つかっていなかったかもしれない…単に運な気もする。運だ。病人が仕事を取ってこれるかどうかというのはほぼほぼ運で、ボクが一所懸命お客さんの所に足を運んで売り込んでとかやっても、基本的には大体ダメで、ダメでというかダメだったんですけど…まず自分の病気の都合でリモートワーク必須という自分の条件が厳しすぎる…それが、今受けてる案件のようにサクッと決まったりもする。あまりにも運。
色々あったけれど、一つ言いたいのは、自由な働い方~とか謡っている社の殆ど、少なくともボクが行った社の全ては大して自由ではなかった。当たり前だけれど、社会は病人に厳しい。社会は普通に健康な人間に最適化されている。合理的だし、正しいとは思う。しかし今のボクは病人なので、困る。
あと、ボクはフルタイムで働けない。フルタイムで働けるなら普通にサラリーマンに戻る。時給単価の安い仕事なんて受けて居られない。時給単価安い仕事せっせとやって貴重な体力を失うくらいなら、大して貰えない生活保護でも受けつつ仕事を探したほうがましだ。問題は生活保護受給額で仕事探しって交通費すら厳しいということなんですが…いやほんとに…
高い時給単価で案件を受けるには自分のバリューが一定高くないと、そういった案件は受けることが難しい。これも運な気がするけれど。あまり外面を保つためだけに何かやるみたいなのは好きでないので難しいところだけれど、個人事業主で、自分という存在がある種のブランドで、自分でお仕事取ってこないといけない以上は、その辺も考えないといけない。一番分かりやすいのは OSS プロダクトに contribution したり自分で何か作ったりだと思うのだけれど、ボクはそういった行為に全く興味がない。仕事で使ってるものに仕事の時間外にちょっと contribution するくらいはやっていった方がいいのかもしれない。それで仕事で使っているライブラリなどが改善されたりすれば仕事もしやすくなるし。一番いいのは業務として contribution することだけれど。
というか実際に仕事ができるかどうかなんて正直 github で草生やしまくってるとかと殆ど相関ないと思うんだけれど、どうなんだ。まあ、どうでもいいか。ボクには関係ない。話せる範囲でお仕事の話をできればいいと思うんだけれど。
まあしかし、どんなに自分は優秀ですよとアピールしたところで、精々一日四時間ぐらいしか安定して稼働できない、リモートワークでないと働けない病人ですよといった途端にバリュー一瞬で下がるし、どうしようもない気もする。ウムム。
長くなったけれど、急にお仕事なくなって困った~みたいにならないようにしましょうということです。去年はそうなった。今年はそうならないようにしたい。
あと、これは去年からわかっていたことだけれど、もう正直安定稼働が見込めない人間は開発ガンガンする系のプログラマとしては価値が圧倒的に低い。ので、案件も単に何か作るみたいなのを受けるのは多分お客さんにとっても自分にとっても損で、そうではない何かがいいはずで、じゃあそれって何なんだという部分を、もうちょっと考えていきたい。必要ならその辺の学習もしないといけない。

長くなった。次に生活保護。前述したように 11 月に貯蓄が尽きた。ガルパン BD とかグッズとか買いすぎたせいでは?といわれると、まあそうなんだけれど、買っていなくても、どの道 12 月には尽きている。大体自分が稼いだお金でアニメの BD も買っちゃいけないんだったら、もう何のために働いてるのかわからなくなってしまう。
ケースワーカーによる(意図的なものか単にケースワーカーに業務遂行能力がなかったのかは謎、恐らく両方)水際作戦を受けて、本来 11 月に受給できていたはずの生活保護が、今も受給できていない。NPO に相談したところ(実際に相談窓口に依頼してから対応してもらえるまで二週間以上かかった、それだけ相談が多いのだろうとかg萎えると闇)、ケースワーカーの対応が違法なものと判明したため(少なくとも法的に定められていないことを言われているなということは分かったので相談した)、NPO の人とカチコミにいきましょう、ということになった。行くまでは話は進めないでください、といわれてそれを守っているので、未だに受給できていないのだけれど、いい加減貰うもの貰えないと、貯蓄がなくなってから早二か月と少し、当たり前だけれど困っている。今のお仕事の収入が発生する方が早いみたいなことになりそう。全く笑えない。
ややこしいのは、本来 11 月に受給できていれば、12 月のアパートの更新料も自分が払う必要はなかったし、そのために余計に借金する必要もなかったという部分で、その辺どうしましょうね、というところで電話での相談は終わって、以後はメールでやり取りしましょうとなったのが先月の終わりくらいだった気がする。メールはまだ一件もきていない。アドレス確認のメールくらい欲しい。メールアドレスは口頭で伝えたので、間違えって伝えているかもしれないけれど、その時はまた電話がくるだろう…住所から電話番号から知られているのだから…順当に考えれば、単純に年末年始で NPO の人もお休みなのだと思う。NPO の対応してくれている人がどういう人なのかがまず分かっていない。NPO の人にまで放置されたらもう知らない。この一件のおかげで人間がどんどん信用できなくなっている。
ところで水際作戦はよくある話だと聞いていたのだけれど、NPO の人に詳細伝えたら、急に声のトーンが深刻になって、違法ですね…みたいになったので、実際に NPO にそういった事案が相談されることは少ないのかもしれない。泣き寝入りが多いのか、生活保護受ける人間の殆どなんて、基本的には高齢者なので(少なくとも、うちの区の生活科で年寄り以外を見かけることなんてあまりない)、年金で我慢とかそういう感じになるのか。それとも破滅するのか。
なんにせよ、病気を患ってはいるが復職、就労の意志のある 20 代の若者(そう、まだ 20 代だ)に水際作戦は辞めて欲しい。いやそうでなくても違法だし辞めろよという話なんだけれど…年寄りみたく、他にも年金とか貰えるなら分かるけどさ…他に貰えるものなんて何もない若者に対してやることじゃあないと思うんですが…何なのだ…社会は厳しい。

病人生活六年目だけれど、病気背負いつつ個人事業主始めてからは一年なので、まだまだこれからですね程々に頑張りましょう、ということで、終わりです。生活保護問題今月中には解決するといいけど、今月忙しい(今請けている案件以外にも営業続けているお客さんがいるのでその諸々)ことが既に確定してるんだよなあなんなんだほんと…