Zinnia hacks tomorrow. (Digest)

はやおきをすると、いいことがあるよ
(なかまにしてほしいといっています)

お勉強会 やっています。よかったらご参加下さい。

オリジナルはrisky-safety.orgの方です。zinnia.dyndns.orgはミラーです。

アンテナ被捕捉状況: 1コ上におひっこし

他の記録

おしらせ

タイミングと条件が合えば転職しようと思っております。 相談に乗ってね (読者参加型転職)

2020/01/25 (Sat)


= 最近のF#

_ 先日の1回休みのときに Scott Wlaschin - Talk Session: Domain Modeling Made FunctionalThe Power of Composition - Scott Wlaschinを見た。 後者はこのひとの一連のプレゼンの中ではかなり基礎的な話なのでとっつきやすい。 前者は、関数型言語と型をどうあつかってゆくといいのかという戸惑いにいろいろ ヒントを与えてくれる内容だった。


= O'Reilly Learning

_ やっぱり読み上げをさせたい。アプリ+Talkbackだとうまくないし、 AndroidのChromeは期待通りにページを読ませることがうまくできた試しがない。

_ Windows10だとどうかな? どうやら「ナレーター」という機能で読み上げが可能らしい。 視覚障害者向けの機能だとは思うんだけど、けっこうショートカットキーが 駆使されているようで、有効無効を切り替えるために Windows+CTRL+Enter と すでにハードコアな組み合わせを求めてくるあたりがすごい。 コンテキストに依存する操作よりもショートカットキーのほうが効率がいいのかもしれないが…

_ O'Reilly Learningのebookで試してみたところ、読み上げの具合も悪くない。 精度は申し分なく、読み上げ位置をきちんと画面内におさめてくれるような制御も してくれるので、長めのページであればそのまま放っておいて読みつづけるといったことが 可能なようだ。たまに前触れなく読み上げが止まってしまうことがあるものの、 再開すればまた読んでくれるのであまり大きな問題ではない。 これならWindowsタブレットでもいけるかな? ArrowsTabで試したところ、 どうも読み上げスピードが一定しない。読み上げ自体のスピードは遅くないのだけど、 「間」を感じることが多い、と言ったほうが正確だろうか。 3〜4語ごとにその「間」を感じるので、せっかく読み上げスピードを上げてもあんまり 速くない。ArrowsTabでこの調子だとすると、それよりも性能が劣るLavie Tabではさらに 悪い成績になるかもしれない。あとで試す。

_ 読み上げが安定してできるようになるとかなりよい。 今ちびちび読んでいるCoders at Workも読み進めるのが楽になるし、 この手のインタビューものや、技術系エッセイみたいなものの消費を進めることができそうだ。 O'Reilly LearningにはJoel SpolskyやPaul Grahamの本が収録されているので、 当分読むものには困らないだろう。他にもコードが少ない技術書ならどんどん読んでゆけそうだ。 幸い都心に勤務している身であり 地下鉄の中も含めてネットワークにつなげることができない状態はほとんどないので、 アプリで頑張るメリットがあまりない。けっこう最後に読んだ場所を忘れてくれるときも あるし… Sync Positionすると復活するときと、しないときがある。


= タブレットとナレーター

_ ナレーターキー (デフォルトだとINSまたは無変換が) を中心としたショートカットキーを 繰り出そうにも、ソフトウェアキーボードでできるのか? そもそもナレーターキーにアサインされているキーとの同時押しを想定しているようなので むりっぽい。 タッチ操作でもできるみたいだけど なかなかのアクロバティックな操作を要求されているような。 あとマルチタッチ対応のタッチパネルじゃないとだめそうだ。Lavie Tabはどうだったかな… それとArrowsTabだとナレーターを有効にしつつChromeを使おうとすると けっこうな頻度でディスプレイドライバがいやんなことになってログイン画面に戻されてしまう。



= WinDbg

_ 平成が終わってもまだこのソフトを使っているというのが不思議な気分だが 他に替えがきかないままの状態なので仕方ない。 カーネルのデバッグに使うというよりはSOS拡張を使って .NET のデバッグをするケースが多い。とくにメモリが絡むやつは これが一番調べやすいように思う。

