AI時代に必要なのはプログラミング能力ではなくコンピューティング能力 - きしだのHatena
「プログラミング教育について語る会 」で話した内容をまとめておきます。 「AI時代のプログラミング教育」としたのだけど、内容的には「コンピューティング能力を伸ばそうぜ、その道具としてプログラミングしよう」みたいな話になりました。 Nextbeat Tech Bar：第二回プログラミング教育について語る会 - connpass 資料はこちら まず前提として、AIのコーディング能力が7ヵ月で倍になっているというのがあります。なので、今現在の能力で話をしてもあまり意味がなく、ゆくゆくはかなりのレベルでAIがコードを書くという想定をしておいたほうがいいです。 元ネタのツイートはこれ https://x.com/METR_Evals/status/1902384481111322929 論文はここ [2503.14499] Measuring AI Ability to Complete Long
「読みやすいコード」を依存グラフで考える
はじめに こんにちは、ダイニーの ogino です。 この記事では、コードの読みやすさを比較判断するために役立つメンタルモデルを紹介します。 本記事を読むと、「このコードは良い / 悪い」という感覚が身につき、その理由を自信を持って説明できるようになるはずです。 コードの読みやすさとは何か コードを読む時には大抵、何か特定の目的があります。例えば、 API /foo にリクエストした時の動作を知りたい、ある画面で発生しているバグの原因を知りたい、などです。 この時、コードベースの隅から隅まで読み尽くすのではなく、特定のポイントから出発して関連する箇所を芋蔓式に辿りながら読むはずです。 人が一度に理解して覚えておける情報量には限界があるので、辿らなければいけないコード量が少ないほど当然読みやすくなります。 つまり、ある目的に関連するコードの箇所が局所的かつ明示的であるほどコードは読みやすいと
Psyhoさんによるヒューリスティック・ボットコンテストのための無料Tips - カメヲラボ
ある日、マラソン王者のPsyhoさんがつぶやきました。 Let's make a silly experiment. For every like this post receives in the next 24 hours, I will post one tip for heuristic/bot programming contests. I will start posting these as a thread in ~1h from now. I could talk about those things for days, so bring it on!— Psyho (@FakePsyho) 2022年12月21日 要約すると、 これから24時間、1いいね毎にヒューリスティック/ボット プログラミングコンテストのヒントを投下します。 という話です。このまとめ記事を更新する
CLINEに全部賭けろ
Cline を使い始めて2ヶ月ぐらい経った。 自分の直感として、Cline は真のイノベーションの入口であり、そして開けてはいけないパンドラの箱でもあったと思う。 ここでいう Cline は Cline型コーディングエージェントであり、広義には Devin / Cursor や Copilot Agent 等を含む話。だが、後述するように Cline でしか見えない世界がある。 その先の未来に、プログラマとしての自分はフルベットする、という話をする。 私たちが知っているプログラミングの終焉 大事なことは次の記事に全部書いてある。まずこれを読んでほしい。 (Google翻訳) Steve Yegge 氏は、置き換えられるのはジュニアおよび中級レベルのプログラマーではなく、新しいプログラミング ツールやパラダイムを受け入れず過去に固執するプログラマーであると指摘しています。 <略> これはプロ
いいコードを書きたければTell, Don't Ask - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? いいコードを書きたい オブジェクト指向でプログラミングをする時に知っておくと、コードを書く時の指針になるような法則がいくつかあります。 今回はその中でもTell, Don't Askについてまとめていこうと思います。 また、この記事の内容はポッドキャストでもお話ししているので、もし音声のほうがいいという方は、以下のリンクからポッドキャストを聴いてもらえると幸いです。 Tell, Don't Ask〜ようこそグランメゾンTETSUDUKI〜 | Spotify Tell, Don't Ask〜ようこそグランメゾンTETSUDUKI〜 |
できるだけUIを作らない（新規作成画面編）｜toofu
貿易管理 SaaS を提供している Shippio でプロダクトデザインを担当している toofu です。 最近、機能開発・改善をするときに「なるべく UI つくりたくないなあ」と思うことがよくあるので、その考えを事例とともに共有させてください。 メインオブジェクトの作成機能を設計しました先日、Shippio のメインオブジェクトである「シップメント（貿易案件的なもの）」の作成機能をリリースしました。 メインオブジェクトの作成機能がなかったの…？と思われるかもしれませんが、Shippio にはシップメントを画面上で作成する機能がなく、外部データをインポートすることしかできませんでした。 「プロパティが多い貿易案件をすべて手入力していくよりも、ユーザーが普段の業務で管理している Excel 上の貿易データをそのままインポートしてもらうほうが、より業務効率化に近づくはず」というプロダクト開発初
関数とかクラスとかを切り出すときに考えていること
私の書くコードは読みやすさにまあまあそこそこ定評がある気がしています。 そんな私が読み手の脳に染み込みやすい設計にするために個人的に気にしていることを書きます。 About Me 株式会社ヘンリーでエンジニア的なことをしつつ、個人開発してます。 Social accounts: kohii on GitHub @kohii00 on X Developing: SmoothCSV MediXplorer Moyuk 他 関数やクラスを切り出すということ なぜ分割するのか なぜコードを分割するのかというと、コードベース全体の大きさや複雑さは人間の認知能力の限界を遥かに超えるからです。巨大で複雑なものを扱うには分割統治が基本戦略です。 コードを分割する手段として、関数、クラス、コンポーネント、パッケージ、モジュール、マイクロサービス、etc… など様々な方法がありますが、これらは「詳細や手続き
ソフトウェア開発現代史：製造業とソフトウェアは本当に共存できていたのか？品質とスピードを問い直す
【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」登壇資料です。 https://techplay.jp/event/967093
Tidy First?のススメ - 日々常々
薄い本なので軽い気持ちで読みましょう。 先に読むべき？→Yes！ 私は初詣の列に並んでいる1時間で読みました。寒かった。 Tidy First? ―個人で実践する経験主義的ソフトウェア設計 作者:Kent Beckオーム社Amazon 力を失ってしまった「リファクタリング」を復活させる本です。私の中のサブタイトルは「Make Refactoring Great Again」です。 第一部の冒頭から引用します。 整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。 「リファクタリング」という言葉は、機能開発の長い中断を指す言葉として使われ始めたとき、致命傷を負った。 「致命傷を負った」に「だよねー」と思ってしまう昨今。「それリファクタリングじゃねーしなー」とか思いながら「リファクタリング」という言葉が使われているのを眺めつつ
午前中に読み始めたら午後には設計が上達してしまった！ - 『Tidy First?』を読んだ - Mitsuyuki.Shiiba
私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい
何となくのコードレビューを小さくて素早く価値あるプロセスに変えるための参考値や考え方 - mtx2s’s blog
ソフトウェア開発におけるコードレビューの位置づけは、曖昧にされがちだ。欠陥を見つけるためにやっているのだろうか。コード品質を高めたいのだろうか。いずれにしても、チームやプロジェクトで統一された目的がないこともめずらしくない。レビュアーはただ、眼の前にあるコードの中で気になった箇所にコメントしているだけになってはいないだろうか。 また、チームのバージョン管理ツールを観察すると、コードレビュー待ちの開発ブランチが多いこともめずらしくない。実装することにばかりに時間が割かれ、コードレビューは後回しになっているのだ。しかし、レビューを終えなければ、それらは統合ブランチにマージされない。そうして生存期間が長いブランチが多くなるほど、マージコンフリクトが起こりやすくなる。その対処に支払うコストもばかにはならないだろう。 本稿は、コードレビューに関する2つの論文を中心に、機能的なコードレビューのあり方に
良いコードレビューとは
コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、
Practice Rust
Practice RustLearn Rust by practicing, choose from a variety of coding exercises and challenges to help you improve your Rust programming skills
その変数名だけはやめろ：頼むから analysis を anal と略さないでください
Linux には /tmp という一時ファイル用のディレクトリがあるので tmp は許容範囲である。というか日本語読みなので英語圏にこのネタは通じない。cng, mng, unk も同様である。cnt は英語圏でも普通に使われる変数名のようで、ass や anal ほどの忌避感はないようである。 最悪な変数名は anal_check や anal_insert である。from anal import * も芸術点が高い[1]。 叩いた回数の累積などを cumshot（「射精」のスラング）にするのも割と最悪みがあるようだが、日本人にはあまり伝わらないという意味でそこまででもない。 以下、改善案。 変数名 改善案 理由
Python mipライブラリを使った数理最適化 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 数理最適化は、与えられた制約条件の下で、最も効率的な解を見つけるためのアプローチであり、様々な分野で幅広く応用されています。特に、物流や製造、エネルギー管理、ポートフォリオ最適化といった領域では、資源の配分やコストの最小化、利益の最大化といった課題に対して有効な手段となります。 例えば、物流業界では、複数の倉庫から多くの顧客への配送ルートを最適化する「輸送問題」や、特定の条件下で商品の積載量を最大化する「ナップサック問題」などが数理最適化の代表的な例です。また、金融業界ではリスクとリターンのバランスを考慮した資産運用（ポ
【完全版】歴史でシェルの設定ファイルを理解する - 全POSIXシェル対応 (.profie, .bash_profile, .bashrc, .zprofile, zshrc, etc.) - Qiita
プロファイルでできることは環境の設定だけです。シェルの設定は実際にはできないことはないのですが、やっても無意味なことになるのでできないとします。無意味なことになるというのは新しく起動したシェルにはプロファイルで行うシェルの設定は反映されないということです。環境の設定とは、特定のシェルに依存しない初期化処理のことで、その一つが環境変数の設定です。環境変数は OS の機能であってシェルの機能ではありません。環境の設定には、他に stty コマンドによる端末の設定や umask コマンドによる umask の設定などがありますが、プロファイルで設定することはあまりありません。 rc ファイルでは環境の設定とシェルの設定の両方ができます。シェルの設定、例えばプロンプト文字列の設定やシェルの機能を有効にしたり補完スクリプトの読み込みなどは rc ファイルに書きます。つまり、ほとんどのことは rc フ
「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
先輩社員がどうやって不具合を解決しているのか - Qiita
Java はスレッドごとにメソッドの呼び出しをスタックで管理している スタック = LIFOのデータ構造 例外を new すると、その時点のスタックの情報が例外に記録される スタックトレースは、このスタックの情報を出力したもの トレース = trace = 追跡 スタックを追跡するためのもの スタックトレースを読むと、その例外を投げたスレッドがどのようにプログラムを通り、どこで例外をスローしたかが分かる スタックトレースの読み方 初めて長大なスタックトレースを見るとビックリしてしまうかもしれないが、全部を読む必要は無い 「例外の発生箇所を特定する」という目的に対しては、一番重要なのはスタックトレースの先頭だけ スタックトレースの先頭行は、その例外が生成された場所 普通は throw new Exceptin() のように、生成と同時に例外をスローするので、例外が生成された場所＝例外がスロー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AI時代のプログラミング教育 / programming education in ai era
バックエンドエンジニアのためのフロントエンド入門 #devsumiC
