Pixel6 Proに機種変した

Pixel4からお引越し。昨年の春前に買ったから約1年半ぶりの機種変更。

使い勝手

使い始めて一週間くらいたったので感想書いておく。

  • 指紋認証が良い。遅いと評判だけど、Pixel4が顔認証のみで外出時ほぼ機能していなかったのであるだけで助かる
  • 大きくて重い。けど慣れた。たまにPixel4触ると小さく感じる。
  • カメラ最高。2世代分の差を感じる。画質がよくなったというよりも、もっと細かい部分の表現力が上がったように見える。粗さみたいなのはそんなに違いを感じないので不思議。
  • カメラ画面長押しでLensが起動するの便利。チップが関係しているかは知らん。
  • フロントカメラは全く気にならなかった。多分画面が大きいから?
  • Pixel4についてたActive Edgeがあってほしかった。電源ボタンでアシスタント呼べるけど、物理ボタンを探さなくて良いのが助かっていた。
  • 90Hzから120Hzへの変化は正直まだ実感できていない。なんとなくきれいになってる気がするのはそういうことなんだろうか?

ちょっと気になったところ

  • 被写界深度が短い気がする。人物や風景撮影するときはボケがきれいに映るけど、年末調整の書類を撮影しようとしたら、中央以外が若干ボケて見づらかった。アプデを期待している
  • 最初のセットアップが失敗したのか、Felicaが使えない期間があった。色々調整したけど改善しなくて、初期化して移行キット使わずセットアップしたら使えるようになった。
  • 良い感じの保護フィルムを見つけられてない。ガラスは指紋認証の関係でNGで、買ってみたTPU素材のものはケースの干渉で剥がれてしまった。まだフィルム無しで使ってるので探し中

Android12関連

  • MaterialYouのエフェクトがちょっと過剰かなと思うことがある。これも慣れる?
  • フォーカスモードは便利かも。仕事でスマホ使うから、誘惑を断ち切れるのは助かる。
  • 緊急情報機能は地味に良い機能。AppleWatchでカバーしている領域の一部を、Androidスマホでフォローしている感がある。

まとめ

ここ数年は毎年スマホを買い替えたい願望を持ちながら過ごしていたけど、無印ではなくProを買ったことで個人の興味とスマホアプリエンジニアとしての所有欲を満たすことができた1

結構満足しているので、これなら2年使い続けても大丈夫そうだなと思った2


  1. Foldableが販売してたらちょっと違っていたかもしれない

  2. 私用Macがlate2012でいい加減買い替えたいので、来年はそっちにお金使いそう

Navigation コンポーネントを使ってみた

developer.android.com

目的

  • Navigation自体は発表直後から存在を知っていたが、利用シチュエーションやメリットがいまいちピンと来ていなかったために特に学習していなかった
  • FlutterでNavigator2.0が出ていて、少し似ている気がしたので興味が出た
  • 画面ごとに画面遷移を管理するのではなく、Raildのrouterの様にルーティングを一箇所でまとめて管理するほうが流れを追いやすく、それを実現するためには良いものなのではと思った

所感

  • nav_graphによって視覚的に画面フローを確認できる。ほとんどのユースケースは起点となる画面からツリー状に遷移フローが生まれるため、それをある程度表現できている
  • パラメータが型安全に授受できる。何だかんだキャストするストレスが発生していたので、助かる
  • やはりSingleActivityを基本とした考え方になるので、既存のActivityをスタックする前提のアプリに入れるハードルはまだ高そうな感じがした。部分的に導入はできるが、混ざるのは結局混乱を招きそう。featureモジュールを切ってそれのユースケースだけ使う、みたいな完全別モノに使うのはアリ
  • Composeとのコンフリクトはありそう。この辺はまだ自分の中にイメージができてない

github.com

groupieを使ってみた

github.com

目的

RecyclerViewをそのままで使うとカスタムレイアウトをいい感じに利用したい時にViewHolderを宣言する必要があり、そこそこ面倒。

developer.android.com