_ とはいえ道具だてをきちんと把握できていないので、手作業が多い。 もうちょっとスクリプトとかプログラム言語的なもので解析を進めてゆきたいところなのだが…

_ Cisco-Talos/dotNET_WinDBGから辿れる Talos Blog || Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Unravelling .NET with the Help of WinDBGを読むと、 pykdというやつを使ったりできるようだ。 あと、 JavaScript のブリッジにより、WinDbg でのマルウェア分析が容易に (Cisco Japan Blog) に書かれているような手法もあるらしい。 Debugger Data Model C++ Interfaces Overview - Windows drivers | Microsoft Docsというのがあるようだ。

_ 知らないだけでやりようはいくらでもあるみたい。 WinDbg自体もいろいろ垢抜けつつあるようだけど、それ以前にWinDbgをエンジンにして 自分の望む解析をするというアプローチをきちんと理解しておくべきなのかもしれない。


2020/01/24 (Fri)


= 歩いた

_ 昨日は雨あがりだったということもあり短かめにした。清澄白河で折りてから歩く。 そのまま北に歩くと京葉通りで、あとはいつも通り… で、50分くらいかかった。 4kmくらいだろうか


= 今日のKotlin

_ 雑音ばかりであまり進んでいない。が、ひとまず Kotlin Bootcamp for Programmersを終えた。 Androidに進もうかとも思ったが、 Refactoring Kotlinをおすすめされたのでそっちを少し見てみる。 Javaっぽい書きかたをKotlinっぽい書きかたにするにはどうすりゃいいの、というような 内容らしい。… そんなにボリュームがないのでひと通り眺めて完了とした。

_ Kotlin/Nativeで試しにEXEを作ってみた。Hello, Worldで1.4MB、 依存するDLLはkernel32.dllとMSVCRT.dllだった。 バックエンドはMinGWみたい (作成されたディレクトリから判断しているだけ) だが、 MSVCRTに依存するんだっけ? … 普通にgccでビルドしても同様なので、そんなもんらしい。

_ Cinteropというのがあるらしい。そしてARMのバイナリも吐けるようなので、 ひょっとしたらGoと同様にクロス開発ができる…かもしれない? ただHard floatじゃないとだめ? なように読めないこともない。 ターゲットのデバイスはSoft floatなのでむりかな

_ たまたま近くにRasPi3を転がしていたのでそちらで動かしてみた。 stripしたら200KBちょっとだった。とくに問題なく動く。 ただコンパイルが盛大に遅いなあ


= 今日のF#

_ こちらもさほど進んでいない。

_ JupyterでF#が使えるのが便利。 以前はF#を手軽に試すことができて便利。だったのに対して、 F#にちょっと慣れてきた最近はJupyterの機能を活用するにあたりF#が使えて便利、 というように、便利に感じる内容が少し変わっている。いずれにしても便利


2020/01/22 (Wed)

_ 今日は1回休み。いろいろ計画を事前にしていたんだが、9時過ぎに目が覚めたら 身体がとてもだるく活動することができなかった。 11時くらいまでフトンでうだうだして、再度寝て、気付いたら14時だった。 そしてだるさはほとんど改善しておらず、それに加えて頭痛まで…

_ 借りていた本を返さなければいけないこともありようやく活動を始めた。


= Who's in charge? / <わたし>はどこにあるのか

_ Dr林のこころと脳の相談室の 精神科Q&Aで何ヶ月か前に掲載された 【3868】コンサータによって自己の連続性を失いつつあるは、 ここ何年かの中で屈指のエントリだと思う。 このQ&Aの中でDr林が紹介している本が表題のものだ。

