Google、オープンソースソフトウェアの脆弱性をバージョンごとにデータベース化する「OSV」（Open Source Vulnerabilities）プロジェクトを開始
Googleは、オープンソースで開発されているソフトウェアの脆弱性がどのバージョンで生じ、どのバージョンで修正されたかなどの詳細をデータベース化する「OSV」（Open Source Vulnerabilities）プロジェクトの開始を発表しました。 オープンソースはクラウド基盤からアプリケーションまで、さまざまな場所で重要な役割を果たすようになってきています。そのため、正確な脆弱性情報の管理もまた重要さを増しています。 OSVにより、オープンソースソフトウェアの開発者やメンテナは手間がかかっていた脆弱性の報告が容易になります。 利用者はオープンソフトウェアの脆弱性がいつ修正されたのかなどの正確な情報を簡単かつ一貫した方法で得られるようになり、利用するソフトウェアの脆弱性の管理と対応を迅速かつ容易にできるようになります。 バグの再現手順を提供すればOSVが自動的にバージョン情報などを探索
ソフトウェアアーキテクチャ・ ハードパーツ: Software Architecture The Hard Parts
ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12 での発表資料です https://forkwell.connpass.com/event/265858/ 動画: https://www.youtube.com/watch?v=6eCiC8oISYc …
この前職務経歴書を書いたので、そのとき色々考えたり調べたりしたことを書きます。 一般的な転職活動の職務経歴書は微妙だった 僕の転職は二回目です。 一回目の転職のときは、リクルートエージェントのサービスを使って転職しました。 リクルートが公開している、一般的な職務経歴書のサンプルは↓こんな感じです。 Wordで表をつくって、編年体に、何をやってきたかを書くことで、自分の職務経歴を書きます。 ただ詳細はちょっと長くなるので、職務経歴書の冒頭に数行でサマリーが書いてあって、親切ですね。 一般的な日本の職務経歴書というのは、このフォーマットで問題ありません。 実際一回目の転職のときは僕もこのフォーマットで転職しています。 二回目の転職活動も、この職務経歴書に二社目の経験を追記すればいいか、と思っていましたが、 見れば見るほどこのフォーマットで書いた自分の職務経歴書が微妙に感じてきました。 何が微妙
タグ 61式戦車バングラディシュ軍モロッコ軍メルカバポーランド軍ベラルーシ軍ブルガリア軍フランス軍フィンランド軍フィリピン軍ハンガリー軍ラインメタルパキスタン軍ノルウェー軍ナイジェリア軍トルコ軍ドイツ軍デンマーク軍チャレンジャー3チャレンジャー2チャレンジャー1ヨルダン軍ラオス軍タイ軍対空砲陸上自衛隊軽戦車米陸軍米軍米海兵隊米宇宙軍第一次世界大戦水陸両用車対空兵器リトアニア軍台湾軍北朝鮮軍中国軍中国人民解放軍ロシア軍レオパルト2レオパルト1ルクレールルーマニアチェコ軍センチュリオン99式戦車MGCST-84T-80T-72T-64T-62T-55T-54T-14M60UAE軍M48M47M2bradleyM109KF51K2HIMARSBMPTBMP-1T-90VT-4セルビア軍エチオピアスロベニア軍スペイン軍スウェーデン軍スイス軍クェートキプロス軍カナダ軍オランダ軍オーストラリア軍エイブ
回答 (21件中の1件目) 案件ですね。 「○○を作れ」という方がきっちりと仕様書を起こしてくれるなら問題ないのですが、要求仕様に対する「納入仕様書」を起こします。 それで依頼者と合意を取った上で設計に入ります。 「プログラミング言語ですか？デザパタですか？」何を言っているんでしょうね。そんなの後回しです。「まず、何を作るのか」が一番最初に来ます。 https://note.com/hantani/n/ndf51c3ece4ae 普段プログラム作る時も大体同じです。 案件定義 ユースケース シーケンス図 クラス図 ーーー（ここまではプログラム言語に依存しません）－－－ ...
本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号｜技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない） 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務
フロム・ソフトウェアは“面白いゲームを真剣に作っていればそれでいい”。宮崎英高社長に聞く，「ELDEN RING」で目指したものや独特の開発体制
フロム・ソフトウェアは“面白いゲームを真剣に作っていればそれでいい”。宮崎英高社長に聞く，「ELDEN RING」で目指したものや独特の開発体制 編集部：御月亜希 ライター：大陸新秩序 カメラマン：増田雄介 「DARK SOULS」シリーズや「Bloodborne」，「SEKIRO: SHADOWS DIE TWICE」（PC/PS4/Xbox One）などを代表作に持ち，アクションRPGで世界的にも評価の高いフロム・ソフトウェア。2022年2月にリリースされた「ELDEN RING」（PC/PS5/Xbox Series X/PS4/Xbox One）は，発売から1か月も経たずに世界累計出荷本数1200万本，国内累計出荷本数100万本を突破した大ヒット作となり，同社のタイトルに触れた人はさらに広がっていくだろう。 高難度のアクションRPGという，ニッチなはずのジャンルでありながら，これだ
成長しない日本のソフトウェアスタートアップ 国内競争を促進してエコシステムを創出する | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
IPA調査分析ディスカッション・ペーパー2023-01 公開日：2023年9月14日 独立行政法人情報処理推進機構 調査分析室 鷲見 拓哉 当機構が日米のソフトウェアスタートアップを対象に実施したアンケート調査により、アンケートに回答した日本のソフトウェアスタートアップの多くは、創業後10年間でほとんど成長していないことが明らかとなった。 本ディスカッション・ペーパーでは、成長するビジネスモデルを見いだす「ビジネスモデル探索活動」に特に着目して、日本のソフトウェアスタートアップが抱える課題とその解決策について考察する。 1．はじめに 昨今、ディスラプターの出現により企業の競争環境は急激に変化している。経営においても、業務効率化、コスト削減等の従来から言われる観点に加えて、外部環境変化に如何に迅速に対応し事業を展開するかという「アジリティ」の観点が求められるようになった。顧客に対して如何に早
面白い課題を解決したいソフトウェアエンジニアへ ── 複数の専門性が交わるところで「今できないこと」をやる - Findy Engineer Lab
はじめまして、田籠聡（@tagomoris）です。現在はフリーランスのソフトウェアエンジニアとしていくつかの会社で技術顧問をしつつ、個人的なプロジェクトの開発をしたりしています。これまでのキャリアとしてはISPやSIerで働いたのち、livedoor（およびその後のLINE）や、Treasure Dataといった会社で働いてきました。また、みなさんがご存じかもしれないものだと、ISUCONというイベントを始めたり、データ分析基盤関連の技術やFluentdをはじめとしたOSSプロダクトの開発に関わったりしています。 自分のキャリアを振り返ると、これまでいろいろと面白いプロダクトやサービスに関われてきました。一方で、自分にとって面白いプロダクト・面白い開発とは何かということが、経験を積むにつれて変化してきたとも思います。この記事では、何を面白いと思うか？ どうやって面白いものに関わり続けていく
www.oreilly.co.jp 目次はこちら 第1部 主題 1章 ソフトウェアエンジニアリングとは何か 第2部 文化 2章 チームでうまく仕事をするには 3章 知識共有 4章 公正のためのエンジニアリング 5章 チームリーダー入門 6章 スケールするリーダー 7章 エンジニアリング生産性の計測 第3部 プロセス 8章 スタイルガイドとルール 9章 コードレビュー 10章 ドキュメンテーション 11章 テスト概観 12章 ユニットテスト 13章 テストダブル 14章 大規模テスト 15章 廃止 第4部 ツール 16章 バージョンコントロールとブランチ管理 17章 Code Search 18章 ビルドシステムとビルド哲学 19章 GoogleのコードレビューツールCritique 20章 静的解析 21章 依存関係管理 22章 大規模変更 23章 継続的インテグレーション 24章 継続的
特集 - ソフトウェア開発者／有限会社サイトー企画代表 秀まるお氏 インタビュー | REALFORCE | 日本製プレミアムキーボードの最高峰
「秀丸」という2文字を見て即座に反応できた人はかなりのベテラン PC ユーザーか、もしくは上級（？）クラスの PC ユーザーと言うことになるかと思う。 そう、「秀丸」とはインターネット全盛期の現在よりも前の「パソコン通信時代」（パソ通時代）から "痒いところに手が届く" 数々の名作シェアウェア（+フリーウェア）を世に送り出してきた、秀まるお氏のソフトウェアブランドのことだ。今回は Realforce のヘビーユーザーとして、あの伝説のシェアウェア（+フリーウェア）作家であられる秀まるお氏をお迎えして、「プログラマー目線からのキーボードへのこだわり」について伺った。 伝説のシェアウェア作家、秀まるお（斉藤秀夫）氏のプロフィール パソ通全盛期からインターネット全盛期を駆け抜けた自分のような人間からすると、秀まるおさんといえば「伝説のシェアウェア作家」というイメージが強く、私だけでなく読者の多く
マイクロソフト、ビルド時にソフトウェアの部品表（SBOM）を自動生成する「SBOM Tool」、オープンソースで公開
マイクロソフト、ビルド時にソフトウェアの部品表（SBOM）を自動生成する「SBOM Tool」、オープンソースで公開 マイクロソフトは、ビルド時にそのソフトウェアがどのようなソフトウェア部品から構成されているかを示すデータ「SBOM」を生成してくれるツール「SBOM Tool」を、オープンソースで公開しました。 SBOMによるサプライチェーンリスクの解決 SBOMとはSoftware Bill Of Materialsの頭文字をとったもので、日本語では「ソフトウェア部品表」とされます。あるソフトウェアがどのようなソフトウェア部品によって構成されているのかを示す情報がまとまったデータのことです。 ほとんどのソフトウェアは単独で成立しているわけではなく、多数のライブラリやコンポーネントなどのソフトウェア部品に依存しています。そのなかのいずれかに脆弱性が発見されればドミノ倒しのように他のさまざま
（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました） エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 （個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。） そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる
フルタイムでオープンソース・ソフトウェアを開発すると開発者にはどういう変化が訪れるか(個人の感想レベル)
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Fastlyが大規模障害の経緯を公開、原因はソフトウェアのバグ。障害を1分以内に検知し、49分でおおむね復旧させたと報告
Fastlyが大規模障害の経緯を公開、原因はソフトウェアのバグ。障害を1分以内に検知し、49分でおおむね復旧させたと報告 CDNベンダ大手のFastlyが日本時間6月8日夕方に障害を発生、その影響は国内にもおよび、メルカリや楽天市場、Amazon.co.jp、Twitter、ABEMAなど多くのサービスに接続できないなどの障害が発生しました。 We identified a service configuration that triggered disruptions across our POPs globally and have disabled that configuration. Our global network is coming back online. Continued status is available at https://t.co/RIQWX0LWwl
IT業界は人材の入れ替わりが激しいことが知られており、有能な開発者は好待遇を求めてさまざまなチームを渡り歩いているほか、企業側も不景気時には積極的に人員整理を行います。ところが、ソフトウェア開発チームの運営に関する複数の著書を持つBaldur Bjarnason氏は、「プログラマーを解雇して新しい人員に置き換えることは、ソフトウェアにとって致命的になり得る」と主張しています。 Theory-building and why employee churn is lethal to software companies – Baldur Bjarnason https://www.baldurbjarnason.com/2022/theory-building/ Bjarnason氏はソフトウェアのプログラマーを庭師にたとえた上で、「ソフトウェアは一時的な庭であり、その運命は庭師と密接に関わっ
経済産業省、「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」公開。環境構築、SBOM作成、運用管理など解説
経済産業省は「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を策定し公開したことを明らかにしました。 SBOMは日本語では「ソフトウェア部品表」とされます。あるソフトウェアがどのようなソフトウェア部品によって構成されているのかを示す情報がまとまったデータのことです。 ほとんどのソフトウェアは単独で成立しているわけではなく、オープンソースを始めとする多数のライブラリやコンポーネントなどのソフトウェア部品に依存しています。そのなかのいずれかに脆弱性が発見されればドミノ倒しのように他のさまざまなソフトウェアに影響することは必至です。 例えば2021年末に発覚したJavaライブラリ「Log4j」の脆弱性は、非常に幅広いJavaのソフトウェアに深刻な影響を与えました。 多くの産業や社会インフラにおいてソフトウェアの存在が欠かせなくなってい
ありがたいことに、いわゆる文系・ビジネス職からベイエリアでソフトウェアエンジニアになった前回の記事は多くの方に読んでいただきました。改めてお礼を申し上げます。とはいえ、当然ですが、ソフトウェアエンジニア（以下、SWE）になって終わりではなく、SWE になってからもそれ以上に大切であり、実際に SWE 転向後、どのような経験をしたのか、現実的な点も含めて、この記事では書いてみようと思います。 結論から言うと、初めは知識や経験の浅さから苦労しましたが、最終的には社内査定でも最高評価をいただき、なんとか昇進、異動する運びとなりました。 SWE になってみてまず、ポジティブな面から、状況整理も兼ねてお話しすると、自分は多くの方に使っていただいている製品・機能の Android アプリ（≠ Android OS）及び、そのバックエンドを担当することになりました（つまり、Android アプリがメイン
年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。 ソフトウェア開発に役立つプラクティスを示した本 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した本 ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;
ソフトウェアテストに関する知識をもう少し言語化したいなと思い、「はじめて学ぶソフトウェアのテスト技法」を読んだ。 はじめて学ぶソフトウェアのテスト技法 作者:リー コープランド日経BPAmazon この本では主に良いテストケースの作成手法について学べた。良いテストケースとは「最小の時間と労力でほとんどのエラーを検出する可能性がもっとも高くなるようなテストケース」のこと。これにできる限り近づけられるようにテストケースを工夫する。 良いテストケースを作るためにどういう技法があるかをこの本はいくつも教えてくれる。自分がこれまでテストを書いていると「こういうテストの方がなんとなくベターだよな...?」みたいに感覚的に考えていたところを、言葉として定義してくれることで構造化できるのはありがたかった。たとえば 同値クラステスト 同じグループのテストが、以下を満たせば同値クラスを形成する 同じ機能をテス
『ドメイン駆動設計をはじめよう』の概要説明 ①この本で学んでほしいこと（原著者の思い） ②原著者のドメイン駆動設計のとらえ方 ③この本の特徴 ④ソフトウェア実装と事業戦略を結びつける方法 ⑤事業の成長とソフトウェアの成長 ⑥開発チームの学習と成長
自律型AIソフトウェアエンジニア「Devin」発表。課題から情報収集して環境構築・ビルド・デプロイまで | テクノエッジ TechnoEdge
ITジャーナリスト／Publickeyブロガー。IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。 AIスタートアップのCognitionは、自律型のAIソフトウェアエンジニア「Devin」を発表しました。 Devinは人間が課題を与えると、自律的に情報を参照し、コーディングやデバッグ、デプロイを行い、システム構築を実現するAIソフトウェアエンジニアだと説明されています。 Cognition AI CEOのScott Wu氏以下はデモ動画からのキャプチャです。 Devinは人間のソフトウェアエンジニアと同様に、自身のコンソール画面（右上）、コードエディタ（右下）、Webブラウザ（左下）を持っています（左上は人間とチャットでやり取りする領域）。 人間がプロンプトで何らかの課題を与えると、まず課題解決のためのプランを生成します。 今回、Dev
ソフトウェアテストはなぜやるのか誰がやるのかについて考えてみる / why who testing
アジャイル開発研修の中で、ソフトウェアテストってなぜやるの？誰がやるの？って話をしたときの資料です。
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
この記事はソフトウェアテストのカレンダー | Advent Calendar 2022 - Qiitaの23日目です。 毎年のことながら「何を書こう・・・」と悩んでいてTwitterに助けを求めたところ、@teyamaguさんからネタをいただきました（ありがとうございます） 案1：今年読んだ中で最も役に立ったor読んで良かった本 案2：今年で見た中で最もイケていた自動テストシステム とかどうでしょうか？ — teyamagu (@teyamagu) December 6, 2022 最も役に立った、だとなかなか決めかねる部分があり、「読んでよかった本」をつらつらと書いていこうかと思います。 私が2022年に読んだというだけで、今年発売された本には限らない点ご注意ください。また、熟読した本ばかりではなく、ポイント読みやざっと流し読みした本も含めます。（意志薄弱 The BDD Books -
【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
LAPRASのソフトウェアエンジニア向けスキルチェック課題を公開しました - LAPRAS Tech Blog
こんにちは、LAPRAS CTOの @rocky_manobi です。 タイトルの通り、LAPRASのソフトウェアエンジニア職の選考課題を公開しましたので、その詳細や心についてこの場を借りて紹介します。 公開した選考課題はコチラ GitHub - lapras-inc/exam-swe-template: SWE Backend, Frontend ポジション選考課題のテンプレートリポジトリ SWE Backend, Frontend ポジション選考課題のテンプレートリポジトリ. Contribute to lapras-inc/exam-swe-template development by creating an account on GitHub. github.com どうして公開したのか主に以下を目的としています。 応募の心理的なハードルを下げる会社を評価するための材料を提供する
by NASA/JPL-Caltech 1977年に打ち上げられた宇宙探査機ボイジャー2号のソフトウェアアップデートのため、NASAが18時間かけて行っていたパッチの送信が完了しました。このあと、現地時間の2023年10月28日にコマンド発行が行われ、パッチが正常に動作しているかの確認が行われます。 NASA’s Voyager Team Focuses on Software Patch, Thrusters https://www.jpl.nasa.gov/news/nasas-voyager-team-focuses-on-software-patch-thrusters NASA just sent a software update to a spacecraft 12 billion miles away https://bgr.com/science/nasa-just-se
米ホワイトハウス「将来のソフトウェアはメモリ安全になるべき」と声明発表。ソフトウェアコミュニティに呼びかけ 米ホワイトハウスの国家サイバー局長室（The White House Office of the National Cyber Director：ONCD）は、サイバー空間における攻撃対象領域を積極的に削減する目的で、テクノロジーコミュニティやソフトウェアコミュニティに対してメモリ安全（Memory Safe）なソフトウェアの実現を積極的に呼びかけるプレスリリース「Future Software Should Be Memory Safe」（将来のソフトウェアはメモリ安全になるべき）を発表しました。 プレスリリースの中で、国家サイバー局長Harry Coker氏は「私たちは国家として、サイバースペースにおける攻撃対象領域を減らし、あらゆる種類のセキュリティバグがデジタルエコシステムに
修士課程を退学した15年前に、僕は全く実現可能性を考えずに”30歳までにアメリカの大学院に留学”という目標を立てました。 もう一度大学院に行きたい、行くなら世界トップのアメリカがいいだろう、そんな程度の認識でした。 ただ、これはどちらかといえば無理やりひねり出した30歳まで生きる理由であって、そこまで強い意志があったわけではありません。 しかし、おかげで何とか30歳を超え40歳目前まで生き延びることはでき、気が付けばアメリカではなくカナダで永住権を取って暮らしています。 大学院留学は引き続き他のハードルが高くて達成できる気はしませんが、15年前に目標を立てた時点では認識できていなかった 「海外に移住する」という難儀を10年ほどかけて乗り越えることはできました。 けれど、そういえば事の顛末を一つにまとめたことが無かったなと気づいたので、僕のキャリア10年＋αを振り返って記事にしてみました。
働き始めてから丸10年経った。 2012年、僕は北海道に住む大学院生で、趣味としてプログラミングを楽しんでいた。Appleのファンだから、macOSやiOSのアプリケーションを開発して、ちょっとでもAppleに近づいたような気持ちになっていた。その夏1ヶ月のインターンシップに参加した。インターンシップで、それまで趣味だったプログラミングが突然違った価値を持ち始めて、これを仕事にしないといけないと思うようになった。それで、両親や先生に謝って、大学院を退学して、インターン先の会社に正社員として入社した。それが2012年11月のことで、それから10年間、株式会社はてなで働いている。 この業界では、10年同じ会社で働いているというと、ちょっと珍しい部類なのかなと思う。とはいえ社内ではそれほど珍しくもなくて、あまり気にならない。いろいろなプロダクトを夢中になって開発していたら、いつの間にか10年経っ
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b…
Red HatがRHELソースコードの一般公開をやめて顧客限定に、自由ソフトウェアの原則を軸にしてきたLinux関係者たちから猛批判を受ける
企業向けに「Red Hat Enterprise Linux(RHEL)」というLinuxディストリビューションを提供しているRed Hatが、これまで一般公開してきたRHELのソースコードの配布を顧客限定にすると発表しました。この発表に対して、自由ソフトウェアの理念を持つ開発者たちが批判の声を上げています。 Furthering the evolution of CentOS Stream https://www.redhat.com/en/blog/furthering-evolution-centos-stream 自由ソフトウェアとは下記の4つの「自由」を持つソフトウェアのこと。 ・どんな目的に対しても、プログラムを望むままに実行する自由 ・プログラムがどのように動作しているか研究し、必要に応じて改造する自由 ・ほかの人を助けられるよう、コピーを再配布する自由 ・改変した版を他に配
なんか言及もされたのでアンサー的に書いてみたけど、アンサーには大してなってないな? ってやつです。一部で言及された、競技プログラミング (競プロ) 関係の話。 その前に、「プログラミングの競技」っていろいろあります。 短時間で問題に解答していく型 (ICPC / 情報オリンピック / AtCoder Regular / TopCoder とか)最適解が容易に求まらない問題のスコアを競う型 (SuperCon / AtCoder Heuristic / ISUCON / ゴルフ / ICFP Programming Contest の一部とか)対戦型 (ICFP Programming Contest の一部とか、最近のはあんまり知らないですが RoboCode / Imagine Cup とか)謎解き型 (ICFP Programming Contest で何回かありましたね。 UMIX
オープンソースソフトウェアの開発プロジェクトで連絡用プラットフォームとしてDiscordを用いる例が多くあります。しかし、自由ソフトウェア(FOSS)の推進者であるドリュー・デヴォールト氏は「『自由ソフトウェア』の開発プロジェクトにDiscordを使うべきではない」と警鐘を鳴らしています。 Please don't use Discord for FOSS projects https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html Discordはユーザーが「○○というゲームについて話し合うサーバー」「○○愛好会のボイスチャット用サーバー」「GIGAZINEの公式サーバー」といったように自由にサーバーを作ることができるコミュニケーションアプリで、各サーバーではテキストや音声で会話できるほか、ファイルをアップロードした
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
1月28日、新刊『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』発刊！Googleでテックリードを務めるTom Long氏が、プロフェッショナルなソフトウェアエンジニアとして、信頼性が高く、メンテナンスしやすいコードを書くための概念やテクニックを解説 Tom Long氏は、よいコードを書くため「4つのゴール」と「6つのコード品質の柱」を掲げ、「よいコード」と「悪いコード」を比較することで、「なぜ、このコードはよい／悪いのか」を具体的な事例とともに、1つ1つ解説しています。さらに、「よいコード」が正しく動き、「悪いコード」を発見するための「ユニットテスト」についても2章に渡って解説しています。 本書は、11章で構成されており、大きく3つの部に分かれています。最初の第1部では、コードに対するソフトウェアエンジニアとして考えを形作るための理論的な上
軽量で自分のローカル環境上に構築するメモサイトを探しているなら！「memos」 - ソフトウェア開発者のための OSS、まとめてみました！
概要 皆さまはメモを取りたいときやタスクを管理したい、アイデアを何かにまとめたいといった場合、どのようなものに頼っていますでしょうか？ 非デジタルであればノートだったりメモ帳を使用しているかもしれませんし、デジタルであればメモアプリだったりテキストエディタを利用、もしくはクラウド管理されているアプリを利用してるかと思います。 今回はデジタルで利用するメモアプリの話題について取り上げていきたいと考えていますが、もしデジタルでメモを取っている方はどのようなアプリや Web サイトを利用されていますでしょうか？ 有名どころで、メモやタスク管理、ドキュメント管理、データベースなど、仕事で使う様々なツールが 1 つにまとまっているアプリ「Notion」を利用されている方が多いのではないかと考えています。 www.notion.so 私自身も普段からこちらの「Notion」を積極的に利用させていただい
【Twitter】非常に複雑なソフトウェアの面倒を見る人を減らして急な機能追加をすると『あちこちから無視できない水漏れが起こる』みたいな壊れ方をする
Fumihiko Shiroyama @fushiroyama 父、博士課程 Software Development Engineer @Adobe / ex-@Microsoft, ex-@amazon All opinions are my own. note.com/fushiroyama/ Fumihiko Shiroyama @fushiroyama Twitterがゆっくりとしかし確実に壊れていっていることに残念ながら驚きはないというか、非常に複雑なソフトウェアの面倒を見る人を減らして急な機能追加をすると「分かりやすい大爆発」を起こすのではなくて「あちらこちらから無視できない水漏れが起こる」みたいな壊れ方をするんですよね Fumihiko Shiroyama @fushiroyama 世界最高峰のTech Giantsが世界最高峰の頭脳を世界最高峰の報酬でかき集めて作られてい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアエンジニアとしての職務経歴書の書き方を考えました
ウクライナのソフトウェアエンジニアがT-80戦車に乗ってロシア軍車両24台を撃破│ワールドタンクニュース
ソフトウェアエンジニアは、〇〇を作れと言われた時まず何から考えますか？プログラミング言語ですか？デザパタですか？
『ドメイン駆動設計』の解説記事を書きました - ソフトウェア設計を考える
「Googleのソフトウェアエンジニアリング」を読んだ - wyukawa's diary
"The Essence of Software"が提唱する全く新しいソフトウェア設計の考え方｜Idein株式会社
プログラマーを解雇して新しい人員に置き換えることがソフトウェアにとって致命的になり得るという指摘
ソフトウェアエンジニアになってから: 昇進と異動（と最高評価）｜Hiro Tsujino
現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
ソフトウェアの実装と事業戦略を結びつける
2022年に読んで「良い」と思ったソフトウェアテスト関連本 - テストウフ
NASAが190億km離れたボイジャー2号に18時間かけてソフトウェア更新用パッチを送信
米ホワイトハウス「将来のソフトウェアはメモリ安全になるべき」と声明発表。ソフトウェアコミュニティに呼びかけ
10年かけてカナダでソフトウェアエンジニアになるまでの道のり - As a Futurist...
ソフトウェアエンジニアとしての最初の10年 - cockscomblog?
設計の知識と技能で駆動するソフトウェア開発
競技プログラミング、ソフトウェア・エンジニア、コミュニティ
「『自由ソフトウェア』の開発にDiscordを使わないで」という主張
[スタパ齋藤の「スタパトロニクスMobile」] Androidで災害対策するならソフトウェアラジオかも!!!
![[スタパ齋藤の「スタパトロニクスMobile」] Androidで災害対策するならソフトウェアラジオかも!!!](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a32fbb22abc6ccc5e58e21e1dc7997e01055dc7/height=288;version=1;width=512/https%3A%2F%2Fk-tai.watch.impress.co.jp%2Fimg%2Fktw%2Flist%2F1316%2F019%2Fstptncs2021-04-05_c04.jpg)
1月28日、新刊『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』発刊！