Evernote for Windowsの起動が重い

【事象】
Evernoteは利用する時だけ起動させ、後は閉じておきたい。
そのため、都度起動させては×ボタンで閉じたい。
結果、都度コルタナ経由でEvernoteを起動させていたが、非常に重たい。

【原因】
自分のやり方が悪かっただけ。
都度起動ではなく、Evernoteの常駐機能に早く気付くべきであった。

【対応方法】
常駐タスクからシステム全体のショートカットを用いて起動させる。
Evernoteのマニュアルには、2021/2/13時点では対応していないと記載されている。
help.evernote.com

しかし、最近対応されたっぽい。
そのため、以下のいずれかで呼びだせば良い。
 ・Shift + Win + F:検索モード
 ・Ctrl + Alt + N:新規ノート作成
 ・Ctrl + Alt + H:クイックノート、右上のアイコンでEvernote呼び出し

【その他】
Evernoteのホーム画面を呼び出すショートカットを早く用意して欲しい。
Ctrl + / でショートカット一覧見れるのは超便利。
Notion気になるけど、検索性能強いのでまだまだEvernoteで頑張る。

Evernote

Evernote

  • 発売日: 2017/07/14
  • メディア: アプリ

P129 DBのスキーママイグレーションとデータマイグレーションを分ける

DjangoのORMはマイグレーションの機能も提供している。
Django ORMのモデルに定義したフィールドの移動は、実際にはフィールドの削除と新規追加として扱われる。
このような変更に対するマイグレーションファイルは、1つのマイグレーションでカラムの追加と削除を行う。
そのファイル内にデータ移動の処理も加えたいとする。
(1つのDjangoマイグレーションファイルにスキーマ変更とデータ変更の両方を実装するのはよく見かける)
結果、カラム追加、データ移動、カラム削除を同時に行う1つのマイグレーションファイルが出来上がる。
当ファイルは基本的には問題ないが、エラーが発生した場合、Django ORM側ではどうにもできなくなる。
この問題は、MySQLOracleDDL実行するとトランザクションが完了してしまうためである。
対応方法としては、上記の例であれば、3つのファイルに分けるべきである。
また、データマイグレーションロールバック処理も実装するべきである。

Tomcatが出力するログが640になる

事象

Tomcatのログは開発時に一般ユーザーが見れないのは不便なので、644にしておきたかった。
特に何も特殊な設定入れてないので大丈夫かと思っていたら、640になっていた。

そこで、以下を確認したが、いずれも該当しなかった
・sudo -u tomcat umaskの値
・/etc/profile, /etc/bashrcのumaskの値
・/etc/systemd/system/tomcat.serviceにUMaskの指定有無
・/etc/fstabにumaskやfmaskの記述有無
・/etc/login.defsのUMASKの値(※1)

※1 但し、今回はshadowログイン機能を用いる際に参照するため関係無
Man page of LOGIN.DEFS

原因

catalina.shにumask指定があるから

(中略)
# Set UMASK unless it has been overridden
if [ -z "$UMASK" ]; then
    UMASK="0027"
fi
umask $UMASK

対応方法

catalina.shなどに上記が実行される前にUMASKのシェル変数を宣言しておく。

UMASK="0022"

P84 ソフトウェアプロジェクトにおける心理的安全性

心理的安全性はアットホームな職場の意味ではない

心理的安全性とは、ハーバード大学で組織行動学を研究するエイミー・エドモンドソン教授が
自著内で提唱した概念「サイコロジカル・セーフティ」を日本語に直訳したものである。

心理的安全性の直接的な定義は同書で次のように定められている。

チームにおいて、ほかのメンバーが自分が発言することを恥じたり、
拒絶したり、罰をあたえるようなことをしないという確信をもっている状態であり、
チームは対人リスクをとるのに安全な場所であるとの信念がメンバー間で共有された状態

心理的安全性の高いチームとは、意見や考えを戦わせ合う事ができることを指している。
仲良しだけど、同調圧力が強い、疑問を見て見ぬふりをしてしまうのが多いチームは、
心理的安全性は低いチームであると言える。

心理的安全性の4つの「大丈夫」と「不安」

心理的安全性を支える大丈夫 心理的安全性を下げる不安
「ここにいても」大丈夫 「ネガティブだと思われる」不安
「意見を言っても」大丈夫 「無知だと思われる」不安
「間違いを認めても」大丈夫 「無能だと思われる」不安
「助けを求めても」大丈夫 「邪魔をしていると思われる」不安

どうやって測定するのか

心理的安全性を測る7つの質問
1.チームの中でミスをすると、たいてい非難される
2.チームのメンバーは、困難な課題も提起し合える
3.チームのメンバーは、異質なものを排除することがある
4.チームに対してリスクをとる行動をしても安全である
5.チームのほかのメンバーに助けを求めることは難しい
6.チームメンバーは誰も、自分の仕事を意図的に貶めようとしない
7.チームメンバーと仕事をするとき、自分のスキルと才能が尊重され、活かされていると感じる

但し、アンケートで計測される対象も人間なので、現状に満足していれば悪い評価をあまりしない。
健全でないチームであっても、悪い結果書いたら後で改善とかに付き合わされて面倒だからいい評価みたいなケースもありえる。
そのため、
・定期ミーティングに出るメンバーが偏っている
・振り返りで発言があまり出ない
・雑談の中で仕事の質にかかわる会話が減っている
・メンバー同士の陰口が増えている
・あの人が言っているから仕方ない
みたいな定性的な兆候で理解することも重要である。