_ マイケル・S・ガザニガは、 アメリカの心理学者らしい。 分離脳患者の研究を通して右脳左脳の特性や 相互のやりとりについていろいろな成果を出したひとらしい。 この本は、ガザニガが ギフォード講義で行った 講義を元に構成されたものらしい。そのせいもあってか、 対象をとりまく問題の難しさを、 様々な分野の理論や仮説を紹介しつつ描写してゆくという構成になっているので、 書籍として読んだときに少々とりとめのなさを感じる。 この本で幅広く紹介されている事柄について、興味を引かれた部分を、 出典などを元にさらに学んでゆく、というような読みかたになるのかな、と思う。

_ 「インタープリター」について説明している部分は、 私がよく書く「後付けの理屈」そのものだった。なぜそう考えたのかを 説明しようと試みるときに常に抱く感覚だ。比喩として使っていた「後付けの理屈」は 実際その通りだった、ということか〜

_ 原著はKindleで、和訳は単行本で読んだ。原著→和訳→和訳→ と読んできた。 原著は、今の私には少々きつかった。別に難しい英語を操っているというわけではなく、 臓器・器官などの用語が理解できなかったり、 実験の手順について記述しているところで途中で迷子になったり、ということが 多発した。KindleのWord Wiseも、たまに「Medical word」みたいな、 それは分かってるんだけど的な註釈しかしてくれないことがあって難儀した。 和訳を2回読んだので再度原著を読み直してみるつもりだ。

_ この本と、それを読むきっかけになったQ&Aと、Dr林のコメントは、 私が抱いていた疑問というか違和感に近いものを表現していると感じたわけだが、 私の疑問というのはもっと素朴なもので、 生まれか育ちか (この本では「nature or nurture」と表現されていた) とか、 決定論、といった話以前の疑問として、 人間というものが遺伝と環境のいずれかまたは両方でつくられているのであれば、 自分というのはつまりなんなのだ? という感じのものだ。 あらかじめ決定したものであってもなくても、 遺伝であっても環境であっても、どっちにしても「自分の外」にあるように 見えてしまうので、つきつめてゆくと「自分の意思」なんてもんは なくなってしまうのではないのだろうか?

_ 自分の意思の存在を疑うことはないまま日常生活を送っているという 事実もあるわけで、この、自分の意思なんてものが果たして存在するのだろうか? というようなラジカルな見解と、わりと不具合なく自分の意思で生活できている 事実のギャップというのがとても不思議に感じる。 私なりの結論というか、妥協点としては、 まずそんなことを言っていたら元も子もない、というのが1つ目だ。 何か問題行動があったときにその責任を本人の意思に求めることができないのであれば 社会が成立しないではないか、というような発想。 もう1つは、年齢を重ねるにつれ、だんだんと「自分の意思」というもののウエイトが 大きくならざるを得ないのではないか、という感じの、うまく説明できないが、 そういう発想だ。その自分の意思というやつがどこから生まれているのか、 という点にはあいかわらず答えられないわけだけど。

_ 意識は多数の分散したシステムである (定説) にも かかわらず統合された意識の実在を確信している状態をつくりあげているのは なぜか? という、この本に書かれていた疑問 (意訳) は ここまでに書いた内容に近いのかもしれない。そこにはインタープリターが 大きな役割を占めているようで、つまり統合されているというのは そう見せられているに過ぎない、という話になる。 Q&Aで書かれていた「自己の連続性」というのもそれにあたるのだろうか。


= 奉行所と同心の住居

_ 昨日も歩いて帰ってきた。歩いていると暑くなるので薄着で歩き始めて、 結果けっこう寒いので体調が悪いのはそのせいかもしれない。

_ そして50分超えたあたりで絶妙に飽きるのも通例通りだった。 でも昔の武士やら同心やらは、このくらいの距離を普通に通勤で 歩いていたんじゃないのか? という思考になり、がんばって歩いた。 当時の人達がPodcastを聞きながら通勤していたとは思えないが… と、疑いようのないものに含みを持たせるのは私の悪い癖かもしれない…

_ 帰ってきてから北町奉行所、南町奉行所を調べてみたら、どちらも 東京駅の八重州口の近くだった。2ブロックくらいしか離れていない。 それなら八丁堀なんて1kmあるかないかじゃないか… 同心の通勤の苛酷さを 思いながら頑張って歩いたのはなんだったんだろう。へたすりゃ最寄りの駅まで 歩いたってそのくらいの距離だからなー


