msfukuiの日記

おおまさのみみはそらのみみ。

Vim Terminal mode 周りの設定の備忘録

もうちょっとちゃんと Vim を使っていきたい欲が高まっているので、少しずつ設定を入れたり本を読んだり Youtube を眺めたりしているのですが、 Terminal 周りの設定で四苦八苦したので、備忘録を兼ねて。

やりたいこと

これ。

qiita.com

Vim のウインドウ分割と Terminal 機能を気軽に使える状態にしたいなって思っていて、記事を拝見しごもっともだなって思って、設定に足を踏み入れたのですが、いろいろと地雷を踏みました。

やったこと

今のところこのあたりの設定に落ち着いています。L343 - L352 あたりと L377 以降になります。

github.com

前提

私有の Intel Macbook Pro と会社から支給されている M2 Macbook Pro の Terminal.app で Terminal 版の Vim を利用する想定です。

外付けの英字キーボードを使っています。

Windows のことは(環境はあるのですが)一旦脇に置く。

GUI 版の Vim は今まで使ったことがなくて、今のところ今後も使う予定がありません。

踏んだ地雷と対処

最初に Claude3 に対処方法を聞いてみたのですが、聞き方が悪いのか、最後まで意味のある対応内容を回答してくれることはありませんでした。

正反対のことを回答することが多く、AI はこの用途には向いていなさそうなことがよくわかりました。

Terminal.app の設定

プロファイル > キーボード の「メタキーとして Option キーを使用」にチェックを入れる

Option + いろんなキーを押すと、制御文字ではなくていろんなギリシャ文字っぽいものが入力できて、なんだーって思ったのですが、比較的たくさんの情報があって気がつきました。

IntelliJ IDEA の Terminal でも同じ設定があるみたいであとで試してみる。

https://youtrack.jetbrains.com/issue/IDEA-165184

Vim の Meta キーのマッピング設定

<A-..> の設定を入れてみたのですが、動作せず、理由を探していたところで、以下の比較的古い記事を拝見しました。

thinca.hatenablog.com

Option キーは ESC とマップする必要があるみたいで、アレンジして nmap <ESC>t <A-t> などと設定を入れてみると動作しました!

この情報、なかなか見つからなくて、時間がかかりました。

Vim Terminal mode 周りの設定

最初の記事のマッピング設定をアレンジして入れてみました。

当初 tmap の設定が漏れていることに気が付かず、二日ほど時間を無駄にしました。。

慣れるとサクサク操作できて快適。

" Alt key を normal mode で有効にする
nmap <ESC>w <A-w>
nmap <ESC>t <A-t>
nmap <ESC>s <A-s>
nmap <ESC>v <A-v>
nmap <ESC>j <A-j>
nmap <ESC>k <A-k>
nmap <ESC>o <A-o>
nmap <ESC>; <A-;>
nmap <ESC>/ <A-/>

" Alt key を Terminal 内の Vim でも有効にする
tmap <ESC>w <A-w>
tmap <ESC>t <A-t>
tmap <ESC>s <A-s>
tmap <ESC>v <A-v>
tmap <ESC>j <A-j>
tmap <ESC>k <A-k>
tmap <ESC>o <A-o>
tmap <ESC>; <A-;>
tmap <ESC>/ <A-/>

" ターミナルモードのキーマップ変更 (C-w をシェルで有効に)
set termwinkey=<A-w>
" ターミナルジョブモードで垂直分割した右ウインドウを開く
noremap <A-t> :vs<CR><C-w>l:term ++curwin<CR>
" ターミナルジョブモードからノーマルモードに切り替える
tnoremap <A-t> <C-\><C-n><CR>
" 水平分割した上ウィンドウを開く
noremap <A-s> :sp<CR>
" 垂直分割した右ウィンドウを開く
noremap <A-v> :vs<CR>
" ウインドウ間移動
noremap  <A-j> <C-w>w
tnoremap <A-j> <C-\><C-n><C-w>w
" ウィンドウ間を逆に移動
noremap  <A-k> <C-w>W
tnoremap <A-k> <C-\><C-n><C-w>W
" 他のウィンドウを閉じて最大化する
noremap  <A-o> <C-w>o
tnoremap <A-o> <C-\><C-n><C-w>o
" コマンドラインモードに移行
noremap  <A-;> :
tnoremap <A-;> <C-\><C-n><C-w>:
noremap  <A-/> /
tnoremap <A-/> <C-\><C-n>/
" ウインドウ操作時にターミナルノーマルモードの場合は
" 自動でジョブモードに切り替える
autocmd WinEnter * if &buftype ==# 'terminal' | normal i | endif

