macOSのPreviewでフレーズ検索をする

macOSでPDFを読むとき、skimというアプリを使っている。 今となってはmacOS標準のPreviewアプリでもわりと快適にPDFを読むことができるのでskimを使い続けている必然性は薄れているが、使い慣れているので惰性で使っている。

今日もskimを使っていたところ、検索ワードを入力すると途中でクラッシュすることを繰り返した。 そこでPreviewで開き直して同じワードで検索したところ、スペース区切りの二つの単語に対して、単語の並びではなく、入力した単語すべてを含むページがヒットするという挙動をしているようだった。 Googleの検索よろしく二つの単語をダブルクオーテーションで囲ってみたが、そうすると一件もヒットしない。

Previewでフレーズ検索する方法を求めてWebを検索して、検索バーの虫眼鏡アイコンをクリックして“exact phrase”に変えられるよという掲示板の書き込みを見つけた。 言われてみると虫眼鏡アイコンの横に意味ありげな印がついている。 そしてそれをクリックすると「正確な語句」という設定が出てきた。

これにチェックを入れると意図した検索ができるようになった。 めでたしめでたし。

ちなみに古い情報だと引用符で囲うことでフレーズ検索ができるというものも見かけた。 どこかでこの辺の挙動が変わったのかも。

pgModelerをm1 macでビルドしたメモ

pgModelerはPostgreSQLを対象とするモデリングツールで、ビルド済みのバイナリは有料で販売していてソースから自分でビルドするのはご自由にという形で提供されている。 ちょっと試してみたいという程度なので今回はソースからビルドしてみた。 多少の試行錯誤があったので、手順をメモする。

前準備

$ brew install postgresql
$ brew install qt@5
$ git clone https://github.com/pgmodeler/pgmodeler.git
$ cd pgmodeler

libxml2も使うがXcodeに付いてくるものがあるので別途インストールする必要はない。

pgmodeler.priを修正する

バージョン番号などの詳細は実行したタイミングによって異なるので適宜修正する。