= 今日のCoders at Work

_ Joe のインタビュー (6章) を再度読み直している。

Seibel: Are there any other characteristics of good programmers?

Armstrong: I read somewhere, that you have a good memory to be 
a reasonable programmer. I believe that to be true.
いいプログラマになるためには記憶力が必要だとどこかで読んだことがある、 と言っていながらどこで読んだのかを覚えていない、というジョークをJoeなら やりかない気がしてしまうのだが…それは読みかたが歪んでいるのだろうか… ともあれ記憶力は大事だと私も思う。私は技術的な事柄や、 仕事に関する記憶力は周囲の人よりよいつもりでいるのだけど、 それは単に他の人が覚える気がないというだけなのかもしれないし、 自身の記憶力が少しずつ衰えていることも感じるので気をつけなければいけないと 思っている。


2020/01/21 (Tue)


= 歩いた

_ 冬場は寒くて走る気力がなかなか出ないのと、先日走ったときに息切れがひどく こりゃー走るコンディションになるまで走るのは減らしたほうがいいなと思い知った。ので 歩く量を増やすことにした。米沢にいた頃は歩くのは大好きだったが、 街中を歩くのはそんなに楽しくない… が、まあ連日同じ景色を見るというのも アトラクションのひとつだと割り切ることにする。

_ で仕事帰りに歩いたんだが… そこそこの重さの手提げを持ちながら、脱いだコートを 持ちながら、革靴で歩くのはわりとしんどいようだ。靴や鞄の整備も必要かもしれない。 あと、家までおよそ80分かかり、これが微妙に飽きる。 60分を超えたあたりから、疲労とは別の飽きるという感覚が出てくる。 もっともこれは地理的な要因もあるのかもしれないが… 隅田川を超えてからの 2〜30分が長く感じるというやつ。1時間ちょうどか、少し下回るくらいの距離となると、 水天宮前くらいまで移動すればよいのかもしれんが、2〜3駅の移動のために電車に乗るというのは なんというか間抜けに思える。


= ベビーオイル

_ とくに冬場はワセリンが大活躍で、塗りたい箇所をあらかじめ湿らせておいて、 濡れた手にワセリン載せて温めてから伸ばす… という感じでかなり良好な保湿性能を発揮している。 ただ成功率が必ずしも高くない…というのは言いすぎかもしれんが、100%というわけではなく、 たまに、一部が塗れてないとか、 逆に衣服に移ってしまいそうなくらい残ってしまうといった塗りむらが多い。

_ なのでベビーオイルで代行できないか試している。久しぶりに使ったベビーオイルは、 こんなにそのまんま油みたいな触感だったっけ、とちょっと驚いた。そして気付いたらその べたべたはなくなって、さらさらになっている。どういう仕組みなのかはよくわからないが、 その特性によるものなのか保湿能力はワセリンにはずいぶん劣るような気がする。 ただベビーオイルを塗ってすぐのところはステロイドなどの軟膏や、ワセリンなどが 伸びやすいので、不足しているところはワセリンで補えばいいかーという気がしている。 あるいは単に量が少ないだけなのかもしれない。休みの日に多めにすることを試してみるか…


= 今日のKotlin

_ Koansを昨晩も続けていた。しかしこれKoansという名前の通りある程度中身を 分かっている人間が理解度テスト的に使うのが本来の形なんだろう。 初心者向けの心配り、たとえばこのKoanはこのドキュメント読みながらやってね、というような コメントは入っているものの、そこに書いていないものを普通に要求されるので 対象のことをほとんど理解できていない状態で取り組むのはきつい。

_ 各所のドキュメントで見掛けるのがAndroid Jetpack なる謎の用語だ。 これか。KTXという用語も よく見掛けたが、Kotlin向けの拡張 らしい。 KotlinもAndroid Studioも、Androidも、このJetpackというやつも、 どれも変化が激しそうなので、ちびちびとやっているとなかなか身につかないだろう。 一定期間は集中したほうがよさそうだ。でもF#も触りたいんだよなー Erlangを なかなか触れない寂しさを紛らせてくれるのはF#しかないようだ。