他にもdatasource更新時の挙動管理でボイラープレートが増えがちだったり、デフォルト実装があればいいのに・・・と感じるメソッドがあったりで、昔は不満に思いながら開発していた。

そのような課題を解決するためのサードパーティライブラリがいくつかある。一つはgroupieで、もう一つがepoxy。

epoxyはairbnbがメンテしているライブラリで、databindingのサポートやカルーセル形式のViewの拡張をサポートしていたりでリッチなライブラリ。groupieより先に使ったこともあり、個人的に馴染みがある。前職で利用していた時に書いた記事 →

qiita.com

ところがDroidKaigiのリポジトリや世間の風潮を見ると、groupieというものがあってそちらのシェアが多いっぽいということが分かった。比較記事を見ている感じだと

  • epoxyは機能が豊富でリッチ
  • groupieはRecyclerViewのAdapterを入れ替えるだけで済むため導入が簡単

とのこと。確かにepoxyの機能を使いこなすほどの要件はそれほど多くない印象があり、自然とgroupieで良いやという人が増えてもおかしくはなさそう。

最近デファクトのライブラリは一通り触っておきたいなと思い始めたため、これも少しだけ手を動かして触れてみることにした。


サンプリコードは充実してる

exampleアプリを触った限り、結構色々できそう。スワイプでの要素削除だったり、ソートやpagingなど。ライブラリで抽象化はされてないかもしれないが、サンプルコード自体の実装が充実しているので、いざという時にどうにかできそう

ライブラリの導入でつまづく

https://github.com/lisawray/groupie/blob/bc3c799b8cbb08ddf5f450b8f9b62f84aff33a84/README.md

READMEの通りにgradleファイルを更新するとエラーになる。パスの指定が違ったみたい(DroidKaigiアプリのリポジトリを参考にした)

# OK
implementation "com.xwray:groupie:2.9.0"
implementation "com.xwray:groupie-databinding:2.9.0

# NG
implementation "com.github.lisawray.groupie:groupie:$groupie_version"
implementation "com.github.lisawray.groupie:groupie-viewbinding:$groupie_version" 

これを調べてる過程でメンテナ募集中みたいなコメントを見かけて、少し不安になった

com.xwray:groupie-viewbinding can't be resolved · Issue #333 · lisawray/groupie · GitHub

I am actually transitioning to a new career and would like this library to be able to continue without my hands-on help.

実装自体は簡単

専用のAdapterのインスタンスのitemとしてViewHolderの代わりのクラスを追加すればいいだけなので、理解しやすい構成で簡単に書けた。

  • モジュールの使い方はわかった
  • モジュールの分割方法のイメージはついた
  • データ更新のイメージはなんとなくできた
  • 実際にデータの差分更新までやると問題は発生しそうだけど、調べれば解決できる気がする

実際の所感としてはこんな感じで、利用する抵抗はなくなった。やってみてよかった

github.com


参考記事

https://qiita.com/takahirom/items/4125d7c871fad534d3c2

AndroidでGitHubリポジトリを作るときの手順(with SourceTree)

初心者感丸出しでちょっと恥ずかしいレベルの内容だけど、いつも忘れるのでメモ

課題

community.atlassian.com

  • 新規作成したリモートリポジトリをクローンしてでAndroidStudio上でProject Newしても、テンプレートのappフォルダが生成されない
    • 理由はちゃんと調べてない。これが解決すれば良い気もするけど、ワークアラウンドさえ分かればいいので今分かる範囲でどうにかしたい
    • .gitignoreのコンフリクトが原因なような気がしている
  • Gitのコマンドは極力CLIを利用しない。SourceTreeでやる
    • SourceTreeを利用できる環境で働いているので今はCLIにこだわってない。SourceTreeでできるようになったら同じ手順をCLIで実現できるようにする