おしいところ

tmap で ESC + .. をキー割り当てしている関係上避けられないのですが、 Terminal job mode で開いているターミナルで、コマンドラインの vi mode のノーマルモードへの切り替えに ESC キーの入力待ちが発生します。

根本的に Option キーを Karabiner-Elements で別キーにマッピングすることも考えたのですが、Terminal.app 以外の操作に悪影響がありそうだったので、ここは一旦あきらめています。

その他

プロンプト表示をシンプルな内容に見直したり、 fzf-tab を入れたり、vimwiki を使うようになったり、少しずつタイピング練習したり、新しいキーボードを買いすぎて怒られたりしています。

今しばらくは VimIntelliJ IDEA の両方でコードを書くことになりそうです。使いこなせるようになる日は来るんだろうか。。頑張ります。

「Clean Agile」「エクストリームプログラミング」を読みました

新しい職場での参考図書の一つとして「Clean Agile」を紹介いただいたので購入して読んでみました。

https://www.tumblr.com/asciidwango/631315320701960192/clean-agile
asciidwango.jp

買ってみて「ボブおじさん」の本を読むのが初めてであることに気がつきました。「Clean Code」も「Clean Coder」も「Clean Architecture」も未読。「アジャイルソフトウェア開発の奥義」も未だ積まれたままでした。読みます。。

薄いのと技術的な詳細が書かれた本ではないので、待ち時間などに比較的サクサクと読み進めることができました。副題の「基本に立ち戻れ」にある通り アジャイルソフトウェア開発宣言 の作成の経緯から始まって、どうしてアジャイルを選択するのか、アジャイルではないことは何か、が平易な文章で書かれていて、特にアジャイルな開発が比較的当たり前になっている現在においてその論旨の必要性を含めて納得感を持って読むことができました。プロセスも大事だけど技術スキルを磨いてプロの仕事をしよう、というメッセージが印象に残りました。アジャイルコーチが、ビジネススキルも技術スキルもないからと文中で二度ほどボコボコにされているのがちょっと気の毒な感じでした。

この本を読む少し前にたまたま XP の白本を読み直していました。段ボール箱をひっくり返しましたが初版の本が見つからず..結局第2版を買いました。

www.ohmsha.co.jp

最初に読んだ時のことはあんまり覚えていなくて、テストファーストペアプログラミングなどの技術的プラクティスだけが印象に残っています。たぶん00年代前半だったと思うのですが、恐らく当時の自分には XP の登場の背景や、当時の開発者の抱えている閉塞感や怒り、みたいなのが見えていなかったのだと思います。改めて読んでみて、まずは著者の怒りと情熱がストレートに伝わってきて、こんなに熱い本だったんだな、ということにまずは実感を持って驚きました。みなさんの感想にもたくさん書かれていたはずなのに。

なお書かれている中だとP.83-84にある「開発のプルモデル」の意味するところ今も(特に図が)理解できていなくてピンときていない。リソース効率とフロー効率の話? とも思ったがどうも違うみたいな気もする。もうちょっと別の方面からも調べてみたいなって思いました。

両方の本とも、なんでソフトウェア開発をこんなやり方でやるの? みたいなことが原点としてシンプルに言語化されていて、振り返りにもなり、楽しく読むことができました。

ちなみに XP 本を探していた際にダンボール箱からは他に懐かしい書籍がいくつか出てきまして、見つけた以下も読み返していました。

www.amazon.co.jp

だいぶ読みにくい..のと、 XP 本以上に内容を全く覚えていない。「ソースコードは設計なのか?」という章で Ruby のまつもとさん(Matz)の言葉が引用されていて、おおってなりました。

本を読んでいるとソフトウェア開発なんもわかってないなって改めて思いまして、今後はもうちょっと読むペースを上げていきたいです。

国会図書館に行ってみました

タイトルは、前回に引き続き 2355 のおやすみソング「小石川植物園に行ってみました」へのオマージュです。

時間がたくさんあるので、隙間を見つけてはお出かけしているのですが、先日ついに憧れの地に踏み入れました。

とても古い記事になるのですが、

msfukui.hatenablog.com

調べる予定にしていた「構造的プログラム設計の原理」の内容について、4年越しに実際に調べてきました。

その話は後で書くとして、その後は NORTH CAFE で美味しいカツカレーを食べて幸せでした。*1

