yak shaving life

遠回りこそが最短の道

Vacuous Truth という概念を知っておくとプログラミングに(ちょっとだけ)役に立ちそう

TL;DR

空のコレクションに allMatch() 的な判定をするとtrueになるぞ!気をつけろ!

背景

あるリストの全ての要素がとある条件を満たすどうかを返すメソッドがあり、 allMatch(何かしらの条件) した結果をbooleanとして返すという実装になっていた。このメソッドを利用しようとした時、ふと頭に疑問が湧いた。これって、リストが空だったら結果はどうなるんだっけ…?

というわけでREPLを開いてちゃちゃっと確認してみたところ、結果はtrueであった。

# 空のリストに対して、「全ての要素が奇数である」という判定をしたら true になる…?
jshell> List<Integer> list = List.of();
list ==> []

jshell> list.stream().allMatch(v -> v % 2 != 0);
$3 ==> true

直感的にはfalseが返ってくるのかと思った(だって奇数は含まれてないし!)ので、何故こうなるのか、他の言語でも同じなのかなどを調べてみた。

プログラミング言語における実装

Java

その時使っていたのはJavaだったので、Stream APIallMatchメソッドの仕様を確認したところ、下記のように書いてあった。

If the stream is empty then true is returned and the predicate is not evaluated.

はい。普通に載ってましたね。公式ドキュメントちゃんと読めって話ですな…。でも、なぜそうなるのかは書いていない。なぜなんだろうか。

docs.oracle.com

Ruby

次にRubyArray#all?の仕様を調べてみると、arrayが空の場合については特に書いていない…と思いきや、例のところにこっそり(?)載っていた。

p [].all? {|v| v > 0 }           # => true

trueということなので、JavaallMatchと同じ挙動のようだ。しかしこれ、文章で説明書いといてくれた方が親切な気もするな。

docs.ruby-lang.org

Rust

もう一例くらい欲しいなと思ってRustの iterator::all の仕様を調べたところ、

An empty iterator returns true.

とあった。やはりtrue

doc.rust-lang.org

何故なのか

3例も調べたので、まあどのプログラミング言語でも同じ結果になると思ってよさそう1。ということは、なぜ true になるのかちゃんとした理由があるに違いない。

Vacuous Truth

どうやらこのような挙動は論理学でちゃんと定義されており、"Vacuous Truth"と呼ばれているらしい。対応する日本語はなさそうなので、Wikipediaも英語版しかない。

en.wikipedia.org

ここで書いてある例としては、「ある部屋にある全ての携帯電話は電源がオフである」という命題があった時、その部屋にそもそも携帯電話がなかった場合、この命題は真になるというもの。

ちなみに「ある部屋にある全ての携帯電話は電源がオンである」という命題もまた真になり、また「ある部屋にある全ての携帯電話は電源がオンであり電源がオフでもある」という支離滅裂な命題もまた真になる。このような命題は部屋が空であるときにしか真にならないため、"vacuously" trueと呼ばれているそうだ。へー。あ、vacuousは「空虚な」みたいな意味です。

で、結局なぜこの場合trueになるの?というところですが、「論理包含」というページ内の例に説明がありました。

ja.wikipedia.org

P が偽ならば、Q の真偽にかかわらず「P ならば Q」が真である ということらしく、直感に反している感はあるけどちゃんと説明可能とのこと。辞表の例が一番わかりやすそうな気がしたので引用します。

ある人が「この仕事が失敗したら辞表を出す」と言ったとしよう。この言葉が嘘となるのは、仕事が失敗したにもかかわらず辞表を出さなかった場合のみである。仕事が失敗して辞表を出したならば約束を守ったのであるし、仕事が成功して(失敗せず)かつ辞表を出さなかったならば、やはりその人は嘘を言わなかったことになる。仕事が成功したにもかかわらず(何か他の理由で)辞表を出した場合も、やはり嘘を言ったとはみなされないであろう。すなわち、先の宣言では仕事が成功した場合のことは何も言っていないのであるから、辞表を出そうが出すまいが本人の自由である。

