Alpine Linux でどのファイルがどの apk に含まれるか調べる Docker イメージを作りました。

小さい Docker イメージを作るためには、 Alpine Linux をベースにすると良いという事なので、 自分で作るイメージだけでなく、他人のイメージも Alpine Linux をベースにしている物が多くなってきました。

ところが、Alpine Linux の apk パッケージは普段使っている Ubuntu, Debian 等のパッケージと違って、 よく使うファイルやコマンドがどのパッケージに入っているかイマイチ分かり難いです。

そこで、車輪の再発明とはなりますが、ファイル名(の一部)を指定して、パッケージを検索する Docker イメージを 作ってみました。

https://hub.docker.com/r/okadahiroshi/apk-files/

使い方は簡単でコマンドラインで、

$ docker run --rm -it okadahiroshi/apk-files 探したいファイル名(の一部)

と入力するだけです。

中の仕組みなど

中の仕組みは簡単で

1. apk update でキャッシュにapkファイルの一覧が入るのでそれを取り出す。
2. 一覧のそれぞれに apk fetch で apk ファイルを取得して tar tzf でファイル一覧を取り出す。(取り出したあとは apk ファイルを削除)
3. docker run 時に grep -F で検索して出力する。

という仕組みです。実際は build 時間を少なくするため、2 は 5スクリプトを並列で走らせています。

なお、手元の環境だと build に一時間くらいかかります。マシンのスペックにあんまり関係ないようです。 dockerhub での build は 25分ほどで終了するので、ネットワーク速度等が律速要因だと思います。

System76 の ノートパソコンを買いました

最近は外出時は Chromebook を常用していたした。 そこそこ使えていたのですが重いページで固まりやすかったり細かいところが不満だったので以前から注目していた System76 https://system76.com/ で Ubuntu プリインスールのノートパソコンを注文して購入しました。 今は円安で輸入にはあまり良い時期ではなかったのですが...

スペックは上記の通りで、あまり大したものではないのですが、買って大正解で、いつも家ではデスクトップ PC に Ubuntu をインストールして使っているのですが、ノートPCでも同じ環境が使えてとても快適です。

( Windows マシンはもちろん Mac OS X でも、例えば inotifywait と同等のコマンドって何だったかな? などと一々調べなくてはならなく二度手間でストレスを感じていました。 )

またこれでようやく、喫茶店等で使っているのを自由ソフトウエア主義者の人たちに見られて軽蔑されるのではという不安から解消されます :-)

注文したのが 12月14日で、届いたのが 12月25日なので 11日ほどかかりました。

途中、クレジットカードの請求書に届いた5桁の文字を入力しないと注文処理が進まない部分があり、幸い反映の早いカードだったので OK でしたが、そうでないカードの時は注意が必要かもしれません。

---

ACアダプタは比較的小型の一般的なもので、それは良かったんですが残念ながらプラグがアースがあるタイプのものでした、たまたま変換プラグを持っていたので今はそれで凌いでいます。

残念ながら BIOS は自由なソフトウエアではありません、やっぱり自由ソフトウエア主義者の人たちには怒られるかも。

INotifyPropertyChanged の実装が面倒くさい (Google Apps Script を使ってスニペットを生成したけどそれでも面倒くさい)

久しぶりに Windows アプリケーションを C# で書いているのですが、INotifyPropertyChanged の実装が非常に面倒くさいです。正直言って非人間的だと思います。

仕方がないので、Google Apps Script でコードの断片を自動生成することにしました。

具体的な方法としては

(1) Google スプレッドシートを開いて、さらにスクリプトエディタを開いて以下のスクリプトを作成しました。

gistd911b45aa32a99e5c0be

(2) スプレッドシートを閉じて開いて、以下のように のように入力しました。

