Lycolog

確認環境

やり方

# sambaの導入
sudo apt install -y samba

# sambaユーザーの作成
export $NEW_USER=hoge
sudo useradd -s /usr/bin/zsh $NEW_USER
sudo passwd $NEW_USER
sudo mkdir /home/$NEW_USER
sudo smbpasswd -a $NEW_USER

# 必要最低限の設定を突っ込んでおく
sudo cp ~/.nanorc /home/$NEW_USER
sudo cp ~/.zshrc /home/$NEW_USER
sudo cp -R ~/.zsh /home/$NEW_USER
sudo chown -R $NEW_USER:$NEW_USER

# 元の設定退避
sudo cp smb.conf smb.conf.default
# 設定追加
cat <<EOF | sudo tee -a /etc/samba/smb.conf
[$NEW_USER]
path = /home/$NEW_USER/
browsable = yes
writable = yes
guest ok = no
read only = no
create mask = 0644
directory mask = 0755

vfs objects = recycle
recycle:repository = /home/$NEW_USER/.recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:touch = no
recycle:maxsize = 0
recycle:exclude_dir = .recycle
EOF

トラブルシュート

同一IPのsambaに異なるユーザーでアクセスできない

例えば\192.168.1.10\hogeにhogeユーザー、\192.168.1.10\piyoにpiyoユーザーでアクセスしようとすると上手くいかない。これはWindowsの資格情報がホスト単位であるためと思われる。hostsにドメインを切るなどし、ホスト部を別個にすると上手くいくようになる。

この場合、hoge.localとpiyo.localを192.168.1.10に向け、それぞれにhogeユーザーとpiyoユーザーの認証情報を持たせることで両立できる。

因みに\192.168.1.10\hogeにhogeユーザー、\192.168.1.10\piyoにもhogeユーザーでログインすることはできるが、基本的に権限周りで問題が起きると思う。無難なのは何かしらグループを作っておき、そのグループであれば自由に読み書きできるフォルダをsambaの共有フォルダに設定することだろう。

なんとなくアプリを作りたくなったので。Hello worldするとこまで。

確認環境

手順

1. 公式サイトからインストーラーを落としてくる
2. NextとAgree連打でインストールする
3. Empty Activityを選ぶ

   1. 

4. Tools→Device Managerでデバイスがなんか入ってるのを確認する

   1. 

5. 再生ボタンみたいなやつを押す

   1. 

6. しばらくするとエミュレーターが起動するのでドロワー中央のAndroidアプリを起動

   1. 

7. 画面が出てくればOK

   1. 

Groovy Scriptの読み方が分からなかったので読み解き方のメモ。全て憶測

確認環境

サンプルコード

def credentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
    org.jenkinsci.plugins.plaincredentials.StringCredentials.class,
    jenkins.model.Jenkins.instance.getItemByFullName("ここにフォルダパス")
)

def cred = credentials.findResult { it.id == "ここに取得したいやつのCredentials ID" ? it : null }

読み解き方

個人的な解釈なので特に根拠はない。全て憶測。

lookupCredentialsの部分

端的に言うとデータ型とストア名のようなものを指定し、認証情報を取得する機能であると思われる。Groovy Script的にはCollectionが返ってくる。

• com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials())
  • 第一引数にデータ型、第二引数にLOOKUP条件を設定するものと思われる
• org.jenkinsci.plugins.plaincredentials.StringCredentials.class
  • 文字列の認証情報ということだと思われる
• jenkins.model.Jenkins.instance.getItemByFullName())
  • 現在のJenkinsインスタンス（Jenkinsシステムそのもの）から名前で要素を取得するものだと思われる

findResultの部分

• http://docs.groovy-lang.org/docs/groovy-2.1.3/html/groovy-jdk/java/util/Collection.html#findResult(groovy.lang.Closure)
  • 恐らくJSのArray.findと似たような機能で、itの中に配列要素が入ってくるので、それを使って配列内容の要素を取り出すのに使うのだと思う

タイトルの通りさくらのレンタルサーバーにTiny Tiny RSSを構築する話。いつの間にかDockerコンテナにされてたが本体は単純なPHPのままなのできちんと設定してやるとDocker環境がなくとも動く。

確認環境

手順

以降Tiny Tiny RSSをTTRSS表記とする。

1. さくらのコンパネからTTRSSで利用するDBを作る
2. 以下のセットアップスクリプトを適宜書き換えて実行する

git clone https://git.tt-rss.org/fox/tt-rss.git

cd tt-rss/

cat <<'EOF' | > config.php
<?php
# This file can be used to customize global defaults if environment method is not available (i.e. no Docker).
#
# Use the following syntax to override defaults (options are declared in classes/config.php, prefixed by TTRSS_):
#
# putenv('TTRSS_SELF_URL_PATH=http://example.com/tt-rss');
#
# Plugin-required constants also go here, using define():
#
# define('LEGACY_CONSTANT', 'value');
#
# See this page for more information: https://tt-rss.org/wiki/GlobalConfig

putenv('TTRSS_PHP_EXECUTABLE=/usr/local/bin/php');

# Sets admin user access level to this value.
# Valid values:
# -2 - forbidden to login
# -1 - readonly
#  0 - default user
# 10 - admin
putenv('ADMIN_USER_ACCESS_LEVEL=10');