手順

  1. リモートリポジトリを作成する
  2. ローカルで新規プロジェクトを作成する
  3. SourceTreeで作成したローカルプロジェクトを新規リポジトリとして登録する。リモートリポジトリも作成するはチェックを外す
  4. SourceTreeで リモートを追加を選択
  5. origin/作成したGitHubリポジトリのURLを設定して登録
  6. fetch
  7. ローカルの.gitignoreを削除(コンフリクトの原因になるため)
  8. originを選択してリモートのmainブランチをチェックアウト
  9. ローカルの変更をcommit
  10. pushする

読書メモ Web API The Good Parts

目的

業務のアプリ開発の一環でWebAPIの仕様を考えることがあり、仕様についてチームメンバー同士でなかなか合意に至らないことがある。合意に至らない原因はそれぞれに理想のAPI像があるためで、学習するよりも過去の経験や既存設計の延長線上の会話で議論する結果収束しない、みたいな感じ。

以前所属していた会社のAPIの設計が割とフロントエンドに優しい仕様になっていたこともあり、自分はどちらかと言うとフロントエンドがjson色付け係になれる方向で設計しがち。一方バックエンドの人は、BFFがない場合に過度にフロントエンドの仕様に寄せた設計にするのを避ける傾向がありそうで、両者ともに間違ったことを言っているとも思えなかったので自身を持って会話をできなかった。

最近いくつかAPIに関する技術書の存在を知り、その中でも一番評判の良かった本を読んでみた

感想とか

有名サービスのAPIを比較しながら良いWebAPIとはなにか?に答えている。

発行時期の関係で情報は少し古い気がする(初版が2014年)が、jsonをベースとしたAPIはそれほど大きなパラダイムが起こってなさそうだし公開してから頻繁に変えるようなものでもないので、気にしなくて良さそう。例示されたサービスの現状を見て、生き残っている仕様は長続きする仕様みたいな判断もアリだと思う。

APIをどういう単位で作成すべきか、それでどういうものを返却すべきかについて学ぶことができた。HTTPやAuthに関する情報はバックエンドの人に任せようと思っているので飛ばして読んだ。自分の中で一つ指針ができたので、今後迷うことがあればまずはこの本で学んだ原則に従って検討を進めようと思う

  • LSUDsとSSKDs
  • 覚えやすく、理解しやすいURI
  • ページネーションのAPIはデータ量が増えると相対位置指定だとパフォーマンスが落ちるので注意
  • REST LEVEL3 HETEOASの概念
  • メタ情報はbodyではなくheaderに。HTTPを活かす
  • 配列を直接返却するとセキュリティリスクがある。オブジェクトで包んだほうが良い
  • 時刻情報は特定言語の情報が含まれないRFC3339か、特定アプリのみで利用する場合は使いやすいUNIXタイムスタンプがおすすめ

Webで調べられる内容でも技術書を読んで学んでいる理由

技術書にかかる費用が増えてきた。

リモート勤務になったことで読む時間が増えたからだと考えていたけど、よく考えるとその前からそれなりに購入している。人から言われてではなく自分が読みたいから購入しているし、仕事で使う内容なので良い投資だとは思っている。

たまに、今はwebで調べられる、無料だし情報の鮮度が違う、本で学ぶ必要はないみたいな主張を見かける。確かに正しい気がするし、であれば自分が本を購入する理由は何なんだろう?とモヤモヤしていたが、ふとした拍子にきっかけを思い出した。

スキル不足チームの炎上プロジェクト

すごく印象に残っているエピソードとして、何個か前に所属していた会社のとあるプロジェクトでの話。

そのチームは、社会人5年目で多少開発経験がある自分と、某コンサルSIer出身でギジュツナンモワカランけど自信たっぷりのPMと、なぜ面接通過したかわからないベテランエンジニアの3名だった。

当時の自分はまだ若くて、良いプロダクトコードを意識はしていたけど説得力があるほどのレベルではなく、かつプロジェクトで扱う技術にふれるのは初めてだった。他の二人はそもそも技術に興味が無くスキルもないのでより上位のエンジニアの意見に流されるだけで、プロジェクトは中々の炎上っぷりを見せた。

PMがあてにならんので自分も色々行動をするのだが、一向にすすめることができなかった。なぜ進められないかというと、合意形成をしようとした時に僕が他の二人を理解できるような説明ができず、理解できないので悪いものだと考えられ、結果現状の延長での活動しか認めないからだった。

