はじめに これは「フィヨルドブートキャンプ Advent Calendar 2025」の15日目の記事です。fjord-calendar.jp 昨日の記事は id:unikounio さんの「【Obsidian】Thinoで思考の整理を楽しもう」と、 id:hiroblogdesu さんの「フィヨルドブートキャンプに入会して丸2年が経ったのでモチベについて語らせてください」でした。 今回はメンターである僕、伊藤淳一がふだんの業務で生成AIをどんなふうに使っているのかを紹介したいと思います。 また、記事の後半ではフィヨルドブートキャンプ生に向けて、プログラミング初学者が生成AIを利用する際の注意点についても書いてみます。 【もくじ】 はじめに どんな生成AIを使っているのか どんなときに使うのか 自分でコードを書いてもいいが、ちょっと面倒なとき 自分で調べてもいいが、時間がかかりそうなとき

序文 しばらく前から、プログラマーを対象とした圏論に関する本を書こうと考えていた。計算機科学者ではなくプログラマー、科学者ではなくエンジニア向けだということに注目してほしい。正気の沙汰ではないし、本当に恐ろしい。科学と工学の間に大きなギャップがあるのは否定できないと思う。自分自身がその分断の両側で仕事をしてきたからだ。それでも、物事を説明したいという強い衝動をいつも感じていた。簡潔な説明の達人だったリチャード・ファインマン1を心から尊敬している。自分がファインマンではないことは分かっているが、最善を尽くしたい。まずは、この序文――読者に圏論を学ぶ気を起こさせることを想定したもの――を公開することから始めようと思う。それによって議論を開始しフィードバックを募れることを願っている2。 ここからの数段落をかけて、この本はあなたのために書かれたものであり、数学のうちでも特に抽象的な分野を学ぶために
monorepo のGo テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos

文・xcloche 棒が来ないので負けました。 テトリスでゲームオーバーになったときの言い訳ナンバーワン。棒がくればもっと続けられたのに。棒、ほしいときに来なさすぎじゃない? テトリスは1984年にソビエト連邦で生まれた、誰もが知る元祖落ちものパズルゲームである。「最も多くのプラットフォームに移植されたビデオゲーム」としてギネス記録にも登録されている。おおよそどんなゲーム機でもテトリスができる。古くてめちゃくちゃ移植されているだけあって、1984年から今にかけてテトリスは静かに進化してきた。あんなゲームの何が進化できるのか? そう、棒が来るようになったのだ。 対戦のテトリス、ぷよぷよテトリス、バイオセンサーを取り付けて心拍に応じて変なピースが落ちてくるテトリス……テトリスの派生メカニズムは数知れずあるが、今回はそこには寄り道しない。これから語るのは、おなじみのあのテトリスの「ピースが落ちる

はじめに 「ソケット通信ってなんやねん」、そう思った経験はみなさんもあると思います。 私もそのうちの一人です 👍 個人的に初学者の方がつまづくポイントが多い概念なのかなと感じていました。本記事では、そのモヤモヤを解消すべくソケットの基礎概念に触れていこうと思います。 この記事を読み終わった後、皆さんはソケットを理解し、ウキウキになれるはずです! では、一緒に「見えない通信」の扉を開きましょう〜 👽 対象読者 ソケット通信を基礎から理解したい方!! ソケット通信とは何か? まず、ソケットとは何なのかみていきましょう。 ソケットとは ソケット は、オペレーティングシステム (OS) が提供する、プロセス間通信のエンドポイント、つまり「出入り口」のことです。 同じコンピュータ内の異なるプログラム同士、あるいは、ネットワークを介した異なるコンピュータ上のプログラム同士がデータのやり取りをする

コードを読んでいるときに「なんかよく分からんが複雑でわかりにくいな...」と感じることはありませんか? 私は既存のコードを読んでいるときはもちろん、自分が書いたコードを読むときもそう感じることがあります。 複雑さの要因を理解していないと、適切な改善ができませんよね。 今回は、「脳に収まるコードの書き方」という書籍を参考に、コードの複雑さの可視化とその複雑度を軽減させる方法を解説していきます。 前提 当たり前ですが、コードは書く回数よりも読まれる回数の方が多いです。 コードの価値には、アプリケーションが動くことだけではなく可読性も大きく関係しています。 目先のリリースを優先して「とりあえず動くコード」を許してしまうと、将来、他の誰かあるいは未来の自分がそのコードを読むときに必ず苦しむことになります。 可読性を二の次にせず、「脳に収まるコード」のための最適化を常に検討しましょう。 コードの複雑