_ ひとまず今月一杯は軸足をKotlinに置くことにしよう。 Kotlinが6、F#が3、Goが1という感じだろうか。本当はGoのウエイトをもっと増やさないと いけないんだが、馴染の浅い言語を2つ同時にやるのはけっこうしんどい。 F#は馴染めないというほどではないので大丈夫だ

_ あと、AndroidやKotlinの周辺のドキュメントは、和訳されたものでも 比較的読めるものが多いと感じる。Microsoftの和訳ドキュメントは、 きちんと翻訳されたもの以外は読めたものではないので、今のところは Microsoftより好印象に感じる。とはいえMicrosoftのドキュメントの蓄積は膨大だし、 単に私がAndroidやKotlinの露出度が高い部分しかまだ見ていないから そう思えるだけなのかもしれない。リンク辿った先が英語だった、といったケースも けっこうあるし… それでもMicrosoftの機械翻訳通しただけみたいなページよりは 好ましいと思わざるを得ない。

_ そういえばLeetCodeはKotlinには対応していたのだった。 最初期のGoいじりのときも多少は役に立ったし、Goで書いていても楽しくなかった LeetCodeも、Kotlinなら少し様子が変わるかもしれない。 F#は、もう実戦投入できているので、訓練のためにやることはないかな〜という気がする。

_ さっそくLeetCodeの1問目 (Two Sums) をやる。 ループまわすのは別に難しい話ではないのでいっぺんそれでsubmitしてみた。 Goの5倍遅く(48msec→216msec)メモリは10倍以上喰っている(3MB→43.6MB)。 それはそれとして、List comprehensions的な処理ができれば かなりコード量は短かくなるはずだよなあ… と試してみたところ、 巨大なintArrayに対するテストでタイムアウトになってしまった。

_ Erlangのときも同じような悩みを抱いたことがあるのだが、fold とか filter とかで 途中で処理を打ち切る、という制御構造が欲しい。けど適当なのが見つからないので結局 手づくりすることになる。…が、凝ったことをしようとすると結局元々のループ処理と 大差がないような気もしてくる。汎用性のある構造を作ることができればよいのだけど、 まだコーディング能力がそれに追い付いていない。

_ そうそうAndroid StudioやIntelliJ IDEAにはKotlinのREPLがあるようだ。こりゃーべんりだ


= いくらでも時間が潰せる離島の事典「シマダス」の最新版が15年ぶりに出た :: デイリーポータルZ

_ これはすごい。電子化されることはないようなので、普通に買うか…?



= 今日のF#

_ 結局やる。シーケンスで貰えたやつをSeq.fold で順番に実行してゆく… というような構造にしてみたがどうだろう。状態を引き渡しつつループするというと すぐに思いつくのがこの形式になるが… 今のところすごくすっきり書けていてよい気がする。

_ F# では複数のデータをまとめてどうにかする構造が複数あって、 それらはだいたいメンバーを持てるのでどういうときにどれを使えばいいのかね? という点で悩みを覚える。 Recordの章にあるDifferences Between Records and Classesとか、 Classの章にあるWhen to Use Classes, Unions, Records, and Structuresなんかを読んで 自分なりに理解した限りでは、基本はRecordとDiscrimination Unionを使っていって、 それでは限界があるときにStructやClassを使う…という形だろうか? 限界というのは、たとえばC#でも使いたいとか、 Polymorphicなやつをやりたいとか…

_ Recordは、作る際に持っている値たちを全部指定しないといけないみたいだ。 Goのstructみたいにゼロクリアが強制されていれば楽なんだけど… なお↑のRecordの説明を読む限りでは、default recordを1つ用意しておいて、 初期値を変えたいときは with なんとか〜 で変更する、というやりかたを推奨しているようだ。 1回は全部指定しなきゃいけないことには変わりないが、それならそれでいいか〜

