lessでgz形式のファイルを見るときに使えるコマンドのメモ

ログファイルをgz形式で圧縮しているけど、その中身を見たい。というときがあったりします。それで、lessでgz形式のファイルを見るときに使えるコマンドを手元にメモしていたので、ここで紹介します。

例えば、こんな感じです。

$ zcat file_name.gz | less

zcatのドキュメントはこれです。zcatは圧縮形式のファイルの中身を表示できます。

Ubuntu Manpage: gzip, gunzip, zcat - compress or expand files

zcatを使ってlessでファイルを見ようとすると、メモリ上に一旦ログを展開してしまうので、でかいログを開けるのは危険。というのをどこかで読んだ気がします。

2020-06-08追記

「lessでgz形式のファイルを見るときに使えるコマンドのブログが参考になった」と言う話を聞いて、久しぶりに記事を見ました。

この記事を書いた時は知らなかったのですが、 zless や zgrep というコマンドもあります。

gz形式で圧縮してるファイルを見るときはおそらくそちらの方が適切かと思いますので、本記事で紹介したコマンドより、zlessやzgrepを使う方が良いでしょう。

JupyterでDocstringを確認する

Jupyter実践入門を改めて写経してて、便利だった話を書きます。

PythonユーザのためのJupyter[実践]入門

それは、JupyterでDocstringを見る話。

? でDocstringが見れる。めっちゃ便利でした。

こんな感じです。

今まで使えてなかったーーーーーー!!!!!!

これでもっと捗りそうです。

引越しました（2018年）

引越しをしましたので報告します。

引越し理由

引越した1番の理由は、夫婦の通勤時間削減です。うちの夫婦は共働きですが、それぞれが職場まで、片道1時間から1時間半かかっていました。

元々の通勤経路では、朝の時間帯に特急がなく、朝に移動すると昼に移動するより20-30分余分に時間がかかってました。

通勤時間が長いとストレスがたまり、生活がつらくなります。

その通勤時間を削減するために引っ越すことにしました。

あと、今住んでいる家は、定期借家契約で、ぼちぼち契約更新の話があったのもあります。

引越し先

ざっくり言うと東京の東の方に住むことにしました。

僕は、職場までドアtoドアで45分くらいになりました。

金銭的な負担とか設備を考えた結果、そのあたりにおさまりました。

もう少し通勤時間が少なくなると良かったのですが、現状、職場に近くなる程、家賃が高くなるというのもあり、こんな感じになりました。

個人的に時間以外の通勤のポジティブな話としては以下があります。

• 乗り換えがなくなった。
• 電車の本数が増えて電車通勤が楽になった。
• 家から駅までが遠くなったので、電車に乗ってる時間は減った。

僕は東京での満員電車通勤にすごくストレスを感じるので、移動時間はさておき、電車に乗る時間が減ったのが嬉しいですかね。

歩くのは運動になるし、別にいいかな。と思ってます。僕は。

物件的な話

もともと住んでた物件が分譲マンションだったこともあり、設備的なハードルが高かったなあと思いました。

例えば

• 浴室乾燥機ないとつらい。
• 宅配ボックスは欲しい
• 敷地内にゴミ置場あって、24hゴミ出し可能が良い。

とか言ってるとハードルが高かった。

上の条件を妥協しない代わりに、部屋は狭目にした。

おわり

とりあえず引っ越した報告でした。

また、何かあれば報告したいと思います。

iEmpathyを使ってみて思ったこと

iEmpathyというライティングツールを紹介してもらったことがありました。

empathywriting

一回使ってみたいなと思ってました。実際に使ってみました。感想を書きます。

この記事は、iEmpathyで作っています。

一回３０分程度でできた

僕は、アカウント登録してから一つ目のブログ記事の作成が完了するまで、３０分程度でした。

１回目に時間をかけてしまうと、次にやる時に、めんどくさいと感じてしまうと思ったので、急いで書いています。

とはいえ、１回の文章構成で３０分くらいだと早いと思います。

短時間で文章がまとまる

僕の場合、ブログを書いていると、どんどん書きたいことが膨らんで、話がまとまらなくなります。

そして、時間がどんどんなくなっていきます。

でもiEmpathyは文章を書くのがプロセス化されているので、今、全体の中でどの程度の文章を書いたのか、がわかりやすいですし、全体の作業量見積もりも立てやすいです。

全体の作業量がわかったら、ブログを書くのにどれくらいの時間が必要かもわかるし、短時間で文章をまとめられます。

まとめられる。というのはすごくいいなあと思いました。

文章の構成をサポートしてくれる

書いたあとで、これ何を言いたいのかわからないな。とか話がわかりにくいな。というのがわかりやすいです。

セクションを質問に従って書いた後に、それらを簡単に入れ替えられます。

まだ、一つの記事しか書いてないですが、これは便利だなあと思いました。

ずっと使わなくてもいい

当たり前なんですが、iEmpathyを使い始めたら、ブログとか文章を書く時は、必ず使わなきゃならないという話ではないです。

気が向いた時に使うでもいいのかなと思っています。

あと、iEmpathyの考え方でブログを書くというのは面白いと思うので、その考え方を学ぶために使ってみるのもいいかなと。

使い方は短い動画で説明してる

僕の場合、使い方を動画で学びました。 短い動画でiEmpathyの使い方の説明をしてくれています。

こちらのデモ動画がわかりやすかったです。 https://www.m.empathywriting.com/iempathy

僕は、iEmpathyを初めて使いましたが、わかりやすくて、スムーズに使うことができました。

