タグ

プログラミングに関するrryuのブックマーク (555)

  • [解説]「Windowsの設定がフランス語だとゲームが起動しない」開発者がXで公開した小数点表記に関するバグの詳細をレポート

    [解説]「Windowsの設定がフランス語だとゲームが起動しない」開発者がXで公開した小数点表記に関するバグの詳細をレポート by せきやdn · 公開済み 2023年8月12日 · 更新済み 2023年8月17日 [UPDATE 2023/08/17] TryParse()系の例外をキャッチして処理するコードを省略していましたが、表記があったほうがいいというコメントをいただいたため、追記を行いました。 ゲーム開発を含むプログラミングにおいては、意外なところに落とし穴がたくさんあります。今回紹介するのは「フランス語のローカライズ対応における小数点問題」です。 発端となったポスト 今回の記事は、筆者(せきやdn)がX(旧Twitter)にポストした次のツイートが発端です。 今回の「ファミレスを享受せよ」 Windowsがフランス語だと立ち上がらない不具合。 お恥ずかしい話なのですが、 同じミ

    [解説]「Windowsの設定がフランス語だとゲームが起動しない」開発者がXで公開した小数点表記に関するバグの詳細をレポート
    rryu
    rryu 2023/08/13
    OSの言語設定の指定が効くのはライブラリにこういう機能があるからなのだが、ドキュメントでいきなりシステムカルチャが云々と書かれてもなんのことやらというのはある。
  • そりゃスパゲティーコードにもなるよな - orangeitems’s diary

    お気の毒に・・。 www.nikkei.com スパゲティコードになるプロセスはよーくわかる。 仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。 スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか?。 大企業のプロジェクト運用体制に、1つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当し

    そりゃスパゲティーコードにもなるよな - orangeitems’s diary
    rryu
    rryu 2023/08/12
    スパゲティになるコードは最初からちょっとスパゲティで、2本のあみだくじみたいになっている。これに普通に処理を追加するとあみだくじが成長してしまうのでやがて立派なスパゲティになる。
  • 徐々に高度になるリングバッファの話 - Software Transactional Memo

    リングバッファのイメージ図 1. リングバッファとは何か 機能的にはFirst In First Out (FIFO)とも呼ばれるキューの一種であるが、リング状にバッファを置いてそれの中でReadとWriteのインデックスがグルグルと回る構造をとる事によって容量に上限ができることと引き換えに高速な読み書き速度を得たものである。キューを単に実装するだけなら山ほど方法があって線形リストを使ってもいいしスタックを2つ使っても原理的には可能だ。その中でもリングバッファを用いた方法の利点はひとえに性能の高さでありメモリ確保などを行わないお陰でシステム系の様々な場所で使われている。 これの実装自体は情報系の大学生の演習レベルの難度であるが少し奥が深い。まずリングバッファのスタンダードなインタフェースと実装は以下のようなものである。 class RingBuffer { public: explicit

    徐々に高度になるリングバッファの話 - Software Transactional Memo
    rryu
    rryu 2023/07/30
    一見無駄な変数のコピーを使うようにするとマルチコアで実行する時に速くなるとか、知識がなかったらまるっきり謎なコードである。
  • きれいなコードを書けという話について - Software Transactional Memo

    前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語るは山ほどあり、それらのを崇める事は悪

    きれいなコードを書けという話について - Software Transactional Memo
    rryu
    rryu 2023/07/14
    一番きついのは書いた人の気持ちを脳内で再現したら書いた人もコードを理解して書いていないという結論になった時。結果としてはこれだけだからこの処理は要らないはずって削ると動かなくなるという
  • 凄腕エンジニアさんから学んだ例外の話 - Qiita

    はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトエンジニアさんに伝えたところ、反応が良く、とても勉強になりました!という声をいただけたので、アウトプットしていきたいと思います。 (この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。) ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth

    凄腕エンジニアさんから学んだ例外の話 - Qiita
    rryu
    rryu 2023/06/27
    必ずキャッチしないといけないようなものを例外にしても誰も嬉しくないという。例外にしたくなるのは戻り値の表現力が弱いだけなので処理結果を表す型を作れば良い。
  • 空の配列に対するmaxは何を返すか - きしだのHatena

    ちょっと前に「配列中のすべての要素が条件を満たすかどうか判別する関数で、空の配列はTrueを返すべきかFalseを返すべきか」のような話が話題になってました。 まあこれは「Trueを返す」が答えなわけですが、では「配列中の最大値を返す関数で空の配列の場合は何を返すか」が気になりました。 「配列中のすべての要素が条件を満たすかどうか判別する関数」について言えば、簡単に言えばこんな感じ。 まず、配列のすべての要素が偶数であるかどうか判別する関数を考えます。 void main() { int[] data = { 23, 44, 12, 98, 5 }; System.out.println(allEven(data)); } boolean allEven(int[] data) { for (int n : data) { if (n % 2 != 0) return false; } r

    空の配列に対するmaxは何を返すか - きしだのHatena
    rryu
    rryu 2023/06/06
    数学的には空集合に対するmax関数は一意に定義できないから考慮しないという感じで、そんななのでプログラミング言語にどう実装しても正解であり不正解であるということになる模様。
  • デバッグが早い人と遅い人の違い

    会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作(バグ)はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの?」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を

    デバッグが早い人と遅い人の違い
    rryu
    rryu 2023/04/19
    要は何が起こっているのか、どうしてそれが起こるのかの2つを突き止める作業で、そのコツは書いてある通りである。
  • 「悪〜いコード」を読んだので、ついでにコードメトリクスを計測してみた - Qiita

    はじめに 先日、「悪〜いコード」を読む機会がありました。 どんな風に悪いのか、軽くですが分析してみたので、ポエムとして投稿したいと思います。 古のコード 私は普段Ruby on Railsをメインに開発を行っているのですが、ユーザーからの質問に答えるために、普段の開発や保守しているのとは全く別のシステムのコードを読む機会がありました。 そのシステムはPHPで書かれた古いコードでした。ユーザーの質問はシンプルだったので、コードを見れば一瞬で答えは見つかるだろうと思ったのですが、とても読み難いコードだったので30分ほど頭を悩ませながら読むことになりました。 何が読み難いのか 結果、ユーザーからの質問には答えることができたのですが 「僕の30分を返してくれーーー!」と叫びたい気分です。 と愚痴ってしまいましたが、それだけでは何の進歩もないので、何が読み難かったのかを明らかにしてみたいと思います。

    「悪〜いコード」を読んだので、ついでにコードメトリクスを計測してみた - Qiita
    rryu
    rryu 2023/04/03
    NPath複雑性がやばすぎる。どれだけ分岐を入れればこの数値を叩き出せるのか…
  • PHPの最高機能、配列を捨てよう!! / Throw away all PHP array now!!!

    At: PHPerKaigi 2023 ( https://phperkaigi.jp/2023/ ) Track A DateTime: 2023/3/25 10:20 (40min) Speaker: uzulla

    PHPの最高機能、配列を捨てよう!! / Throw away all PHP array now!!!
    rryu
    rryu 2023/03/26
    要はコード上に明確な定義があればマシなので、stdClassをnewして使うプロパティを全て初期化するというのは良くやる。PHPは未定義プロパティをエラーにしないのでクラスを定義してもさして変わらないという。
  • AIにコードまるごと解説してもらうと、界王拳100倍すぎる件|深津 貴之 (fladdict)

    最近、見つけた技。知らない言語でコードかくときChatGPTが神すぎる。 そのテクはなんと「プログラミングまるごとを、ChatGPTに突っ込む」というもの。 え、そんなの動くの!? と思うんですが、動くんですそんなの。直球すぎて盲点だった。 試してみよう たとえば、下記はGoogleサービス使って、リアルタイムにマイク音声を文字起こしするサンプル。 こいつをチャットAIで音声会話をやろうと、軽く読んでみたのですが…うん、よくわからん。 Pythonだし、Streamingだし、音声の操作だし、普段つかわない技術が満載すぎてわからん。 雑にコードを突っ込むと人生が解決こういう時は 以下のコードを、わかりやすく説明して。 <以下、上記コードをそのままコピペ>とすると……  こうなる。 このコードは、Google Cloud Speech-to-Text APIを使用して、マイクからの音声をリア

    AIにコードまるごと解説してもらうと、界王拳100倍すぎる件|深津 貴之 (fladdict)
    rryu
    rryu 2023/03/14
    listen_print_loopはジェネレータじゃないし、何か色々怪しい感じがする。
  • プログラミングが難しくなったのはなぜか、原因はC言語のあの記法?

    プログラミングを全くしたことのない人がプログラミングの学習を始めた場合、どこでつまずくかを考えることがよくある。小学校でプログラミング教育が始まったこともあり、プログラマー以外の人も少しはプログラミングを知っておいたほうがいいと思うからだ。 初心者がつまずく場所としてよく聞くのが「繰り返し」だ。プログラミングには、処理の流れを制御する構文として、主に「条件分岐」と繰り返しの2つがある。初心者にとって、条件分岐は理解しやすいが、繰り返しは理解が難しいのだという。 たしかに日常生活の中でも「条件によってやることを変える」という場面は多い。プログラミングを知らない人でも普段から慣れている考え方だろう。 これに対し、プログラミングにおける繰り返しは、同じことを繰り返す場合もあるが、たいていは「ルールに従って値を連続的に変えながら処理を繰り返す」というものになる。日常生活では、同じ作業を繰り返すこと

    プログラミングが難しくなったのはなぜか、原因はC言語のあの記法?
    rryu
    rryu 2023/03/10
    代入の=はよく言われるが、:= にしたところで結局言語仕様を知らなければ読めないことには変わりないので些細なことだと思う。知らない言語のプログラムは読めない、それだけである。
  • 50万人が毎年受ける試験で採用、“謎”のプログラミング言語「DNCL」を学ぶ意義とは

    日経クロステックが2022年10月に実施したプログラミング言語の利用実態調査によると、メインで利用するプログラミング言語で最も回答が多かったのが「Java(ジャバ)」、2位は「Python(パイソン)」だった。ところが、このランキングでトップ10にも入っていないプログラミング言語が、毎年50万人近く受ける試験に採用される。そんな“謎”のプログラミング言語が「DNCL」だ。 DNCLなんて聞いたことがないというITエンジニアもいるだろう。筆者も高校生の息子に昨年聞いたばかりだ。DNCLを採用した試験とは何か、なぜ、どんな問題に採用されたのか。謎のDNCLに迫った。 試験のためのプログラミング言語 DNCLとは「共通テスト手順記述標準言語」と呼ばれるプログラミング言語で、大学入試センターが実施する「大学入学共通テスト」(2020年までは「大学入試センター試験」)で使用している言語だ。DNCLは

    50万人が毎年受ける試験で採用、“謎”のプログラミング言語「DNCL」を学ぶ意義とは
    rryu
    rryu 2023/02/28
    DNC(大学入試センター)が作った言語だからDNCLっぽいが、文章ベースの手続き手順のアレを呼ぶために捻り出された名前という感じがする。
  • 雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try

    (この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました) 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする&機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな

    雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
    rryu
    rryu 2023/02/20
    UI関連だとテストコードを用意しなくても実行できるので優先順位が低い訳で、モジュールやAPIはそれを実行するためにテストコードを利用した方が早いというだけだと思う。
  • 「プログラミングは能力の成長を測ることが難しい」子供向けプログラミング教室の市場規模に関連した塾の経営の話が面白い

    中田:‖ @paddy_joy 塾の経営者の話が面白かった。 「昨今はプログラミング教室が活況に見えますが、都会の一部だけの現象です。塾の市場規模は1兆円ありますがプログラミング教室市場はわずか200億円。伸びてはいますが全体の50分の1でしかありません。これはプログラミング技能を測ることが難しいということが→ 2023-01-15 18:09:49

    「プログラミングは能力の成長を測ることが難しい」子供向けプログラミング教室の市場規模に関連した塾の経営の話が面白い
    rryu
    rryu 2023/01/18
    測るというか教わったことを親に披露できないのが親に受けない原因な気がする。ソースコードを見せられても困る訳で。
  • 言語のスレッド実装の雑な話(Green threadからGoのgoroutineまで)

    Twitterで "green thread" という単語をたまたま見かけたので、知っていることをつぶやいたよ。 Green thread 言語のスレッドとOSのスレッドの関係 N:1 mapping 言語のスレッドの全てがひとつのOSのスレッドの上で実行されるもの。その代表が上記のJavagreen thread。 OSのシステムコールを呼ぶときには必ずnonblockingモードを使い、EAGAIN または EWOULDBLOCKが返ってきたときには他のスレッドの実行権に譲るようにする必要がある。うっかりシステムコールでブロックされてしまうと、全部のスレッドが巻き添えになって動けなくなる。 スレッドの生成やコンテキストの切り替えは軽い。しかし、マルチコアを生かすことができないため、シングルコアの環境でのみ使用される。 1:1 mapping OSのスレッドと言語のスレッドが1対1対応

    言語のスレッド実装の雑な話(Green threadからGoのgoroutineまで)
    rryu
    rryu 2023/01/11
    グリーンスレッドはシングルコアの時代のもので、マルチコアが普通になった時にどうスケジュールするのかという問題になり、今は空きコアで実行する手続きのキューを作るというのがメジャーな感じがする。
  • ついに実現!実用的なC++20コンパイル時出力 - Qiita

    はじめに 早いもので、今年ももう大晦日です。 大晦日といえば、やることは1つです。 そう、コンパイル時処理ですね!! コンパイル時出力 C++ のコンパイル時処理は非常に強力で、様々なことがコンパイル時にできます。 入力に依存しない計算なら、大抵コンパイル時にしてしまうことができます。 しかし、その結果の出力については実行時に行う必要があり、当にコンパイル時に処理できているのか分かりにくくなってしまうこともあります。 そこで、なんかこういろいろ頑張ってゴリ押すことで、制限はありますがコンパイル時に出力することができます。 先日公開した記事では、そんなコンパイル時出力について書いています。 コンパイル時出力の改良 この記事の目的は、コンパイル時出力の改良です。 現在のコンパイル時出力は次のような問題点があり、使いやすくはありません。 出力の前後に余計な出力(はみ出たエラーメッセージ)がある

    ついに実現!実用的なC++20コンパイル時出力 - Qiita
    rryu
    rryu 2023/01/02
    まさかのアセンブル時出力。.printディレクティブは結構色々なアセンブラに実装されている模様。そんなにアセンブル時に出力する需要があるのか…
  • ChatGPTによるプログラム生成の可能性と限界(後編) - Qiita

    はじめに この記事では最近話題のChatGPTによってプログラムを生成する際のコツについて解説します。 前編はこちら https://qiita.com/autotaker1984/items/5b5ac8c01d11fbbbc4a7 コードを生成するのではなく、コードを生成する過程を生成する ChatGPTは言語モデルベースのAIです。言語モデルとは、お題(プロンプト)に沿った文章を生成するモデルです。それ以上でもそれ以下でもありません。 従ってなんらかの機能を実装してもらう際もいきなり「機能」から「コード」の生成だとあまり満足いく結果は得られません。 もちろんChatGPTはかなり博識なのでそれっぽいコードは出してきます。ただ、そのような生成の仕方だとChatGPTが学習したコードにかなり依存したものが出力されるため、実際のユースケースとはズレたものが生成されますし、生成物の著作権リス

    ChatGPTによるプログラム生成の可能性と限界(後編) - Qiita
    rryu
    rryu 2022/12/05
    AIが出してきたコード断片を一つにまとめるのは人間っぽいのでスマートコピペツールという感じ。AIは分からないと言わず適当に嘘で埋めてくるのがこわい。
  • マトリョーシカ人形のようなメソッド設計を避ける - give IT a try

    フィヨルドブートキャンプのコードレビューでよく指摘してるシリーズです。 次のようなパンを焼くRubyプログラムがあります。 このプログラムはどういう工程を経てパンが焼かれるのか、ぱっと把握できますか? def main パンを焼く(粉, 水) end def パンを焼く(粉, 水) 焼く(パンを発酵させる(粉, 水)) end def パンを発酵させる(粉, 水) 発酵させる(パンを整形する(粉, 水)) end def パンを整形する(粉, 水) 整形する(パンをこねる(粉, 水)) end def パンをこねる(粉, 水) こねる(粉, 水) end main 上のプログラムは次のように書いても同じように処理されますが、工程の全体像がつかみやすいのはどちらでしょうか? def main 生地 = パンをこねる(粉, 水) 整形された生地 = パンを整形する(生地) 発酵した生地 = パ

    マトリョーシカ人形のようなメソッド設計を避ける - give IT a try
    rryu
    rryu 2022/11/28
    「焼く(発酵させる(成形する(こねる(粉,水)))」ならまだましなので、2工程ずつの謎の分割が悪さの元だと思う。
  • コードは2回書きたい - Mitsuyuki.Shiiba

    TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている

    コードは2回書きたい - Mitsuyuki.Shiiba
    rryu
    rryu 2022/11/12
    最終的な形が見えてない場合は大きな構造の変更が必要になる時が多いが、そういう時にテストも全部書き直しになると気力が尽きてやめたくなるという…
  • 先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか?

    回答 (63件中の1件目) 35 年前、私は 8 bit CPU (Z80) + メインメモリ 64 KB の PC でアセンブリ言語を用いてプログラミングしていました。メモリが限られるため、いまは OS が担うスワップ/ページング機能を自分で記述しましたし、サブルーチンを通るたびに自分を書き換えて次回のコールに備える自己書き換えテクニックを知って感動を覚えました。あの頃はメモリが大変貴重であり、消費メモリを 1 byte 単位でケチるのは常識でした。 確かにいまはそのようなことをする必要はありません。潤沢なメモリ、高性能な OS、超高級言語がプリミティブな操作を担ってくれます。 し...

    先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか?
    rryu
    rryu 2022/10/10
    令和であっても瞬間的にどれくらいメモリを使ってその内どれ位かが居座り続けるのかくらいは意識しないとダメだと思う。