PDFファイルをImageMagickで画像に変換します。
ポイントは解像度指定です。
拡張子はPNG以外でも問題ありません。
$ convert -density 350 -units PixelsPerInch origin.pdf converted.pngdensity により解像度の指定が可能です。
ここでは350を指定していますが、600や1200を指定するとその値になります。
ネット上には画像への変換ツールも数多くありますが、内容によっては利用が憚られることもあるかと思います。
高解像度画像への変換もお手軽に。
こんにちは。開発担当のマットです。
実は、私が旗オタクです。なぜかわかりませんが、小さい時から国旗のことを気に入って、家にいくつかの旗を飾っています。
ところで、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に名前の提案を求めることもできるので非常に助かっています。
既存の共通処理があるにも関わらず、同じ内容の処理を重複して書いてしまい、それに関して指摘を受けたことがあります。
将来、仕様が変わった際に改修が必要となると、修正の漏れが生じるリスクが増えます。共通処理が存在する場合、その処理を再利用するか、共通のロジックとして新たに切り出すことが重要です。
以上が、これまでいただいたレビューから確認するようになったポイントです。
レビュー時に学んだことを活かして同じ指摘を受けないようにすること、そしてケアレスミスをしないよう注意することでレビュアーの負担を軽減し、コードの品質向上に繋がると思うので今後も意識したいと思います。
Solr 9.3 から従来と同じ solr-9.3.0.tgz の他に solr-9.3.0-slim.tgz という配布形式が追加されました。追加のモジュール類が不要な利用者向けに、各種のライブラリを除外した配布となっています。
solr-9.3.0.tgz と solr-9.3.0-slim.tgz をそれぞれ展開して含まれているファイルを比較したところ、以下の２つのディレクトリが有るか無いかの違いであることが分かりました。
prometheus-exporter は Solr と Prometheus を連携させるためのツールです。
modules の下には以下のモジュールが含まれています。
それぞれのアーカイブファイルのサイズと展開後のサイズを比較すると、slim の方はかなり小さくなっていることが分かります。
$ ls -lh solr-9.3.0.tgz solr-9.3.0-slim.tgz
-rw-r--r-- 1 splout splout 60M 9月 23 12:42 solr-9.3.0-slim.tgz
-rw-r--r-- 1 splout splout 265M 9月 23 12:42 solr-9.3.0.tgz
$ du -sh solr-9.3.0-slim solr-9.3.0
78M solr-9.3.0-slim
304M solr-9.3.0調べていて気が付いたのですが、Solr 9 から Zip ファイルでの配布は無くなったのですね。