https://peps.python.org/pep-0703/ Python の GIL 外す話。これすごく楽しい読みものでした。参照カウントのところが一番人気だと思うのですが、他のところも色々良い。こういう、「んーこういうことするとこういう問題が起きない？」と思ったら次の章くらいでそれが説明される、みたいな読みものは大変好きです 参照カウント: オブジェクトっていうのは作ったスレッドが解放するというのがほとんどなんだから、その場合はロックをいらなくする、他に渡ったら普通の参照カウントぽくする、という話。 Swift に 2018 年に導入された 話らしい。他のスレッドに渡された後で DECREF すると他スレッド用の参照カウントが負になりうるのだけど、その時に queue に入れるということをして、ややこしいので、なんかこれ無しですむ方法はないのかなぁ……と Immortalize

はじめに この記事は、ChatGPTを受けての競プロ周りの情報、およびchokudai個人の意見を発信したものです。基本的にはAtCoderの運営についても同方針を取る予定ですが、方針が変わり次第、AtCoderのHP/Twitter等で告知されます。 現在のAtCoderにおける競プロAIの実力についての事実 AtCoderのコンテストに対するソースコードはインターネット上に多くあり、おそらくそれを学習してChatGPTなどが作成されているため、過去問を利用して解ける/解けないを判定すると、過剰に解ける側に寄ってしまいます。 そこで、最新のコンテストで調査した事例について、Twitterからいくつか引用します。 ABC280にChatGPTを参加させてみました。結果はC問題まで解くことができ、順位は7245人中5290位でした。 A問題→ノータイムで正解 B問題→ノータイムで正解 C問題

僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定

Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a

GNU Assembler互換(サブセット)のアセンブラをGo言語でフルスクラッチで作ってみました。 開発22日目で自作Goコンパイラ(をセルフホストしたときに出力される20万行のアセンブリ)をアセンブルすることに成功しました。 どうやって作ったかというと、小さいコードを GNU Assembler (以下 as) に食わせて出力されたバイナリを観察する、を繰り返して中のロジックを推定し再現しました。as の実装は見ていません。(一瞬見たけど巨大すぎて何もわからなかった) アセンブラ自作は、やってみるとコンパイラ自作よりだいぶ簡単でハマりポイントも少ないので、学習テーマとしてはおすすめです。2箇所ほど難所(命令エンコーディングのルールを理解するのと、ジャンプ命令の最適化)がありましたがそれ以外はさくさく楽しく作れました。 作ってみた結果、アセンブリ言語の理解が深まったのはもちろんのこと、E

はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 （元ネタ）Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰？ 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味でGoに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関