(3) メニューからスニペット作成→INotifyPropertyChangedスニペットを実行し、以下のような文書が作成されるのでこれをコピーしてプログラムにペーストしました。

        private int testOne = 0;
        private string testTwo = "";

       /// <summary>テスト1</summary>
        public int TestOne        {
            get { return testOne; }
            set
            {
                if (value != testOne) {
                    testOne = value;
               }
               NotifyPropertyChanged("TestOne");
            }
        }


        public string TestTwo        {
            get { return testTwo; }
            set
            {
                if (value != testTwo) {
                    testTwo = value;
               }
               NotifyPropertyChanged("TestTwo");
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;

        private void NotifyPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }

面倒臭さが 100 から 50 くらいには減りましたが、いちいちコピペするのは全くイケていません。外部ライブラリ等を導入するのも躊躇するしみんなどうしているのだろう。

Android Javaでやっぱりフィールドにmまたは_をつけるべきではないのか。

少し前に、

gfx.hatenablog.com

という記事があって、その時は自分もブックマークで「新規に書く場合はそうすべきだと思う」とか言っていたのだけれども。最近ちょっと意見が変わりました。

m 又は _ をつけた方が良い理由は以下のとおりです。

• 確かに IDE では、フィールドとローカル変数や、パラメータと区別がつくけどコードは必ずしも IDE 上でだけ見るわけではない。コマンドラインで git --diff することもあるし、ブログに引用されるかもしれない*1。コードのポータビリティー(どの環境でもそれなりにわかりやすくする)はそれなりに確保すべき。

• フィールドと引数は往々にしてかぶる。その場合、 typo に弱くなる。例えば

class Product {
    private static final double RATE = 0.8;
    private int price = 1;

    public void setPrice(int price) {
        if (price >= 100) {
           this.price = (int)( RATE * (price - 100) + 100);
        } else {
           this.price = price;
        }
    }

を間違えて

class Product {
    private static final double RATE = 0.8;
    private int price = 1;

    public void setPrice(int plice) { // r と l を typo
        if (price >= 100) {
           this.price = (int)( RATE * (price - 100) + 100);
        } else {
           this.price = plice; // r と l を typo
        }
    }

としてしまった場合、間違いをみつけることが非常にむずかしくなる。

• そもそも型についてのハンガリアン記法とちがって、無限に種類が増えるものではない、m がメンバー変数であるのは十分に java 文化圏では認知されている。

以上です。

*1:そしてそのブログの読者は色弱かもしれない

Haskell 勉強記録 35 日目

すごいHaskellたのしく学ぼう！

今日は、第13章:モナドがいっぱい の途中(位置6700) まで読み進めました。

今日のまとめ(復習の部分が多いです)

• Functor 関数を文脈付きの値に適用して、文脈付きの値を得るための typeclass
  (*2) fmap Just 3
• Applicative 文脈付きの関数を文脈付きの値に適用して、文脈付きの値を得るための typeclass
  Just (*2) <*> Just 3
(*) <$> Just 2 <*> Just 3
• Monad 普通の値を取るって文脈付きの値を返す関数を文脈付きの値に適用して、文脈付きの値えるための typeclass
  Just 3 >>= \x -> Just (x * 2)

Haskell 勉強記録 34 日目

色々、あってサボっていたが今日からまた勉強を再開しました。

ブランクが長かったので 12章 モノイドの初めから進めました。 今日は 12章の終わり(位置 6572)まで読み進めました。

今日のまとめ

type, newtype, data の違い

• type 型シノニム、型に別名をつける、別名と元の型名は同じなので混ぜて書いてもよい。
• newtype 既存の型を包み込んだ新しい型を作り出す。
  慣用句: newtype 新しい型名 = 新しい型名 { get新しい型名 :: 既存の型名} deriving (...)
• data 自作の新しい型を作る複数のコンストラクタを持てる。

Monoid

結合的(associativity) な二項演算子と単位元からなる構造 Monoidにする方法が複数あるときは newtype でくるむ。 Ordering モノイドを使うと、値比較で優先する特徴と劣後する特徴を持つような事例を簡単にあらわせる。

Folderble

畳みこみのできる構造 有る形を Folderbleにするには foldMap を定義すればよい。

わからなかったこと

foldMap を定義するとなんで foldr が自動的に使えるようになるのか。

Haskell 勉強記録 33 日目

昨日さぼってしまった上に今日もあまり捗っていません。

今日は 第12章:モノイド モノイドで畳み込む の途中 (位置 6502/11175) まで読み進めました。

「すごいHaskellたのしく学ぼう！」を読んでいて出てきた関数のメモ