GitHub Actionsにおける環境変数の記述法
はじめに
この記事では、「GitHub_Actionsにおける環境変数の記述法」について書いています。
GitHub Actionsで環境変数を利用しようとしたときに、状況によって書き方が微妙に違ったりしてハマったのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「GitHub Actionsにおける環境変数の記述法が知りたい」や「GitHub Actionで環境変数のエラーが発生する」な人の一助になれば嬉しいです。
要点だけ
- ワークフロー内で利用できるコンテキストという変数
${{ env.VARIABLE }}
のように書く
- 実際のコンピュータ内で利用できる環境変数
試してみる
以下のようなymlファイルを用意します。
name: Action Sample on: workflow_dispatch: env: GREETING: Hello jobs: greet_linux: runs-on: ubuntu-latest steps: - name: ${{env.GREETING}}-from-linux run: echo "$GREETING World!" greet_windows: runs-on: windows-latest steps: - name: ${{env.GREETING}}-from-windows run: echo "$env:GREETING World!"
Linux環境(runs-on: ubuntu-latest)とWindows環境(runs-on: windows-latest)でHello World!
を出力させるようなものです。
(Mac環境については、Linuxと同じ書き方で良いので省略しています)
ポイントは、それぞれのsteps:
以下で記述している箇所で、それぞれ解説していきます。
workflowファイルで参照する(name
の部分)
まずはname:
の行の部分です。Linux, Windows共に${{env.GREETING}}
という書き方で環境変数を使用しています。
このようなymlファイル上で環境変数にアクセスする場合には、${{ env.変数名 }}
という書き方で環境変数を参照します。
action実行中で参照する(run
の部分)
この部分は、Linux環境とWindows環境で書き方が変わってきます。
これはそれぞれでシェルが違う(Linux環境はbashシェル、Windows環境だとPowerShell)ためで、注意が必要です。
Linux環境の方では"$変数名
、Windows環境の方では$env:変数名
という書き方で環境変数を参照します。
おわりに
「GitHub_Actionsにおける環境変数の記述法」について解説しました。
少しややこしいですが、これを知っておくことでより見やすく、また再利用しやすいymlファイルを書くことができるかと思います。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
https://docs.github.com/ja/actions/learn-github-actions/environment-variables
https://book.st-hakky.com/docs/github-actions-environment-variable/
はてなブログでmermaidを図を表示させる
はじめに
この記事では、「はてなブログでmermaidを図を表示させる方法」について書いています。
現在mermaidの書き方を勉強しており、いくつかmermaidに関する記事を投稿したのですが、内容を見返して見ると「あれ?ちゃんと図として表示されていない」となったのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「はてなブログでmermaidを図を表示させたい」な人の一助になれば嬉しいです。
方法
正直、このリンク先の記事を読んでください、で終わります(笑)
例えば拡張機能でmermaidを表示できるようにしたVSCodeだと
```mermaid
pie
"cat" : 21
"dog" : 35
"bird" : 44
```
と書けばプレビューで表示されますが、はてなブログではこれだと表示されません。ただこのコードがそのまま表示されます。
はてなブログで表示されるようにするには以下のように書きます。
```
<div class="mermaid">
pie showdata
title 円グラフのタイトル部分
"アルファ" : 3.45
"ベータ" : 16.32
"ガンマ" : 44.10
"デルタ" : 36.13
</div>
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
<script>mermaid.initialize({startOnLoad: true});</script>
```
と、div
タグの間にmermaidのコードを記述してください。
Note
記事編集画面でのプレビューではmermaidが表示されません。確認する場合は一回記事を投稿し、実際のブログの記事の画面で見る必要があります(プレビューでも表示されるようになって欲しい)
また、例えば複数のmermaidの図を載せたい場合、<script...>の部分は1つだけでよく、
```
1つ目の図表です
<div class="mermaid">
pie
"cat" : 21
"dog" : 35
"bird" : 44
</div>
2つ目の図表です
<div class="mermaid">
pie
"alpha" : 14
"beta" : 58
"gamma" : 28
</div>
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
<script>mermaid.initialize({startOnLoad: true});</script>
```
という記述で複数のmermaid図表を表示させることができます。
おわりに
「はてなブログでmermaidを図を表示させる方法」について解説しました。
mermaidはテキストベースで簡単に図が書けるので、はてなブログでも使っていきたいと思います。
MKDocsで数式を表示するためにKaTeXを使えるようにしてみる
はじめに
この記事では、「MKDocsでKaTeXを用いて数式表示をする方法」について書いています。
MKDocsで数式も書けると使える場面が増えて便利だなと調べ、以前に紹介しました。
更に調べたところ、以前に紹介したものはMathJax
というエンジンを用いたもので、他にもKaTex
というエンジンを用いてMKDocs上で数式を書く方法もあることが分かったので導入の仕方を調べ実際に試してみた結果を記事にしてみました。
自分に向けた備忘録でもありますが、「MKDocsで数式を表示したい」や「MKDocsでKaTeXを使いたい」な人の一助になれば嬉しいです。
要点だけ
pip install markdown-katex
markdown_extensions: - markdown_katex
導入の仕方
まずはmarkdown-katex
をインストールします。
pip install markdown-katex
Note
ちなみに、インストールせずに作業を進めるとMKDocsのビルド時に以下のようなエラーが出ます。
ERROR - Config value: 'markdown_extensions'. Error: Failed to load extension 'markdown_katex'. ModuleNotFoundError: No module named 'markdown_katex' Aborted with 1 Configuration Errors!
続いてはyml
ファイルを編集していきます。次のように書いてください
site_name: My Docs theme: name: 'mkdocs' markdown_extensions: - markdown_katex
大切なのは下の二行で、ここでmarkdown_katex
を使うことを宣言しています。
これでmkdocsでkatexを使うことができるようになりました。
KaTeXでの数式の書き方
katexを書く時は
$`f(x) = e^x + x^2`$
や
```math
f(x) = e^x + x^2
```
のように書きます。逆に以下の書き方では数式と認識されないため数式の描画はされません(MathJaxとは書き方が少し違います。)
$$
f(x) = e^x + x^2
$$
さて、では実際にMKDocsでの表示のされ方を見てみましょう
Formula
の節の部分が数式で書いたものです。上で紹介された順番で書いています。
良い感じで数式が表示されてますね。
おわりに
「MKDocsでKaTeXを用いて数式表示をする方法」について解説しました。
数式も書けるようになると、更にMKDocsで書ける文書の幅が広がり、便利に使えるかと思います。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
リカーリング(ビジネス)の概要
はじめに
この記事では、「リカーリング(ビジネス)の概要」について書いています。
自分に向けた備忘録でもありますが、「リカーリング(ビジネス)がどんなものなのか知りたい」な人の一助になれば嬉しいです。
リカーリングビジネスとは何か
- リカーリング(Recurring)とは、英語で「繰り返される」「循環する」の意味。
- 継続的に提供するサービス契約から収益を得るビジネスモデル。
- リカーリングの種類は2つに大別できる。
- 消耗品販売: 商品を販売した後にそれを使い続けていくうえで継続的に必要となる消耗品を別売りで購入してもらう販売スタイル。プリンターのインクカートリッジなど。
- 月額課金: 一定額の基本料金を課金したうえで、利用料に応じた料金を従量制で課金するもの。電気代、ガス代、水道代、インターネット接続料金など。
他のビジネスモデル(収益モデル)との違い
売り切り型との違い
- 売り切り型は継続性がなく、一度商品やサービスを提供したらそれで終わり。
- リカーリングビジネスは継続的に価値を提供し、収益を得る。
- 売り切り型に対して「利用者がいる限り収益が続く」ことが大きなメリット。
- 顧客満足度が低いと顧客がすぐに解約・退会してしまい収益に繋がらないので、絶えず顧客の声を聞いて改善し続けないといけない。
サブスクリプションとの違い
- 有名なサブスクリプションとしてはApple Music、Spotify、Netflix、Hulu等がある。
- サブスクリプションは、期間の料金が定額に設定されている。
- 対してリカーリングビジネスは従量課金(期間の使用量に合わせて料金が変わる)も含まれる。
- サブスクリプションはリカーリングビジネスに含まれるビジネスモデルとも言える。
リカーリングビジネスで収益を獲得した例
ジレット(Gillette)社
ソニー(Sony)
- 日本を代表する企業
- 「プレイステーション4」では、従来のようにゲーム機本体とゲームソフトを販売するだけでなく、特定のゲームタイトルの遊び放題やオンラインマルチプレイなどの特典を含む有料会員サービスを導入し収益を獲得している。
おわりに
「リカーリング(ビジネス)の概要」について解説しました。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
リーンソフトウェア開発と7つの原則
はじめに
この記事では、「リーンソフトウェア開発と7つの原則」について書いています。
より良いソフトウェア開発が出来るよう開発手法について学んでいるのですが、その中で「リーンソフトウェア開発」という言葉が目に留まり学んでみたいとなったのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「リーンソフトウェア開発とは何かを知りたい」な人の一助になれば嬉しいです。
リーンソフトウェア開発とは何か
- トヨタ生産方式(TPS)を参考に考案された開発手法のひとつです。
- トヨタ生産方式 -> リーン生産方式 -> リーンソフトウェア開発
- 徹底してムダを減らし、必要とするプロダクトを素早く、そして効率的に開発することを目指します。
- リーン(lean)とは、「脂肪やぜい肉がない」「均整のとれた」といった意味があります。
- そこから「無駄がない」「無駄をなくす」という意味で使われるようになった。
リーンソフトウェア開発の原則
- ムダをなくす
- ムダとは、顧客に価値を提供しないもの、および顧客が必要としていないものを指す
- ソフトウェア開発におけるムダの例は以下のとおり
- 未完成の作業(仕掛かり)
- 使われないコードや余分な機能
- 余分なプロセス
- 作業の引き継ぎ
- 作業の切り替え
- 開発の遅れ
- 欠陥(バグなど)
- 顧客に価値を提供しない「ムダ」を徹底して無くしていく
- 知識を作り出す
- 不確実性の高いプロジェクトでは道中で学び知識を生み出すことが重要になってくる
- 個人だけでなく、チーム・組織として学習をしていくことが重要
- 品質を作りこむ
- 不具合は発見が遅れるほど、修正するコストが増大していく
- 不良を後工程へ流さないようにすることでコストを抑える
- 決定を遅らせる
- 市場は変化が速く、決定した時点からもどんどんと市場は変化していく
- 市場の変化に対応するためにはギリギリまで決定を遅らせた方が良い
- ギリギリまで遅らせた方がより多くの情報が得やすい
- 決定が遅らせられるような仕組み(変更に柔軟なシステム、体制)を作ることが重要
- 早く提供する
- 価値あるものを作りためには顧客からのフィードバックが欠かせない
- 製品を作り終わってからフィードバックをもらうのでは本当に価値あるものを作るのは難しい
- 早く提供し、そして早く顧客からフィードバックをもらうことが重要
- 権限を与える
- 情報を一番持っている現場の人たちに権限を与えることが重要
- そうすることでソフトウェアの設計が良くなる効果が見込める
- 全体を最適化する
- 開発の最終目標をソフトウェアの完成ではなく価値を生むこと
- 局所最適ではなく全体でのパフォーマンスを重視する
所感
- DevOpsもリーン生産の原理をソフトウェア開発に応用したものなので、リーンソフトウェア開発とDevOpsはかなり近いものかなと感じた。
- どれも「なるほど」と思わせるものが多かったです。
おわりに
「リーンソフトウェア開発と7つの原則」について解説しました。
リーンソフトウェア開発の知恵を自分のソフト開発にも取り入れ、更に良いソフトウェア開発が出来るようになりたいです
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
https://tracpath.com/works/development/lean_software_development/
https://ssaits.jp/promapedia/method/lean-software-development.html
http://www.e-ainet.com/LeanSoftwareDevelopmentPrinciples.html
Rustのspecial-module-nameに関するエラー
はじめに
この記事では、「Rustのclippyで指摘されたfound module declaration for lib.rs
」について書いています。
Rustでプログラムを書いていた時clippyで指摘され、(もしかしたら「こんなの当然だよ」というレベルの話かもしれず恥ずかしくもあるのですが)その原因を調べたのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「同じような指摘を受け、理由が分からない」な人の一助になれば嬉しいです。
ワーニングが出た条件
環境は以下の通りです。
- OS: Windows 10
- Rust: 1.65.0
Rustのプロジェクトは以下の通りです。
sample ├ src │ ├ main.rs │ └ lib.rs └ Cargo.toml
各コードについては、main.rsは
mod lib; fn main() { lib::greet(); }
lib.rsは
pub fn greet() { println!("Hello, world!"); }
です。
ライブラリのgreet()を呼んでHello, world!
を出力するという簡単な処理のプログラムです。
ワーニングの内容
このプロジェクトについてcargo clippy
を行うと最初にも書いたワーニング文が出てきます。
より詳細には以下のような出力です。
warning: found module declaration for lib.rs --> src\main.rs:1:1 | 1 | mod lib; | ^^^^^^^^ | = note: `#[warn(special_module_name)]` on by default = note: lib.rs is the root of this crate's library target = help: to refer to it from other targets, use the library's name as the path
どうもライブラリのファイル名をlib.rsにしてることに対して怒られているようです。
更に色々調べると以下のページに答えがありました。
https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#special-module-name
Explanation Cargo recognizes lib.rs and main.rs as the root of a library or binary crate, so declaring > them as modules will lead to miscompilation of the crate unless configured explicitly.
To access a library from a binary target within the same crate, use your_crate_name:: as the path path instead of lib:::
つまり、lib.rs
はクレートのルートとして認識する特別なものだから、これを使う場合、mod lib
のようにモジュールとして宣言すると、ミスコンパイルにつながる可能性があるから、という理由でワーニングになっているようです。
対応
案: クレートの名前を使って呼び出す
以下のようにクレートの名前を使えばワーニングは解消されます。
fn main() { // lib::greet(); // ワーニングが出る sample::greet(); }
案: ライブラリの名前をlib.rs
から変える
lib.rs
という名前なのが問題なので、違う名前に変えることでワーニングを解消できます。
おわりに
「Rustのclippyで指摘されたfound module declaration for lib.rs
」について解説しました。
main.rs
やlib.rs
はRustでは特別な意味を持つ名前なので、安易に使うと思わぬワーニングが起きてしまうみたいなので今後は気を付けようと思います。
Rustのtui-rsライブラリに入門してみた
はじめに
この記事では、「Rustのtui-rsライブラリの導入の仕方」について書いています。
Rustを色々勉強しており、色々なクレート(ライブラリ)を触ってみているので記事を書いてみました。
自分に向けた備忘録でもありますが、「Rustのtui-rsライブラリって何?」や「ちょっと触ってみたい」な人の一助になれば嬉しいです。
前提(環境)
以下の環境、フォルダ構成で実験をしていきます。
- OS: Windows 10
- Rust: 1.64.0
そもそもtuiとは何か
tui(TUI)とは Text User Interfaceの略で、テキストベースのユーザーインターフェースのことです。
CUIとGUIの中間のような感じで、CUIのようにコマンドラインからコマンドを打ち込むではないですが、GUIのように動画や画像、音声データを結びつけたりすることもできません。
TUIは一般的なテキスト端末で表示できる記号や文字だけで画面を構成されています。
tui-rsとは
tui-rsはRustでTUIを簡単に作ったり扱うことのできるライブラリです。
導入して実際に動かしてみるまで
tui-rsのドキュメントに導入の仕方があるので、それに沿って書いていきます。
まずはCargo.toml
に依存関係を追加します。
...(略)... [dependencies] tui = "0.19" crossterm = "0.25"
ここではバックエンドにcrossterm
を選んでいますが、termion
や他のものにすることも可能のようです。(ここではその話はせずcrossterm
で進めていきます)
次に、main.rs
にコードを書いていきましょう
use std::{io, thread, time::Duration}; use tui::{ backend::CrosstermBackend, widgets::{Widget, Block, Borders}, layout::{Layout, Constraint, Direction}, Terminal }; use crossterm::{ event::{self, DisableMouseCapture, EnableMouseCapture, Event, KeyCode}, execute, terminal::{disable_raw_mode, enable_raw_mode, EnterAlternateScreen, LeaveAlternateScreen}, }; fn main() -> Result<(), io::Error> { // setup terminal enable_raw_mode()?; let mut stdout = io::stdout(); execute!(stdout, EnterAlternateScreen, EnableMouseCapture)?; let backend = CrosstermBackend::new(stdout); let mut terminal = Terminal::new(backend)?; terminal.draw(|f| { let size = f.size(); let block = Block::default() .title("Block") .borders(Borders::ALL); f.render_widget(block, size); })?; thread::sleep(Duration::from_millis(5000)); // restore terminal disable_raw_mode()?; execute!( terminal.backend_mut(), LeaveAlternateScreen, DisableMouseCapture )?; terminal.show_cursor()?; Ok(()) }
これも公式のドキュメントのままです。ターミナルに描画して5秒ほど待って終了するという内容のコードです。
これでcargo run
で実行させてみましょう
非常に寂しい感じですが(笑)、無事表示することが出来ました。
おわりに
「Rustのtui-rsライブラリの導入の仕方」について解説しました。
ターミナル操作系のライブラリはtui-rs以外のものも色々あるそうなので他のものも使ってみていきたいと思います。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。