Magnolia Tech

いつもコードのことばかり考えている人のために。

Scalaで環境変数を参照する方法

sys.envを使う

sys.envという関数が用意されていて、実態はSystem.getenv()ScalaのMapのインタフェースで包んだものが得られます。immutableなので、書き換えることはできません。

存在しない環境変数を参照と例外が送出されますので、参照する際はgetOrElseでデフォルト値を必ず与えておくと良いでしょう。

短いので、Scala 2.13のソースコードをそのまま貼り付けてしまいます。

  def env: Map[String, String] = Map.from(System.getenv().asScala).withDefault { v =>
    val s = System.getenv(v)
    if (s == null) throw new NoSuchElementException(v)
    s
  }

scala.util. Propertiesを使う

Mapとして丸っとコピーするには環境変数は大きいので、必要な物だけアクセスすればいいのでは?ということで、scala.util.Propertiesに、envOrElse関数が用意されてます。

これも短いので、該当箇所をまるっと貼り付けてしまいますが、以下のようなコードになっています。

  def envOrElse(name: String, alt: => String)   = Option(System getenv name) getOrElse alt

sys.envの方がタイプ数が短いのだけど、若干「なんかScalaっぽくない」感じがするので、scala.util. Propertiesを使った方が好みです。また、ScalaJDKのバージョン取得用のメソッドが用意されていたりと、便利なメソッドが用意されているので、scala.util. Propertiesのメソッドは一通り見ておくと良いかも。

なぜ、「過剰な」アーキテクチャを作り込むのか?

何を以て、過剰か、というと定義しづらいけど、「作る物が増え過ぎて、品質保証が終わらない」「動かすために優先度が低い部分が作られない」「動く時は動くけど、動かない時は中途半端に動かない」「そもそも運用するために理解すべきことが多過ぎる」などなど...「本当にこれは必要なのかな?」と疑問に思う瞬間が訪れた時、「過剰」が存在するのかもしれない。

そして、「過剰」が発生するのは、このような分断があるからでは?と言えるかも。


振り返って「最適なアーキテクチャだった」と言い切るのはけっこう難しいけど、「最適ではなかった」ということは気付きやすいので、そういう言語化は大事だなーと。

『教養としてのコンピューターサイエンス講義』は、現代の”教養”を理解するために必須の1冊

以前、第1版を買っていて、もう一回読み直そうと思っていたら、今年に入って第2版が出版されていたことを知り、第2版を買って読み直した。

いやぁ、改めて読んでみると、やっぱり「教科書」だ!

圧倒的なボリュームで現代的なコンピュータの構造、現代までに至る歴史、使われ方、取り巻く環境など、いろいろな周辺エピソードを交えて解説が続く。

プリンストン大学の一般人向けの講義がベースになっているので、普段からコードを書いたり、インフラを作っていたりと、コンピュータと日常的に触れている人にとっては割と「そりゃそうだよねー」という話ばかりだけど、改めて”一般の人にコンピュータを分かるように説明するためには、どんな語り口が必要なのか?”が分かると思うし、案外知らないことも(特に散りばめられたエピソード系は)有って、楽しめた。

とりあえずコンピュータについて、プログラミングについて、取り巻く環境について理解したい、という人が居たら、書名の通り「教養」としての理解レベルだったら、これを渡しておくといいんじゃないかと思いました。経営者みたいな立場の人にはぜひ読んで欲しいですね。

第2版で第4部「データと情報」が独立したのが、主な違いです(冒頭はやはりCOVID-19がもたらした環境変化が語られています)。

  • 第1部 ハードウエア
  •  第1章 コンピューターとは何だろう
  •  第2章 ビット、バイト、そして情報の表現
  •  第3章 プロセッサーの内部
  •  ハードウェアのまとめ

  • 第2部 ソフトウェア

  •  第4章 アルゴリズム
  •  第5章 プログラミングとプログラミング言語
  •  第6章 ソフトウェアシステム
  •  第7章 プログラミングを学ぶ
  •  ソフトウェアのまとめ

  • 第3部 コミュニケーション

  •  第8章 ネットワーク
  •  第9章 インターネット
  •  第10章 ワールド・ワイド・ウェブ

  • 第4部 データ

  •  第11章 データと情報
  •  第12章 人工知能機械学習
  •  第13章 プライバシーとセキュリティ
  •  第14章 次に来るものは?

ただ、全体として図表は少なめだし、それも理解を促すための解説みたいなものではなく、あくまで参考情報みたいなものなので、なかなか読み砕くのが難しく、これが誰からのフォローも無く理解できる人って既にコンピュータを取り巻く環境を一通り理解している人じゃない?みたいなところもありますね...