ちなみに、書籍も関係するのかもしれませんが、僕は読んでいません。

伝えたいことを文章にできる

まあ、最終的に重要なのは、何を書きたかったのか。から脱線せずに文章を仕上げられるということです。

それはすごく重要。

なんとなく、こういうことを伝えたい。というイメージだけはあるのに、何を話せばいいのかわからない時はあります。

でも、このiEmpathyに従って書いていくと、どんどん文章が出来上がっていきます。

質問に答えているだけなのに、何を書けば相手に伝わるのかを考える手間が省けるなあ、と思いました。

以上。

価格の価値観は立場で変わる

ザ・ゴール2を読んでいた。

興味深い話があったから書く。

ザ・ゴール 2 ― 思考プロセス

ザ・ゴール2の中で挙げられている問題で

• 製品に対する市場の価値観は、買ったモノを持つことで得られるメリットで決定される。
• サプライヤーの価値観は、生産コスト+マージンで決定している。

みたいな話が出てくる。

そりゃそうだ。と思ったけど、自分の中で言語化できてなかったから、おもしろいなあと思った。

買う人は手間を買ってるんじゃなくて価値を買ってるのは常識だと思う。

だけど、確かに、これまで見てきた全ての分野で、価格が買う人の視点で決定されていなかったなあと思った。自分も常にそういう視点かどうかは怪しい。

わかりやすい話だと、僕は飲食店で働いてたことがあったけど、飲食店は販売価格を原価率ベースで考えることが多いと思う。それは、原価に手間賃というマージンをのせてると思う。

農業とか土木の領域も『手間賃』という言葉があるような気がして、それは同じように提供する人の都合で価格を決めてるんだろうと思う。

飲食業の中には『おいしい』という価値を買うんじゃなくて、『自分が片付けなくて良い。』とか『自分が作る必要がない。』とか『手間』を売ってるお店があると思う。

その『手間』は、時間に換算しやすいし、時間は、時給を元に価格が想像しやすい。だから原価率で価格を決めるのかもしれないと思った。でないと買う方が妥当に感じれないように思う。

ぼんやり考えてたら、ファーストフードは、手間だけじゃなくて、速さに対して価値を感じてるんだろうなあと思った。

同じ価格と味とメニューで、提供スピードが５倍遅くなったら、価値がすごく低くなる。提供スピードは重要な価値になってる。

提供スピードを速くしつつ、品質を安定させるか、がファーストフードの企業努力なのかなあ、と思った。

あと、飲食業の中でも高級なお店は手間とか、提供スピードは売ってないはず。味とか高級感を売ってるのかなあ。

高級店の価格はどうやって決定されたんだろう？

何はともあれ、価格を考えるとき、マージンではなくて、相手が得る価値で考えないとうまくいかないと思う。

とはいえ自分が定期したい何か、もあるはずで、きちんと自分が提供したい価値を考えないと何をやってるのかわからなくなりそうだなあと思ったりした。

Linuxディストリビューションってなんだろう

Linuxディストリビューションがわかってない。ここではなんとなく知っていることと、知らないことを整理しつつ、インターネットで調べたことを書こうと思う。

写経したら疑問が出てきた

最近、PyQをやってて、思ったことがある。

それは、

• ドキュメントを読んだり、本を読んだりしていても、いまいちプログラムの動きが頭に入ってきてなかったってこと。
• とりあえず写経して動かして見てから、ドキュメントを読むとプログラムの動きが頭に入るってこと。
• ぼーっとあんまり頭を使わずにコードを写経しているだけでも、けっこう力になっている気がするということ。

みたいな話。

ドキュメントを読んで、理解するのもいいんですが、ドキュメントだけ読んでいるとけっこう話が空中戦になっていて、何が起きているのかが想像の中でどんどん膨みます。で、何があってるのかわからなくなりがちです。

でも、一回プログラムをコピーしてみて、動かしてみると、何が起きているかわかったりして、気持ちがいい。

だからチュートリアルとか、既存コードを写経するだけでも実は、理解が進むのかもしれないなーと思ったりしました。

関連して、「もしかして、Djangoのコードを写経してみれば、Djangoについてめちゃくちゃ詳しくなるのでは？」とか思いました。

いや、全部写経するの大変だし、やらなくてもいい気がするんですが、ちょっとでも写経して見たら、何が起きてるのか理解が進むのかなー。って。

というわけで、今日気になったモジュールをとりあえず写経して見た。

それは、 django.db.models.manager

django.db.models.manager | Django documentation | Django

写経して見た感想。

わからないところが多いなと思いました。django.db.modles.managerがわからないというより、Pythonの書き方としてわからない部分があって、一つや二つならコードを読みながら調べたらいいんですが、たくさんあるので、読みながら調べるのは辛そうだなー。って。

これまで、Djangoのソースを見て、いまいちよくわからないなあと思う箇所があったので、それはPythonの書き方でよくわかってない箇所がたくさんあったからだろうなあと改めて思いました。

とりあえず、思った疑問を書いて起きます。

近いうちに調べたい。

• __new__ ってなんだっけ。
• django.db.router ってなんだろう
• django.db.models.query.QuertSet ってなんだろう
• _meta ってなんだろう
• deconstruct ってなんだろう
• getattr / setattr / hasattrが知ってるようで知らない
• inspect.getmembers のpredicate ってなんだろう
• __eq__ ってなんだろう
• __hash__ ってなんだろう
• なんで空のManager があるんだろう
• EmptyManager って何に使うんだろう