_ if で MemoryStream、 else で FileStream をそれぞれ返す、なんてことをしようとすると、 if と else で返す型が違うと怒られるので Streamにアップキャストしなきゃいけないようだ。 あるいは、戻りの型をきちんとStreamと指定すればいいかな… ? と思い試してみたところ、 StreamとMemoryStream/FileStreamは型が違うと怒られる。そういうもんなのか

_ なお先日作成したウインドウの位置を保存/復帰するスクリプトは極めて便利に使っている。 席を離れる前にsaveして、戻ってきたらloadする、だけで、だいたいのウインドウは元の 位置に戻ってくれるのでとてもありがたい。もちろん出先で新しく作ったウインドウは 戻ってくれないけど、それはさすがにしょうがないだろう。 保存されていないウインドウはとりあえず動かす、というような戦略も可能だが…



= Coders at Work

_ O'Reilly Leaningで読めるので、ちびちび読んでいる。 インタビューする人もされる人も有名で有能なひとたちばかりで、一人一人の インタビューがかなり長い。質問項目がある程度統一されているので、同じ内容について 三者三様の答えがあるのが面白いし、その答えになった理由をきちんと聞き出しているので 大変に充実している。

_ ただC++を擁護する意見はほぼまったくないのが興味深いというか笑えるというか… せいぜい、Bjarne Stroustrup に配慮が必要な立ち位置の人が本人を擁護するという程度で、 あとは積極的に憎んでいるか、近付かないようにしているか、やむなく使っている、といった 態度ばかりだ。これだけ有能な人達がC++に対してそういうつきあいかたしかしない、 というのは、やはり興味深いと思う。


= トップダウンとボトムアップ

_ これについてもCoders at Workでインタビューされている人が様々な意見を述べている。 私自身は以前書いた通りボトムアップ派だ。 理由も当時書いた通りテストがしやすいというのがある。ただ、 Coders at WorkでJoeがほとんど同じような回答をしていたので、意識してか無意識かは ともかく、それに影響されている気がする。 Coders at Workを最初に読んだのは、記録に残ってないから なんとも言えんが2013年当時にはもう読んでいたと思われるし…

_ ここのところ思うのは、トップダウンだと別にプログラム言語じゃなくてもいい範囲が けっこうあるんじゃないの? ということだ。たまに、トップダウンのアプローチで プログラムを書くことがあり、その際は、おおまかな流れを記述するのは コメントに書いた日本語だったり疑似コード的なもので済ませることが多い。 そして、そういうトップダウン的な書き方をするのは、 すでに要求仕様やフローががきちんと記述されているものとかに限られるようだ。

_ ボトムアップのアプローチは他の人のコードを読むときも同様かもしれない。 何か目に見えるもの、たとえばメッセージとかを手がかりに関心がある部分を探して、 デバッガが使えるならそこで止めて、少しずつ呼び出し元に戻ってゆく…というやりかたが多い。 まず全体を把握してから…というようなアプローチはまずしない。

_ 書くときも、読むときも、ボトムアップではどうにも行き詰まることがあり、 そのときになって初めてトップダウン的なアプローチをすることになる。 やっている最中につまずいている部分をきちんと控えておいて、それらが解決することを 目指しつつ読んでゆき、最終的にはトップダウンとボトムアップが出会って全部つながる… みたいな感じだろうか。ボトムアップだと、とくに読むときはなかなか体系的な理解に 至らないので、時間を空けて再度ソースを読むよ際に同じようなことを何回もすることに なりがちかもしれない。繰り返していると少しずつ体系的な理解に至るというべきか… 一方で、トップダウンだと、その時どきの関心の範囲だけを考えると無駄な 読解が増えるけど、体系的な理解ができていればだんだんコストが下がってゆくのかもしれない。 どっちにしても苦手なのでうまくできない…ので、せめてできるのは、ボトムアップ的な アプローチで得た理解をその場限りで終わらせないような記録の残しかた・記憶のしかたを 工夫する、という程度になってしまう。

