こんにちは。開発担当のマットです。
実は、私が旗オタクです。なぜかわかりませんが、小さい時から国旗のことを気に入って、家にいくつかの旗を飾っています。

ところで、AIに頼んだら各国の旗をなんとか面白く再構想できるではないかと思いまして…
この記事でやりたいと思います！

国旗を作るには

国の旗は国民を象徴するものです。要素を適当に選んではいけませんね。
どの国でも、国民が好む色やシンボルがあるかと思いますので、まずはその情報をAIに尋ねてみます。

なんとなくですが、日本語で質問をすると、各国のデータにちょっとした偏見が出ると思いますので、英語で質問をすることにしました。
なお、ChatGPT がかなり長い文面を返すことが多いので、短めな 10 ワード以内な回答をお願いしてみました。

日本の場合、赤, 白, 黒が一番人気だそうです。
黒はちょっと想定外ですが・・・赤と白は確かにそういう気がしますね。
（日の丸だけではなく、日本に「紅白」のテーマなものが多いですね。）

そして、日本を象徴するシンボルが 桜、富士山、鯉 のようです。
これは確かに命中していると思いますね。

この情報を使って、画像生成 AI に旗作りを頼みました。
今回、使わせていただきましたのは Craiyon という 画像生成 AI です。

A flag design in the colors Red, White, Black with the symbols of Cherry Blossom (Sakura), Mount Fuji, Koi Fish.

のプロンプトを使って、生成してみたら、以下の9枚の画像が生成されました。

その中から「旗っぽい」ものを選んで、旗っぽい比率で切り取ったら…

確かに・・・日本らしい国旗を作れました (笑)。

他にも・・・

せっかくなので、他の国も作ってみました〜
全部、以下に並べますが、どの旗はどの国か、当ててみてください。

全部わかりましたでしょうか？
いくつかわかりにくいものもあるかと思いますが、その国のイメージ通りなものもありますね。

まとめ

最近、AI の画像生成も、AIの会話も急激に進化してきています。
この新しいツールで、色んな人が色んなことができるようになりました。

数年前だったら、このような画像をつくることは絶対にできませんでしたけど、今は楽に、何十枚も簡単に生成することはできます。

世界の皆さんが、この新しい AI で、何を作るかを楽しみにしています。

Markdown のドキュメントをコマンドラインで読みたいことがあります。
自分で書いているときはエディタのプレビューやブラウザの拡張を使えば良いのですが、たとえば github のプロジェクトを clone してきて README.md を読むような場合にはコマンドでさっと読める手段があると便利です。

初め markdown2html とか md2html みたいな名前で探したのですが、Debian パッケージとしては見つからず。結局のところ、markdown というそのまんまの名前のパッケージが見つかりました。

sudo apt install markdown

使い方は簡単で、ファイル名を指定してコマンドを起動すると標準出力にHTMLが出力されます。パイプで繋いでやればテキストブラウザで表示できます。

markdown README.md | lynx -stdin

以下の画像は Solr の s3-repository モジュールに付属の README.md を markdown で変換してから lynx で表示したものです。

こんな感じでさくっと閲覧できます。

入社してから1年の間にコードレビューで、たくさんのありがたいご指摘(アドバイス)を受けてきました。
その中で実際にいただいたレビューから、今でもレビュー依頼する前に確認していることについてまとめてみたいと思います。

余計なスペース、インデントが入ってないか

入社直後のときはあまり気にしてなかったため数多くご指摘いただきました。
余計な空白や改行が入ることで、予期せずコードの動作が変わることはまれだと思いますが、Gitで不要な差分が追加されたりコードのフォーマットがバラバラになったりするので、不要な変更は削除したほうがいいです。

VSCodeでは、以下のプラグインを導入することでスペースが一目でわかるようになり、便利です。

https://marketplace.visualstudio.com/items?itemName=ybaumes.highlight-trailing-white-spaces

分かりやすい変数名、関数名を意識する

変数名、関数名には何の処理をしているか一目で分かりやすい名前をつけると別の開発者や未来の自分が見た時にそのコードの意味や目的をすぐに理解することができるので大切です。

とはいえ、ちょうどいい変数名や関数名が思いつかない…といったことが多々ありますが、最近では、ChatGPTに名前の提案を求めることもできるので非常に助かっています。

既存の共通処理を利用しているか

既存の共通処理があるにも関わらず、同じ内容の処理を重複して書いてしまい、それに関して指摘を受けたことがあります。

将来、仕様が変わった際に改修が必要となると、修正の漏れが生じるリスクが増えます。共通処理が存在する場合、その処理を再利用するか、共通のロジックとして新たに切り出すことが重要です。

その他

• 処理が複雑な箇所はコメントを残しているか
• マジックナンバーが使われてないか
• 既存のユーザーや機能に対する影響がないか
• 不要なコメント、デバッグコードを残してないか
• 既存の処理より大幅にクエリの発行回数が増えてないか

まとめ

以上が、これまでいただいたレビューから確認するようになったポイントです。

レビュー時に学んだことを活かして同じ指摘を受けないようにすること、そしてケアレスミスをしないよう注意することでレビュアーの負担を軽減し、コードの品質向上に繋がると思うので今後も意識したいと思います。