Cython 3.0.0 リリース [Python]
Cython 3.0 がリリースされたことを知った。
https://pypi.org/project/Cython/
breaking change があるらしいが・・・
と思ったら、ここにまとまっていた
https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html
驚いたことに Cython3.0 でも Python2.7 がサポートされているようだ。
試しに CyMySQL を python2.7 と python3.10 で unittest を実行してみたら、特に Error とか Fail とか発生しなかった。
最近は、 Cython よりも Rust を使われることが多いのかなぁという感じがしている。
Cython で使える C コンパイラをインストールするより Rust をインストールする方が簡単だからかな？
Cython で書くほうが Rust で書くより簡単だと思うし、Cython は、**うまく書けば** C言語で書くくらい速くなるだけでなく、C のライブラリを呼び出すコードが比較的簡単に書けるのがいい。
fugashi という MeCab のラッパーが Cython を使って MeCab の API を呼んでるらしい。
https://github.com/polm/fugashi
頭いいな、と思った。
Cython を使う側の視点から見ると、思ったよりドラステックな変化はないっぽいので、（習得し直さなくて良さそうなので）また、Cython で何か書いてみたいな。
NumPy のデータとのやり取りができるインターフェースがあるので NumPy と連携する何か Cython で書けないかな。
https://pypi.org/project/Cython/
breaking change があるらしいが・・・
と思ったら、ここにまとまっていた
https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html
驚いたことに Cython3.0 でも Python2.7 がサポートされているようだ。
試しに CyMySQL を python2.7 と python3.10 で unittest を実行してみたら、特に Error とか Fail とか発生しなかった。
最近は、 Cython よりも Rust を使われることが多いのかなぁという感じがしている。
Cython で使える C コンパイラをインストールするより Rust をインストールする方が簡単だからかな？
Cython で書くほうが Rust で書くより簡単だと思うし、Cython は、**うまく書けば** C言語で書くくらい速くなるだけでなく、C のライブラリを呼び出すコードが比較的簡単に書けるのがいい。
fugashi という MeCab のラッパーが Cython を使って MeCab の API を呼んでるらしい。
https://github.com/polm/fugashi
頭いいな、と思った。
Cython を使う側の視点から見ると、思ったよりドラステックな変化はないっぽいので、（習得し直さなくて良さそうなので）また、Cython で何か書いてみたいな。
NumPy のデータとのやり取りができるインターフェースがあるので NumPy と連携する何か Cython で書けないかな。
20年使える業務システム [日記]
最近 Oracle8 + Java でできている業務システムをバージョンアップして新サーバーに移行したという話を聞いて
https://nakagami.blog.ss-blog.jp/2023-05-06
とりあえず 20年、その後 30年、40年と使っていく業務システムを作りたいとなったら何を使えばいいんだろうか？
と、たまーに考える
- 機能改修は継続的に行われる
- 業務アプリなので、UI 的にシュッとしたかっこよさは必要ない
- OS, RDBMS, プログラミング言語とライブラリは LTS サポートがなくなる前にバージョンアップする
と考えた時に、 1番下の（業務的にはあまり必要とされてない）バージョンアップの負担がどれだけ減らせるか？
ということと、使っている要素が廃れてしまって適切にセキュリティパッチが出なくなったり、扱える人が減ったり、しないようにしたい。
・・・つまり、 Visutal Basic 6.0 や Perl で書いて20年後の人に迷惑かけないようにしたい、というあたりが、長く使うためのポイントかなぁ。
- SPA は業務アプリに必要ない一方、フロントのライブラリーやツールを更新するのは大変。サポートされる期間も非常に短い
- Web フレームワークは３年くらいで LTS でなくなる一方変化が激しいので、バージョン上げたてそのままってことが少ない
というあたりが 20年〜40年って考えた時にネックになるかなぁ
- RDBMS は PostgreSQL か MySQL (今の時点だと PostgreSQL を選ぶ方が安心かなぁ）
- プログラミング言語は Go
- 極力外部パッケージは使わず、 Web フレームワークの薄ーいやつ (ginとか) と、データーベースドライバーだけ使う
くらいだと 100年くらい使えるかなぁ
https://nakagami.blog.ss-blog.jp/2023-05-06
とりあえず 20年、その後 30年、40年と使っていく業務システムを作りたいとなったら何を使えばいいんだろうか？
と、たまーに考える
- 機能改修は継続的に行われる
- 業務アプリなので、UI 的にシュッとしたかっこよさは必要ない
- OS, RDBMS, プログラミング言語とライブラリは LTS サポートがなくなる前にバージョンアップする
と考えた時に、 1番下の（業務的にはあまり必要とされてない）バージョンアップの負担がどれだけ減らせるか？
ということと、使っている要素が廃れてしまって適切にセキュリティパッチが出なくなったり、扱える人が減ったり、しないようにしたい。
・・・つまり、 Visutal Basic 6.0 や Perl で書いて20年後の人に迷惑かけないようにしたい、というあたりが、長く使うためのポイントかなぁ。
- SPA は業務アプリに必要ない一方、フロントのライブラリーやツールを更新するのは大変。サポートされる期間も非常に短い
- Web フレームワークは３年くらいで LTS でなくなる一方変化が激しいので、バージョン上げたてそのままってことが少ない
というあたりが 20年〜40年って考えた時にネックになるかなぁ
- RDBMS は PostgreSQL か MySQL (今の時点だと PostgreSQL を選ぶ方が安心かなぁ）
- プログラミング言語は Go
- 極力外部パッケージは使わず、 Web フレームワークの薄ーいやつ (ginとか) と、データーベースドライバーだけ使う
くらいだと 100年くらい使えるかなぁ
GitHub アカウントを知られると恥ずかしい？ [日記]
仕事のソースコードが GitHub で管理されるのが当たり前になって、そのアカウントを仕事用と私用とで分けないことが普通になっている。
公開しているリポジトリが、個人のリポジトリが仕事仲間や第三者に見えることは、プログラマー、ITエンジニアにとってメリットだと思っている。
もし、個人のコードが恥ずかしいならプライベートにできるし、どうせ仕事の恥ずかしいコードは仕事仲間には見えちゃってるんだし。
全くもって twitter や Facebookのアカウントとは異なる種類のものだと思うのだが、GitHub のアカウントが知られるのが嫌な人がいるらしい。
GitHub のアカウントがみられている恥ずかしさと、仕事のコードをみられている恥ずかしさは共通する部分があって、GitHub のアカウントが知られるのが恥ずかしいというのは、プロとして克服すべき羞恥心が克服できてないのではないのかな。
公開しているリポジトリが、個人のリポジトリが仕事仲間や第三者に見えることは、プログラマー、ITエンジニアにとってメリットだと思っている。
もし、個人のコードが恥ずかしいならプライベートにできるし、どうせ仕事の恥ずかしいコードは仕事仲間には見えちゃってるんだし。
全くもって twitter や Facebookのアカウントとは異なる種類のものだと思うのだが、GitHub のアカウントが知られるのが嫌な人がいるらしい。
GitHub のアカウントがみられている恥ずかしさと、仕事のコードをみられている恥ずかしさは共通する部分があって、GitHub のアカウントが知られるのが恥ずかしいというのは、プロとして克服すべき羞恥心が克服できてないのではないのかな。
スケールアップの時代 [日記]
コンピューターの歴史は集中と分散を行ったり来たりしている。
現在の（これから出る）AMD の一番いっぱい CPU コアを積めるやつが 128コア256スレッドなんだそうである
https://www.amd.com/en/newsroom/press-releases/2023-6-13-amd-expands-4th-gen-epyc-cpu-portfolio-with-leader.html
https://pc.watch.impress.co.jp/docs/news/1508404.html
Amazon や google や LINE じゃない限りこれだけの CPU があればやりたいことは大概できそう。
そろそろ、機能ごとにサーバーを分けたりスケールアウトできるように構成したり、
考えたりするの面倒だから、全部一台に載せちゃえ、っていう時代来ないかな。
現在の（これから出る）AMD の一番いっぱい CPU コアを積めるやつが 128コア256スレッドなんだそうである
https://www.amd.com/en/newsroom/press-releases/2023-6-13-amd-expands-4th-gen-epyc-cpu-portfolio-with-leader.html
https://pc.watch.impress.co.jp/docs/news/1508404.html
Amazon や google や LINE じゃない限りこれだけの CPU があればやりたいことは大概できそう。
そろそろ、機能ごとにサーバーを分けたりスケールアウトできるように構成したり、
考えたりするの面倒だから、全部一台に載せちゃえ、っていう時代来ないかな。
