GitHub、「Copilot Workspace」テクニカルプレビューを開始。ほとんど全ての開発工程をAIで自動化
GitHub、「Copilot Workspace」テクニカルプレビューを開始。ほとんど全ての開発工程をAIで自動化 テクニカルプレビューは上記のCopilot Workspaceのページからウェイトリストボタンをクリックして申し込みます。 Copilot Workspaceはほとんど全ての工程を自動化 Copilot Workspaceは、自然言語で書かれたIssue（課題）を基に、Copilotが仕様案と実装計画を示し、コーディングや既存のコードの修正を行い、ビルドをしてエラーがあればデバッグも行うという、プログラミングのほとんど全ての工程をCopilotが自動的に実行してくれる、というものです。 人間は各工程でCopilotから示される内容を必要に応じて修正するか、そのまま見守ることになります。 GitHub CEOのThomas Dohmke（トーマス・ドムケ）氏は、Copilot
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお
ソフトウェアエンジニアのライブラリアップデートの向き合い方 - Uzabase for Engineers
こんにちは。ソーシャル経済メディア「NewsPicks」NewsPicks Stage.事業のエンジニアをしています、林です。 業務では Next.js / Rust / Go などを用いて、経済・ビジネス情報に特化した動画配信サービスであるNewsPicks Stage.の開発・運用を行っています。 はじめに 突然ですが、皆さんは自身のソフトウェアのライブラリアップデートは行えていますか？ 皆さんはどのようにライブラリアップデートを行なっていますか？ 新機能を試したくて？ npm iで失敗してから頑張る？ Renovate / dependabot が自動Mergeされる環境？ もしくは対応担当が特定の日にまとめてMergeする運用？ しかし多くの開発者は、アップデートに対して「うまくいっている」と言えないのではないでしょうか？自身も様々なプロダクトを開発してきた経験上、日々の中ではどう
ポスト資本主義におけるソフトウェアエンジニア
1. はじめに 企業に務めるソフトウェアエンジニアにとって、生産性向上というフレーズは聞かない日がないほど身近なものです。私自身も日々の仕事が、チームや組織の生産性向上に寄与するかどうか、意識しながら働いています。そもそもソフトウェアエンジニアという仕事は、人を機械に置き換えるという性質上、生産性向上とは切っても切り離せないという関係性を超え、生産性を向上させる営みそのものと言っても差し支えありません。 では私たちソフトウェアエンジニアのDNAである生産性向上の出自は何処かと探っていくと、どうやら資本主義と共に拡大してきたイデオロギーであることが分かります。資本主義は無限の成長を志向するエンジンを内蔵しており、現在先進国に住まう私たちの生活の豊かさは疑いなく資本主義の恩恵に依拠しています。その一方で、200年以上稼働し続けるこの資本主義というシステムについて、昨今多くの学者と有識者がその綻
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
社内受託にならないエンジニアチームのつくり方 | Social Change!
先日（といいつつ結構前になりましたが）、私が社外取締役を務める株式会社クラシコムのエンジニア向けトークイベントに参加して、出番を頂いて話をしてきました。 クラシコムは、ECサイト「北欧、暮らしの道具店」を運営する会社で、商品コンテンツだけでなくドラマや映画、ポッドキャストを通じて世界観を発信しています。そうした様々な活動を支えるためにも、エンジニアチームを抱えてシステムを内製しています。 今回のイベントテーマは「社内受託にならないエンジニアチームのつくり方」で、私も含めクラシコムのテクノロジーグループが取り組んできた経験を話してきたので、本稿では私の話したことに加えて補足をいれながら言語化してみます。 社内受託になりがちな内製エンジニアチーム まず一般的な話ですが、事業会社におけるエンジニアチームの立ち位置は、場合によっては、同じ社内にもかかわらず一括請負の受託開発のように、決めたものを作
Dockerがコードネーム「Docker Debug」発表、コンテナ内に任意のデバッグツール群を一括導入、効率的なデバッグを実現。DockerCon 23
Dockerがコードネーム「Docker Debug」発表、コンテナ内に任意のデバッグツール群を一括導入、効率的なデバッグを実現。DockerCon 23 Docker社は米ロサンゼルスで10月3日と4日の2日間、年次イベント「DockerCon 23」を開催しました。 1日目の基調講演で、Dockerコンテナ内でのアプリケーションのデバッグを高効率化するDocker Desktopの新しい拡張機能「Docker Debug」（コードネーム）が発表されました。 コンテナのデバッグは面倒 一般にDockerコンテナは、使用メモリの最小化とセキュリティを高めるなどの目的で、余計なシェルコマンドやツールなどを徹底的にそぎ落としたOSの上にアプリケーションを載せた構成にします。 そのため、コンテナ内のアプリケーションに問題が発生し、その解決のために基本的な動作確認や設定確認などをしようとした場合で
財務諸表というフレームワークで考えるソフトウェア開発と技術的負債｜Yoshinobu Wakamatsu
この記事は「Funds Advent Calendar 2022」21日目の記事です。 ファンズ株式会社 CTO の若松と申します。 今年も例年通り Twitter の運用は三日坊主となり、 note についても筆を断ったまま2022年を終わりを迎えようとしていたところ、アドベントカレンダーの時期が来ていました。 せっかくの機会ではあるので、以前から漠然と思っていた考えを整理してみたいと思い、この記事では財務諸表を読み解く概念的な考え方を使い、技術的負債について読み解いてみることにしました。 ソフトウェア開発上の概念である"技術的負債"ファンズは、貸付ファンドのオンラインマーケット「Funds」を通じて、個人投資家には着実な資産運用の機会を提供しつつ、企業に対しては借入によるファイナンスの機会を提供しています。そのような事業業態の性質上、コーポレートファイナンス的な考えに触れる機会も一般的
内製するかSaaSに逃がすか
InternalManufacturing.md 概要 アプリやサービスをソフトウェアエンジニアが作るときに「ここはSaaSで賄いましょう」「ここは自作しましょう」みたいな判断を迫られがちです。 プロダクトごとに背景が違うので一般論は述べにくいですが、最近の僕の気持ちはこんな感じ、というのをまとめておきます。 // 極論すると、99%くらいのソフトウェアはSaaSを使ったから(勝った|負けた)みたいな短絡的な要素は無くて、それ以外のところで勝敗が決まることが多いです。なので好きにしたら良いという気もする。 ふつうの人間は、内製した方がえらい、というバイアスがある 要はバランス、ではあるが僕は内製箇所を少なくする方を提案することが多い SaaS導入のメリットデメリット 何を今更、ですが一応書いておきます。 メリット SaaSを作ってるのは賢い(?)人たちなので、内製するよりも競争力があるSa
そりゃスパゲティーコードにもなるよな - orangeitems’s diary
お気の毒に・・。 www.nikkei.com スパゲティコードになるプロセスはよーくわかる。 仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。 スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか？。 大企業のプロジェクト運用体制に、１つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当し
ソフトウェアはなぜバージョンアップしなければならないのか - Qiita
はじめに 社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。 特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。 そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは？」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。 この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。 ソフトウェアの有効期限は2-5年 まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。 なぜ
CTO から見た，なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck
Speaker Deck This deck requires a password Password
現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。 ソフトウェア開発に役立つプラクティスを示した本 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した本 ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て
ソフトウェア開発サイクルの改善を行う際に認識すべきボトルネックの種類 - stefafafan の fa は3つです
去年認定スクラムマスターになって、実際に自分の開発チームにScrumを導入したり、最近ではチーム内でテックリード交代して開発プロセスの高速化についてより考えるようになってきた。 Agile, Lean, XP, DevOps, Four Keys, Team Topologies など様々なフレーズを見かけたり本を読んだりしたところ大体皆同じ場所を目指していると感じるけど、イマイチ自分の脳内インデックスが貼れていない気がしたのでこのエントリで軽く考えを整理してみようと思う。 とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない) 開発速度が上がらない (ソフトウェア開発者側) Extreme Programmingのプラクティス DevOpsのプラクティス チーム内での連携が上手くいっていない チームの構成がイマイチ・他チームとの連携が上手く取れていない まとめ とにかく改善
『Joel on Software』を読んだ - 30歳からのプログラミング
Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。 Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。 ひとつひとつの章がかなり短い（長いものでも 20 ページくらい、短いものだと 4 ページほど）ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。 技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。 無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。 本書に収録されているのは 2000 年から 2004 年に書かれた記事なので
Marie Kondo your software stack with open source
As someone makes more money, expenses once considered luxuries can suddenly become seen as necessities: It’s called lifestyle creep. In the world of software development, we can suffer from a similar affliction: stack creep. Where hardware limitations once restricted developers to a minimalist approach, increased processing power, memory, and storage have led many down a more maximalist path. It’s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity
IPA、「重要情報を扱うシステムの要求策定ガイド」を公開 3ステップでシステムの要求策定を支援
/uses
ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide
