GitHub Actionsにおける環境変数の記述法

はじめに

この記事では、「GitHub_Actionsにおける環境変数の記述法」について書いています。

GitHub Actionsで環境変数を利用しようとしたときに、状況によって書き方が微妙に違ったりしてハマったのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「GitHub Actionsにおける環境変数の記述法が知りたい」や「GitHub Actionで環境変数のエラーが発生する」な人の一助になれば嬉しいです。

要点だけ

  • ワークフロー内で利用できるコンテキストという変数
    • ${{ env.VARIABLE }}のように書く
  • 実際のコンピュータ内で利用できる環境変数
    • Windows
      • $VARIABLEのように書く
    • Ubuntu, Mac-OS
      • $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を図を表示させたい」な人の一助になれば嬉しいです。

方法

正直、このリンク先の記事を読んでください、で終わります(笑)

cartman0.hatenablog.com

例えば拡張機能で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で書ける文書の幅が広がり、便利に使えるかと思います。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

qiita.com

リカーリング(ビジネス)の概要

はじめに

この記事では、「リカーリング(ビジネス)の概要」について書いています。

自分に向けた備忘録でもありますが、「リカーリング(ビジネス)がどんなものなのか知りたい」な人の一助になれば嬉しいです。

カーリングビジネスとは何か

  • カーリング(Recurring)とは、英語で「繰り返される」「循環する」の意味。
  • 継続的に提供するサービス契約から収益を得るビジネスモデル。
  • カーリングの種類は2つに大別できる。
    • 消耗品販売: 商品を販売した後にそれを使い続けていくうえで継続的に必要となる消耗品を別売りで購入してもらう販売スタイル。プリンターのインクカートリッジなど。
    • 月額課金: 一定額の基本料金を課金したうえで、利用料に応じた料金を従量制で課金するもの。電気代、ガス代、水道代、インターネット接続料金など。

他のビジネスモデル(収益モデル)との違い

売り切り型との違い

  • 売り切り型は継続性がなく、一度商品やサービスを提供したらそれで終わり。
  • カーリングビジネスは継続的に価値を提供し、収益を得る。
  • 売り切り型に対して「利用者がいる限り収益が続く」ことが大きなメリット。
  • 顧客満足度が低いと顧客がすぐに解約・退会してしまい収益に繋がらないので、絶えず顧客の声を聞いて改善し続けないといけない。

サブスクリプションとの違い

カーリングビジネスで収益を獲得した例

ジレットGillette)社

  • カーリングの先駆けと言われているアメリカの剃刀メーカー。
  • 剃刀本体を無料でユーザーに配布し、代わりに利益率の高い替刃を継続的に購入してもらうことで安定した収益を獲得している。

ソニーSony

  • 日本を代表する企業
  • プレイステーション4」では、従来のようにゲーム機本体とゲームソフトを販売するだけでなく、特定のゲームタイトルの遊び放題やオンラインマルチプレイなどの特典を含む有料会員サービスを導入し収益を獲得している。

おわりに

「リカーリング(ビジネス)の概要」について解説しました。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

www.veritrans.co.jp

www.robotpayment.co.jp

リーンソフトウェア開発と7つの原則

はじめに

この記事では、「リーンソフトウェア開発と7つの原則」について書いています。

より良いソフトウェア開発が出来るよう開発手法について学んでいるのですが、その中で「リーンソフトウェア開発」という言葉が目に留まり学んでみたいとなったのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「リーンソフトウェア開発とは何かを知りたい」な人の一助になれば嬉しいです。

リーンソフトウェア開発とは何か

  • トヨタ生産方式(TPS)を参考に考案された開発手法のひとつです。
  • 徹底してムダを減らし、必要とするプロダクトを素早く、そして効率的に開発することを目指します。
  • リーン(lean)とは、「脂肪やぜい肉がない」「均整のとれた」といった意味があります。
    • そこから「無駄がない」「無駄をなくす」という意味で使われるようになった。