あと、ブライアン・カーニハンの著書といえば、『プログラミング言語C』が一番有名だけど、近作でいうと『プログラミング言語Go』が有るし、今でも新装版が入手できる『プログラミング作法』が有って、どちらもお勧めです。

ほんと、何歳になっても現役感が凄い!

Bing Wallpaper for Macをアンインストールする手順

Bing Wallpaper for Macをアンインストールする手順

  1. アプリケーションから「Bing Wallpaper」を削除する
  2. $HOME/Library/LaunchAgentsから、com.microsoft.msbwapp.plistと、com.microsoft.msbwupdater.plistを削除する
  3. $HOME/Library/Preferencesからcom.microsoft.msbwapp.plistcom.microsoft.msbwdefaults.plistと、com.microsoft.msbwupdater.plistを削除する
  4. $HOME/Library/Application Support/MicrosoftからBing Wallpaperディレクトリを削除する。
  5. $HOME/Library/Cachesから、com.microsoft.msbwappと、com.microsoft.msbwdefaultsと、com.microsoft.msbwupdaterを削除する
  6. $HOME/.binから、関連するファイルを削除する
  7. 再起動する

直後に、System Preferencesの「Desktop & Screen Saver」から、他の壁紙が表示されなくなったけど、Photosアプリを起動したら、なぜか表示されるようになった。単に一定時間必要なだけだったかもしれない。


毎日クオリティの高い壁紙が自動更新されて便利なんだけど、複数のマシンにインストールしているとどれも壁紙が同じになってしまって混乱するので、アンインストールした。

アンインストールの方法がいくら検索しても分からなかったけど、$HOME/Library以下に、色々なファイルが置かれていることがわかったので、全部消して回った。


一台だけにインストールするなら、おすすめです。

bingwallpaper.microsoft.com

ログレベルは「検知した時の初動」に合わせて決める...よね?

アプリケーションログの重要性について、実運用を経験した人なら誰も異論は無いでしょう。

一方で、言語やフレームワークが用意するロギングライブラリの使い方について、ログをターミナルや、ログファイルへ出力する方法までは解説されていても、実際の監視設定や、監視運用と組み合わせて、アプリケーション側がどのような設計をすべきかは個々のプロジェクトの事情に合わせて検討していく必要があります。

一般的に、ロギングライブラリには、その順序づけられたログレベルが定義されています。

例えば、Javaの代表的なロギングライブラリである、logback-classicには、TRACEDEBUGINFOWARNERRORという5種類のログレベルがあり、左から右に行くほどレベルが高くなると定義されています。

実際のログの出力は、このレベルを対象にコントロールされ、例えば先ほどのlogback-classicであればデフォルトではDEBUG以上のレベルがログとしてメッセージに出力されます。ログレベルにはそれぞれ用途を決めやすい名前が予め付けられてはいますが、実際にアプリケーションの中で何を基準に出力するかは、あくまでアプリケーション側の設計次第です。

じゃあ、どうすればいいか?となる訳ですが、監視システムでそのログレベルを検知した時の初動で決めるものだと思っています。

DEBUGや、TRACEは開発中しか出力されないように設定すると思いますが、逆にプロダクション環境のログに出ていたら、設定の誤りを疑うか、解析のための一時的に有効にしている状態かのどちらかですね。

また、同じログの出力先に対してアプリケーション自身と、そのアプリケーションで使っているライブラリの両方がログを出す可能性があり、出力する基準が違う可能性があります。こんな時は、ログレベルに加えて、オブジェクト名などで区別する必要が出てきます。

その他、例えばERRORが出ているログだけだと分からないので、前後のログを一緒に見るためにプロセスIDや、DBのキーなどをログに出力することで一連のログを、ログレベルに関係なく関連づけて見る場面もあり得ます。

どちらにしても、「そのログが出た後、何をするのか?」を考えて設計する必要があります。


また、ログレベルは、ロギングライブラリごとにバラついていて、DEBUGINFOWARNERRORくらいは割と同じですが、TRACEが無かったり、ERRORの更に上にCRITICALが有ったりします。

さらに、JDKの標準ライブラリであるjava.util.loggingは、割と独特の表記で、以下のようなログレベルになっています。また、環境のLocaleの設定によっては、そのロケールに合わせて翻訳されて出力されるなど、なかなか独特ですね...

  • SEVERE (highest value)
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST (lowest value)