ちなみに何か特殊なことを説明したわけではなく、自分が知っている世界線ではエンジニアにとって割と当たり前な話だと思っている。例えばコードに関することだとこんな感じ。

元コード

idx = 0 # 他ではindex。これだけ何故か省略
while true do 
  # 何か色々複雑な処理。頑なにメソッド分割しないのでめちゃくちゃ長い。ネストも深い
  idx = idx + 1 
  if index == 100 then # 100は適当に設定されたマジックナンバー。データが10くらいしかなさそう、という判断らしい。ちなみにindexとtypo
    break;
  end
end

提案内容

items.map do |item| 
  set_categoty(item)
  calc_price(item)
end

これが却下された。少なくとも既にバグっているので直したほうが良いはずだけど、賛成1反対2で多数決となり、Ctrl + zを連打された。mapが理解できないのと、関数に分離したことで見るファイルが増えて大変という理由だった。

他にも要件定義に関する話もしたが、それもコンサル出身のPMが言っていることが正しいはずだとバックグラウンドを理由にされ通らなかった。

自分の力だけで説得できると思わないことにした

おそらく当時は自分が一番まともな開発経験を積んでいて良い判断ができる、だから自分の意見を取り入れるべきだという意識で話していた。開発経験が一番重要な要素で、それが基準で会話していると思っていた。なのでなぜ拒否し続けるのか理解ができなかった。

今にしてみれば、相手は相手で年齢やそれまでの(開発と関係ない)経験が判断軸として重要な要素として信じていて、互いに合意の基準を合わせないまま戦っていたのであんな判断になっていたのだと思う。

あのときは判断基準をきめてから、それに則った理屈で説明すればよかったのかもしれない。判断基準は色々あると思うけど、あのチームメンバーの感じだとより上位の上司か一般的に認められている人の意見に合わせる、というのが良さそう。

そして、上司に根回しすると言うのはその手法に再現性を作りづらいけれど、一般的に認められている人 ≒ 提示できる正しい情報元 とすれば、一度書籍で得られた知識はそのまま活かせそう、ということに気づいた。

あらためて、Web vs 書籍

例えば、プログラムを書いている、書き方がわからない、だから調べたいという場合、プログラムが書ければよいので、公式サイトを調べれば良い。これは正しさを判断する主体が自分であり、公式=正しいが自明なのでそれで大丈夫。

一方、先程の例のような人と議論する(できるようになる)ために何か知識を身に着けたいと思ったらちょっと様子が変わりそう。

議論するということは相手の人がいるわけで、その相手に自分の主張のベースとなる知識や意見を理解して貰う必要がある。でも現実問題、理解できない人もいるしそういう人がステークホルダーになっている場合は何かしら判断基準に則った情報を与えないといけない。その時に、〇〇という書籍に書かれている〇〇という意見を参考にしている、と言えるだけで割と説得力が出てくるような気がする。

逆にwebの情報だけだとどのページから調べたのかまで提示しないと情報の正しさを証明しづらいし、相手にもwebで調べたと言われると引き分けになってしまう。その点、技術書だとレビューとかで一般の人の評価もわかりやすいし、何より体系的に整理されているので説明が破綻しているようなこともほとんどなく、間違っている証明が難しい。

そういう理由で、人と関わるタイプの仕事だと書籍も読んでおいたほうが良いんじゃないかなと思っている。

本当にふと思いついて書いたので文章がところどころ変になっていそうだけど、大体の主張はこんな感じ。


※1 別に自分の意見を通したいのではないけれどダメそうな意見をゴリ押しされたときの自衛策みたいな感じ。間違った判断を回避できてさえいれば、プロダクト開発はそれなりに成功するものだと思っている

※2 コード修正の提案は、開発初期でリリースどころかほとんどの機能ができていない状態での話。なので修正範囲とかは気にするフェーズじゃなかった