■AIと性格選択が生み出す新体験 『電脳少女プログラミング2088-壊レタ君を再構築-』は、paizaがこれまでに提供してきた『PaizaProgramming Game』(以下、PPG)シリーズの最新作です。PPGは、ユーザーのプログラミングスキルをS・A・B・C・D・Eの6段階で評価する「paizaスキルチェック*」のシステムを活用し、ユーザーが楽しくプログラミング問題に取り組みながら学習できる無料のプログラミングゲームです。 このゲームでは、「楽しみながらプログラミングを」というPPGのコンセプトを実現するため、生成AIを通じてフィードバックそのものをエンターテインメント化しました。プログラミング学習は難しく、特にエラーやつまずきによってモチベーションが低下しやすい課題があります。この課題を解決するため、生成AIを活用し、楽しくスキルアップできるPPGを作りました。ゲームプレイ

こんにちは。 苦しんでプログラミングを学んだ柴犬こと、くるしばです。 独学でプログラミングを学習し、Webサービス作りITベンチャーを起業しました。 その後個人開発したサービスを売却したり、また別のIT系の会社を創業したりしています。 下記のTwitterにてプログラミング学習に関して発信し、1.9万人以上の方々にフォローして頂きました。 また、最近はUdemyでReactとFlutterのプログラミング講座も出して、ベストセラーにも入っています。 初心者のうちは知らなかったが、学習を進めたり実務に入って経験が長くなってから 「こんな便利なものあったんだ...!」 となるツールってありませんか? 僕はめちゃくちゃありました。 こういったツールは他の詳しい人から教えてもらうケースも多いので仕方がないのですが、もしこれらを初心者のうちに知ってたら色々楽だったのにな...と思うものが沢山あります

本記事は、学生本人から許可を頂いて書いています。 はじまり こんにちはTECOPARK株式会社代表の三宅と言います。会社の代表作はPICO PARKという協力アクションパズルゲームです。今はゲームデザイン業務がメインですが、職業ゲームプログラマー歴が13年、メインプログラマー経験があります。 さて、事の始まりはそんな私がゲーム会社でゲームプログラマーをやってた時代にさかのぼります。私は当時、ゲームプログラマー志望の就活生のプログラムコードを見る機会がありました。ちゃんと設計されているコードを持ってくる学生ももちろんいるが、今のこのタイミングでこのレベルのものを持ってくるとなると厳しい就活になりそうだなと思う子もいました。就活のタイミングではなくもっと早いタイミングで見る機会があればいくらでもアドバイスできたのにな。そう思うこともありました。 その時、思ったのである。 「専門1年または大学1

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

モブプログラミングは、なぜ5人が1台のPCで仕事をしているのに生産的になれるのか(前編)。モブプログラミングの生みの親が解説するその理由と効果とは? 2人のプログラマが協力して同じコードに対してプログラミングを行う「ペアプログラミング」に対して、モブプログラミングは3人以上のチームメンバーが協力してプログラミングを行う方法です。 このモブプログラミングの生みの親であるWoody Zuill氏が、今年(2024年)1月に東京都内で行われたイベント「Regional Scrum Gathering Tokyo 2024」の招待講演「Software Teaming (MobProgramming) and the Power of Flow.」(ソフトウェアチーミングと「フロー」のチカラ)を行いました。 講演のなかでZuill氏は、なぜ一見すると手分けをして作業するよりも効率の悪そうなモブプ

ここ数日、.NET 6 でできたアプリを .NET 8 に更新する作業をしています。.NET 8 のリリースから半年以上が経った今になって遅ればせながらやっているのは、Azure Functions (In-Proc) がようやく .NET 8 に対応したからです。それに引っ張られてずっと .NET 6 のままの運用を強いられていました。 それはそれとして、近年の .NET は互換性を高く保ちつつもちょこちょこと破壊的変更を入れて「よりあるべき姿」になろうと奮闘しています。その点については大変好感を持っていますし、実際これまでに幾度となく .NET のバージョンを上げてきたときも全くと言っていいほど破壊的変更を踏むことがなかったので若干過信していたところはあります。 が、今回検証過程で実際に遭遇して「うわ、危なッ」となる部分があったので紹介していきます。 実際にハマッた破壊的変更 2 選

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く