AI時代のコードを書かないソフトウェア開発 | Social Change!
ChatGPTなど生成AIの著しい進化によって、これまで人にしかできないとされてきた知的労働も代替される場面が増えてきました。 この先さらにAIが賢くなり、誰もが手に入れられるような時代になったら、知性だけでは価値を生み出すことができなくなるかもしれません。 そんな時代に、ソフトウェア開発はどのように変化していくのか。本稿で考えてみます。 ソースコードを書くことはプログラミングの一部にすぎない 「AIによってプログラマは不要になる」という言説は、プログラマの仕事は何か？を定義しないと議論に誤謬が生じます。 「ソースコードを書くこと」をプログラミングと呼ぶのであれば、その仕事は無くなってしまう可能性が高いでしょう。かつて「ソースコードを打ち込むこと」を仕事としたコーダーという職業は、今はありません。 しかし、「ソフトウェアを生み出すこと」をプログラミングとするならば、そう簡単には無くなりませ
開発人生25年で学んだ7つのソフトウェア原則（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Seven things I know after 25 years of development 原文公開日: 2025/01/27 原著者: zverok 日本語タイトルは内容に即したものにしました。 本記事は、私が2024年9月にEuRuKoカンファレンスで行ったキーノートスピーチを大まかに記事化したものです（スピーチの動画はこちらです）。残念ながら録画という形での登壇でしたが、それでも大変光栄なことでした。このテーマは私にとってとても重要なので、テキストで読みたい方のために、本記事で少々手を加えた形で公開することにいたしました。 私はかれこれ25年にもわたってソフトウェア開発に携わってきました。 そのうち20年間はメインの言語としてRubyを用いてきました。 私のRuby言語への貢献や、その他オープンソースへの貢献について
Rails: 「個人開発フレームワーク」で100万ユーロ/年を稼ぐまでの体験談 （翻訳）｜YassLab 株式会社
原著者の許諾を得て翻訳・公開いたします。 英語記事: The One-Person Framework in practice 原文公開日: 2025/04/20 原著者: Bram Jetten 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 One-Person Frameworkは「個人開発フレームワーク」と訳しています。 2022年の初めのことでした。私たちが運営している PlanGo というビジネス（訳注: オランダの自動車教習所向けのソフトウェア）の年間経常収益を集計してみたところ、共同創業者と私は信じがたい瞬間を共にしました。同社の年間経常収益が100万ユーロ（訳注: 約1億6300万円）という重要なマイルストーンをついに突破していたのです。たった1つのRailsコードベースとたった1人の開発者（=私）で構成されている企業がこのような瞬間を迎えると
感想: Tidy First?―個人で実践する経験主義的ソフトウェア設計｜llll
あらすじは以下の通り。 乱雑なコードは厄介です。コードを読みやすくするには、管理できる小さなまとまりに分割する必要があります。本書は、エクストリームプログラミングの考案者で、ソフトウェアパターンの先駆者であるケント・ベックが、システム全体の構造を念頭に置き、コードを改善するには、いつどこで整頓するのがよいかを解説します。 整頓のしかたを一気に習得するのではなく、整頓を少しずつ試しながら自身の課題解決につなげます。コード行数の多い大きな関数については論理的にコードを小さなチャンクに分割する方法を学び、その過程で、結合、凝集、ソフトウェアシステムの経済的価値（ディスカウントキャッシュフローやオプショナリティ）などソフトウェア設計の背後にある重要な要素を解説します。また、ソフトウェア設計の基礎理論とそれに作用するフォース、システムにおけるふるまいの変更と構造の変更の違い、先に整頓したりあとに整頓
『Ruby on Railsパフォーマンスアポクリファ』 - snoozer05's blog
翻訳を担当した電子書籍『Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。 Ruby on Rails パフォーマンスアポクリファ 本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。 The Ruby on Rails Performance Apocrypha The Ruby on Rails Performance Apocrypha: A starter guide to making Rails apps faster and more scalable (English Edition) 作者:Berkope
Writebook
What kind of books can I publish? Whatever you’ve written is ready for Writebook. No publisher, no gatekeeper, no permission necessary. Just write it. Instruction manuals. Publish a manual to go along with a piece of software, hardware, or a process that needs simple, clear documentation. Like the Writebook Manual itself. Graphic novels. Writebooks offer a picture-page type so you can have a book
自由なソフトウェアと抗議と倫理の「（不）可能性」について
自由なソフトウェアと抗議と倫理の「（不）可能性」について 2022.05.10 Updated by yomoyomo on May 10, 2022, 18:15 pm JST 大変ごぶさたしております。実に約5年半ぶりになりますが、またこちらで書くことになりました。ブランクが長かったため、ここへの文章の書き方を自分でも忘れてしまったところがあるのですが、稲田豊史氏の「ウェブは最初に結論を書く、くどくど掘り下げて説明しない、とにかく簡潔に」という金言に逆らい、地味な話題についてくどくどと書いていこうと思います。 いや、結論だけは先に書いておきましょうか。銀の弾はない、それだけです。 2022年2月にロシアがウクライナへの侵攻を開始して早くも2カ月以上経ち、ロシア（のプーチン大統領）の甘い見通し、予想以上のウクライナの抵抗、多くの国のウクライナへの支援などと相まって、現状、ロシアが手こずっ
倫理を振りかざすライセンスが好ましくないのは何故か？
オープンソースが社会で受容されるにつれ、コミュニティの中においても一定の倫理が求められる傾向が強まっている。Code of Conduct(行動規範)を定める開発プロジェクトが多くなったのもその流れだろう。しかしながら、ライセンスによって使用者に対して倫理的な行動を求めることは現在に至っても忌避されており、それを悪だと看做す人々も多い。これは何故だろうか？ (本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。) 嫌いな奴を排除する 大抵の人には嫌いな人がいるものだ。人間とはそのようなものだろう。その嫌いな人々に自分が開発したソフトウェアを使わせたくないという感情を持つことを中々否定できるものではない。そして、ソフトウェアの開発者には開発したソフトウェアに対する著作権が帰属する。著作権に基づいて第三者に対しソ
「作りたいものをいかに早く完成させるかが正義」 まつもとゆきひろ氏が語る、ソフトウェア開発におけるベロシティの重要性 | ログミーBusiness
今回のテーマは「動的型付け言語と大規模開発まつもとゆきひろ氏：こんにちは。まつもとゆきひろです。Matzチャンネル、18回目になりますね。今日は前回の続きで、「動的型付け言語と大規模開発」について話そうと思います。 本当は前回放送リリースした次の日ぐらいに放送できるようにと思っていたんですけど、意外と忙しくてですね（笑）。 今度、フィンランドのヘルシンキで、「Euruko」というカンファレンスが開かれるんですけれども、まだ物理で海外旅行する気にならないので、キーノートを録画しましょうという話になって、そのキーノートの準備をして、スライドを書いて、英語の講演を録画するみたいな作業をしていたら、あっという間に時間が経ってしまって、「Voicy」が後回しになってしまったというのが正直なところですね。でも、前みたいに2ヶ月も空けたりしないので、今後ともがんばろうと思います。 先に決めた型をガイドに
The Ruby on Rails Resurgence - DevOps.com
The Ruby on Rails Resurgence Ruby combines functional and imperative programming to create an easy-to-use, powerful language where everything is an object. Introduced in 1995, the open source programming language became popular in the 2000s during the dot-com era, when developers at startups and established companies were under pressure to rapidly launch new web applications. Ruby on Rails, releas
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
コンパウンドスタートアップというLayerXの挑戦｜福島良典 | LayerX
どうも、すべての経済活動を、デジタル化したい福島です。 本日はLayerXが挑戦するコンパウンドスタートアップについて解説したいと思います。 コンパウンドスタートアップとは、Ripplingという米国のスタートアップ のCEO Parker Conradさんが提唱しているスタートアップの新たな競争戦略です。Parker Conradさんはユニコーン企業Zenefitsの元CEOであり、Zenefitsでの失敗の経験を元に、Rippplingを創業。コンパウンドスタートアップという従来のセオリーとは異なるやり方で大成功を収めています。 Ripplingは20年8月にユニコーン入りしており、日経記事でも紹介されています。 TLDR(長すぎて読めないよという方に) コンパウンドスタートアップとは 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 部署でサービスを区切るのではなく、デ
“変化の拒絶”か“過剰な進化か”——求められるトレードオフ ソフトウェアが進化し続けるために必要なこと | ログミーBusiness
「Visionとリーダーシップ」というタイトルで登壇したのは、Ruby開発者のまつもとゆきひろ氏。30年続くRuby開発の中で学んだ「リーダーの役割」を、日本CTO協会主催の「Developer eXperience Day 2023」で発表しました。全3回。3回目は、ソフトウェアプロダクトが生き延びて進化し続けるためのトレードオフについて。 「Ruby3.0はRuby2.0よりも3倍高速にしよう」とぶち上げたまつもとゆきひろ氏：さて、もう8年になるのか（笑）。8年ぐらい前に「Ruby3x3」という別のRubyのコミュニティのスローガンを立ち上げました。意味としては「Ruby3.0というバージョンを、Ruby2.0というバージョンよりも3倍高速にしよう」という開発者のためのゴールであり、スローガンです。 ある処理を3倍にするというのは、あまり簡単なことではないんですよね。これは、だいぶ困難
iOS 17、本日提供開始
本日から無料のソフトウェアアップグレードとして提供されるiOS 17は、連絡先ポスター、新しいステッカー体験、ライブ留守番電話などにより、コミュニケーション体験をアップグレードします。 iOS 17では、充電中のiPhoneの体験が新しくなるスタンバイ、AirDropでのさらに簡単な共有、タイピングのスピードと正確さを向上させるより賢い入力など、コミュニケーションアプリの大幅なアップデートにより、iPhoneがさらにパーソナルで、直感的になります。iOS 17は、本日より無料のソフトウェアアップデートとして提供されます。 電話アプリはiPhone体験の中心にあり、大幅なアップデートによって大切な通話が今よりもさらに目をひくようになります。パーソナライズされた連絡先ポスターは、他社製の通話アプリも含め、ユーザーが登録されている連絡先に電話をかけた時の自分の見た目をカスタマイズして、自分を表現
きれいなコードを書けという話について - Software Transactional Memo
前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪
GPTのモデル構造を可視化した｜shi3z
GPTのモデル構造を目で見てみたい! そんな気持ち、わかるでしょ? 技研フリマをやりながら、どうにかこうにか出力したよ ご覧あれ やり方メモ from transformers import AutoTokenizer, AutoModelForCausalLM from torchviz import make_dot tokenizer = AutoTokenizer.from_pretrained("gpt2") from transformers import pipeline, set_seed generator = pipeline('text-generation', model='gpt2') m= generator.model x= m.generate() y= m.forward(x) image = make_dot(y.logits, params=dict(
マイクロサービス – 分散された大きな泥だんご | POSTD
モノリシックがダメだからといって、マイクロサービスが解決策になるわけではない ソフトウェア開発業界は流行に左右されやすいという証拠に、今マイクロサービスが、いたるところで大騒ぎされています。”次の大ブーム”だと思う人もいるでしょう。また、（10年前に”上出来”と見なされたような）大型のSOA、サービス指向アーキテクチャが単に軽量化して進化したものだと捉える人もいるでしょう。私は現在のマイクロサービスアーキテクチャに関しては好意的に見ています。しかし、だからといってこのアーキテクチャは決して万能薬ではありません。言うまでもないことかもしれませんが、多くの人が間違った理由でマイクロサービスに飛び付いているように思えるのです。 これは私の講演でよくお見せするスライドで、 以前ブログにも書きましたた が、ソフトウェアシステムを開発するにはいろいろな方法があります。まず、昔ながらのモノリシック（一枚
オープンソースビジネスの挑戦と現実｜Rui Ueyama
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「社会的責任」からじゃない。 趣味でつくって、おすそ分け。──まつもとゆきひろ｜WIRED.jp
ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へ | Social Change!