投稿者: @msfukui
Threadsで見る

3時間くらいの滞在でしたが、能動的に調べ物をしたい場合は、周りの雰囲気も含めて最高な場所でした。また行きたい!

肝心の調べ物について

該当の箇所は、序文と第12章の両方に見られていて、その前後の文章を含めてとても興味深いのですが、一旦、第12章の記載を引用してみます。

最適化(optimization)という言葉は間違って使われている. ラテン語からの意味では(プログラムを)最適化するということはできるだけ良くすることである. しかし, われわれが最適化されたプログラムを使うのは, できるだけ小さく, 又は速くすることである. 小さくしたり速くしたり, またはできるなら両者を行うときには色々な意味で悪くしがちである. 理解が困難になり, 保守がむずかしく, そして間違い易くなることであろう.

簡単に言えば, 最適化にはお金がかかる. 我々の最適化についての基本的態度を2つの規則で定義しておこう.

  • 規則1: 最適化を行ってはいけない.
  • 規則2: まだ最適化を行ってはいけない.

最初の原則は, われわれが最適化する前にそうすることの積極的ではっきりした根拠を必要とすること, およびしばしば正当化する根拠が存在しないことを述べている. もしその結果が使用されない計算機の CPU 時間を大きくするだけならプログラムを速くすることは意味がない. もしメモリの標準サイズにより分類された部分で使われない場所の数を多くするだけなら, プログラムを小さくすることは意味がない. もしプログラム・エラーのためにできたプログラムを 5% だけ再実行させることになりそうなら, 実行時間で 5% 減らしても意味がない.

2番目の規則は, 最終的には最適化するつもりでいても, 最適化されてない設計でいつでも始めなければならないことを述べている. 最適化されていない設計のみが十分な理解に必要な明白さと単純さを持ちうるものである. もし論理的エラーを導くことなく最適化するつもりなら, われわれは自分のプログラムを十分理解しなければならない. プログラム保守にたずさわってきた者はどうみても単純でないプログラムを変えるのがどれほど危険かよく知っている. 明らかに無害な変更でも驚くべき, かつ悲惨な影響を持つものである.

この後の記述では、計算機パラメータのチューニングとアルゴリズムの変更による最適化はその対象外であることと、「カントール有理数の数え上げ」を題材にして、その最適化をどの様に行うか、またその際に発生する特定のデータ構造や変数、プログラム順序に対する依存性について、COBOL でのプログラムを例に、ところどころでちくちくと刺しながら書かれています。本当に最適化というものが嫌なんだな、、というのが伝わってきてとてもいいなって思います。

私は COBOL についても他と同様さっぱりなので、コードの中身は雰囲気でしかわからなかったですが、上記の引用文だけでも、それぞれの規則(ルール)とその理由が明確に述べられていて、当時の時代背景を差し引いたとしてもとても面白く読むことができました。

あと、序文ではもう少し違う観点も含んで、最適化についての記載が書かれています。

最適化に関しては, 次の2つの規則に従っている.

  • 規則 1 最適化を行うな.
  • 規則 2 (専門家だけのために) まだ, 最適化を行うな -- すなわち, 完全に簡明で, 最適化されていない解決を得ないうちは行わない.

..(中略)..しかし, 2つのポイントは常に憶えておくべきである. 第一は, 最適化はシステムの信頼性を下げ保守を困難にする. それ故作ったり実行させたりするのがより高価になる. 第二には, 最適化が構造をあいまいにするので, すでに部分的に最適化されたシステムの効率を改良するのがむずかしい.

かなり薄い感想ですが、個人的にまとめるとこんな感じかと思いました。

  • 最適化にはお金(と労力)がかかる

  • 実益のない最適化には意味がない

  • 最適化は保守性の低下を招く

  • 早すぎる最適化は部分最適を招き、その後の全体最適の大きな妨げになる