上記はほんの一部かいつまんだだけに過ぎないので、実際の記事は以下に記載されています。

心理的安全性について記載されている書籍の日本語版

P81 問題解決のステップと合意形成のステップ

【問題解決のステップ】
問題解決のステップには様々な考え方があるが、
あらゆる領域で活用可能な「What→Where→Why→How」の4つのステップを紹介する。

●What:何が問題なのか?(問題意識の明確化)
●Where:どこが問題なのか?(問題箇所の特定)
●Why:問題が生じる原因は何か?(真因の追及)
●How:どうするのか?(対策の立案・実行)

こうした考え方が必要なのは、決め打ちやしらみ潰しなどに陥らない様にするためである。
また、上記考え方を思考の癖にすることは重要である。
人は多くの場合、どうしたらよいのか(How)から考えてしまう、
もしくは、なぜそうなっているのか(Why)から考え始める傾向が強い。
一時的には状況が改善できても、しばらくすると同様の問題が再発する事が往々にしてある。
これは、本質的な原因に対処できていないためである。
また、事前に何が問題なのかを正しく課題設定しておかないと、
別に重要ではないこと、そもそも問題ではない事を考える無駄が発生してしまう。

【合意形成のステップ】
合意形成のステップの中に問題解決のステップが組み込まれている。
以下の合意形成のステップの内、アクションの理由の共有・合意を取る際の手法が問題解決のステップである。

●場の目的共有
問題解決のステップの前段
 ・議論の場の目的自体は何か?
 ・合意のための手続きは妥当か?
 ・参加者への期待役割は何か?

●アクション理由の共有・合意
問題解決ステップのWhat、Where、Whyの3つのステップを含む
 ・問題意識の明確化(What)
  あるべき姿の要件を洗い出す
  具体化して議論するプロセスを通じて問題意識を共有する
 ・問題箇所の特定(Where)
  広げて、絞る
  Whyに飛ばず、Whereに留まることが問題解決の肝
  共通点・相違点に着目して問題の構造をあぶりだす
 ・真因の追及(Why)
  原因の把握にこそ、多くの意見が必要
  広げる→絞り込む→深める
  MECEだけでなく、状況の映像化、イメージアップすることによる状況整理、把握

●アクションの選択と合意、実行プラン・コミットの確認・共有
上記2つは問題解決のステップのHowに当たる
 [アクションの選択と合意]
 ・取りうる選択肢は何か
 ・どのような基準で選択するか
 ・選択した場合の想定されるリスクや対応策は何か
 [実行プラン・コミットの確認・共有]
 ・実行プランをどうするか
 ・各自の役割は何か
 ・実行時に生じる判断や意思決定をどの様に行うか

書籍には上記内容が図解で分かりやすく解説がされている。

SSMS[SQL Server Management Studio]のポート番号の指定方法

指定方法

ホスト名, ポート番号
ポート番号を省略すると1433に自動接続
補記事項
ホスト名\インスタンス名, ポート番号

その他

ログイン時にデータベースを指定したい場合

接続プロパティでデータベース名を指定
(但し、別に指定しなくてもつながるし、後から選べる)

通常は編集しなくても問題無
インスタンス名などの確認方法
確認対象 確認方法
インスタンス select ** @@SERVERNAME
データベース名 SELECT DB_NAME()
データベース名一覧 SELECT name, database_id, create_date FROM sys.databases;
スキーマ SELECT SCHEMA_NAME()
スキーマ名一覧 select * from sys.schemas order by schema_id;
テーブル名一覧 select * from sys.tables order by schema_id, name;

補記事項

インスタンス

・サーバー名と記載する場合有
・名前が設定されていない場合がある(これを既定のインスタンスと呼ぶ)
 一方名前が付与されている場合は、名前付きインスタンスと呼ぶ

ユーザー周りの関連性

●キーワード
・ログイン:ログイン時に利用するID
・ユーザー:データベースにアクセスする際のID
スキーマ:データベースのデータを格納する領域

●ログインとユーザーが分かれている理由
ログインした際にデータベースにアクセスするユーザーを切替できる
そのため、ログイン名はuser1でログインを行った際、
データベースAはuserA、データベースBはuserBとすることができる
データベースが複数ある場合は便利、一つだけの場合はややこしい
また、データベース毎にユーザーを作成する必要有(※1)
※1 あまりSQL Server使いこなせてないので、共用する方法あるかもしれないが

●ユーザーとスキーマの関連性
デフォルトロールという設定は行う必要はある
しかし、Oracleの様にユーザー=スキーマという関係性はない
MySQLの様にユーザーとスキーマは個別管理という関係性である

サクラエディタでキーマクロを保存しようとするとエラー

事象

サクラエディタでキーマクロを実行して保存しようとすると、
 マクロファイルを作成できませんでした。
 c:\Program Files (x86)\sakura\RecKey.mac
というエラーが発生して保存できない。

対応方法

いくつか手段はあると思うが、面倒なのでフォルダを
 c:\ProgramData\sakura
とProgram Files以外に移動させた。