リーンソフトウェア開発の原則

  1. ムダをなくす
    • ムダとは、顧客に価値を提供しないもの、および顧客が必要としていないものを指す
    • ソフトウェア開発におけるムダの例は以下のとおり
      • 未完成の作業(仕掛かり)
      • 使われないコードや余分な機能
      • 余分なプロセス
      • 作業の引き継ぎ
      • 作業の切り替え
      • 開発の遅れ
      • 欠陥(バグなど)
    • 顧客に価値を提供しない「ムダ」を徹底して無くしていく
  2. 知識を作り出す
    • 不確実性の高いプロジェクトでは道中で学び知識を生み出すことが重要になってくる
    • 個人だけでなく、チーム・組織として学習をしていくことが重要
  3. 品質を作りこむ
    • 不具合は発見が遅れるほど、修正するコストが増大していく
    • 不良を後工程へ流さないようにすることでコストを抑える
  4. 決定を遅らせる
    • 市場は変化が速く、決定した時点からもどんどんと市場は変化していく
    • 市場の変化に対応するためにはギリギリまで決定を遅らせた方が良い
      • ギリギリまで遅らせた方がより多くの情報が得やすい
    • 決定が遅らせられるような仕組み(変更に柔軟なシステム、体制)を作ることが重要
  5. 早く提供する
    • 価値あるものを作りためには顧客からのフィードバックが欠かせない
    • 製品を作り終わってからフィードバックをもらうのでは本当に価値あるものを作るのは難しい
    • 早く提供し、そして早く顧客からフィードバックをもらうことが重要
  6. 権限を与える
    • 情報を一番持っている現場の人たちに権限を与えることが重要
    • そうすることでソフトウェアの設計が良くなる効果が見込める
  7. 全体を最適化する
    • 開発の最終目標をソフトウェアの完成ではなく価値を生むこと
    • 局所最適ではなく全体でのパフォーマンスを重視する

所感

  • DevOpsもリーン生産の原理をソフトウェア開発に応用したものなので、リーンソフトウェア開発とDevOpsはかなり近いものかなと感じた。
  • どれも「なるほど」と思わせるものが多かったです。

おわりに

「リーンソフトウェア開発と7つの原則」について解説しました。

リーンソフトウェア開発の知恵を自分のソフト開発にも取り入れ、更に良いソフトウェア開発が出来るようになりたいです

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

https://tracpath.com/works/development/lean_software_development/

https://ssaits.jp/promapedia/method/lean-software-development.html

https://codelab.website/lean/

http://www.e-ainet.com/LeanSoftwareDevelopmentPrinciples.html

Rustのspecial-module-nameに関するエラー

はじめに

この記事では、「Rustのclippyで指摘されたfound module declaration for lib.rs」について書いています。

Rustでプログラムを書いていた時clippyで指摘され、(もしかしたら「こんなの当然だよ」というレベルの話かもしれず恥ずかしくもあるのですが)その原因を調べたのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「同じような指摘を受け、理由が分からない」な人の一助になれば嬉しいです。

ワーニングが出た条件

環境は以下の通りです。

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.rslib.rsはRustでは特別な意味を持つ名前なので、安易に使うと思わぬワーニングが起きてしまうみたいなので今後は気を付けようと思います。

Rustのtui-rsライブラリに入門してみた

はじめに

この記事では、「Rustのtui-rsライブラリの導入の仕方」について書いています。

Rustを色々勉強しており、色々なクレート(ライブラリ)を触ってみているので記事を書いてみました。

自分に向けた備忘録でもありますが、「Rustのtui-rsライブラリって何?」や「ちょっと触ってみたい」な人の一助になれば嬉しいです。

前提(環境)

以下の環境、フォルダ構成で実験をしていきます。

そもそもtuiとは何か

tui(TUI)とは Text User Interfaceの略で、テキストベースのユーザーインターフェースのことです。

CUIGUIの中間のような感じで、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以外のものも色々あるそうなので他のものも使ってみていきたいと思います。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

docs.rs

blog.fascode.net