その他序文では、システム設計者とプログラマを分けるのはばかげている、などの何故か今に繋がる話であったり、日本語版に際しての M.A.Jackson さんから訳者の鳥居さん (https://ja.wikipedia.org/wiki/%E9%B3%A5%E5%B1%85%E5%AE%8F%E6%AC%A1) に書かれている賛辞も読めて、とても楽しい読書体験でした。(全部は読めていませんが。。)

調べるものをもりもり見つけてぜひまた行きたい!

プログラミングも頑張ります。。

*1:今のところ食べたもの系は Threads に放り込むことにしています。

JJUG CCC 2023 Fall に行ってみました

Java 関連にはこれまであまり縁がなかったのですが、今後 Kotlin + SpringBoot という構成のシステムに携わる可能性がありそうで、雰囲気を知りたくて、参加させていただきました。

ccc2023fall.java-users.jp

ほぼ初参加だったのですが、現地開催のみ、ということで、とてもとても賑わっていました。先日の PHP カンファレンス 2023 もそうだったのですが、本格的にカンファレンスが戻ってきた、という感じで、とてもわくわくできて楽しかったです。

以下、参加したセッションについての簡単な感想です。*1*2

https://sessionize.com/api/v2/2gdy2o95/view/GridSmart

Exceptionハンドリングの基本と新しい手法について (河野裕隆さん)

speakerdeck.com

Java の例外の分類と基本的な使い方をコンパクトに説明いただいた後での、パターンマッチと sealed によるすっきりした見通しのよいコードがとても印象的でした。

これまであまり深く考えたことがなかったので、例外処理について深掘りして、自身の知識をアップデートしたくなりました。

ブランチ運用とデプロイフローを見直してリリースを楽にする (ユカイさん)

speakerdeck.com

担当されているプロダクトのブランチ運用とデプロイフローの課題とその改善内容を、わかりやすくまとめていただいていました。

たくさんある課題と改善の中で、改善の際に「失われたもの」を一つ一つ上げられているところがとても印象的でした。
フィーチャーフラグの実装により、切り戻しが格段に早く、楽になる、というコメントが、とても納得感があって良かったです。
DB migration を伴うリリースはどう自動化しているのか、フィーチャーフラグの実装により分岐が増えてコードの見通しが悪くならないか? という点は、ぜひ意見お聞きしてみたいと思いました。

レガシーなWebサービスから世界標準への挑戦 (Rina Hashimoto さん)

GMOペイメントゲートウェイでの OpenAPI 実装の提供について。「王道」という感じでした。

この規模の歴史もあるシステムだと、いろいろあって大変で、でもその中でもきちんと今のWeb標準に則った対応をされていて、この「普通に開発する」の大変さをあまり感じさせないところがとても良かったです。
途中の説明にあった「決済系なので GET は使わない」は頷いている人が多かった印象ですが、RESTful に染まっている私にはちょっとピンと来なかったです。あと「リダイレクトとコールバックだけは cookie が消えるので GET で実装」は、もう少し詳しくお聞きしてみたいと思いました。(ドメインの異なるサイト間での情報の受け渡しになるから、、ということだと納得ですがそんな単純な話ではなさそうに感じました。)

JDK 21 へようこそ (dbuck さん)

この 9 月に出た Java21 について、いくつか代表的な新しい機能についての解説。

タイトルや概要を認識していたものはいくつかありましたが、詳しい内容は全然把握できていなかったので、とても嬉しいセッションでした。内容もわかりやすくてとても良かったです。なにより解説が日本語なことがとても助かりました。。すごい。

このあたりで持って行った PC のバッテリー容量がみるみる減って切れてしまい、なんで? ってなりました。寒かったからかな。。

あと一番前の机のある席が結構空いていて、座っている人があまりいなかったのがもったいない感じでした。遠慮せずに特等席でお聞きできてとても良かったです。

持続可能なデータアーキテクチャを実現したリアーキテクティング (Katsuyoshi Urano さん)

www.docswell.com

指数関数的に増大するデータをバックエンドに持つシステムを、リアーキテクチャにより改善した話。

DynamoDB の制限の話がとても具体的な痛みで良かったのですが、どなたかも書かれていましたが、ここは JAWS-UG かと思ってしまいました。面白かったです。タイムアップになってしまったのですが、アプリケーションのリアーキテクチャの話もお聞きしたかったです。資料が後ほど公開されるみたいなので、拝見してみたいと思います。

この辺りで会議室の寒さに耐えられずに一旦外に出ました。

動くコードを書こう (kis さん)

speakerdeck.com

「きしだのはてな」で有名なきしださんのセッション。とてもこなれている感じで考えさせられる楽しいセッションでした。
内容は、先日休刊した Web + DB Press で書かれていた記事から、ということだったのですが、未読なのですが内容には既視感があり、過去にきしださんが書かれていた以下の記事を思い出しながらお聞きしていました。

nowokay.hatenablog.com

この件は昔からずっと気になっていて、先日以下でこの記事の内容をダメコードですが簡単に実装してみたりしていました。

github.com

自身のプログラムを書くことののわかりにくさのポイントとか、人に教えるときの考え方とか、AIとの棲み分けとか、コードを書く話でありながら、コードを書くこと以外で考えることが多い話題だと思いました。身近でお聞きできてとても良かったです。

アンカンファレンス (谷本さん、他)

アンカンファレンスのテーマ募集のホワイトボードがあったので、Java に詳しくない身から「Java 言語の使いどころと他の言語とのすみ分け」のチケットを貼ってみたところ、取り上げていただいていろいろな観点からみなさんのお話を聞くことができました。メンバーの持っているスキルによるところが大きいということでしたが、他にも、型付き言語であることの利点、問題があった場合の原因追及ができるツールの豊富さ、10年選手としての後方互換性の高さ、書ける・運用できる人の多さ(特にベテラン勢)など、主にエンタープライズ領域で第一線を張っている言語ならではの特徴を、著名な方々から実感を持って聞くことができて、とても参考になりました。

PHPRuby などで作られたシステムを、生き残って大きくなるにつれて他の言語で作り直す/一部機能を分離する、という話はよく聞きますが、知識としてその言語やエコシステム、人材の特徴などは知っていても、実感を伴わないままで選択はしたくないな、と改めて思いました。

あと、アンカンファレンスの内容については、書けない話が多いことがよくわかりました。ほぼ会話を聞いているだけでしたが、楽しかったです!

ラムダ式をHowではなくWhyで理解しよう! (青木 澄怜さん)

speakerdeck.com

ラムダ式を理由から理解しよう、というお話。

傘のメタファーでのWhyの大事さの説明など、納得感あってとても良かったです。初心者の方に説明する際に使ってみたいと思いました。
何より一年目で登壇してお話しされているその勇気に敬意を評したいです。登壇の経緯を質問された際の、受け取った恩返しとチャレンジの話は、とてもグッときました。それを聞いた会場の、おおっ、という感じもとても良かったです。みんないい人。

スポンサーブース

Oracle さんのノベルティが欲しいなって思ったのですが、アンケートに「会社名」を書く欄があって、現在主夫なので断念しました。勇気を出して聞いてみれば良かったです。😄

GMO さんの Java クイズは、プログラムはともかく、Effective Java を読んでいないので回答を断念しました。やっぱり部外者には難しい。。

まとめ

JJUG とても良いなって思いました。今回は多くのものをいただいた形なので、次回参加するときまでに何か還元できることにチャレンジしたいと思いました。

登壇者のみなさま、スタッフのみなさま、スポンサーの企業さま、本当にお疲れ様でした & ありがとうございました。

*1:セッション一覧にはセッションごとのパーマネントリンクが設定されていないみたいで、API実装がかっこよさそうなのに、直接のリンク貼れないのがちょっと残念。。

*2:各セッションの資料が公開されたら、できるだけ拾って追記したいと思います。

Flutter/Dartに入門してみる 環境準備編(1)

7月からしばらくお休みをいただいたので、宣言的 UI によるスマートフォンアプリの開発を理解したいと思い、Flutter に入門してみることにしました。

アプリ開発iOS, Android とも過去に少しだけ入門的なものを少しだけ触ったことがあるだけで、無に等しい状態なので、道のりは長いですが楽しみです。

まずは開発環境のセットアップからメモしてみます。

(2023/7/9追記)

Java のバージョンを当初 defaut-java で入る 11 にしていたのですが、後ほど入れる Windows 側とバージョンを合わせたいため LTS の 17 に変更しました。

方針

作るものは最小限にしたいので、ターゲットは当面 Android のみ、半年ほど前に買ったスマートフォンの Pixel6a 上で動くことをターゲットにします。

手元にある Windows10 + WSL2 (Ubuntu22.04.2) 上で開発環境を作ります。

コードは WSL2 の Linux 上の Vim で Terminal 経由で書き、Windows 上のエミュレーターと実機で確認できるようにします。

標準的な構成ではないので少し遠回りになるのですが、比較的慣れている環境でコードを書いてみたいのと、統合開発環境のメニューなどであまり隠蔽されていない、素の状態で進めた方が本質の理解が進むと思ったからです。

事前準備

Microsoft Store から WSL2 に Ubuntu 22.04 を入れます。

OS 入れた後はあらかじめ用意している dotfiles で適度に実施、Windows Terminal から JavaVim が一旦使える状態にします。

Java は以下で openjdk-17 を入れておきます。

$ sudo apt update && sudo apt install openjdk-17-jdk -y
...
$ java --version
openjdk 17.0.7 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Ubuntu-0ubuntu122.04.2)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Ubuntu-0ubuntu122.04.2, mixed mode, sharing)

