TL;DR Q: HPCプログラマの書くコードってなんで古臭いの？ A: そうしないと性能が出なかったから はじめに スパコンを使ってそれなりに長いこと研究をしています。初めてスパコンを使ったのは今から25年くらい前です。発展の早い世界ですので、昔と今ではだいぶ違ってきています。この前、スパコンを使う時の「常識」がすでに現在では常識ではなくなっているっぽいことを知り、私も「そっち側」になったのか、と感慨深くなりました。以下は、HPC業界の語り部に片足を突っ込んだおっさんの戯言です。 なお、以下では主に「京」の話をするため、富士通のC++コンパイラに文句を言う形になりますが、富士通が悪いのではなく、昔のスパコンに搭載されていたC++コンパイラはどれもかなり酷かったということはあらかじめ言っておきたい気がします。IBMのコンパイラとかも酷かったし、なんならIntelのコンパイラもバグだらけだっ

Googleは、人間がタスクを与えると自律的に実装計画を立ててコードの生成や変更、バグフィクスなどを実行してくれるAIエージェント「Jules」を発表しました。 同社が発表した最新の生成AIモデルであるGemini 2.0が用いられています。 タスクやイシューを与えると、それを起点に自律的なプログラミングを行う生成AIを用いたサービスは、先日正式サービス化されたDevinや、現在テクニカルプレビュー中のGitHub Copilot Workspaceなど、すでに先行しているサービスが存在します。 参考：GitHub、「Copilot Workspace」テクニカルプレビューを開始。ほとんど全ての開発工程をAIで自動化 GoogleもGemini 2.0によって、同様に自律的なプログラミングが可能なレベルのサービスを開発可能になったということでしょう。 Julesが動作する様子 Google

コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、