_ とりとめがないが、トップダウン的なコーディングができない理由として根本的なのは、 名前をつけるのが苦手だというのがあるようにも思う。小さなロジックであれば それにつく名前が適切かどうかはある程度判断可能だけど、「おおまかな流れ」に対して 名前をつけようとすると、なかなかむずかしく感じる。私がプログラムを書いている中で、 手が止まる瞬間というのは、慣れていない環境でのデザイン的な悩みを除けばほとんどが 「関数や変数の名前をつける」だ。


= 今日のKotlin つづき

_ さて次はUdacityのやつやろうかしら… と思ったんだが、 Self Pacedとはいえ想定期間が2ヶ月程度と言われると躊躇する。 いろいろ探してみたところ、 Udacityの講義の元になっているのは書きもののTutorialのように見える。 Kotlin Bootcamp for Programmersと、 Android Kotlin Fundamentals。 こっちをやればいいかなーという気がしてきた。

_ 書きもののTutorialであればいろいろスピードアップする余地はあるが、 反面手が止まってしまったり、手を抜いてあまり身についていなかったりすることが あるかもしれない。一方この手の学習プラットフォームなら、 動画を中心に追いかけることになるので迷子になることはまずないだろう。 一方でスピードアップしたくてもできないという問題がある。

_ ひとまず1〜2日、書きものの方をやってみて、問題なさそうならそのままさっさと 終わらせてしまおうと思う。

_ Kotlin Bootcamp for Programmers からはじめる。 ……… そうかAndroidが絡まないKotlinの開発をAndroid Studioでやることはできないのか。 そりゃそうか。IDEAを入れる。

_ Kotlinでは関数は最後の引数でとる慣例があるらしい。 たしかにこういう書きかたができるのはメリットかもしれない。が、 パイプライン演算子みたいなものは実現できないように見える。この例みたいに foldとかfilterとかがメソッドであればあまり大きな問題ではないのかもしれない

_ IDEAではmutableな変数にはアンダーラインで装飾されるようだ。これは分かりやすい

_ Lesson 4 まで終わった。openしないとoverrideできないというのはよい気がするものの、 親クラスを作っている段階でoverrideされる可能性があるかの考慮をミスすると サブクラスが不便というのが問題になる場合は問題かもしれない。自分で書いたやつや 社内のものであれば、じゃあ見直すか…と簡単にできることもある (できないこともある) が、 そうでなければきびしいだろう。とはいえそのあたりの考慮ができていないものが overrideしても安全かどうかというとそうでもない気がするし、 そもそもC#だってvirtualつけてないとoverrideできずnewするほかないという 運用になっているわけだし、だいたいinterfaceを中心にしたプログラミングであれば このあたりは自然とそうなっているわけだし、それ以前にcompositionがやりやすい 環境になっているようなので、このあたりはうっかり問題を起こすことが減ったという 好意的な解釈でよいような気がする。

_ 向こう1日半はこのあたりの取り組みができないが、このボリューム感であれば週末までには Androidの方も含めて終わりそうな気がする。そこですかさずAndroidの開発ねたが出てくれば よいのだが、もうちょっと後になるかもしれない。Kotlinの勘を鈍らせないように


2020/01/20 (Mon)

_ 5時過ぎに目が覚めてしまった。そのままフトンでじっとしていた結果、 いつも起きる時刻の20分前くらいからウトウトしはじめたようで、結果として眠い。 いい加減真剣に生活の見直しが必要そうだ。睡眠時間は決して短かくないのに、 日々しんどくなっているように思う。


= 湯たんぽ

_ 先日2.5Lの湯たんぽを買った。2.5Lはちょっとでかすぎた。 いったんフトンに入れれば半日くらい暖かいままでよいのだけど、 2.5Lのお湯を準備するのが大変。 fashyのようなフレキシブルなやつならよかったんだが、今回買ったのは ポリエチレンのやつなので、満タンにしておかないと使えない。

_ その後ダイソーで600mlの湯たんぽを発見したのでそちらを使っている。 これでも8時間くらいはそこそこ暖かいままなので悪くない。とくにフトンに入ってすぐの、 冷えきった足が温まるまでの時間がかなり短くなってありがたい。といっても30分くらい かかってしまうんだが…