※3 もちろん、正しい情報のみ選択してそれから知識を得ることもできるけど、そもそもインターネットはたくさんの情報の中に正しい情報もあるというものだと思っているのでフィルタリングや正しい情報の証明が大変。あと、細切れの情報だと論理の破綻に気づきにくかったりする

読書メモ ユニコーン企業のひみつ

販売直後に結構話題になっていた本。社内の人で買ったという人もちらほら。

自分は強い目的意識が合ったわけではないが、キャンペーンのノベルティが欲しかったのと今の会社がもっと大きくなるために必要なTipsみたいなものを知れると良いなと期待して購入した。

Spotifyでの体験談をベースに、市場に価値を提供して急拡大する組織を作るための文化だったり、そこに所属する社員に必要なマインドセットを紹介してくれた。後半の数章は割と一般的な内容で、ある程度プロダクトを重要視している企業ならできていそうな内容(データを活用する、生産性を上げるための活動、みたいなところ)。マーカーを見ても前半に偏っていた。

これを真似すれば大丈夫!ではなく、あくまで例の一つとして捉えておくのが良さそう。自分の考え方をアップデートできたのと、良い文化・習慣を実践するきっかけになった。たまに読み返してモチベーションアップに利用したい。

  • 試行は戦略的に、行動は局所的に
  • アジャイルはもう皆やっている。これをやったからといって市場優位性はない。
  • スタートアップが競っているのは開発スピードではなく、如何に未知を明らかにできるか
  • スタートアップ企業に必要なのは探索性。エンタープライズ企業が重視している計画性ではない
  • プロダクトのリリースはスタート地点。そこから以下にしてPMFできるか。提供しているプロダクトをベースに、更に顧客が求めているものを探す
  • プロジェクトではなくプロダクト
  • 自立したメンバーでチームを組む。チームを信頼してもらい、自分たちの判断でプロダクトをより良くしていく。チームの外からは、チームがより良い活動をするための手助けをする。管理は重要じゃない。
  • 会社として重要なことにベットする。そのために資金を惜しまない。
  • スピードは大事。でも品質も同じくらい大事。納期や予算を言い訳に妥協しない
    • スピード > 品質 で考えがちなので、肝に銘じる。リリースして終わりでないことを理解すれば、自然とできるようになりそう。

読書メモ テスト駆動開発

良いコードを書きたいというモチベーションからいろんな技術書を読み進めていくうちに、TDDは避けて通れないことを察して読むことにした

大きく分けて、3つのセクションにわけてテスト駆動開発について説明されている。

1つ目は比較的理解しやすい多国籍通貨を表現するMoneyクラスの機能追加を例に上げ、2つ目はより複雑なテスト用クラス自体に対するテスト、3つ目のセクションがTDDで知られたデザインパターンの説明、になっている。

一番読みやすかった第一セクションが一番印象に残っていて、知識として吸収できた部分も多かったように感じる。

慣れている人にとっては少し過剰に感じるかもしれないが、コードの現在地をTODOリスト形式で表現してくれていて、それを章ごとに一つずつ解消していく流れのため、難しくて手が止まるということもなく読み進められた。

要求に対して何かするときはまず実装を考えるのではなくテストを考える、というマインドセットが全編通じて徹底されていた。また、テストを失敗させることで、まったく手探りの状態から課題を観測可能な状態にする、というステップも納得感があった。

小さいステップで不安を解消しながら完成状態に近づいていくという実装を自分のペースで追体験できたので、読み終えて テストを書くことの心理的なハードルが下がっていることが実感できた。

業務でもフレームワークに依存しないテストを書きやすいところは積極的にテストコードを追加したくなった。お盆明けから早速試してみる。

Android StudioでJDKバージョンを11に変更しても反映されないときの対処

An exception occurred applying plugin request [id: 'com.android.application']
> Failed to apply plugin 'com.android.internal.application'.
   > Android Gradle plugin requires Java 11 to run. You are currently using Java 1.8.
     You can try some of the following options:
       - changing the IDE settings.
       - changing the JAVA_HOME environment variable.
       - changing `org.gradle.java.home` in `gradle.properties`.

