Xorshift32をRustで実装してみる
Xorshift32をRustで実装してみる
今回は、Rustで色々コード書いてみる一環として、疑似乱数生成法の1つであるXorshiftを実装してみたいと思います。
実装してみるのは32bitのXorshift（下のページのxorshift32）です。
https://ja.wikipedia.org/wiki/Xorshift
まずはC言語でこのコードを動かし、得られた数値を基にRustでテストを書きます。
#include <stdio.h> #include <stdint.h> struct xorshift32_state { uint32_t a; }; uint32_t xorshift32(struct xorshift32_state *state) { uint32_t x = state->a; x ^= x << 13; x ^= x >> 17; x ^= x << 5; return state->a = x; } void main() { struct xorshift32_state st = {1}; for (int i = 0; i < 10; i++) { printf("%u\n", xorshift32(&st)); } }
このコードを実行して得られる出力は以下の通りです。
270369 67634689 2647435461 307599695 2398689233 745495504 632435482 435756210 2005365029 2916098932
これで、xorshiftを実装した時の正しい値が分かりました。
では次にRustで実装を行います。
まずテストの部分です。
#[cfg(test)] mod tests { use super::*; #[test] fn test_xorshift32() { let mut rng = Xorshift32::new(1); let expected: [u32; 5] = [270369, 67634689, 2647435461, 307599695, 2398689233]; for e in expected.iter() { assert_eq!(e, &rng.next()); } } }
10個出力しましたが、まぁ5個も確認して合っていれば十分かな、ということで先頭から5個の値をテストします。
では実際のXorshiftの実装をしていきます。以下のような感じで書きました。
pub struct Xorshift32 { state: u32, } impl Xorshift32 { pub fn new(seed: u32) -> Xorshift32 { Xorshift32 { state: seed } } pub fn next(&mut self) -> u32 { let mut x: u32 = self.state; x ^= x << 13; x ^= x >> 17; x ^= x << 5; self.state = x; self.state } }
特に移植で難しい部分もなく書き移せました。では最後にcargo testで確認します。
running 1 test test tests::test_xorshift32 ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
無事テストが通ったということで、XorshiftをRustで実装することができました。
めでたしめでたし、ということで今回はここまでです。
Pythonのpytestで-kオプションを試してみる
はじめに
この記事では、「Pythonにあるpytestの-kオプションに関する概要と実際の簡単な使い方」について書いています。
要点だけ
- 指定した文字列で検索して、テスト実行する
pytest -k "xxx"と、""の間に文字列を記述する- 「特定のテストだけ実施したい」場合に便利な機能
実際に試してみる
Note
試した際の環境は以下の通りです。
実験で使うフォルダ（ファイル）は以下の通りです。
sample ├ test_add.py └ test_sub.py
test_add.pyの中身は以下のようになっています。
def test_add1(): assert 2 == 1 + 2 def test_add2(): assert 4 == 1 + 3
test_add1()は、テストに失敗するようにしている点にご注意ください
また、test_sub.pyの中身は以下のようになっています。
def test_sub1(): assert 1 == 2 - 1 def test_sub2(): assert 2 == 3 - 1
この状態で、まずはpytestした際の出力結果を見てみましょう
================================================= test session starts =================================================
platform win32 -- Python 3.9.4, pytest-7.1.3, pluggy-1.0.0
rootdir: C:\Users\xxx\sample
plugins: anyio-3.6.1
collected 4 items
test_add.py F. [ 50%]
test_sub.py .. [100%]
====================================================== FAILURES =======================================================
______________________________________________________ test_add1 ______________________________________________________
def test_add1():
> assert 2 == 1 + 2
E assert 2 == (1 + 2)
test_add.py:2: AssertionError
=============================================== short test summary info ===============================================
FAILED test_add.py::test_add1 - assert 2 == (1 + 2)
============================================= 1 failed, 3 passed in 0.23s =============================================
4つあるテスト全てが実施され、1つが失敗、3つが成功したと書かれています。
では次に-kオプションを使い、一部のテストだけ実施してみましょう。
例えば、pytest -k "2"として、関数に"2"とつくテストだけ（つまり、test_add.pyのtest_add2()とtest_sub.pyのtest_sub2()の２つを行う）やってみるようにしてみましょう。
以下のような出力が得られます。
================================================= test session starts ================================================= platform win32 -- Python 3.9.4, pytest-7.1.3, pluggy-1.0.0 rootdir: C:\Users\xxx\sample plugins: anyio-3.6.1 collected 4 items / 2 deselected / 2 selected test_add.py . [ 50%] test_sub.py . [100%] =========================================== 2 passed, 2 deselected in 0.04s ===========================================
pytestだけの時と違い、2つだけテストが実施されています。が、これでは何のテストが実施されているか分かりませんので、pytest -k "2" --collect-onlyとし、テストされる関数を確認してみます。
================================================= test session starts ================================================= platform win32 -- Python 3.9.4, pytest-7.1.3, pluggy-1.0.0 rootdir: C:\Users\xxx\sample plugins: anyio-3.6.1 collected 4 items / 2 deselected / 2 selected <Module test_add.py> <Function test_add2> <Module test_sub.py> <Function test_sub2> ===================================== 2/4 tests collected (2 deselected) in 0.03s =====================================
期待していたtest_add2()のtest_sub2()だけテストされていることが分かりました。
おわりに
「Pythonにあるpytestの-kオプションに関する概要と実際の簡単な使い方」について解説しました。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
MkDocsで脚注を付けてみる
はじめに
この記事では、「MkDocsで脚注を付ける方法」について書いています。
MkDocsでドキュメントを書くことが最近多いのですが、その使い方を色々調べる中で「知ってたら便利そう」な小ネタを知ったのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「MkDocsで注釈を付けたい、その方法が知りたい」な人の一助になれば嬉しいです。
注釈の付け方
mkdocs.ymlに以下の記述を加えます。
markdown_extensions: - footnotes
下に簡単な例を出すとこんな感じになります。
site_name: My Docs theme: name: 'mkdocs' markdown_extensions: - footnotes
また、markdownで注釈は以下のように書きます。
...(省略)... ## Test これ[^1] は注釈のテストです。 [^1]: ここに注釈の内容が記されます。 ...(省略)...
実際にMkDocsをビルドすると以下のように表示されます。
「Test」の項の部分が注釈を付けた箇所になりますが、「これ」の右上に注釈の番号が書かれ、またドキュメントの下に注釈の内容が書かれていることが分かるかと思います。
おわりに
「MkDocsで脚注を付ける方法」について解説しました。
ちょっとした小ネタですが、知っておくと便利かもしれません。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
継続的デリバリとその原則について調べてみた
はじめに
この記事では、「継続的デリバリの概要」について書いています。
自分に向けた備忘録でもありますが、「継続的デリバリとは何か知りたい」な人の一助になれば嬉しいです。
継続的デリバリとは何か
- ソフトウェア開発手法の1つ
- 開発や修正といった様々な変更を安全、迅速、そして持続可能な形で本番環境に組み込んだりユーザーに提供する仕組み、もしくはそれを実現するための手法の集まり
継続的デリバリの原則
- 自動化に投資する
- 繰り返し行う作業は全て自動化し、人間は問題解決にあたる
- 特に、繰り返し行い高い信頼性が必要なリリース（デプロイ）プロセスの自動化には本気で投資する
- そうすることが信頼性につながる
- 品質を作りこむ
- 品質メトリクスは絶対ではないかもしれないが、ある方がない方よりもマシ
- 品質メトリクス: 複雑度、カバレッジ、コーディングスタイルなど
- 品質メトリクスは絶対ではないかもしれないが、ある方がない方よりもマシ
- 徹底した改善努力を継続的に行う
- 「改善」を各メンバーの日常業務の一つにする
- 全員がリリースプロセスに対して責任を持つ
- 開発者のノートPC上だけで動作するソフトウェアはなんのお金も産まない。
- リリースすることで開発したものははじめて価値を持つ
- だからリリースプロセスは社内全ての人が責任と関心を持たなければいけない
- 開発者は、作ったものがどのようにデプロイされるかを意識して開発に取り組まなければならない。
- マネージャはデプロイメントに注意を払ってプロジェクトの計画をたてなければならない。
- テスターはコードの問題と同じ位デプロイメントに関する問題についてテストすべきである。
おわりに
「継続的デリバリの概要」について解説しました。
ソフトウェア開発の中でよく聞かれるようになった言葉の一つですので、覚えておくと何かの約に立つかもしれません
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
業務改善提案ネタの探し方
はじめに
この記事では、「業務改善提案ネタの探し方」について書いています。
私事ですが最近自分の会社で改善提案を強く求められるようになったので、改善提案はどのように行えばいいのかを調べてみようと思ったのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「業務の改善提案のやり方が知りたい」な人の一助になれば嬉しいです。
改善提案ネタの探し方
過去の事例や他社の事例から見つける
過去や他社の事例を見てみることは改善提案のネタを作るきっかけになりえます。
「ここは自分の業務に応用できる」、「ここを変えれば良さそう」などがあるかもしれません。
また、それらは既に結果が出ているため、効果の測定の仕方や導入プロセスなど実施する上で参考できることが多いのも嬉しいポイントです。
テーマ（範囲）を絞る
改善提案が思いつかないのは、「何かを改善しよう」と漠然としているからかもしれません。
例えば「業務の〇〇の部分で改善ネタを探してみよう」など範囲を限定することでよりイメージが具体的になり、ネタが探しやすくなります。
ちょっとした不満を見逃さない
業務をしていると「この作業嫌い」「めんどうくさい」と思うことがあるかと思います。
そういう所に改善のポイントがあるので、そういうちょっとした不満はメモに残し、どう改善できるか考えるクセを付けるとよいかもしれません。
業務を可視化してみる
業務を可視化する（例えば作業手順をフローチャートとして書く、など）のも改善提案ネタを見つけるための方法の一つです。
図などで見えるようにすることで「ここはムダなのでは？」と気づくことも多いです。
おわりに
「業務改善提案ネタの探し方」について解説しました。
この方法は改善提案だけでなく、例えば開発に応用すれば特許提案、開発テーマ創出にもつながると思いますので是非試してみてください
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
https://kaizen-penguin.com/kaizen-suggestion-4047/
スタンダップミーティングについて調べてみた
はじめに
この記事では、「スタンダップミーティングとは何か」について書いています。
スタンダップミーティングとは
- 主にアジャイル開発やスクラム開発で用いられる、短い会議のこと
- 主に朝に短い時間立ったままで行われることが多い
- デイリースクラムと呼ばれることもある
- 日本では「朝会」や「たちっぱ」と呼ぶこともある
- 主に以下の３つの内容を報告する
- 昨日何をやったこと
- 今日やろうとしている事
- 障害となっていること
スタンダップミーティングのメリット
- メンバーの進捗が分かる
- メンバー間のコミュニケーションの改善に役に立つ
- 課題を早期に共有することができる
スタンダップミーティングで気を付けること
- 手短に行う
- 15分以内で行うのが好ましい
- メンバーが全員参加できるようにする
- 全てのメンバーで情報を共有することが重要
- 問題解決をその場で行わない
- 問題解決はスタンダップミーティングの後で出来る
- 問題解決まで行おうとすると時間が長くなってしまう
おわりに
「スタンダップミーティングについて調べてみた」について解説しました。
ここまで読んで下さりありがとうございます。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
https://blogs.itmedia.co.jp/hiranabe/2012/02/daily-scrum-or-standup-meeting.html
https://asana.com/ja/resources/stand-up-meeting
https://bliki-ja.github.io/ItsNotJustStandingUp/#tocAnchor-1-3
MKDocsで絵文字を使ってみる
はじめに
この記事では、「MKDocsで絵文字を使う方法」について書いています。
MKDocsはmarkdownからWebサイトのような構成のドキュメントを作ることができる非常に便利なツールです。
このMKDocsで絵文字を使うことができないのかなぁとなったのが記事を書いたきっかけでした。
自分に向けた備忘録でもありますが、「MKDocsで絵文字を使いたい」な人の一助になれば嬉しいです。
実際に試してみる
MKDocsで絵文字を使用する場合は、mkdocs.ymlに絵文字を使うために以下の設定を追加します。
markdown_extensions: - pymdownx.emoji: emoji_generator: !!python/name:pymdownx.emoji.to_alt
例えば以下のように書きます。
site_name: My Docs theme: name: 'mkdocs' markdown_extensions: - pymdownx.emoji: emoji_generator: !!python/name:pymdownx.emoji.to_alt
この設定で実際にMKDocsで絵文字が表示されるのか確認してみましょう。
index.mdに絵文字を表示するために以下の記述を追加します。
## Test :smile:
:smile:が絵文字を表示するためのコードです。
さて、これで実際に表示させてみた結果が下の画像になります。
Testの項の部分に絵文字が表示されています。
おわりに
「MKDocsで絵文字を使う方法」について解説しました。
MKDocsはドキュメントを作るツールとしてとても便利ですので、是非使い方を覚えて活用してみてはいかがでしょうか。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