# Database
putenv('TTRSS_DB_TYPE=mysql');
putenv('TTRSS_DB_HOST=database.example.com');
putenv('TTRSS_DB_PORT=3306');
putenv('TTRSS_DB_USER=hoge');
putenv('TTRSS_DB_NAME=piyo');
putenv('TTRSS_DB_PASS=fuga');

# You will likely need to set this to the correct value, see README.md
# for more information.
putenv('TTRSS_SELF_URL_PATH=https://example.com/');
EOF

php update.php --update-schema

1. TTRSSを設置したURLにアクセスする
2. ID: admin, PW: password でログインする
3. ログインパスワードを変更する
4. 適当にフィードを登録する
5. php update.php --feeds を流す
6. TTRSSの画面でフィードが取得できることを確認する
7. cronに以下のコマンドを適当に登録する
   • /usr/local/bin/php /home/<USER>/www/tt-rss/update.php --feeds --quiet 1> /dev/null

トラブルシューティング

TTRSS画面を開くとエラーが出る：Exception while creating PDO object:could not find driver

.envに設定を書いても読み込まれないのでconfig.phpに書く

TTRSS画面上にRSSの取得失敗エラーが出る：Update process failed with exit code: 127 ()

以下のコマンドを実行したときにエラーが出る筈なので、それを見て対処する

php update.php --force-update
php update.php --feeds

phpのパスが見つからないと言われた場合はconfig.phpにputenv('TTRSS_PHP_EXECUTABLE=<PHP_PATH>');を追加して、phpのパスを設定すれば直る

フィードを追加しても更新されない

勝手に更新されることはないのでCRONが走るのを待つか以下のコマンドを流す

php update.php --feeds

Androidアプリが欲しい

Google Playにはなく、公式サイトからapkを落としてくる必要がある。
昔は有料だったが今は地味に無料化されている。

https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/releases

参考情報

• Tiny Tiny RSS
  • 公式サイト
• Installing on a host machine
  • ホストマシンへのインストール方法に関する公式資料

HuskyとはNode.jsを利用した開発で非常によく使われているGit hooksのユーティリティだが、個人的にはこのツールの存在価値に疑問を感じている。

という訳で、この記事ではHuskyのメリデメを考えた結果と、Huskyが何をしているか、Huskyの必要性について書いてゆく。

Huskyがあるメリット

Huskyは極めて有名なツールであるため、Huskyが入っているとこのプロジェクトはGit hooksで管理されており、標準化されていることが確認できるだろう。恐らくHuskyのメリットはこれ以外に存在しないと考えている。

Huskyがあるデメリット

Huskyの管理をしないといけない、Huskyも地味にアップデートするからだ。これは明確なコストである。

そしてHuskyのコードやリポジトリを見たことがある人は多分ほとんどいないと思う。更に言えばHuskyが何をしているかすらも知らない人だっているはずだ。そんな得体の知れないものを使うのは怖いというところだ。

Huskyは何をしているか？

端的に言えばGit hooksのパスを .husky/ に設定しているだけである。
要するに git config core.hooksPath .husky を叩いているだけだ。
もう少し細かく言えば以下に相当する処理を実行している。

mkdir -p .husky/_
cp husky.sh .husky/_
git config core.hooksPath .husky

勿論、ソースコードには他の処理も書かれているのだが、実質的には上記三行が全てと言って良い。

husky.sh を活用しているケースがどれほどあるか怪しいことを考えると、本質は git config core.hooksPath .husky だと思うので、正直あるだけ邪魔では？と考えている。

Huskyの必要性

ここまででHuskyがしていることは git config core.hooksPath .husky だということが解ったが、だとしたらHuskyは本当に必要なのだろうか？私は特に理由がないのであれば package.json で husky install と書いてあるところに git config core.hooksPath .githooks とでも書いておけば良いのではないか？と思っている。恐らく何も不都合はないはずだ。

ただ世の中には色々な事情があり、使わざるを得ないケースもあると思う。しかし、可能であれば排除してもいいのではないか？個人的にはそう思っている。

何故この記事を書いたか

「この世からHuskyを滅ぼすため」というのはまぁ冗談だが、個人的にHuskyの存在価値があまり良くわかっておらず、多分世間の人もあまり理解できていないと勝手に考えていて、可能であればプロジェクトに入れたくないと考えているので、そのお気持ち表明というか、そんな感じだ。

ここからは余談だが、Huskyには結構な数のスポンサーが付いていて、恐らく毎月それなりの収入があると思われる。以下はHuskyのスポンサーである。

個人的にHuskyは最も成功したOSSの一つではないかと考えている。理由としてHusky自体は非常に単純なプロダクトであり、コミット履歴を見てもさしたるメンテナンスがされておらず、ほぼ手放しで維持されていると思われるからだ。

しかし、Huskyはそれなりの額の寄付を集めており、この記事を書いた時点で確認できるだけでも最低 10USD * (4 + 16) + 100USD * (4 + 2) の寄付がされており、つまり800USD、日本円にして11.2万円ほどだ。何もしてないのに毎月この収入があるのは大分ありがたいだろう。他のOSSならIssueやPull Requestsに対して対応したり、コード本体のメンテナンスがあるはずだが、Huskyにそんなものはないため、プロダクトの維持コストに対して非常によく寄付を集められていると感じる。