先にこちらのQiita参照のこと。多分殆どの人は解決しそう

qiita.com

自分の場合、Preferences | Build, Execution, Deployment | Build Tools | Gradle からGradle JDKをクリックして11系にApplyしても反映されなかった。

$ ./gradlew --version

------------------------------------------------------------
Gradle 7.0.2
------------------------------------------------------------

Build time:   2021-05-14 12:02:31 UTC
Revision:     1ef1b260d39daacbf9357f9d8594a8a743e2152e

Kotlin:       1.4.31
Groovy:       3.0.7
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          1.8.0_302 (Amazon.com Inc. 25.302-b08)
OS:           Mac OS X 11.2.3 x86_64

ふと、ダウンロード済みのものではなく新規ダウンロードを試したところちゃんと反映され、目的の処理を実行することができた。

f:id:burgerham:20210810213007p:plain

選んだのは Amazon Corretto versionのものだけど、多分ほかのでも問題ないはず。

ダウンロード済みに見えているJDKにパスがちゃんと通って無くて反映されえず、新規ダウンロードしたJDKではダウンロードプロセスでそれが解消されたのかな、とか思っているがホントのところは謎。

読書メモ レガシーコード改善ガイド

リーダブルコードで読んだリファクタリングとテストに対する理解を深めたくなったので読んだ。

hamburger.hatenablog.jp

確か以前読んだ時に挫折していて、テーマが壮大すぎるのと自分の脳内メモリが足りなくて諦めた。以前よりも少しだけ知識がついたので再挑戦。

テストが無いコード=レガシーコードというシンプルな問題提起を起点に、テストをしながら(しやすくしながら)取り組めるマインドセットリファクタリング技法が紹介されている。少しずつ修正して、テストがなかったらそこにテストを書こう!を細かく書いてある。

章のタイトルが、実際にコード改善したい時の思考っぽい命名(第6章 時間がないのに変更しなければなりませんなど)になっているので、後から辞書的に使うのにも向いていると思う。

オブジェクト接合部やスプラウトクラス・メソッド、試行リファクタリングといったなんとなく皆概念として知っているものに対して名前が振られていて、それが特に印象に残っている(逆に言うと、ほかはストーリーベースなので理解はしやすかったが記憶しきれるような感じではない)。

レガシーコード改善時に発生する課題一覧として目次を眺め、今感じている気持ちと一番近いトピックを再度読んでこれからの作業の参考にする、という使い方をして活かしていきたい本だった。

再発防止策検討時の謝罪の言葉はノイズに感じる

処世術として謝ることのハードルを下げている人がいて、それが時々鬱陶しいと感じている。具体的には、問題が発生した際に事象の確認をするために質問すると、二言目には すみません と発する人がいて、テンポが悪くなってしまうシチュエーション。

悪気は無いのはわかっているけれど、すみませんと言われることでこれ以上質問してほしくない様に感じてしまう(人が一定数いる)のと、そこで本人の思考が止まっているケースが見受けられ、たまにモヤる。

特に大々的に振り返りの場を設けているのに、その場は問題だけ上げて解決案の検討をしない人は無責任だなと感じる。

もちろん、迷惑をかけた相手に対してその事実を謝罪するのは必要だし全く謝罪がないとムカつくときもあるので、いい塩梅で振る舞ってほしい。

ということを最近考えていて、自分も注意しないとなと思った。

読書メモ リーダブルコード

未来の自分も含む他者がコードを読んだときに理解するコストを下げる、ということを目的としてテクニックがまとめられている書籍。超有名

新卒SIer時代に一度読んだことがあるが、今でも記憶に残っている部分が多い。後半の記憶が薄れているので復習のために読んだ。

1,2部は処理に直接影響を与えないようなコードフォーマットや命名に関する内容。

初めて読んだ当時、こんな簡単な改善でコードが劇的に見やすくなるということがわかって衝撃を受けたのを覚えている。ここのテクニックを普通に使えるようになると、読みやすさが一つレベルアップする。コードの書き方がわからない新人時代に読んでいてよかった。