ベースの準備が整ったら Terminal から一旦抜けて cmdコマンドプロンプトを開いて、念のため作った環境のバックアップを取っておきます。

> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Stopped         2
  Ubuntu-22.04    Running         2
> wsl -t Ubuntu-22.04
> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Stopped         2
  Ubuntu-22.04    Stopped         2
> wsl --export Ubuntu-22.04 C:\tmp\Ubuntu-22.04.tar

手元の環境だとファイルサイズは 5GB 程度になりました。

WSL2 上のセットアップ

基本的には以下の公式の手順に従って進める形になります。

docs.flutter.dev

Flutter SDK のインストール

あまり覚えるものを増やしたくないので snap を使ったインストールは行わず ${HOME}/dev 配下にマニュアルで入れます。

Android Studio のインストール

Android Studio は全部は使わないので、コマンドラインツールだけを入れます。

developer.android.com

ここの下の方にある「Command line tools only」の Linux のリンクをクリックして、規約に同意した上で URL を入手して、Linux 上から curl でダウンロードします。

インストール先など含めてこんな感じです。ここでは platform-tools だけ入れておきます。

$ mkdir -p ~/Android/SDK/cmdline-tools
$ curl https://dl.google.com/android/repository/commandlinetools-linux-xxxxxxxx_latest.zip -o latest.zip
$ unzip latest.zip
$ mv cmdline-tools ~/Android/SDK/cmdline-tools/latest
$ rm -rf latest.zip
$ export ANDROID_HOME=$HOME/Android/SDK
$ export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
$ sdkmanager --list
[=======================================] 100% Computing updates...
$ sdkmanager --update
[===                                    ] 10% Computing updates...
Updating:
...
$ sdkmanager --install "platform-tools"
...

