[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails

After spending the last few years embedded in AI-assisted development, I've noticed a fascinating pattern. While engineers report being dramatically more productive with AI, the actual software we use daily doesn’t seem like it’s getting noticeably better. What's going on here? I think I know why, and the answer reveals some fundamental truths about software development that we need to reckon with
何があっても開発だけは止めない。誕生29年、圧縮解凍ソフト「Explzh」作者の不屈【フォーカス】 2025年5月27日 圧縮解凍ソフト「Explzh for Windows」開発者 鬼束 裕之(pon software) フリーランスエンジニア。1996年に圧縮解凍ソフト「Explzh for Windows」を公開し、同年シェアウェア化。以来、29年間にわたってメンテナンス・保守を行う。2007年からは、個人での非商用利用に限ってはフリーウェアとして提供している。解凍に特化したフリーソフト「Archive Decoder」も公開している。 「Explzh for Windows」公式サイト 1996年から提供されている、「Explzh for Windows」(以下Explzh)という個人開発の圧縮解凍ソフトウェアがあります。 正式には「Explzh(エクスプローラエルゼットエッチ)」
Previous slideNext slideToggle fullscreenOpen presenter view TS特化Clineプログラミング mizchi / tskaigi 2025 mizchi: パフォーマンスチューニングの傭兵 一ヶ月で御社のプロダクトをコスパよく高速化します フロントエンド視点のE2Eチューニング(Lighthouse) CI/CD 高速化 (Linux, GitHub Actions) New プロンプトエンジニアリングでワークフロー自動化 主な環境 VSCode + RooCode (ほぼ常に Orchestrator モード) Claude 3.7 + Gemini 2.5 (約2~3万円/月) TypeScript / Node / Deno / Cloudflare あらすじ 2014: なぜ仮想DOMという概念が俺達の魂を震えさせるのか
これを記事にしている 2025 年 5 月の二年ほど前 (2023-06-02) に、縁あって明治大学 情報科学科での特別講義 [1] を担当させてもらいました。 身内の評判は悪くなかったのでスライドは公開していたんですが、単に Google Slides を公開状態にしただけだったんですね。 [2] これではあとから参照・引用するのも難しく、ちょっともったいないかと思ったので、いまさらながら記事の形でまとめなおしておくことにしました。 一年も経てば情報が古くなってしまうコの業界です。賞味期限切れの話もあると思いますが、話のネタにでもしてもらえれば幸いです。 講義の対象と目的 この講義、目的は2つあって、まず「最新の情報科学トピックに触れる」こと。 それから、就職活動が始まる3年生がメインの対象者なので、 今後のキャリアプランとか人生指針に関するいろいろな視点を持ってもらうことです。 この
はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 (@Mahito) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト (The official YAML Web Site) ではこう書かれています。 YAML is a human friendly data serialization standard for
今や、AIを活用してソフトウェア開発すること自体は一般的になり、一種のブームと化している。 しかし、Web上で見かけるのはワンショットでテトリスを作る程度の小規模なプロジェクトの話がほとんどで、驚けるものの、正直あまり実用性は無いように感じる。 俺たちが本当に知りたいのはテトリスの作り方じゃねえ!現実の中規模以上のシステム開発で、いかに楽に良いものを作れるかだろ! ということで、まずは弊社から現時点のノウハウを全公開しようと思う。 弊社ではCursorを1年以上活用(サービスがGAになったタイミングから全社員で利用)しており、一定のノウハウを蓄積してきている自負がある。ただ、あくまで一例ではあるので、ぜひみなさんの現場での活用事例も共有してほしい! 免責事項AIエディタでの開発は、LLMとAIエディタの進化に伴い、常に変化している。 そのため、この記事で述べる方法論は、現時点での、弊社での
class: center, middle # map / filter などの<br>高階関数よりも<br>古典的な for文の方が<br>読みやすいと感じる<br>あなたへ BuriKaigi 2025 2025/02/01<br> @gakuzzzz --- class: left, top ## 自己紹介 * 中村 学/Manabu NAKAMURA * Twitter: [@gakuzzzz](https://twitter.com/gakuzzzz) * [Tech to Value Co.,Ltd.](https://www.t2v.jp/) CEO * [Alp, Inc.](https://thealp.co.jp/) Tech Lead --- class: left, top ## はじめに 昨今のメジャーなプログラミング言語では、 `map` や `filter`
【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」登壇資料です。 https://techplay.jp/event/967093
Operating System in 1,000 Lines Hey there! In this book, we're going to build a small operating system from scratch, step by step. You might get intimidated when you hear OS or kernel development, the basic functions of an OS (especially the kernel) are surprisingly simple. Even Linux, which is often cited as a huge open-source software, was only 8,413 lines in version 0.01. Today's Linux kernel
同僚が書いた Go初学者へのコードレビューでよくあったコメント20選 では、Go初学者へのコードレビューでよくあったコメント20選を紹介しました。 今回は私が コードレビューでよくお願いするコメント追加のお願い について紹介します。 前提:コメントを書いて欲しいわけ コードレビューでコメントを書いて欲しい理由は以下の通りです。 プロダクト、サービスの持続可能な開発を支えるため 人が入れ替わっても開発の迷いを可能な限り減らすため 具体的なコメントの追加パターン ①変数やパラメーターの説明を書く コードを書く人にとっては必要があって構造体や変数を定義しているので自明ですが、第三者からすると解釈に悩むことがあります。 そのため誰が見ても自明でしょうという変数以外については注釈をいれます。 たとえば、User 構造体における ID は自明(どのような採番ルールか?みたいな疑問は出るが、ID を入力
これはなに? こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに? この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード(良いコード) vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版(Gihyo Digital Publishing、Amazon Kindle)をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く