要約一行 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は成り立たないと思う

カイロソフトは9月26日から29日（一般公開日は28日から）まで開催の東京ゲームショウ2024に出展中。同社ブースにはゲーム試遊など、さまざまな展示が用意されている。その中では、イベント全体でもひと際異彩を放つ「自社ゲームソースコード大公開」が実施。一般公開日を待たずして、SNS上などでも注目が寄せられている。 カイロソフトは1996年創業の国内ゲームデベロッパーだ。同スタジオはシミュレーションゲームをPC/モバイルおよびコンソール向けに多数リリースしている。Steam向けにもリリースされたゲーム開発会社経営シム『ゲーム発展国++』などのほか、最近では国民的漫画・アニメ「ドラえもん」を題材とした『ドラえもんのどら焼き屋さん物語』を手がけた。堅実なゲームづくりで根強い人気を誇る老舗デベロッパーだ。 カイロソフトは現在、東京ゲームショウ2024に出展中。ブースには、同社のマスコットキャラクター

メタが提供しているAIモデル「Llama 3.1」を活用したアプリ開発ツール「LlamaCoder」が人気を集めている。 LlamaCoderは、AI企業のTogether AIが開発したオープンソースのウェブアプリケーション。「計算機アプリを作って」といった指示を与えるだけで、フルスタックのアプリケーションを生成する。メタのLlama 3.1 405Bモデルを基盤に、Together AIのLLM推論技術を活用している。 メタによれば、LlamaCoderはリリースからわずか1ヵ月余りで、GitHubで2000以上のスターを獲得し、数百人の開発者がリポジトリをクローンした。さらに、20万以上のアプリがLlamaCoderを使用して生成されたという。 Together AIの開発者関係責任者であるHassan El Mghari氏は、「開発者たちはこれを気に入っています。クイズアプリ、ポモ

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

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

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

An IDE built on top of a canvas, Haystack takes care of the tedious and confusing parts of coding for you

どうも、初めまして。 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

はじめに お客様に提案をしているときの会話です。 お客様：「詳細設計書は作りますか」 私：「昔ながらの詳細設計（ロジックを日本語で書くもの）は作りません。クラス図とか、シーケンス図は複雑であれば作りますが、今回のシステムはそこまで必要なものはないものなので、割愛しようと思っています。」 お客様：「保守をお願いするかどうか未定なので、場合によっては引継ぎのために作ってもらうかもしれません」 私：「・・・・」 といった感じで、私がこの業界に入った30年前は、確かにプログラムを作る前に、詳細設計書と呼ばれるプログラムを日本語で書いていました。 最近、詳細設計と呼ばれるものを作った記憶がなく、無駄なものは作りたくないなぁという思いから、コードから自動生成できないかなと思って、いろいろ試してみました。 Doxygenって いろいろ調べてみると、Doxygen にたどり着きました。 色々な言語に対応し

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命

https://anond.hatelabo.jp/20240625191650 競プロ出身者だけじゃなく、機械学習出身者も問題コードが多い 印象の問題ではなく実際に下記のようなコードが多い 念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある 正常系しか意識していない一番多いのはコレで異常系の動作を全く意識していない 入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない 「エラーが出たらとにかくtry-catchしてログ吐いて終わり」 ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる 「ここの処理でエラーログが出てるから対処よろしく」 「対処しました！（握りつぶし）」 とか滅茶苦茶多い セキュリティに関する意識が低い異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い API作らせて

anond:20240624084844 を読んで思ったこと。2番目以降は正直良くわからないが、一点目についてはわかりみしかない。 うちはメガベンチャーで内製アプリの開発保守をしてるんだが、新卒で採った青(水色？)のエンジニアが連続でクソ野郎でめちゃくちゃしんどかった。 ◯色コーダーマウントちょくちょく自分は◯色コーダーだって主張してくる。 こっちはお前が学生時代に取った資格の話なんて興味ねえんだよ。 センター試験の点数自慢してる社会人いるか？いねえだろ。 評価されたければ与えられたタスク以上の成果を挙げろ。 資格自慢をしたければ、社会人にふさわしい資格を取れ。 お前のガクチカなんぞ知らん。 コードがゴミ競プロエンジニアといっしょに仕事したことある人なら大体頷いてくれると思うんだが、彼らの書くコードは本当にひどい。 処理がどれだけ効率的だろうが、実務においてメンテナンサビリティの無いコード