入れた後の flutter doctor では Android SDK を flutter からは認識しなかったので、公式の手順にある以下を実行すると認識してもらえました。

$ flutter config --android-studio-dir=$HOME/Android/SDK

インストール後の確認

最終的にはこんな感じになりました。

$ flutter doctor -v
[✓] Flutter (Channel stable, 3.10.5, on Ubuntu 22.04.2 LTS 5.15.90.1-microsoft-standard-WSL2, locale C.UTF-8)
    • Flutter version 3.10.5 on channel stable at /home/msfukui/dev/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 796c8ef792 (3 weeks ago), 2023-06-13 15:51:02 -0700
    • Engine revision 45f6e00911
    • Dart version 3.0.5
    • DevTools version 2.23.1

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/msfukui/Android/SDK
    • Platform android-33, build-tools 30.0.3
    • ANDROID_HOME = /home/msfukui/Android/SDK
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.19+7-post-Ubuntu-0ubuntu122.04.1)
    • All Android licenses accepted.

[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✗] Linux toolchain - develop for Linux desktop
    ✗ clang++ is required for Linux development.
      It is likely available from your distribution (e.g.: apt install clang), or can be downloaded from https://releases.llvm.org/
    ✗ CMake is required for Linux development.
      It is likely available from your distribution (e.g.: apt install cmake), or can be downloaded from
      https://cmake.org/download/
    ✗ ninja is required for Linux development.
      It is likely available from your distribution (e.g.: apt install ninja-build), or can be downloaded from
      https://github.com/ninja-build/ninja/releases
    • pkg-config version 0.29.2
    ✗ GTK 3.0 development libraries are required for Linux development.
      They are likely available from your distribution (e.g.: apt install libgtk-3-dev)

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup for detailed instructions).

[✓] Connected device (1 available)
    • Linux (desktop) • linux • linux-x64 • Ubuntu 22.04.2 LTS 5.15.90.1-microsoft-standard-WSL2

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 3 categories.

実機を使った動作確認

ここまでで一旦、サンプルのプロジェクトを作成して、実機にワイヤレスで接続して動作確認を行ってみます。

実機への接続準備

以下の Android Studio のマニュアルをもとに実機の「開発者オプション」を有効にします。

一度有効にすると二度目は実施しなくてもよいみたいです。

developer.android.com

続いて以下のページをもとにワイヤレスで接続するのですが、ここちょっとわかりにくいです。。

developer.android.com

