４月４日発売のそのほかの本kyukyunyorituryo.github.io
４月５日発売のそのほかの本kyukyunyorituryo.github.io
４月６日発売のそのほかの本kyukyunyorituryo.github.io
４月７日発売のそのほかの本kyukyunyorituryo.github.io
４月８日発売のそのほかの本kyukyunyorituryo.github.io
４月９日発売のそのほかの本kyukyunyorituryo.github.io
４月１０日発売のそのほかの本kyukyunyorituryo.github.io
Githubで活動をしているとissue（要望）が来てコードの修正を取り込んでほしいと来ることがある。ただしプルリクエストについて知っていないと。コードの修正の提示だけの場合がある。 一つのファイルだけであれば、苦労することはないのだけど。複数ファイルにまたがっていると変更点を探すのが面倒になる。プルリクエストは変更点を明示したり、誰が書き換えたかということも同時にわかるので便利だ。問題はプルリクエストの仕方の説明がgitコマンドを利用したものが多いということ。デスクトップの操作でマウスを使いながらであればそれほど抵抗がない人でも、コマンドラインには抵抗感がある人がいる。 一応gitの本を読んでgitコマンドも一度はやったが、Github Desktopが楽なのであとはGithub Desktopを使ている。一つのファイルの書き換えだったらGithubのサイト上で書き換えるほうが楽だが、二つ以上のファイルの場合はGithub Desktopがいいと思う。
という形になる プルリクエストの仕方を説明しているが、自分はサンドボックスにしかプルリクエストをしたことがないのであっているかが怪しかったりする。そんな私でもgithubリポジトリを管理できている。 github.com
AndroidStudioでgradleには触れていたが、動作の仕組みまでは調べてなかった。ライブラリを追加するときにimplementationに追加する程度の認識だった。 jar生成の部分ではimplementationで読み込んだライブラリをjarファイルとして全体を固めている。 ant.xmlでは配布するファイルに同梱する内容を生成している。
jar {
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
manifest {
// attributes 'Main-Class': 'AozoraEpub3'
attributes 'Main-Class': 'AozoraEpub3Applet'
}
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
}
ant.importBuild 'ant.xml'
Githubではビルド方法を指定すると、何かのアクションをもとにビルドを実行してくれるようだ。というのもこれを私は書いてないので詳しくなかったから。その後、参考情報を読んでだいたい理解したのでプルリクエストをマージした。 nightly.yml
などといったことをGithub Actionで行っている。 こういうのをCI（継続的インテグレーション）というらしい。
一日に２００回ずつ腹筋背筋腕立てを３週間していたらだいぶ筋肉がついたような気がする。ただし体重や体脂肪率が少ししか変わらないので気のせいかもしれない。主に腕やおなかを触ってみると皮下脂肪の下の筋肉が膨らんでいるきがする。筋トレの回数を増やすと、体が痛くて動きづらい感じが初めはあったが、２週間を過ぎたあたりから物足りない感じがしだしてきた。より負荷がかかるように腕立てを深くまで下げたり、背筋は高くまでとしていたがそこまで負荷として感じなくなってきた。回数を増やすかほかのメニューを増やすなどの取り組みを考える。 筋トレ以外には有酸素運動の歩いたり走ったりという運動も減量にはいいみたいだ。どうしても歩くのを増やすと膝の負担が増えるので膝が痛まないように気を付けながら運動量を調整している。ひざを痛めて休むと結果として運動量が減るのであまり意味がない気がする。
筋肉を増やすの次は体重を落とすのをやりたいが、体重が落ちると今度は体脂肪率が下がらないので難しい。 一般の体重計ではそこまで正確に体脂肪率が図れないので毎回図ってメモをするのは体重ぐらいにしている。 体重も水分をとったら体重が変わるし、起きた後は体重が減るので同じ時間に同じ状況で測るのがいいのだろう。
３月２８日発売のそのほかの本kyukyunyorituryo.github.io
３月２９日発売のそのほかの本kyukyunyorituryo.github.io
３月３０日発売のそのほかの本kyukyunyorituryo.github.io
３月３１日発売のそのほかの本kyukyunyorituryo.github.io
４月１日発売のそのほかの本kyukyunyorituryo.github.io
４月２日発売のそのほかの本kyukyunyorituryo.github.io
４月３日発売のそのほかの本kyukyunyorituryo.github.io
一日一冊を目標に本を裁断してscansnapで取り込んでいた、一冊の裁断に３０分で取り込みに１０分ぐらいで。どちらかというと裁断の方が時間がかかる。ただし失敗した時のリカバリーはスキャンのほうが時間がかかる。
scansnapサイズ固定でスキャンした問題点
本の裁断の問題点 太い本の裁断が大変、裁断機というのもあるが４万円ぐらいして場所をとる。裁断機を置く場所がない。
カッターナイフでの裁断 本を真ん中ぐらいで開いて、買ったナイフで２分割する。それでも厚みが多い場合はさらに２分割するとつづける。カッターでのりしろ以外の部分が切れるようになるまで分割して。カッターナイフで平面で切れそうな暑さになるまで分割する。 実際にやってみると手がかなりしんどい。カッターマットがずれるので体重が載せにくいので手の力だけで切ってしまう。そこで滑り止めマットをカッターマットの下に乗せることで軽減した。
本を１０冊ほどスキャンスナップで取り込んでADFのスキャン機能との違いは、両面スキャンが一度にできると本当に早い。片面の場合は並び替える動作が必要になりその手間がかかる。
ただ、フラットベッドスキャナはあった方が便利に感じる。なぜかというとどうしてもローラーで回すのに向いていないものは当然ある。厚みもバラバラで、滑りやすいものやサイズもまちまちである。
