保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
ShellScriptで自動化を楽にしたい時に知っておいても良いこと | sreake.com | 株式会社スリーシェイク
はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ
三菱MRJはなぜ失敗したのか｜ブースカちゃん
とても長くなりました。10,000字を超えています。 途中で読み疲れちゃうようだったら、ブックマークなどを利用して、分けて読んでいただけると幸いです。 なにがあったのか、まず事実関係を確認「売れなかった」からではない。一部の論者は「MRJはユーザーのニーズに合っていないから失敗した」とかいう誤解をしているようですが、そうではありません。ニーズに合っていたか、よい飛行機だったか、という問題ではないのです。旅客機の開発はお金と時間がかかるので、最初に「見込み客」との契約を行い、それが成立した時点で開発を決定するのです。この顧客を「ローンチ・カストマー」と言います。 MRJの場合、ローンチ・カストマーは全日空でしたが、開発が進むにつれて海外からの発注も獲得しており、将来的に採算がとれるかどうかは別として、「顧客ニーズに合わない」的外れの製品ではありませんでした。 もちろん、これから開発する飛行機
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーシ
Visual Studio2022で.NET Framework 4.8と.NET 6のソースコードを共存させる (WinForms＆WPF) - Qiita
Visual Studio2022で.NET Framework 4.8と.NET 6のソースコードを共存させる (WinForms＆WPF)C#WPFWinForms.net6VisualStudio2022 WinForms, WPFなどのWindowsベースのレガシーアプリ開発をやっていて、 最近ようやくRC版のリリースを終えた.NET 6でも問題なく動くかどうかを確認したかったので、 とりあえずWinFormsやWPFで、ソースコードの移植作業を極力行わない方法でどの程度対応出来るか試してみた。 (いくつか方法はあると思うが、そのうちの一つの方法、ということで) クロスプラットフォームでの挙動については未確認。 C++連携なども現状は未確認(※クロスプラットフォームなどを見据えてP/Invokeを使った方法への切り替えが推奨されているみたいです。C++/CLIは完全Windows固
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
もしあなたが急にAndroidアプリを業務で作るはめになった場合の選択肢(2021年初頭版) - Qiita
本記事はAndroid Advent Calendar 2020の2020/12/01分です。 初っ端ということなので、2020年末と2021年頭でのAndroidエンジニアとして初めて業務でやる場合に抑えておいたほうが良い最低限の部分を書いていこうと思います。（ツッコミ待ちです） 対象 2021年3月ぐらいまでに !!業務!! でAndroidアプリを作らされる事になった可愛そうな人が居たとします この人は手続き型言語でオブジェクト指向プログラミングができる知識があり、Androidアプリもなんとなく趣味で作ったこともあるぐらいのレベル感です~~（なので上長からいきなりお前Android担当なと言われた）~~ 最低限のAndroidアプリの作成の知識はあるものとします（画面の表示にはActivityがいるよとかは書かない) ゲームは対象外です 業務でAndroidアプリを作ることを想定し
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
アジャイル開発の契約は「準委任」が適切、契約前にユーザーとベンダの共通理解が大事。IPAが「モデル契約書」やチェックリストなど公開。
情報処理推進機構（IPA）は、ユーザー企業が開発ベンダにアジャイル開発手法を用いたシステム開発を発注する際の、契約書の見本などを含む「「アジャイル開発版『情報システム・モデル取引・契約書』（本版）」を公開しました。 本作はスクラムを想定したアジャイル開発を外部委託する際の、契約条項とその解説、および補足資料で構成されたもの。 IPAは本作を作成するにあたり、ユーザー企業とベンダ企業が緊密に協働しながら適切に開発を進めることができるモデル契約となるように、ユーザー企業、ベンダ企業、業界団体、法律専門家の参画を得て検討を重ねたとしています。 契約前チェックリストも 本作の作成に関わったIPAの「DX対応モデル契約見直し検討ワーキンググループは」、ユーザー企業とベンダが契約する前に、以下の2つのことを理解しておくことが必要だと説明します。 ユーザ企業及びベンダ企業が、開発に着手する前にアジャイル
七転び八起きのLinuxカーネルコミュニティ開発体験記
はじめに 現在のLinuxカーネルはメモリーホットプラグという，一般的にはなじみがない機能をサポートするようになっています。私は長い間その開発にかかわってきました。 コミュニティに参加する方法というのは，今ではノウハウ化が進み，「Linuxカーネル開発への参加方法」という文書も紹介されるようになりました。 しかし，私が活動をはじめた当時は，まだどうやって開発していけばよいのか勝手がわからず，四苦八苦することとなりました。これまでプロプラエタリなソフト開発しかしたことがないエンジニアにとって，コミュニティ開発というのはまったく開発スタイルの違う世界に飛び込むことだったからです。しかし，その苦労によって得られた経験は，その後の他の開発活動に活かされることになりました。ちょうど良い機会をいただいたので，そのときの苦労を振り返りたいと思います。 メモリーホットプラグをサポートしているハードウエアは
今さら入門するMVVMに必要な技術要素（Xamarin.Forms & UWP） - かずきのBlog@hatena
Model View ViewModelパターン（以下MVVMパターン）が登場して約10年になります。 ここらへんで一度MVVMを実装するうえで必要になる技術要素を振り返ってみたいと思います。 その前にMVVM MVVMは以下のWikipediaあたりでも見てください。 Model View ViewModel - Wikipedia 見た目と、それ以外にクラスを分離して、さらに見た目をXAMLで作りやすいようにViewとViewModelに分離したようなイメージです。 見ていこう ということでMVVMで必要になる技術要素を見ていこうと思います。 INotifyPropertyChangedインターフェース まずは、これが無いと始まりません。MVVMではViewはViewModelを監視して、ViewModelはModelを監視していることが多いです。その時に、クラスのプロパティが変わった
ようやくきました。Visual StudioがGCC/GDB対応
不覚。もうずいぶん前からVisual StudioのGCC対応を熱望していた私が、私が…既に対応していたのを知らなかったとわ。とほほ。ま、最近はIoTに専念していたのでAご勘弁。でも全く関係ないわけではなく、むしろ結構関係してる。 はい、不覚話はそれくらいにして、話を進めます。Visual Studio 2015 がリリースされた時、iPhone、AndroidのNativeアプリが開発できる機能が加わり、GDB対応により実機デバッグができるようにはなっていました。で、2015年11月18日にUpdate 1がリリースされました。その時に https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcing-the-vs-gdb-debugger-extension/ Announcing the VS GDB Debugger Ext
HTTP/1.1 200 OK - Qiita
※このお話はたぶんフィクションです。実在の人物や団体とはあんまり関係ありません。 序 planetter.comをバージョンアップすることにした。数年前にリリースしてからずっと放置していたけど、そろそろ手を付けないとやばいと思った。 しかしウェブの世界はドッグイヤーだ。3年も経てば何もかもが変わっている。しばらく開発から遠ざかっていた僕には、最近の技術トレンドなんてさっぱりわからない。 まずは自分自身をアップデートするところから始めよう。 Atom 最初はIDEだ。以前はEclipseを使っていたけど、いまはもうウェブ系言語の進化速度に追いつけていないようだった。ウェブ開発用のIDEならいまはWebStormが人気のようだ。有料だけど、最新の技術に対応しているし、使い勝手もいい。 でも最終的にはAtomを選んだ。IDE(統合開発環境)ではなくエディタなので、これ自体は単機能だけど、不足分は
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレク
Android案件を見積もる場合に考えておくことリスト - Qiita
Android Nから 縦横という概念自体がなくなる ので、デザイナーが対応できるかも考慮が必要。(-land就職子はdeprecated。-sw320などを使う) WebView有無 WebViewをアプリの一部として使う場合、レイアウト崩れを誰が解決するかを確定させておく必要がある。Android 4.3以下、4.4、6.0でそれぞれWebViewの挙動が多少変わったため、必ずOSバージョン選定と一緒に、WebViewの挙動チェックを行う端末も選定しておく。 「既存コンテンツをWebViewで表示する」案件 これは多くの場合炎上する。 なぜなら、そのように「既存コンテンツを再利用」するということは、モバイルコンテンツに対するコスト意識が希薄で、「簡単に考えている」からだ。 大抵のリスク説明は「そんな風には考えていない」「簡単でしょ」とと言われる傾向にある。 例えばレイアウト崩れの問題が
ダレずに開発を走り切る為の習慣
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう！『だるさ』見積り！本当に大事だよ！ [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
Excelスクショ問題の解決策を現役エンジニアが本気で考えた。 - Qiita
はじめに SIerのExcelスクショ問題が少し前にバズっていた。 SIerでは、プログラムを手動で操作し、その時の画面写真をExcelに貼り付けた資料を作る事で、プログラムが正常に動作するエビデンスとしている。 そもそも、なぜそのような作業が必要なのかは、下記の方のブログが詳しいのでここでは語らない。 - > Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） | 羽根帽子の太公望 ここで語りたいのは、「Excelスクショ作業はなぜ自動化されないのか？」とそれに対する解決策だ。 原因 まず原因はこれらだと思う。 セキュリティの観点から自動化ツール導入に制限がある。（そのツールがスパイウェアでない保証はありますか？） フリーウェアの導入や有名でないシェアウェアの導入の際に問題になる。それらのツールがスパイウェアの類でない事を証明する事は難
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
セガが社内勉強会の資料を無償公開 ～数学は不要？ 断じて否、ゲーム開発ではバリバリ使うぜ！／PDFドキュメントで150ページ超の大分量。ラスボス概念「クォータニオン」に挑め！【やじうまの杜】
NizLog | Planned Happenstance Theory.