「WinMerge」って画像の比較もできたんだ……しかも、10年前から／比較できるのはテキストファイルだけじゃないぞ！【やじうまの杜】
米ホワイトハウス「将来のソフトウェアはメモリ安全になるべき」と声明発表。ソフトウェアコミュニティに呼びかけ
米ホワイトハウス「将来のソフトウェアはメモリ安全になるべき」と声明発表。ソフトウェアコミュニティに呼びかけ 米ホワイトハウスの国家サイバー局長室（The White House Office of the National Cyber Director：ONCD）は、サイバー空間における攻撃対象領域を積極的に削減する目的で、テクノロジーコミュニティやソフトウェアコミュニティに対してメモリ安全（Memory Safe）なソフトウェアの実現を積極的に呼びかけるプレスリリース「Future Software Should Be Memory Safe」（将来のソフトウェアはメモリ安全になるべき）を発表しました。 プレスリリースの中で、国家サイバー局長Harry Coker氏は「私たちは国家として、サイバースペースにおける攻撃対象領域を減らし、あらゆる種類のセキュリティバグがデジタルエコシステムに
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
4年後までにソフトウェアテストの70％を生成AIが作り、コードの品質は向上するようになるとの予測、IDC
4年後までにソフトウェアテストの70％を生成AIが作り、コードの品質は向上するようになるとの予測、IDC 調査会社のIDCは、4年後の2028年までに生成AIベースのツールがソフトウェアテストの70%を作成できるようになり、手動テストの必要性が減り、テストのカバレッジが向上することで、ソフトウェアのユーザービリティとコードの品質向上が実現するとの予測を発表しました。 同社によると、生成AIによるテストスクリプトの生成や管理などを含むテスト自動化は日本を除くアジア太平洋地域で特に人気が高まっており、開発者とDevOpsの専門家がこれらの技術を活用することで、ソフトウェア開発全体の自動化をより推進していくことになるとのことです。 また生成AIはレガシーアプリケーションのコードに対するリファクタリングも促進するとしており、2027年までにリファクタリングに関わるコードの変換や開発タスクの50％が
2023年、特に感動した・気に入った フリーソフト
本日は、2023 年中に紹介したフリーソフト の中から 特に感動した・気に入った というものを、22 個 ピックアップして紹介しようと思います。 2022年、特に感動した・気に入った フリーソフト 2021年、特に感動した・気に入った フリーソフト 2020年、特に感動した・気に入った フリーソフト / ウェブサービス パスワード管理 動画キャプチャー、OCR RSS リーダー 動画 音楽 画像 5 ちゃんねる リモートコントロール 絵文字入力 翻訳 アプリ管理 マウス操作視覚化 ファイル共有 生成 AI パスワード管理 KeePassXC KeePassXC クロスプラットフォームに対応した高機能パスワードマネージャーです。 ウェブサイトのユーザー ID / パスワード / メモ をはじめ、重要な個人情報等を暗号化されたデータベースに保管しておけるようにしてくれます。 定番のパスワードマ
求められるSBOM対応、ソフトウェアのリスク管理は「待ったなし」、さあどうする？
求められるSBOM対応、ソフトウェアのリスク管理は「待ったなし」、さあどうする？：OSS活用の際に直面する“3つの課題”と自社システムの脆弱性にどう立ち向かうか 各国政府や国際機関が、SBOMなどを通じたサイバーセキュリティやソフトウェアのサプライチェーンへの取り組みを急速に進めている。これは人ごとではない。各国政府や、業界団体は、制度化や国際標準化により企業への対応を強く求めている。今後、企業にはどういうアクションが求められるのだろうか。 高まるSBOM導入の機運、継続的な監視／運用の体制作りが重要に ここ数年で、オープンソースソフトウェア（OSS）の利用リスクに大きな注目が集まるようになった。「Apache Log4j」で明らかになった脆弱（ぜいじゃく）性の問題は、今やOSSがあらゆるところで使われており、セキュリティ上の問題がもたらす社会的インパクトが大きいという事実を浮き彫りにした
経済産業省、「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」公開。環境構築、SBOM作成、運用管理など解説
経済産業省は「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を策定し公開したことを明らかにしました。 SBOMは日本語では「ソフトウェア部品表」とされます。あるソフトウェアがどのようなソフトウェア部品によって構成されているのかを示す情報がまとまったデータのことです。 ほとんどのソフトウェアは単独で成立しているわけではなく、オープンソースを始めとする多数のライブラリやコンポーネントなどのソフトウェア部品に依存しています。そのなかのいずれかに脆弱性が発見されればドミノ倒しのように他のさまざまなソフトウェアに影響することは必至です。 例えば2021年末に発覚したJavaライブラリ「Log4j」の脆弱性は、非常に幅広いJavaのソフトウェアに深刻な影響を与えました。 多くの産業や社会インフラにおいてソフトウェアの存在が欠かせなくなってい
ソフトウェア開発上の問題や課題をビジネスリーダーや経営者らの関心事とするために - mtx2s’s blog
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。
従来とアジャイルで、品質メトリクスには本質的な違いがあるのではないか - ソフトウェアの品質を学びまくる
ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されて
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
2022年、特に感動した・気に入った フリーソフト
指定した音声ファイルを、楽器ごとのパートに分解してくれるソフトです。 音声ファイルをドラッグ＆ドロップで放り込むと、該当のファイルを ボーカル ベース ドラム その他（キーボード、ギター 等） ボーカル以外のインストゥルメンタル といった 5 つのファイルに分解してくれます。 処理を GPU（CUDA）で実行することもできます。
ソフトウェアテストの実行を効率化するPredictive Test Selectionの衝撃 - Qiita
12月10日の2022ソフトウェアテストアドベントカレンダーです。 Launchable社でエンジニアとして働いているcvuskと申します。機械学習界隈では機械学習を実用化するためのシステム開発の本を書いてたります。もし良かったら読んでみてください。 『機械学習システムデザインパターン』 『機械学習システム構築実践ガイド』 本ブログでは機械学習を用いてテスト実行を効率化する手法として、Predictive Test Selectionについて説明します。テスト実行時間やコストで課題を抱えているエンジニアに役に立つと幸いです。 昨今の開発におけるテスト事情 2002年に『テスト駆動開発』が世に出て、ソフトウェア開発でテストを書くことが常識になって早20年が経っています。その間にクラウドの登場やDevOpsの普及により、テストをCI/CDパイプラインで自動実行し、コードとプロダクト品質を維持す
ソフトウェアエンジニアとしての最初の10年 - cockscomblog?
働き始めてから丸10年経った。 2012年、僕は北海道に住む大学院生で、趣味としてプログラミングを楽しんでいた。Appleのファンだから、macOSやiOSのアプリケーションを開発して、ちょっとでもAppleに近づいたような気持ちになっていた。その夏1ヶ月のインターンシップに参加した。インターンシップで、それまで趣味だったプログラミングが突然違った価値を持ち始めて、これを仕事にしないといけないと思うようになった。それで、両親や先生に謝って、大学院を退学して、インターン先の会社に正社員として入社した。それが2012年11月のことで、それから10年間、株式会社はてなで働いている。 この業界では、10年同じ会社で働いているというと、ちょっと珍しい部類なのかなと思う。とはいえ社内ではそれほど珍しくもなくて、あまり気にならない。いろいろなプロダクトを夢中になって開発していたら、いつの間にか10年経っ
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
「ソフトウェア開発」と「プロダクト開発」は違う｜市谷 聡啓 (papanda)
執筆をしていて、時々迷うことがある。 「ソフトウェア開発」と書くべきか、「プロダクト開発」と書くべきか。 手元の行為としては同じでも、この2つの言葉の間には隔たりがある。 何げなく使っている言葉であっても、突き詰めて捉えていくと違いに気づくことができる。言葉を丸めたまま扱うと、それ以上理解が深まることはない。大事なテーマであるほど、使う言葉に気を払うようにしたい。「ソフトウェア開発」と「プロダクト開発」この言葉の違いを、置いている「目的」から捉えてみよう。 ソフトウェア開発の目的とは、ソフトウェアを作ることにある。ソフトウェア開発と称して「作らない」ということは稀だろう。どのようにソフトウェアを作るか、という観点に焦点があたりやすい。ときとして、ソフトウェア作りそのものが「こだわり」へと昇華していく。 一方、プロダクト開発の目的とは、プロダクトを利用してもらうことにある。プロダクトを提供し
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「FastCopy」のファイルコピーが9倍に!? 「Microsoft Defender」除外オプションが追加／Windowsプラットフォームで最速を謳うファイルのコピー・削除ツール
良いソフトウェアとコードレビュー / Good software and code review
ホンダ、ソフトウェア人材1万人に倍増 トヨタは9000人再教育 【イブニングスクープ】 - 日本経済新聞
【特集】 【定番動画編集ソフト入門】これだけ読めば基礎が身につく DaVinci Resolve 18。ハリウッドプロ御用達で基本無料