なるほどなー。元の問題に立ち返ってみると、そもそも「コレクションに要素が存在するならば」という条件Pがあると考えればいいのかな。ここが偽になったらQがなんであれ真になると。

結論

ちゃんと数学の勉強をしている人なら当たり前に知っていることなのかもしれないが、Vacuous Truthという概念があり、これはプログラミングにおける「空のコレクションに対して全要素の条件マッチをするとtrueが返る」という実装に反映されている。概念レベルで一度理解してしまえばこの挙動を忘れることはないと思うので、Vacuous Truthについて理解しておくことはプログラマにとって一定の利益がある。ので理解しておきましょう。ということが言いたかったのでした。

余談

ちなみにですが、allMatchではなくanyMatchの場合、結果はfalseになります。Rubyならany?、Rustならany。いずれもfalse。何故こうなるのかはちょっとよく分かってません。

若干罠っぽい(なんで一緒じゃないの?直感的じゃない…と思いがちな)挙動ですが、allanyで結果が逆になると考えれば忘れなさそうです。


  1. 追記: よく見たら Vacuous Truth のWikipedia ページにJavaScriptPythonの例が載っていた。もちろん結果は true

nuxt-create-appしてnpm run devしたらerror:0308010Cになる件

タイトルのまんまですが、nuxt-create-appで適当にプロジェクトを作ってnpm run devしたらいきなり下記のエラーになった。Nodeのバージョンは 17.5.0。

Error: error:0308010C:digital envelope routines::unsupported
...(中略)

  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

なんだかOpenSSL関連っぽい感じ。とりあえずエラーメッセージでググって上から10個くらい記事を読んでみると、Node 17 からOpenSSL 3 が使われるようになり、Webpack 4 内部で使ってるハッシュアルゴリズム (md4?) がサポートされなくなったのが原因らしい。package-lock.jsonを見ると"webpack": "^4.46.0"だったのでなるほどという感じ。ちなみにWebpack 5 でもダメだとか。

ちゃんと調べてないけど、下記のコメントを見る限り Webpack 6 ではハッシュアルゴリズムを変えてくれるらしい。

github.com

Webpack 6 が出てNuxtのdependencyが更新されるまでの間どうすりゃいいのよ?というと、

  • node起動時に --openssl-legacy-provider をつけるか、export NODE_OPTIONS=--openssl-legacy-provider環境変数にセットしておく
  • webpackの設定に output.hashFunction: "xxhash64" を追記する
  • LTS version のNodeを使う (現時点だと 16.14.2)

のどれかでいけるらしい。とりあえずNodeのバージョンを 16.14.2 に下げたら動きました。なかなか難儀な話だなぁ。

教訓としては、特にこだわりがなければ日頃からLTS使っとけってところでしょうか。

参考

itsmycode.com

stackoverflow.com

github.com

github.com

Dockerコンテナが立ち上がらず no space left on device になるからdocker system pruneしたけどダメ

ローカル開発で使っているデータベース用のコンテナが立ち上がらず、no space left on deviceと表示されるのであーノースペースがレフトなんだなと思ってdocker system pruneをノールックで実行というのを雑にやっていたのだが(ローカルに失って困るイメージとかコンテナとかないだろうということで)、これをやっても同じエラーが出続けるので困った。

ちゃんと調べてみると、Docker 17.06.1 以降ではdocker system pruneでボリュームも削除するには--volumesフラグが必要になると書いてあった。全然知らなかった…。ちゃんと最新情報を追わないといけないな。

docs.docker.jp

というかよく考えたら、ボリューム消したいだけならdocker volume pruneした方がいいよなあ。これからはそうしよう。

JavaのUnboxingでNullPointerExceptionが出てほしくない