3部はリファクタリングとして実務で使いそうな内容を、読みやすさ観点で紹介されている。

  • 高次の課題と別の低次の課題は切り出す
  • 小さいコードで一つの課題を解決する
  • 意図を明確にする

ここは別途リファクタリング系書籍で補完しようと思っている。

4部はテストの読みさすさに関する話と簡単な要件に対応するコードを改善するステップの紹介。これも別書籍で補完すれば良さそう。

当初の目的は3,4部をちゃんと読むことだったが、1,2部を復習して自身の解釈をアップデートできたことが今回の学びになった。昔はとにかく長くても正確で命名するみたいな考えで止まっていたが、少し視野が広がったことで周辺のコンテキストを考慮できるようになってきた気がする。

FlutterでiOSのスワイプバックジェスチャーをハンドリングしたいときはcupertino_will_pop_scopeを使おう

画面を閉じる際に実行したいアクションがある場合、WillPopScopeでハンドリングするのが一般的。

しかしWillPopScopeではスワイプバックを検知できない。

前の画面に戻る全ての操作を検知したい場合は別途ライブラリを利用する必要がある

pub.dev

読書メモ 新しいLinuxの教科書

自分がモバイルアプリ開発者として仕事をする上でいくつか苦手な仕事があり、その一つがCI/CD環境の設定というものがある。なぜ苦手なのかずっと考えていたのだが、同僚にオンラインで画面共有しながら作業を手伝ってもらった際にシェルコマンドの理解度が低い事に気づき、この書籍を手にとってみた。

基本的な概念とか用語(シェル、プロンプト)の説明から始まり、CUIでのOS操作方法からスクリプトの書き方まで紹介してくれるため、少しずつ過去の記憶と読んで学んでいる内容のマッチングが進んで「これ進研ゼミで見たことあるやつだ!」的な感覚があった。

おかげで、今まではただの文字列の羅列にしか見えなかったシェルコマンドの多くが、なんとなく読めるようにレベルアップすることができた。

事前に学んだUNIXの考え方と対比して見ることもできたので、それも補完に役立った。

hamburger.hatenablog.jp

特に印象に残っているのはこの4つだけど、それ以外の周辺知識もかなり今後役立っていきそう。

  • よく実行するsource ./.bash_profile の意味とファイル実行との違い
  • 標準入出力の概念とパイプの関係
  • シェルの変数宣言と参照方法
  • 正規表現

一度サラッと読んだだけで個々のコマンドを覚えたわけではないので、作業するときにはまだ細かく調べる必要はあると思う。それでも調べるための基礎知識を短期間で身につけることができたのが良かった。

Linuxの勉強をすることはシステム管理者やインフラエンジニア以外にメリットが少なそうだと思ってずっと避けていたけれど、これほど広い範囲で業務に役立つ知識が得られるのならもっと早くに勉強しておけば良かったと思った。

読書メモ UNIXという考え方

何キッカケで手にしたのか忘れたが、多分誰かがTwitterで紹介していたので購入していた本。
Linuxに関する勉強をしようとしていて、その前に読んでおこうと思って引っ張り出した。ページ数が150弱なのでサラッと読めた。

歴史があって(多分)成功しているソフトウェアが、どのような思想で開発されてきたか?を解説してくれる。コミュニティとして認知されているルールのうち、作者が重要だと思っている9個と好みが分かれるが存在している10個の紹介が中心。

それぞれのルールはシンプルだけど厳密に運用することでこのような効果があるのか、という気づきがいくつかあった。
プログラムのコアの部分は、小さいシンプルなコンポーネント群が協調するように作ることで、長期的には複利のような形で価値向上を促すのだという理解をした。

単純に歴史本として楽しかったし、Linux勉強の導入にもかなり役立っている(※自分は最近までLinuxUNIXの違いや特性を知らなかった)。

Linuxに関する勉強

LinuxのコマンドたちはUNIXを参考にしたからこんな作りになっているんだなという感じで 理解を進められているので、このタイミングで読んでよかった。