_ そして何も考えずに入れっぱなしにしておくとけっこう暑くなるようで、 気付くとフトンを蹴っていることが多い。むずかしいもんだ


= 今日のF#

_ 久しぶりに時間をみつけて触る。触っていない間も本や記事などを読んで イメージトレーニングをしていたので、ひとまずキャプチャの分析の話のつづきで、 sequenceを中心にした処理に変えてみた。変えている最中にいろいろ不要なところが でてきて、それを削ってすっきりしたり、いろいろ無理のない作りになったようには思う。

_ 数日のブランクがあるので必要のないendを書きがちだった。 あと、パターンマッチの最中に長いものを書くことに躊躇を覚える。 Erlangでは何とも思わなかったので、オフサイドルールに対する 警戒心がそうさせるのかもしれない。そうでもないのかもしれない。


= 今日のKotlin

_ 今のところKotlinはAndroid以外の用途で使うつもりはない。 ただKotlin/Nativeとか面白そうな枠組みがあるので今後気が変わるかもしれない。 とはいえF#やGoのかわりになる日が来るかどうか… という感じもする。 .NETの世界にもKotlin/Native的な仕組みはあるようだし

_ Build Your First Android App in Kotlinという tutorialがあったのでそれで試してみようと思ったのだが、 Android Studio 3.6以上を要求しているようだ。私が最新版だと思って落としてきたのは 3.5.3なので、それよりも新しいバージョンを求めてくるというのはなかなか チャレンジングだ。 Stableというチャンネルにいるからだろうな… 3.6系は、RC1が出ている。 プレビュー版とそうでない版は共存できるらしいので、そっちも入れてみた。

_ DDMSはもう使わないのかな。Android Studio にはDevice File Explorerというのがあった。 どうも廃止になったらしい。 まあDalvikなんて名前が残っているようなものをいつまで使うんだという気はしていた

_ Udacityに、Android+Kotlinの無料コースがあった。 必要に応じてやってみるか…

_ 3.6RC1を入れて、↑のtutorialをひと通りやってみた。 layoutのデザイナがよくできているし、 navigationの編集がグラフィカルにできて、うけわたしするBundleについても 自動的に? ラッパーを作ってくれているようで、とても楽ちんだった。

_ IDEAはあんまり使ったことないのでキーバインドがいまひとつ慣れない。 「実行」が状況によってSHIFT+F10だったりCTRL+F10だったりするのはなんとかならんのかな。 エディタのフォントサイズをでかくすると、 ConsoleとかLogcatもそれに合わせてでかくなってしまうようで、これもこれで困っている。 今のところはそれくらいかな?

_ あとはやっぱりメソッドの先頭が小文字というのが目に慣れない感じでつらい。 つらいだけでなく打ち間違えることも多く、その場合はヒントとして出てこないようだ。 Visual Studioだとかなり保守的に候補を出してきてくれるので、大文字小文字を 間違ったくらいではどうということはないのだが…

_ いずれにしてもtutorialをひと通り終えることができてよかった。 私は、ちょうどFragmentというのが導入されつつある頃に、Fragmentを使わないで プログラムを書いていた方なので、今になって再びやることになるとは… という不思議な 感覚がある。当時はなんかとっちらかっているような印象を抱いてしまっていた。 理解する意思が乏しかっただけなのかもしれんが、単にややこしくなっているだけ という印象が勝ってしまい、タブレットも持っていなかったしあまり積極的にやりたい 感じではなかった。もっと言うと、いずれひっこめるんじゃないかというあまり根拠のない 予想をしていたりも。今目の前にあるFragmentが当時とどのくらい同じでどのくらい違うのかは、 当時のことを理解していない私には分からんが…

_ Android中心で取り組んでゆくことになるので、その際にKotlinのスキル不足が 足を引っ張らないように、空いた時間でKoansとかをやっておこうかなと思う。





Zinnia (zinnia@risky-safety.org)
Back