きっかけ Rust Programming Language Forumにこんな質問が出ていました。 構造体にStringを持たせられるようにStringを受け取りたいです。これを実現する方法はいくつかあります。 &str String T: Into<String> T: AsRef<str> 例: pub struct Person { name: String, } impl Person { pub fn new(name: WhatTypeHere) -> Person { Person { name: name.some_conversion() } } どれが一番Rustらしい書き方ですか？ 単純に構造体に文字列を持たせる方法はいくつかあるのですが、実はその実装方法によって文字列のコピーやアロケーションの回数が異なります。 ここでは、上記の4つの場合と、コメント欄で提案されて

数日前にTwitterで, JavaScriptのオブジェクトに対する===の挙動が初心者には難しいみたいな話を見かけた. 発端や周辺の議論をちゃんと追いかけてないからとくに出典は貼らない. たぶん元々の話は「へぇ, こういう挙動なんだ, 簡単ではないね」くらいの話だったのかもしれない. 自分のタイムラインの観測範囲では「そうだそうだ, (参照の同一性ではなく)同値性にしとけばいいのに」と思っている人もそれなりにいそうに見えた. 個人的にも同値性が簡単に確認できるとよい気はするものの, 「なんでそうしないんだ, オブジェクトの中身を確認していくだけだろ!」みたいな簡単な話ではないことも知っているため, 以下のようなツイートをしたのだった. JavaScriptのオブジェクトの同値性、再帰的な構造とか作るとぜんぜん自明じゃないんだよなぁ。リンクの構造は違うけどプロパティを辿ったときのパスはど

はじめに 競技プログラミングに関連する、以下の記事が話題にあがりました。 nuc氏1つ目の記事 nuc.hatenadiary.org chokudai氏の記事 chokudai.hatenablog.com nuc氏2つ目の記事 nuc.hatenadiary.org nuc氏は、元Googleのエンジニアで面接も担当されていました。現在は某医大の特別特命准教授の方で、2007年頃に東大で競技プログラミングをされていた方のようです（氏名も役職も上記の記事のリンク先で公表されています）。nuc氏の記事は、競技プログラミングに対して「我々の目的の一つは、我々が始めてしまった競技プログラミングを我々が終わらせることです。」といった強い主張が多く、これらの記事の反応をみたのですが、 競技プログラミングをしている方々が、nuc氏の主張で不安になり、特に若い世代で、競技プログラミングをやめようとして

こんにちは😉 @ryokotmngです。 今日は社内ドキュメントの、Rust初心者向けのクックブックを公開しようと思います。 私自身コードを書くのに四苦八苦していた頃にとても助けられたので、Rustをはじめたばかりの方の参考になれば嬉しいです。 目次 [toc] はじめに この記事では、The Bookに記載されている知識を前提としています。 Rustを全く書いたことがない方は、先に読んでみることをお勧めします。 サンプルコードが結構長いこと、実行環境があった方が良い内容も多いことから、サンプルコードは大体Rust Playgroundのリンクとなっています。 ぜひご自身で修正して遊んでみてください。 単位つきの計算を型で厳格に縛る 例えば複数の長さの単位 (mm, cm, mなど) を扱う場合に、単位が合っていない長さ同士の計算をする場合、単位を揃える必要がありますね。 この時、最終的

音楽プログラミング言語って結局なんなのさ? 1.言語仕様published: 2021-02-12 last modified: 2023-07-25 この記事は続き物でおおよそ週間ペースを目指しています。 言語仕様(本記事)データとプログラムの境目言語とライブラリの境目松浦知也です。ここ2年ぐらい音楽のための新しいプログラミング言語mimiumを開発しています。 https://mimium.org/ja 最近この自分で作った言語を人に説明する機会がちょこちょこ増えてきたのですが、その度に「既存の音楽プログラミング言語と比べてどこが新しいのか？」という話にたどり着く前に「そもそも音楽をプログラミングで作るってどういうこと？」みたいな疑問に対する解説をしているうちに話が続かなくなってしまうようなケースが増えてきまして、なんかそういう超初歩的な解説があればいいのになあと思っています。 プログ

すごく今更感がありますが、先週末出版しました。 私のプライベートがとても忙しくしばらく書けませんでした。書籍を書きましたのでご報告です。 実践Rustプログラミング入門 作者:初田 直也,山口 聖弘,吉川 哲史,豊田 優貴,松本 健太郎,原 将己,中村 謙弘発売日: 2020/08/22メディア: 単行本 ちなみに、著者、まだ現物を受け取っていません。書店で現物を触りたいなと思って見に行きましたが、今週末は在庫切れで本屋さんにありませんでした。 電子書籍は調整中です。 私の担当は1章、3章の一部、11章の一部です。 他の共著者のみなさんの記事 （2020/09/22 追記） 共著なのにこの記事のタイトルを「書きました」としてしまったので、私もだぞ、とみなさんがタイトルで煽ってきています（違 私も『実践Rustプログラミング入門』を書きました - matsu7874のブログ 私だって『実践R

κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生：DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・

はじめに みなさんこんにちは。Sansan事業部プロダクト開発部のiOSエンジニア荒川です。 以前はRDBMSの記事*1を寄稿し、好評いただいたこともあり、定期的に車輪の再発明系の記事を書いていこうと思います。 さて本日はタイトルの通り、VimやEmacsに代表されるターミナルで動作するインラインテキストエディタをGoで開発してみました。 ソースコードは以下のリポジトリに置いているため、ぜひ参考にしてください。 github.com 完成品 文字だけだとイメージも湧きにくいので、まずは完成品をお見せします。 最低限エディタの動きは出来ている、というレベルの完成度ですね🙏 特徴 1000行インラインエディタ 文字入力/挿入/削除 画面スクロール キーボードショートカット ファイル読み込み/保存 Goのコードハイライト機能 実装の方針 今回はただ開発するだけではなく、いくつかのこだわりポイン

閏年（うるうどし）の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる？」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。本当にそうだろうか？　そう単純な話なのだろうか？ プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月（太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ）をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法（ちじゅんほう）は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年（つまり2月

まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

AI Lab AutoMLチームの芝田です (GitHub: @c-bata)。 ハイパーパラメーター最適化は、機械学習モデルがその性能を発揮するために重要なプロセスの1つです。Pythonのハイパーパラメーター最適化ライブラリとして有名な Optuna [1] は、様々な最適化アルゴリズムに対応しつつも、使いやすく設計的にも優れたソフトウェアです。本記事ではOptunaの内部実装についてソフトウェア的な側面を中心に解説します。 Optunaの内部実装を理解するためには、主要コンポーネントの役割と全体の動作の流れを押さえる必要があります。しかしOptunaの開発は活発で、コード量も多くなり、全体の流れをコードから読み取ることは難しくなってきました。そこで今回Minitunaという小さなプログラムを用意しました。Minitunaには全部で3つのversionがあり、それぞれ100行、200行

縁あって、カロリーメイトリキッドのプロモーション用にちょっとした Ruby プログラムを書かせてもらいました。 www.otsuka.co.jp ↑のリンクを開いて、cd .Quine したところにある CML_quine.rb がそれです。 cat CML_quine.rb とすると中身が見えます。ruby CML_quine.rb すると動きます。 CalorieMate-Liquid-Quine 実行してみましたか？サイト上で気楽に実行できるので、ぜひ試してみてください。 これがどういうプログラムなのか、簡単に解説しておきます *1 。 ローカルでの遊び方 サイト上で ruby CML_quine.rb をするだけでも楽しめますが、自分のパソコンに保存するとより楽しめます。 まず、cat CML_quine.rb した中身をまるごとコピーしてください。 n=2;で始まる行の頭から、'