色々な議論の経緯を踏まえて決定されたのだと思いますが......思いますが、FINEFINERFINESTじゃなくても良かったんじゃないかなーとは思います。


最近は、ログもベタっと1行のテキストで出力するのではなく、最初から構造化ログで出すことが増えてきていて、以前のような「エラーログは別ファイルに出しておいて、ログファイルの行数が増えたらアラート」みたいな仕組みではなくて、もっと最初から中身を見て判定できる仕組みになってきているそうですが、結局は監視設計に合わせて出力する、というところは変わらないですね。

『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』を読むときに、最初に読んだ方がいいこと、実践すべきこと

普通に良い本だなー。あんまり『エンジニアリング』というタイトルにこだわる必要も無くて(シチュエーションを説明する用語が、エンジニアリング・マネージャーに合わせてある、というだけなので)、専任のマネージャー職に初めて挑戦する時にざっと読んでおくと、心構えができる1冊ですね。

すべてを完璧にこなしている人はきっといないと思うけど、上手く立ち回っているマネージャーを観察していると、「あー確かにやっているー」という要素がたくさん有って、拾い読みしておいて何か一つだけでも「これだけ気をつけてみるか」と思えれば買った価値も十分に有ると言えるでしょう。

特に2章「まず自分を管理しよう」の章に紹介されている「カレンダー」「ToDoリスト」「メール」のあたりは、自分でもやっていることに近くて(特にメールはほぼそのままだった)、非常に納得感がありますね。常に自分の関心を置く領域を狭めて、気持ちがあっちに行ったり、こっちに行ったりさせない、というのは大事なテクニックです。


あとは、3.2「委譲」がめちゃめちゃ素晴らしい言語化がされていて、ここを読むだけでも本書の価値は十分にあると言えます。

3.2.2「説明責任は委譲できない」には、こう書かれています。

・タスクに説明責任があるとは、タスクを求められる品質で完了させる責任を持つということです。

・タスクに実行責任があるとは、タスクを実際に自分で行うということです。

これ、理解できていますか?実践できていますか?

いつの間にか実行責任と、説明責任の両方を、ぶん投げていませんか?

説明責任を果たすため、報告が必要だからといって、単に配下メンバへ「あの情報を出せ、この情報を出せ」と結局丸投げしていませんか?

「俺は聞いてない!」「なぜ情報が集まらないんだ!説明できないぞ!」とか言ってませんか、どうですか等、ここを読むだけで、ヤバい汗が出てきそうなくらい良い言語化です。

逆に言えば、本当の意味での「説明責任」が果たせていれば、マネージャーの仕事のかなりの部分が終わっている、とも言えるかもしれませんね。ほんと、この章は必読だし、絶対に実践していくことをおすすめするポイントです。


本書、分量もあるし、けっこう細かい方法論や、手順的な話も多いので、全てがこの本の通りに行く訳もないし、やるべきでもないですが、随所に出てくる「視点」や、「考え方」は、常に念頭においておくと良いことばかりなので、まずは欲張らずに、一つでもやれるところからやっていけばいいな、と思います。

とにかく、「情報を収集して、考えて、判断して、行動しよう」という話に尽きるんですけどね!

「エラーメッセージ対応1000本ノック」みたいなのが実は1番スキル上がっちゃうんじゃないかなぁ

上記ツイートの引用RTが学びに溢れているので、みんな見て欲しい。


独学で「エラーメッセージをちゃんと読む」という習慣を身につけるのはなかなか難しい。

そもそも色んな出力が、ばーっと出てきて、どれがエラーメッセージなのかも分からないし…

エラーへの対応スキルが、仮に、以下のような6つの段階が有ったとして、少なくともステップ3までは適切な人に指導されないと、正しいやり方は身につかないよねぇ。独学で身につけられた人は、「独学でできる、というスキル」がある人だしね。

  1. そもそも「今、エラーが起きている状態」を判別できる
  2. どこが「エラーメッセージ」で、どこが「エラーの内容」なのか判別できる
  3. その「エラーメッセージ」が何を示しているのか、ドキュメントを検索できる
  4. エラーメッセージの示す「誤りの内容」を理解し、正しい状態へと修正できる(←ここにめちゃめちゃたくさんの段階があるけど、割愛)
  5. 参考情報としてのブログや、QAサイトの内容を収集し、目の前の事象との比較ができる
  6. エラーへの対応方法をノウハウとして整理し、ブログや、Wikiなどにまとめることができる

というわけで、エラーメッセージの読み方は、丁寧に教えるのがシニアの役割なんじゃないかなーと思いました、マル。