- 投稿日:
Groovy Scriptの読み方が分からなかったので読み解き方のメモ。全て憶測
確認環境
Env | Ver |
---|---|
Jenkins | 2.249.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
の中に配列要素が入ってくるので、それを使って配列内容の要素を取り出すのに使うのだと思う
- 恐らくJSのArray.findと似たような機能で、
- 投稿日:
タイトルの通りさくらのレンタルサーバーにTiny Tiny RSSを構築する話。いつの間にかDockerコンテナにされてたが本体は単純なPHPのままなのできちんと設定してやるとDocker環境がなくとも動く。
確認環境
Env | Ver |
---|---|
Tiny Tiny RSS | dc25a9cf6816b756cb38490eab93f02589c44a10 |
手順
以降Tiny Tiny RSSをTTRSS表記とする。
- さくらのコンパネからTTRSSで利用するDBを作る
- 以下のセットアップスクリプトを適宜書き換えて実行する
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
- TTRSSを設置したURLにアクセスする
- ID:
admin
, PW:password
でログインする - ログインパスワードを変更する
- 適当にフィードを登録する
php update.php --feeds
を流す- TTRSSの画面でフィードが取得できることを確認する
- 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を落としてくる必要がある。
昔は有料だったが今は地味に無料化されている。
参考情報
- 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にそんなものはないため、プロダクトの維持コストに対して非常によく寄付を集められていると感じる。
- 投稿日:
ブートドライブの交換をする時に色々やったので、その記録です。メインはM2SSDの固着ネジの取りはずしです。
内容としてはCrucial P1 CT500P1SSD8JPをSolidigm P44 Pro SSDPFKKW020X7X1に更新しました。
既存SSDの抜去
交換するために既存のSSDを取り外す必要があったのですが、まずここでハマりました。何故かというと、ネジが固着してて回らないんですね…。そしてネジ穴が潰れて終わりました。しかし外せないと困るのでいくつか試してみました。
まずはネジすべり止め液。これを使えばネジ穴が潰れていてもたちまちネジが回るのだとか!
先端部が細くなっていて、ネジ穴だけに上手く差せそうですが実際はM2SSDのネジだと溢れました。ザラザラしてて取り除くのがやや面倒なのでマザボにはこぼさないほうがいいと思います。サラサラしてて割とドバッと出ます。
ネジすべり止め液を差してみたところ。SSDの基板に掛かっていますがとりあえず無事でした。結局これは効果がなく、次の手を探ることに…。
そこで見かけたのが、なめたネジはずし精密用 なめたネジはずし精密用ハンドル付M1~2.6 No.3610-N)。これなら基板にダメージを与えずにネジを取り去れそうですが、近くに売っているところがなく断念しました。
次に浮かんだのがネジを外す道具として定評のあるネジザウルスです。ネジを掴んで回すのでネジ穴が潰れてても原理上問題ありません。ただ、背の低いM2SSDのネジを掴めるのかと、回してる時に基板をこすって壊さないかが心配でしたが、外せないとどうしようもないですし、試してみないことには解らないということもあり、一か八かの掛けで試してみることにしました。幸いこいつはヨドバシにあったのでその日のうちに買いに行きました。(翌日まで待つとかできない!
神戸に住んでるので頑張って梅田まで出張って買ってきました。(しかし、この後買い忘れに気づきもう一回行くハメに…
という訳でネジザウルスを買ってきました。
結果としてはM2SSDのネジの頭を掴むことができ、特に基板にダメージも与えずネジを外すことができたので良かったです。
ブートドライブのクローン
今使ってるマザボはM2SSDスロットが2つあり、片方がブートドライブになっているため、ドライブをクローンして新しいドライブをブートドライブとして使えるようにしていきます。残念ながらフリーのクローンソフトにめぼしいのがなかったのとDDコマンドを使ってまでやる気が出なかったので、かつてお世話になったAcronis True Imageの後継ソフトであるAcronis Cyber Protect Homeを頼ることにしました。
手順は簡単でツール → ディスクのクローンの作成を選び、表示されるウィザードに沿って進めるだけです。
日本語が怪しくてやや分かりづらいですが一番上のやつで行けました。
NVMeSSDからNVMeSSDへのクローンだったので体感30秒くらいで終わりました。
この後は新M2SSD抜去 → 元々差していたM2SSDを挿入 → 元々のブートM2SSDを抜去 → 新M2SSDに置換という手順で更新を完了しました。M2SSDの交換はPCケースを倒した状態でグラボも外してないと出来ないので、クローン作業との兼ね合いで結構面倒でした…。もう当分やりたくない作業です。
何はともあれブートドライブの容量を500GBから2TBに拡張できたのは良かったです。先日グラボを更新したのもあり、新鮮な気分です。