こんにちは！ Magic Moment フロントエンドエンジニアの @morishin です。 この記事は、Magic Moment Advent Calendar 2024 4 日目の記事です。 はじめに 開発あるある 皆さん開発をしていて、コマンドの "待ち" が長いとき、こんな経験はありませんか。 「ビルドに時間がかかるなぁ」 (別の作業をする) 「もう終わったかな (ﾀｰﾐﾅﾙﾁﾗｰ」 「まだかー」 (以降無限ループ) 作業に集中できない！ 逆に 「このインストール時間かかるなぁ」 「終わるまでちょっと休憩しようかな (ｽﾔｧ」 〜3 時間後〜 「...あっ、いつの間にか終わってた！」 処理の完了に気付かずついつい休憩しすぎた！ ありませんか？ありますよね？ まあ休憩しすぎたっていうのはないにしても、実はエラーで処理が中断していたのに気付かなかった、というのはあるあるな気がします。

「個人開発をしてみたい」 最近個人開発関連の記事は Qiita や Zenn にも多いし、そう思っている人は多いと思う。 しかし「やってみたいけど作りたいと思うものがない」という人がそれなりにいるかもしれない。 ぼくも昔、自分で何か作ってみたいけれども、残念ながら作りたいと思えるものがない、という状態だった。 なにかいい案を思い浮かんだとしても、少し調べてみると誰かが同じようなものを既に作っているからだ。 すでに誰かが作っている、しかも初めて個人開発をする自分なんかよりも経験が長い人が、自分が作ろうと思っているものよりもはるかに多機能で洗練されたものを作っているように思える。 こういったのを見かけると、なかなかやる気にはなれない。 個人開発で作れるものなんて、もうすでに出尽くされているのではないか。 そんな気がしている人は多いと思う。 「とりあえず作ってみる」そんな人におすすめなのは、「な

要約一行 Draw.ioみたいな作図ツールがもっと欲しいから作っている。 モチベーションという名のポエム 世の中にはいい感じのカジュアルな作図ツールが少ない。ここでいうカジュアルとは、CADのような精密さは必要なく、多少座標がずれてても建物は倒壊しないし人も死なないという意味でのカジュアルである。Figmaみたいなデザインツールともまた違う。FigJamはそうかもしれない。tldrawはきっとそうだろう。言ってしまえばDraw.ioだ、そうつまりDraw.ioである。 というわけでカジュアル作図ツールの大御所と言えばやはりDraw.io（Diagram.net）だろう。何かを作図したくなってweb検索したことがある方ならきっと一度は使ったことがあるはずの、まさにカジュアル作図ツール界の金字塔。しかも無料。これでいいじゃんの代名詞。 実際にこれでいいと納得できる箇所は非常に多い。まずwebア

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? デジタル時代において、プログラマーの役割はますます重要になっています。彼らの使命は、単にコードを書くことだけでなく、無限の可能性に満ちた新しい世界を構築することです。効率性と創造的プロセスの楽しさを高めるためには、適切な開発ツールを選択することが重要です。 ここでは、開発効率を大幅に向上させ、全体のワークフローをスムーズにするための高く評価されているソフトウェアツールをいくつか紹介します。初心者から経験豊富なプロフェッショナルまで、これらのツールは、コードの整理、プログラムのデバッグ、プロジェクト管理、効果的なコラボレーションをサポート

「gettyimages」より 一部システムが2038年1月19日3時14分8秒以降の時刻になると誤作動を起こす可能性があるとされる「西暦2038年問題」。新たな論文が発表され、一般的に想定されているより広い範囲で大きな影響が出るのではないかという声が広まっている。どのような規模の影響の発生が想定されるのか。また、システム運用者はどのような対策をすべきなのか。9月に論文「32bitを超えるtime_t型を持つ環境における2038年問題とその検出」を発表した立命館情報理工学部教授の上原哲太郎氏に聞いた。 2038年問題とは、LinuxなどのUNIX環境、C言語プログラムのUNIX timeで表現されたタイムスタンプ値が32bit符号付き整数型で定義されている場合、2038年1月19日3時14分8秒以降の時刻で整数オーバーフローが生じ、それを参照したシステムが不具合・障害を起こすというもの。対

経験の浅い人にちょくちょくするアドバイスとして、「コードリーディングのときにはあんまコードを読まないほうがいいよ」がある。コード全体を詳細に読むのではなく、名前やインターフェイスからコードの意図を把握することで効率的にコードリーディングできる。完全に下記の受け売り。 「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係のグラフを書いたりして。実装はちゃんと出来ていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにするんです。そっちの方が、実装を見るよりずっと楽ですよね。」 牛尾 剛「コードリーディングのコツは極力読まないこと 」 自分なんかは、エディタの畳み込み機能と変数名ホバーを使って、名前とインターフェイスしか見えない状態で読む。中身を読みたいなーと思ったところは畳み込みを解除して徐々に読ん

なにわづ @imawo_harubeto 先人の作ったマシンとOSの上で、先人の作ったデバイスとソフトを用いて、先人の書いた言語とライブラリを借りて、先人の考えたデータ構造とアルゴリズ厶に感謝してプログラミングをしている 依拠性の程度はそれぞれでも、巨人の肩の上に乗らなければcreationは成り立たないと思う 2024-10-03 09:22:12

sponsored いまGIGABYTE”渡辺技師”が推すレシピはコレ！ キラキラを魅せる小型ゲーミングPCを組もう sponsored JAPANNEXTの「JN-IPS245G320F-HSP」をレビュー ゲーマーの私にぶっ刺さった、320Hzで3万円台の24.5型ゲーミングディスプレーがほし過ぎるっ！ sponsored 白のパーツを多く搭載、PCIe 5.0対応SSDを採用 人気のNZXTケース新モデル「H9 Flow White」を中心に、ゲーム性能とカラー統一に注力したPCがコチラ！ sponsored 写真や動画だけでなく、Windows環境を移行する際の一時的なファイル保存にも データ転送が遅いと嘆く人にはThunderbolt対応のSSDがおすすめだ！ sponsored JN-282IPS4KP-HSP-C90Wをレビュー 超広い3840×2560ドット（アスペクト比3

ひろゆきさんが今話したいエンジニア（あるいはプロダクトの作り手）に聞いてみたかったことを聞いていく本連載。話題のプロダクトを、ひろゆきさんはどうみるのか？ 「僕ならこうつくる」というひろゆき案も飛び出すかも！？ 「世の中をあっと言わせるプロダクトが作りたい」エンジニアのみなさんにヒントを届けます。 ひろゆきさんが「今、話したい人」と対談する本連載。今回のゲストは、先の東京都知事選に出馬したAIエンジニアの安野たかひろさんです。 日本のAI研究をリードする松尾豊教授の研究室出身で、AIスタートアップ2社の経営者としての顔も持つ安野さんに対する一つ目の質問は

はじめに 前にも別のモデルでやってる ただ o1-preview は、やり取りを重ねるよりも一発で終わらせるほうがいいらしいので、最終的なテスト全体を渡すようにした。 情報の提示方法が異なると当然結果も変わるので、 gpt-4o でも同様なことを試した。 材料 プロンプトは以下。 基本的に最初にやったときと同じ。ペアプロではないのでその部分の調整をしている - 私がテストコードを提示するのでそのテストケースをパスする最小限の実装をしてください - Vue.js のバージョン 3 と Typescript で実装を行ってください - コードのみを示してくださいコードの解説などは必要ありません - スタイリングは必要ありません - テストケースに失敗したらその内容をチャットで送信するので最小限のコードの修正をしてください - テストのコードには vitest を利用しています jest と互換

プログラミングの勉強方法で最も効果がない方法は「写経」です。コードを記憶しても無駄です。実際のプログラミングでは記憶にないコードを作り出さなければいけないからです 「写経」はタイピング速度の向上やキーワードを覚える効果はあるかもしれませんが、肝心のプログラミングには役に立ちません — Koichi Nakashima (@ko1nksm) September 3, 2024 こういうエントリを見かけたので。 僕は1990年代からプログラミングを人に教える仕事をしています。最初は中学の時に技術家庭科の授業を先生から任されて同級生にプログラミングを教えることから始まりました。その後、色々な方法を試しましたが、結論としてプログラミング初心者は写経した方が結局は上達が速いと今は考えています。 それが特に強く感じられたのは2015年頃から色々な人にAI関連のプログラミングを教え始めた頃です。 AI関

Haystack’s AI pinpoints the best order to review your diffs so you can jump straight into reviewing. No more puzzling over complex pull requests! Haystack’s AI pinpoints the best order to review your diffs so you can jump straight into reviewing. No more puzzling over complex pull requests!

どうも、初めまして。 tokeと申します。 今回は自分の失敗談を話したい、と思います。 実装する前にドキュメントを読まないと、最後になってゴールに辿り着けない可能性がある そういう経験をしたのでご紹介します。 例えば、自社で集めた顧客のデータを活用し、Marketoにデータ連携したいとします。 marketoのAPIドキュメントを調べると、顧客の情報を登録する手段では以下の２パターンがあります。 POST /rest/v1/leads.jsonを使うパターン 以下のドキュメントにあるPOST /rest/v1/leads.jsonを使って、顧客のデータを送信し、連携する事ができます。 https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/lead-database/leads [※Marketoで

はじめに どうも、y-tetsuです。 かれこれC言語には、10年以上携わっているのですが、最近ふと学びなおしをしています。 「Cクイックリファレンス第2版」これを完走めざして読み始めました。全816ページの超大作！ 先は長いので、日頃からかたわらに置いておき、表紙の牛さん(雌牛)と目が合ったら黙って少し読むようにしています。 言語の"歴"だけは長い筆者ですが、この本をちらっと読んだだけでもいまだに知らなかったことが結構潜んでいました。意外と己の"目"ってザルでした。 そんなこんなで学びなおしのため、今回は筆者が感じたままの知られザルそして許されザルなC言語の仕様について、備忘録を残します。 知られザル仕様 恥ずかしながら、今まで存じ上げザルだったシリーズ。 ダイグラフ 名前からして？？？だったんですが、キーボードによっては存在しない記号を別の2文字で表わすためのものだそうです。 ！？…っ

このシリーズではこれらの関数が内部でどのように処理されるのかを調べていきます。 malloc.c を読む (malloc / free) malloc.c を読む (bins) malloc.c を読む (arena) 今回は malloc() free() の全体像を紹介します。 注意としてここでの目的は全体を俯瞰して、詳細を詰めずとも各 bins の役割を理解し、攻撃手法を理解できるようにすることです。それに合わないマルチスレッドや最適化などにおける緻密なトリックやコーナーケースなどは暗黙的に実装されていると仮定します。その詳細についてはソースコードや他の資料を参考にしていただきたいです。 ここで扱う glibc のバージョンは v2.38 です。また glibc のソースコードはブラウザ上で読むことができます。 https://elixir.bootlin.com/glibc/lat