こんな流れになります。

  • 「システム」の「開発者向けオプション」を選択して「ワイヤレスデバッグ」をタップして有効にします。

  • 「ペア設定コードによるデバイスのペア設定」をタップして IP, ポート番号, ペア設定コードを表示します。

  • Terminal 側で adb でペアリングを実施します。

$ adb pair 192.168.10.114:36059
Enter pairing code: ******
Successfully paired to 192.168.10.114:36059 [guid=adb-2B031JEGR13357-xR5Wml]
  • 実機に表示されている IP, ポート番号(これは先ほど入力したポート番号とは別のポートです)で adb connect します。
$ adb connect 192.168.10.114:39067
connected to 192.168.10.114:39067
  • 接続出来たら flutter から認識できているか確認します。実機の情報が表示されたらOKです。
$ flutter devices
2 connected devices:

Pixel 6a (mobile) • 192.168.10.114:39067 • android-arm64 • Android 13 (API 33)
Linux (desktop)   • linux                • linux-x64     • Ubuntu 22.04.2 LTS 5.15.90.1-microsoft-standard-WSL2

サンプルのプロジェクト作成と実行

次に、適当なディレクトリで flutter create でプロジェクトを作成します。ここでは myapp プロジェクトを作っています。

$ flutter create myapp
Creating project myapp...
Resolving dependencies in myapp... (1.3s)
Got dependencies in myapp.
Wrote 129 files.

All done!
You can find general documentation for Flutter at: https://docs.flutter.dev/
Detailed API documentation is available at: https://api.flutter.dev/
If you prefer video documentation, consider: https://www.youtube.com/c/flutterdev

In order to run your application, type:

  $ cd myapp
  $ flutter run

Your application code is in myapp/lib/main.dart.

移動してとりあえずアプリを実機で実行してみます。 フォアグラウンドで動作するのでプロンプトが戻ってこなくなる点には注意です。 (実行後に 'd' で動作させたままデタッチできますが。。)

$ cd myapp
$ flutter run -d 1
Launching lib/main.dart on Pixel 6a in debug mode...
Running Gradle task 'assembleDebug'...                             50.0s
✓  Built build/app/outputs/flutter-apk/app-debug.apk.
Installing build/app/outputs/flutter-apk/app-debug.apk...          24.1s
Syncing files to device Pixel 6a...                                 81ms

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h List all available interactive commands.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).

A Dart VM Service on Pixel 6a is available at: http://127.0.0.1:44739/********=/
The Flutter DevTools debugger and profiler on Pixel 6a is available at:
http://127.0.0.1:9100?uri=http://127.0.0.1:44739/********=/

実機にデモアプリが表示されたらOKです。

'+' ボタンを押すと真ん中中央の数字がカウントアップされるデモアプリになっています。

動いてよかった。。

切断する際は、 'q' で終えるか 'd' でデタッチした上で、 adb disconnect します。

$ adb disconnect
disconnected everything

実機の「ワイヤレスデバッグの使用」をオフにするのも忘れずに実施しておきます。


次回は Windows のセットアップとエミュレーターとの接続、 Vim の設定回りについて書きたいと思います。

参考情報

セットアップにあたって参照した記事になります。とても参考になりました。ありがとうございます。

qiita.com

blog.cosnomi.com

このご飯の充実ぶりを見よ!

東京ではコロナの感染者の方が増えてきていて、職場のあるビルでも、もういつ感染者が出てもおかしくない感じになっています。

感染者が出ると、職場のあるビルは全館閉鎖となり一週間以上立ち入り禁止になるみたいですが、そうなると運用チームとしてはリモートのみで保守することになり、代替手段は準備しているとはいえ、普段のパフォーマンスは出せない、という状況でなかなか厳しい。

仕事変わってからの環境はこの三ヶ月何かと厳しいですが、できる限りの準備をし、できることを考えてやり続けるしかない、という気持ちです。

ということで先週のご飯いってみよう!

f:id:msfukui:20200719184758j:plain
駅前の新しいビルに入っているレストラン街の坦々ワンタン麺。エビワンタンも追加で頼んで幸せな気持ちに。これはしばらくローテーション入りしそう。

月曜のお昼は先週に引き続き穴子天丼だったので、夜はラーメンな気持ちで新しく開拓してみた。これまで意識してなかったけど、食べるところ本当にたくさんある。