Java初心者なので、戻り値の型がLongAPIを使いたいけどnullとか嫌だからlongにしちゃおーといって適当にAuto boxingしたらNullPointerExceptionが出てしまった。こんな感じ。

// SomeLibrary#count の戻り値の型はLong
long count = SomeLibrary.count();  // => NullPointerException

あれ、そうだっけ?nullだったら勝手に0lとかになってくんないの?と思ってJShellでも試してみる。

jshell> Long wrapper = null;
wrapper ==> null

jshell> long primitive = wrapper;
|  例外java.lang.NullPointerException
|        at (#2:1)

まあそもそもラッパークラスになってる時点でnullを許容する必要があり、nullであるという状態は何かしらの意味を持っている(はず)のだからちゃんとnullの時に対応するコードをかけということだとは思うけれども、それでもなおnullとかいらねーよというときはある。皆さんもあるでしょう。多分。結局Optional使ってこんな感じで書けばいいということだろうか。

jshell> long primitive = Optional.ofNullable(wrapper).orElse(0l);
result ==> 0

Optionalがなかったら一旦Long型の変数に入れてからif文でnullチェックして云々みたいなことが必要そうなので、Optionalのおかげで少しは書きやすくなっているということだろうか。しかし、本質的には明示的なnullチェックとそんなに変わらない気がするし、どうせだったらnull合体演算子とかエルビス演算子みたいなの導入してくんないかなあ。long primitive = wrapper ?: 0l とかで書ければ楽なんだけどねえ。

はじめて学ぶソフトウェアのテスト技法 を読んだ

なぜ読もうと思ったか

ソフトウェアテスト系の書籍をあまり読んでこなかったのでちゃんと読もうと思った。ので、適当に評判が良さそうなやつを買ってみた。

どのような本か

本書は、ソフトウェアテストの必修技法を満載した初心者にもわかりやすい解説書です。最少のテストケースで最大の効果をあげるためのツールを満載した、小さいけれどすごい本。

らしい。(Amazonの紹介ページからのコピペ)

確かにそんな感じはする。が、後半はちょいちょいやり過ぎ感ある(※個人の感想です)ので、本当の初心者は前半を頑張って読んで後半はサラッと流すくらいでいいかもしれない。

書評というか感想

確かに初心者でもわかりやすく色々書いてある本だという印象。ただし基本的にテスト担当者が開発者とは別に居ることを前提に書かれているので、基本的に開発者自身がテストも全て実施するような体制だと若干ピンとこない部分はあるかもしれない。特にSection III。まあそういう場合は流し読みすればいいと思う。

知らないことも結構あったし、知っていることも「あ、これってこういう名前なんだ〜へ〜」とか「こういう分類があるんだ、なるほどなー」みたいな感じで楽しく読めた。せっかくなので印象に残ったところを適当にメモします。

まずテストのレベル。本書では単体テスト、統合テスト、システムテスト、受け入れテストという4つのレベルに分類されている。経験上、テストの分類って統一するのが難しいというか会社やチームによって全然違うと思うのだが、この4定義は結構分かりやすい気がするので、初心者の方はとりあえずこれをベースに覚えておいてもらえばいいのかもしれない。

Section I ではテスト技法1つにつき1章という感じの構成になっている。せっかくなのでそれぞれについて感想を書きます。

同値クラステスト(同値分割)、境界値テスト、デシジョンテーブルあたりはソフトウェア開発者なら漏れなく知っておいてほしい技法という感じなので特にコメントなし。知らない人はこの本読みましょう。

次にペア構成テストというのがあって、「すべてのペアをテストする」ということらしい。こいつは簡単そうに見えて結構大変では…?と思って読み進めていたら、直行表を作ってすべてのペアを網羅するサブセットを探す的な手法が出てきてこれがまあまあややこしかった。でも変数が多くてテストケースの作成が大変な時は一度やってみていいかもしれないなあ。

状態遷移テスト、ドメイン分析テストはそういう名前があるとは知らずにやっている人が多そうな感じ。気合い入れてテスト書く時はこういうことやるよなー、的な。でも名前があるとテストケースを考えるときに思いつきやすくて便利そう。

ユースケーステストはいわゆるE2Eテストとしてやってる人は多そう。フォーマットという意味では途中で出てくるテンプレートが参考になりそうだと思った。今度使ってみようかな。

ここまででSection I 終わり。Section II ではホワイトボックステストということで制御フローテストとデータフローテストの二種類の技法が紹介されている。

制御フローテストの方にはテストカバレッジの定義の話があるので初学者には是非読んでもらいたい。データフローテストの方は正直ちょっとピンと来ないかなあ。うーん。こういうのはコンパイラにチェックしてもらいたい気持ち。

Section III はスクリプトテストと探索的テスト。そういう名前だったのかお前ら!という感じ。とにかくなるべく早い段階でテストケースをしっかり作ってその通りにやるのがスクリプトテスト、逆にテストを実行しながらやるべきことを考えていくのが探索テスト。この二つを組み合わせてやりましょうねーみたいな話。なるほどねえ。

第14章「テストの計画」には普通に良いことが書いてあったので、一部を下記に引用します。

「計画は、手段と目的をたえず調整し続けるという点で、連続的なプロセスである。また、計画は連続的な調整および改善であるという点で、進化的なプロセスとみなすべきである。

なんかもう、テストに限った話じゃないですよね。素晴らしいです。思わず敬語になっちゃうレベル。

Section IV は補足的な感じだけど、15章にある色々な分類はちょっと興味深い。どこまで意味があるかはちょっとわからないけど、ISO 9126とか一回読んでみようかな…と思ったら有料かあ。うーむ。

最後にSection Vがちょろっとだけある。ちょっと短すぎて引用したら中身全部載せるのと同義になってしまいそうなのであえて引用しないでおきますが、真理が書いてました。普遍の真理。要は、本読むだけじゃなくてちゃんと実践しろってことですね。

そんなこんなでダラダラ感想を書いたわけですが、文章も読みやすいしなかなか良い本だと思う。ソフトウェア開発初学者にオススメできる良書だし、僕みたいにテスト系の本あんまり読んでないなーという人の入りとしてはとても良いと思いました。

2021年振り返り的な何か

いやね、分かってますよ。もう一月も終わろうとしているわけで。こういうのって普通2021年末にやるか、遅くとも年始くらいにやるでしょ。1/31て。まあ自分の中で「一月中ならギリセーフ」みたいな謎の一線があるのでそこのギリギリのラインを攻めて行きたいと思います。(?)

というわけで昨年の年始…もとい、二月に設定したOKRを振り返ってみようと思う。しかしOKRを真面目にやったことがないので振り返る方法もよく分からない。ちゃんと調べるのも面倒なので雰囲気でやってみよう…とりあえず各Key Resultを見ていった上で、当初の目標になかった成果等も加味して最終的な評価(0~1?)つける。これで。

二月の記事で設定したObjectiveは「初心に返って学び直しをする」だった。各Key Resultについて一つずつ見ていく。

Key Results

技術書を25冊読む

ブログ記事の「技術書」カテゴリを見ると、9冊しかない。あれれ~おかしいぞ~?(名探偵)

実際にはSoftware DesignとかWEB+DB PRESS読んだり、他にもサーバレスアーキテクチャの本とかJavaRuby関連書籍、マネジメント系の本etcをいくつか読んではいるのだが、如何せん最後まで読み切らないケースが多くて記事を書く気にならないのであった。(最後までちゃんと通読して、理解したことをまとめないと記事を書く気にならない…)

実際には25冊近く読んでいる気はするのだけれども、最近記憶力があからさまに落ちてきていて、しっかり記事にするくらいしないとなかなか記憶に定着しないので、ちゃんと25記事書く形にしたかった。達成率低すぎィ!

今年は25記事をガチで目指そう…

ソフトウェア開発以外の本を10冊読む

記事としては8記事となってまたまた未達成。これもまた実際には図書館で借りてきた仏像・観光・建築・アート・お金あたりの本をまあまあ読んでいて、こちらは完読したものも多い。でも途中から面倒になってきて記事にしていないのであった。

「直島誕生」とかはすごく面白かったので読書感想文を書きたかったのだけれども、どうも仕事が忙しくてそもそもブログを書く気力がなかった…。今からでも書きたいけどだいぶ忘れてしまったなあ。

新しいコミュニティに2つ以上参加して継続する

目標を立てた時点でイメージしていたのは、(自分にとって)新しい技術コミュニティに参加していくことと、オンラインサロンというものに一度入ってみようかなという感じであった。エンジニアと人生コミュニティとか。(元々はサロンという名前だった気がする)

が、実際はだいぶ方向性が変わっていて、まずこの情勢であまり勉強会やカンファレンスなどに参加する気になれなかった。そもそも育児になるべくリソースを割きたいので業務時間外の時間の使い方がかなりシビアであり、JJUGセミナー何回か聞いたりrust-jp Slackに入った程度で終わってしまった。

また、縁あってフィヨルドブートキャンプというプログラミングスクールにメンターとして参画することになった。正直プログラミングスクール業界については完全に訝しんでいたのだが、フィヨルドブートキャンプ通称FBCは自分の知っているスクールとはだいぶ違った。そもそもいい評判を聞いていたし、知り合いが中にいたので色々話を聞いて、是非お手伝いしたいということでメンターの末席を汚させてもらっている。メンター陣が豪華すぎて自分なんかが居てもいいものかと思ったりもするが、まあ自分なりに頑張ってプログラミングを学びたい人をサポートしている。

で、なぜこの項目でFBCについて触れたのかというところ。FBCはスクールという感じがあまりしなくて、むしろ「コミュニティ」感が強い。受講生とメンターという立場の違いはあれど、個人的にはプログラマとして一緒に頑張る仲間のように(勝手に)感じている。例え未経験であれ、プログラミングを頑張っている時点でもうプログラマなのだ。もちろんメンターとしての責務はしっかり果たすよう努力しているが、それにしてもDiscordで技術に関係あることやないことをワイワイ話しているこの感じは「コミュニティ」以外の何物でもないと思う。

そんなわけで、今の自分にとってFBCは副業先でもあり大切なコミュニティでもある。「2つ以上参加」は達成できなかったが、継続して参加できるコミュニティが一つ見つかっただけでも個人的には十分な成果だった。引き続きメンター業頑張ります。あ、プログラミングを学びたい方はフィヨルドブートキャンプがおすすめですよ〜是非見てみてください!(唐突な宣伝)

bootcamp.fjord.jp

仕事で使用している技術スタック全てを基礎から勉強し、同じスタックで個人プロダクトを出す

はい。やってません。ごめんなさい。

誰に謝っとるんだという感じではあるが、弁明します(誰に?)。代わりといってはなんですが、仕事で一から小さなアプリケーションを一人で作りました。半ば無理やり自分でやった。やりたかったから。今では反省している。

まあこれが結構いい経験だったので、頑張ってやってよかったと思う。一から作るところの経験をするのが目的だったので実質達成と言っていいのでは…!?いやダメか。今年はやろう…(毎年言ってる)

あと、「公式ドキュメント全部読む」をやらないといけない。これを強く感じた。Springのドキュメント、多いなあ…。 公式ドキュメント全部読むに関して、何度も読み返したいQuora回答はこちら。この文章は本当に素晴らしすぎる。

qr.ae

英語の勉強をして何かしらの試験を受けてスコアアップ(TOEIC換算で比較)

ELSAをやったり、Rust the bookPoEAAを英語で読んだり(両方未完)したものの、どうにも中途半端になってしまった感が拭えない。

最近はJolly Phonicsというのを子供と一緒にやっていて、発音を少しでもマシにしたいなー等と思っている。しかし子供はこれを勉強などとは露ほども思わずただただ楽しい遊びだと思ってやっているので、上達がめちゃめちゃ早い。耳がいいとかカタカナ英語を知らないというのもあるだろう。とにかくやたら発音が良くてどう考えてもお父さんは完全なるジャパニーズイングリッシュ。娘に「違うよーこうやっていうんだよ。お口の形をよく見て」とか言われて日々教えられてます。お父さん頑張ります。。

試験で言うとスピーキングの試験を受けた。正直微妙だった。TOEIC換算を直接的にすることはできないが、Cambridgeのレベルで言えば、全然上達はしてなかった。現状維持くらい。うーむ、英語ムズカシイ。継続的にやるしかないな。

ブログをなんでもいいから100記事書く

50記事だった。ちょうど半分。特に後半の失速具合がすごい。毎日書いてる人とか化け物では?

娘が遊ぶためのWebアプリの新作を出す

イデアに実装力と気力が追いついてなくてできなかった。ただただ無力。もうちょっとしたらPCとか触れそうだしタイピングアプリとか作るのがいいかもなーとぼんやり考えてはいるが、何年か先かな…

プロダクト概要だけ書いて全く開発の進んでいない個人開発モノを全てインターネット上に公開するところまでやる

逆にプロダクト概要だけのものが増えた。

Twitterは一日一時間(?)

平均したら達成している可能性はあるけどそもそも測定するの忘れてた。スマホ変えたし。

技術系の資格を何か取ってみる

AWSのなんかソリューションなんとかアーキテクトみたいなやつを受けよう受けようと思ってたら一年終わってた。

その他

技術以外のところで新しいことをたくさん学んだ気がする。仏像から始まって建築、アート、観光、お金、日本史、アパレル、不動産あたり。学校の成績とかは良かったし十代の頃は自分のことを博識だと思っていた(恥ずかしい!)のだが、今や知らないことが多すぎて逆に楽しくなってきた。全く素人な分野はちょっとかじっただけでどんどん知識が増えて良い。読書が一番優良なコンテンツだと思うけど、最近はYouTubeにも色々あって良い。ただ質の良し悪しを見分けづらいのが難点。あと大河ドラマは良い。

浅く広く知りたいタイプなので、様々な方面に手を伸ばしていきたい。

総評

総じてKRがズタズタ。なーんにも達成してない。でも気持ち的には「去年結構色々やったし学び多かったんでは?良くない?」てな感じなので、まあいっか。数字つけるとしたら0.2 ~ 0.3くらいな気がするけど。低。

「初心に返って学び直しをする」はどのくらいできたのか定性的に考えてみると、技術面ではどうかちょっと分からないけどそれ以外の領域では初心に帰るというより初心者丸出しで色々勉強できたので結果的には割とできたんではないかな。うんうん。自分を褒めるスタイルでいこう。

OKRのおかげでチャレンジすることの方向性をある程度ぶらさずにいられたような気がしなくもないので、今年もやったほうがいいかな。でも達成できてなさすぎて微妙に凹んでもいるので、悩むなあ。うーむ。

あ、書いてるうちに二月になってしまった…(また一つ目標達成できなかった感)

まあ人生全体的にこんな感じな気がするな。のらりくらりとやっていこう。

Pixel 6 をしばらく使ってみた感想

Pixel 6を買って二週間ほど経ったので、レビュー記事というほどではないですが感想をつらつら書きたいと思います。まぁまぁ長いので、忙しい方はtl;drだけ見てください。

tl;dr

総合的に見て良い端末だと思います。画面デカいけど。価格も高すぎないし特に不満点なし。画面がデカくてもいい人にはオススメです。

感想

筐体について

でかい。とにかくでかい。6.4インチって片手で操作するの厳しくないですか?iPhoneも巨大化してきているし、世の人々はどうしているんだろう…不思議だ。

以前使っていたPixel 3は5.5インチで、手に馴染むいい形だったので片手で自由に操作できていたのだが、Pixel 6は無理。絶対無理。上の方とか親指届くわけない。まあでも自分より手が小さい人は5インチでもそれは無理だったりするわけで、すべての人が片手で扱えるスマホというのは存在しないか。であれば大きくした方が色々詰め込めるし電池も大きくなるし動画も見やすいというのでスマホがどんどん巨大化するのは必然なのかもしれない。とはいえ5.5インチが恋しい…。

もちろんいい点はあって、Pixel 3と比べると動画はやはり見やすいし、電子書籍も若干読みやすい。固定レイアウトでなければ技術書読むのもスマホでいいかなと思えるようになったのでこれはかなりプラスかもしれない。

また、カメラバーという独特なデザインについて。これは正直結構いいと思う。見た目的にもすぐ慣れたし、カメラの部分だけ出っ張っていると(iPhone 13のカメラを見よ)置いたときに不安定になったりするが、バーだと安定。ド安定。しかもバーの分ちょっと浮くので掴みやすい。ほら、ツルッツルの机にスマホ置いたら滑ってなかなか取れないみたいなことありません?ない?あそう。まあ僕はあるんですよ。ごく稀にですけど。カメラバーがあるとそういうトラブルとは無縁。地味に良い副作用(?)だと思う。あとバイブでブルブル滑って動いちゃうみたいなこともないです。

指紋認証について

背面の指紋認証ではなく、ディスプレイ内指紋認証になりました。精度はどうだろう、よくはない気がする。ちょいちょい失敗する。が、背面のときも結構失敗してたし体感的には同じくらい。iPhoneと比べるとどうなのかはわからないけど、マスク有りの顔認証に比べたら断然いいでしょう。 家の中で指紋登録して、外で認証しようとすると指先が乾燥しているからか全然通らなかったので、外で指紋登録し直したら結構イケるようになった。ちょっとワークアラウンド感強いですけど同じ悩みのある方にはオススメです。

個人的には置いた状態でアンロックできる分背面より良い。

カメラについて

画質は良い。Proはもっといいらしいけど個人的には十分。ズームは7倍までできて結構使い勝手が良い。

写真については完全にド素人だしあまり良くわからないけど、Pixel 3に引き続きポートレートモードにするといい感じのボケ写真が撮れます。ピンぼけ処理はソフトウェアでやってるらしくたまに不自然になるが、大抵いい感じになってくれる。のでいいんではないでしょうか。

あとは暗いところでの写真がかなりキレイに撮れる気がする。同じ場所でiPhone 10(古くて申し訳ない)と比べると圧倒的に見やすい写真が撮れる。夜景モードにするとさらに鮮やかに。これは結構いいところです。

あとはQRコードの認識が早くなった気がする。というかPixel 3が遅すぎただけか…。遅いというか場合によってはLensを起動しないと読み込んでくれなかったからなあ。ここのストレスがだいぶ軽減されました。

あとは消しゴムマジックなるものが搭載されていて、写真を撮ったあとで周辺に写り込んだ人なんかを消すことができる。機械学習的なアレで消した部分の画像を生成していてTensor SoCの本領発揮というところなのかもしれないけど、個人的にはうーんという感じ。割と不自然になる。消したい対象が相当小さい場合にはそこそこ良い感じになるのでいいかもしれない。

普段の使い心地について

今のところスペック不足を感じたことはなくて、サクサク動くし電池も持つし満足度は高め。買ったばかりなので電池持ちがいいのは当たり前かもしれないけど、外出してそれなりにブラウジング、カメラ(動画)、ゲーム等を使っても一日余裕で持ちます。4614 mAhは伊達じゃないという感じ。僕は動画はあまり見ないのでYou Tubeを延々見るとかするとどうなるかはちょっと分からないけど、筐体をデカくした分電池持ちは良くなっているんじゃないでしょうか。

前述の通りだいぶ画面サイズが大きくなったので、割と両手で扱うようになりました。まあこれは慣れの問題なのでいいんだけど、まれに片手が塞がってるけど空いてる方の手でスマホを触りたいときがあって、そういうときは若干困る。どうしたものか…。まあでもほぼ全メーカーのスマホが巨大化傾向にあるので、BALMUDA Phoneを買うくらいしか回避策はなさそう。

それから、ジェスチャーナビゲーションと3ボタンナビゲーションという切り替えが可能になりました。 3ボタンナビゲーションは従来の「ホーム」「戻る」「アプリの切り替え」のソフトウェアボタンが画面下部に表示されるもの。それに対してジェスチャーナビゲーションは「画面下部から上にスワイプでホームに移動」「左端または右端からスワイプで戻る」「下から上にスワイプから長押しでアプリの切り替え」というiPhoneっぽい操作が可能になります。

これが結構良くて、3ボタンだと戻るボタンが遠い(くどいようですが画面がデカいので…)ため親指が大変なところ、ジェスチャーなら右端から左にスワイプなのでかなーり楽になる。ホームも慣れれば快適、「アプリの切り替え」は慣れるのにちょっと時間かかるけど慣れればそれなり。といった感じです。

面白いのは、iOSと違って「進む」がないこと。左からスワイプしても右からスワイプしても「戻る」になる。これはiPhoneユーザからすると相当戸惑うんじゃないかと推察しますが、個人的には好き。進むってあんまり使わないし、右利き左利きどちらでも同じような体験ができるのは良いことだと思う。この右からスワイプで戻る機能がなかったら3ボタンナビゲーションにしていたかもしれない。

難点としては普通の横スワイプが戻るになってしまい、ジャンプ+を閲覧中に何度も何度一覧画面に戻ってしまい、WRYYYYYYYY!と頭を掻きむしりそうになってしまうことでしょうか。まあこれは設定で「戻る」の感度を「低」にすることでマシになりました。やれやれだぜ…。

その他使っていない機能など

文字起こしとかリアルタイム翻訳の機能が良いらしい。これもTensor SoCのなせるわざでしょうか。でも使ってないしこれからもあまり使う機会がなさそうなので、このあたりについて知りたい方はYou Tubeとかでレビュー動画を見るのが良いと思います。

Pixel Standは持っていないのでどうか分からないですが、リモートワークで仕事部屋をしっかり整えている人なんかは良さそう。普通にサードパーティのQi充電器でもワイヤレス充電できそうなのでそれでも十分かもです(試してない)。

あとは、ネットニュースで様々な致命的バグが報告されているというのを見かけます。勝手に電話がかかるとか、充電できないとかなんとかかんとか。幸運なことに自分はどれにも当たっていないし、今のところ全てのバグはソフトウェアアップデートで解消されているあるいは解消される見込みらしいのでそんなに気にしなくても良さそうです。

まとめ

ダラダラと書きましたが、基本的には満足しています。正直画面サイズは5.5インチくらいがいいんだけど、スマホの巨大化は抗えない流れだと割り切っています。まあ本とか読みやすいし電池持ちも良くなって悪いことばかりではないですし。

お値段もそこまで高くない(Pixel 3はなんやったんや…)ので、Androidユーザにはオススメできる端末だと思います。

Proの方はよく知らないんですけどカメラと画面サイズくらいしか違いはなさそうだし、より大きい方が好きな人はProを選べばいいんじゃないでしょうか。知らんけど。

今更ですが、色はSorta Seaformにしました。なかなかキレイな色なのでオススメです。ああ、あとストレージはなるべく256GBにしたほうがいいと思います。長く使いたいなら特に、128GBだとそのうち足りなくなること必至です。それでは。