Developer Roadmaps
Developer RoadmapsBrowse the ever-growing list of up-to-date, community driven roadmaps Draw your own roadmapGenerate Roadmaps with AI All RoadmapsAbsolute BeginnersWeb DevelopmentFrameworksLanguages / PlatformsDevOpsMobile DevelopmentDatabasesComputer ScienceMachine LearningGame DevelopmentDesignBlockchainCyber Security
トップデベロッパーになるために作成したいアプリ8選 - Qiita
こちらの記事は、Indrek Lasn 氏により2017年 12月に公開された『 The Secret to Being a Top Developer Is Building Things! Here’s a List of Fun Apps to Build! 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 著者Twitter https://twitter.com/lasnindrek 少し考えてみてください。あなたがもし健康に関する書籍をたくさん読んだとしても健康になることはありません。実際には、ジムに行き数時間運動をして汗をかかなければ健康は手に入りません。 同じことが開発にも言えます。努力なしに優れたデベロッパーになることはできないのです。 そこで、コーディング力を鍛える8つの素晴らしいプロジェクトを紹介します。 あなたの好きなテクノロジースタックを使っ
mkoszk’s blog
はじめに USDMに関する記事をインターネット上で検索すると、「要求仕様定義ガイドライン」 に触れた記事がヒットします。ただし、内容について書かれたものは少ないようです。 そこで、どんな内容なのかUSDMとの関連に絞って書こうと思います。 USDMとガイドラインの関係 ガイドライン執筆の動機として、要求仕様書の品質が良くないため、ユーザ企業として何とかしたい。何を書けばよいのかは分かっているが、いかに書くかはよく分からない。どのような要求仕様書を書けばよいのか模索しているとき、清水吉男さんが提唱しているUSDMに出会い、USDMをベースにガイドラインを作ったということです。 なぜUSDMを採用したのか JUASがUSDMを採用した理由として次のようなものが挙げられています。 １．システム要求を二段階で記述すること。 ２．下位要求の基準があること。 ３．要求の下に仕様を記述することにより、仕
東京Node学園祭2015で技術文書をソフトウェア開発する話をしてきた
東京Node学園祭2015に参加したきたメモです。 また、技術文書をソフトウェア開発する話という内容でブログ以上技術書以下の文書を書く場合における開発方法について話してきました。 The State of JavaScript - @domenic スライド: The State of JavaScript (2015) 皆Babelを使い始めたらそれはスタンダードじゃない可能性があるので気をつけた方がいい Custom Element Service Worker ブラウザの中でプロキシサーバ的なことができる Custom Paint registerPaint 新しいCSSプロパティ 言語 TC39/ecma262 に新しい仕様が置いてある GitHubにある Living Standard的な感じになってる Spec番号 あんまり気にする必要はない 言語ではバージョン番号は必要ない
プロダクトラインとは(1) | ZACKY's Software Education Laboratory
このブログはじめての記事として，ブログの説明や最初のあいさつにも書いている「プロダクトライン」とは何かを説明しましょう． ソフトウェアの生産性を向上させたいと経営者も開発現場も思っているでしょう．それに対し，ソフトウェア開発の実態は1つ1つ手作りに近いという現状があります．なんとかしてソフトウェア開発を現代の発達した工業のように効率化できないだろうか，工業化の歴史から学ぶことはないだろうか．それがプロダクトラインという考え方が生まれたきっかけです． Henry Ford 登場以前の工業は1つ1つ手作りでした．手作りだと顧客1人1人に合わせて仕立てることが可能ですが，生産性が低いため，単価を高くしないと元が取れません．ついでにいうと属人性が高いという問題もあります．つまり，品質や工数が生産者の技術レベルに強く依存する，勘と経験の世界で，技術の継承が難しいという状態です．これは現在のソフトウェ
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
書籍「基本から学ぶソフトウェアテスト」を元にした講義資料 — ありえるえりあ
対象読者 ソフトウェアテストを勉強したい人 本を読むのが面倒で、手っ取り早くポイントだけ知りたい人 アリエル固有のことは書いていないので、テスト技術者の教育担当者は、講義資料として使ってください 1. テストの進め方 テストの前に対象ソフトウェアを理解すること バグ1件ごとにバグ報告を書くこと(複数のバグを同じレポート内に書かないこと) 正しく動かないはず、と思ってテストすること 境界条件を意識すること 最小限の再現条件を探す努力をすること 普通の使い方(正常系)でまともに動作しない場合、テストの中断も考慮すること(時間の無駄かもしれないので) wontfix(修正しない)の返答に対して、その判断を無批判に受け入れないこと(プログラマはwontfixの判断をよく間違えるので) リリース間際の場合、修正しない判断には高度に政治的な背景があるかもしれないので、こだわりすぎないこと 格言:優秀な
ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか - プログラマの思索
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
ソフトを一人で作るということ：ITpro
最近，WebアプリケーションやWindowsソフトの取材で，“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく，会社が商品として提供し，不特定多数のユーザーが使っているアプリケーションを一人で作って，一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも，ドワンゴの戀塚昭彦氏がニコニコ動画を一人で（しかも3日間で）作ったと語っていた（関連記事）。よく考えてみれば，ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても，企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容，また開発者のスキルにもよるだろうが，おおむね一人で開発するほうが， ・低コ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ISO/IEC/IEEE 29119 Software testing 勉強会 第1回 規格の全体構成と各規格の概要
要求工学:Requirements Engineering(月刊ビジネスコミュニケーション)
開発プロセス 吉田誠一のホームページ