f:id:msfukui:20200719185216j:plain
水曜日のお昼の肉汁うどん。ゴリラの有名そうなお店でしたが、ボリュームすごくてお昼からお腹いっぱい。うどんはともかく肉汁がゆず入りだしで、お肉、天かすも入っていて、人気なのも納得でした。たまに思い出してまた食べたくなりそう。

f:id:msfukui:20200719185553j:plain
水曜の夜は雨だったので、駅前で何度か入ったことのある豚骨ラーメン屋さんに。豚バラチャーシュー麺、毎度豚バラがちょっとしつこいのに頼んでしまう。替え玉をお願いしました。

f:id:msfukui:20200719185755j:plain
同じお店のもつ味噌串。味は想像通りでしっかりしてて、本当はお酒に合うんだろうな。

f:id:msfukui:20200719185916j:plain
同じお店のとり天。衣がさくさくしててほんのり甘くて、お肉も柔らかい。こちらもお酒のおつまみなんだろうなー。ゆっくり味わっていただきました。

f:id:msfukui:20200717123018j:plain
職場ほど近い「あみ熊」さんの穴子天丼。有名なお店みたいで、お店の中に有名人の色紙があったり、天ぷらしっかり上げてる感じの雰囲気が漂ってた。1,300円とちょっと高めだったけどさすが美味しい!お昼から奮発してしまった。

f:id:msfukui:20200719190402j:plain
夜はお仕事が一応なんとか閉まったので、浜松町まで足を伸ばして、前から気になっていた交差点沿いのカレー坦々麺のお店に。パーコーカレー坦々麺、(いい意味で)もう見たままの想像通りの味で幸せだった。あまり辛すぎないのもよかった。

f:id:msfukui:20200719190650j:plain
同じお店の味玉ごはん。味玉もご飯にかかっている出汁もほんのり甘くて、麺を食べる際のいいアクセントになった。すごい。

同じ会社のグループ内の人とのオンラインでの会話にも少しずつ慣れてきて、雑談roomなるチャットルームで、お昼ごはんどこ行ってます? って投げかけてみたら、思いの外会話が伸びて嬉しかったです。お店情報も聞けたのでご飯もっと充実させたい!

リングフィット報告も書きたいけれど、実施がまだ一回っきりなので、落ち着いたら書ける様に頑張る。。

会社のグループ内で Git の説明会をするなどしました。

今週の出勤日は月・水・金で、徐々に頻度が上がっているのですが、東京の今の状況を見ていると仕事の一山が超える再来週以降はまた出勤日が減っていきそうな感じ。

職場の雰囲気にようやく少し慣れ、お昼休みに少し勤務先から遠出する心の余裕が出てきたので、少し違うものを食べてみることにしました。

f:id:msfukui:20200711180907j:plain
上天丼。お昼休みに贅沢だなあ。。やっぱりアクセントの野菜天がすごくよかった。

f:id:msfukui:20200711181036j:plain
同じお店の穴子天丼。個人的な好みは上天丼よりこちらの方が上だった。お味噌汁もしっかりしてておいしい。

書き忘れていて先々週の木曜日ですが、自分もちゃんとわかっているとは言い難いのだけど、会社の同じグループ内のみなさんに Git の説明をする場を作って話してみました。

msfukui.github.io

名前を聞いたことがあるくらい、研修で少し触ったくらい、、ということだったので、インフラ運用や監視の運用管理という今の仕事の文脈を踏まえた上で、1時間ほどで、簡単な説明と最初の方のセットアップをその場でハンズオンっぽく実施してもらった。

感想をお聞きしてみると、思ったよりも楽しんでもらえたみたいだったので一安心。ただ、時間配分はもうちょっと考えた方がよかった。その場で試しながら実施すると、最低限の理解には少なくともあと2回は必要かなという感触。オンラインだと画面共有を切り替えると状況をすぐ見られるので、指摘もしやすいし、少人数だと対面での実施よりもスムーズだと思った。

ちゃんと自学自習するなら、いまだと公式マニュアルとか Web のコンテンツとか、Progate とかドットインストールとか、素晴らしい資料がいっぱいそろっているけれど、説明会の目的はそれだけじゃないから、題材を変えながら少しずつこつこつと続けられるといいなって思ってる。

仕事の方は、周りの人には他人事のように一山超えてからが大変だよーって散々脅されてて、今の状況見てると確かに、、という気持ちでいっぱい。当たり前だけど、運用ってS-inしてからが本番で、ずっと続くんだよね。知らないことだらけで怖いけど何が起こるか楽しみでもある。死なない程度に死んで覚える感じで。