diff --git a/pgmodeler.pri b/pgmodeler.pri
index 1ab60335..e2dbdd1b 100644
--- a/pgmodeler.pri
+++ b/pgmodeler.pri
@@ -195,8 +195,8 @@ unix:!macx {
 }
 
 macx {
-  !defined(PGSQL_LIB, var): PGSQL_LIB = /Library/PostgreSQL/12/lib/libpq.dylib
-  !defined(PGSQL_INC, var): PGSQL_INC = /Library/PostgreSQL/12/include
+  !defined(PGSQL_LIB, var): PGSQL_LIB = /opt/homebrew/Cellar/postgresql/14.1_1/lib/libpq.dylib
+  !defined(PGSQL_INC, var): PGSQL_INC = /opt/homebrew/Cellar/postgresql/14.1_1/include
   !defined(XML_INC, var): XML_INC = /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libxml2
   !defined(XML_LIB, var): XML_LIB = /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libxml2.tbd
   INCLUDEPATH += $$PGSQL_INC $$XML_INC

ビルドする

$ /opt/homebrew/Cellar/qt@5/5.15.2_1/bin/qmake -r CONFIG+=release pgmodeler.pro
$ make
$ make install

これで/Applications/pgModeler.appが作られるが、アプリをクリックしても実行できない。 実行するにはコード署名が要るようで、以下のコマンドでそれができる。

$ codesign --force --deep --sign - /Applications/pgModeler.app 

これでpgModeler.appを実行できた。

f:id:tsimo:20211218023128p:plain

余談

最初Qt5をインストーラでインストールして使おうとしたが、ビルドが通らなかった。 コンソール出力を見るとリンカがエラーを出していて、x86_64とarm64が混じってるらしかった。 qmakeで生成されたMakefilex86_64という指定があったので、インストールしたQtがx86版だったっぽい。 postgresqlに合わせてqt5もhomebrewでインストールしてqmakeからやり直すとビルドできた。

コード署名のやり方は、アプリの実行ができなくてコンソールアプリでエラー内容を確認して、そこにあった

Namespace CODESIGNING, Code 0x2

という文言で検索すると同様の問題に遭遇して解決できたケースを見つけることができた。

参考

pgModelerのサイトにソースからのビルド方法はあるが、コード署名については触れられていない。 pgmodeler.io

More Effective Agile

Code CompleteのSteve McConnellさんによるアジャイル開発についての本。 Code Completeは地味だけど実践可能で有益な良いコードを書くためのアドバイスが詰まった本という印象だったので、アジャイル開発方法論は若干食傷気味ではあるけれども読んで損はしないだろうと思って手を出してみた。 そして読んで良かったと思える本だった。

Code Complete (Developer Best Practices) (English Edition)

この本は4部構成で、それぞれ

  • より効果的なアジャイル
  • より効果的なチーム
  • より効果的な作業
  • より効果的な組織

となっている。 この中で自分にとって新鮮味があった、得るものがあったと思った点をかいつまんで書いてみる。

より効果的な組織

アジャイルな開発方法論の話はチーム内のプラクティスに焦点を当てたものが多いので、チームを外側について書かれた4部が個人的には新鮮味があった。

マネージャーとチームの関わり方

より効果的なアジャイル:リーダーシップという章に

  • 基本原則:細部ではなく成果を管理する
  • 基本原則:「司令官の意図」を使って目的を明確に表現する

という節がある。 チームに指示を出す立場の人とチームとの間の距離感についての話だ。 スプリント中はチームを邪魔しない、チームにはプロジェクトの目的と求められている最終状態と各人の役割を伝える程度にして細かいやり方まで口出ししないといったことが書いてある。

こういうさじ加減については他の書籍などでも見かけた。 BasecampのShape Upには、イテレーションの間は基本的にはプロジェクトを止めたり方針変換しないことや、チームがプロジェクトに取り掛かる際にタスクレベルに分解するのはチーム自身でやることなどが書いてある。 また、Think Like Amazonという本には、チームの仕事の成果を測るための指標を設定するものの目標をどのように達成するのかまでは関与しないということが書いてあった。 チームメンバーが気分よく仕事ができて管理する側もなるべく手間がかからないようにしつつ目的を果たすということを目指すと、大体この辺に落ち着くようだ。

basecamp.com アマゾンのように考える 仕事を無敵にする思考と行動50のアイデア

プロジェクトで何を予測するか

予測可能性という章がある。 プロジェクトにはスコープ、コスト、期日といったパラメータがあり、プロジェクトによって期日が固定だったりスコープが揃うことが必須だったりと事情が異なる。 スコープ最優先だと終了日やコストを予測することになり、期日を優先するとスコープ(盛り込める機能)を予測することになり、それぞれのケースでどのように予測するか、という話である。 一方、インセプションデッキというものがある。 プロジェクトのスコープ、コスト、期日、品質のうちどれを優先するかメンバー間で意識合わせをするためのプラクティスだ。 つまりこの章の内容は、インセプションデッキの結果によってプロジェクトにおいて予測することになる対象が変わりうるという話である。 これまでそういう認識を持っていなかったので、ちょっとした気づきだった。

より効果的な作業

作業レベルの話にはわりと馴染みのある話が多かったが、それでもいくつか印象に残る箇所があった。

要求の作成

要求の作成の章に、プロダクトバックログに入れる要求の作り方にはトップダウンなやり方とボトムダウンのやり方があるという話があった。 要求を獲得する方法は開発の方法論ごとに独立して語られることが多いと思うが、いろんなやり方を集めてそれらをトップダウンボトムアップに分類して提示されたのを見て頭が整理された。

質の計測

また、仕事の質を測るのに、作業を新しいことをする作業と手戻り作業に分けて手戻り作業のストーリーポイントの割合を見るという話があった。 これまでアジャイルな方法論の文脈で仕事の量を見る指標(ベロシティ)の話は何度も見てきたが質を測るという話を見た記憶がなく、本書に書いてある方法が素朴で手を出しやすそうなものだったので虚をつかれた感があった。

Amazon Echoの感想

いわゆるスマートスピーカーAmazon Echoを入手したので、試している。

とりあえず明日の天気とニュースを聞いた。 ニュースはNHKの○時のニュース一回分を流すようなものだった。 ニュースをダラダラ垂れ流すニュースチャンネルのようなものを期待していたが、そういうものではなかった。 探せばそういうアプリ(スキル?)もあるのかもしれない。

試しに「近くのラーメン屋教えて」と言ったところ、「Echoのある場所が設定されてないので(Amazonに)登録されている住所から探すわー」みたいなことわりを述べてから、以前住んでいた京都の住所の近くのお店を何軒か挙げてくれた。 ちなみに高倉二条と一蘭などだった。 単純にアプリに設定されている住所だけでなく、サービス自体に登録されている住所まで使って何かしら意味のある情報を返そうとするのは丁寧に作ってる印象を受けた。

その後、今の住所を設定してから近くのラーメン屋やら喫茶店やらを聞いた。 お店の名前の読み方があやしいところもありカタコトっぽくなるのはちょっと微笑ましい。

次に音楽をかけてみようと思って試しに「Alexa、ペルソナ5をかけて」と言ってみたら、「アトラスサウンドチームのアルバム、ペルソナ5オリジナルサウンドトラックを再生します」と喋ったのち、アルバムの再生が始まった。 意外と低音が出る。

これだけの文言で音楽を再生してほしいという要望と、かけてほしいアルバムを正しく選んでくれるというのは、事前に想像していたよりもだいぶ気持ちのよい体験だった。 音量を下げたいなと思ったので試しに「Alexa、音量下げて」と言ってみたところ、音量が下がった。 「Alexa、次の曲」と言うと、再生中の曲が止まり別の曲が始まった。 言葉を発するだけで意図した結果が得られることのうれしさがじわじわと実感として高まってくる。

こちらが「Alexa」と声を発すると、再生している音のボリュームがグッと下がる。 もちろんEcho自体も自身の発する音が聞き取りの妨げになるというのもあるだろうが、再生音を下げることが「聞いてまっせ」というAlexaからユーザーへのシグナルにもなっていて、ユーザーが続いて声を発するのを促しているようで、ユーザーにとって自然に思えるやり取りになるよう考えられて作られてるように思った。

とりあえず初日はこんなところ。

サイロ・エフェクト

タイトルだけ見ると「縦割りあかんで」ぐらいの話かと思ったら、話は文化人類学者のものの見方から始まり、予想外に面白かった。

サイロ・エフェクト 高度専門化社会の罠

サイロ・エフェクト 高度専門化社会の罠

人間はものごとを単純化するために対象を分類するが、社会が違えば分類方法も違う。 文化人類学者は異なる社会を比較することが日常となっていて、世の中にはいろんな分類方法があることを自覚していて、自分が所属する社会の分類方法ですら相対化して見るようになってしまう。 しかし多くの人は、自分の分類法が自分の所属する社会の分類法に影響を受けたものであることに無自覚で、その分類法が自然で当たり前と思い、疑うことすらしない。

組織を部門に分けるのは、組織を理解しやすくするために組織の人間を分類することである。 サイロ化(たこつぼ化)は部門間の連携が図られず、組織全体としてチグハグなことをやらかす状態を指す。 組織を部門に分けること自体は問題ではない。 それにより効率化されることもあるし、そもそも人間は分類して単純化しないとものごとを理解できない。

サイロ化する原因は、(意図的では無いにせよ)部門間の交流がほとんど無かったり、部門間で協力しあうことを阻むインセンティブ設計になっていたりなど。

  • Facebookでは、異なる部門の人どうしの交流が生まれるよう人事制度や異なる部門の人どうしが建物の構造上遭遇しやすくなるよう工夫されている。
  • クリーブランド・クリニックでは、患者の視点で最適な医療を提供できるように、医者を専門分野別に分けていたところを、病気や部位ごとに専門の異なる医者を集めたチームに再編成した。
  • サイロ化された大規模金融機関の歪み(異なる部門でほぼ同じものが違う値付けされているといったこと)を利用して稼いだヘッジファンド

オペレーティングシステムの仕組み

オペレーティングシステムの仕組み (情報科学こんせぷつ)

オペレーティングシステムの仕組み (情報科学こんせぷつ)

160ページぐらいしかなく、説明は平易で、しかしながらOSというプログラムがどういう処理をどういう手順で実行するのかが、プログラマであればおおよそ想像がつく程度には詳しく語られている。

プログラミングの知識がある人が、OSというプログラムの実像について程よく学べる良書という印象。