Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。原文(投稿日:2017/07/27)へのリンク開発者とバージョン管理の話をすると、ワークフローツールとしてのGitやコードと履歴書を保存する場所としてのGithubの話になるかもしれない。テスターやビジネスアナリストのような開発者と比べれば技術的ではない職種の場合、Gitは成果物とバグを生み出す魔法の呪文のように思えるかもしれない。テスターがGithubを使って個人的、または、仕事上でのプロジェクトに参画したり、既存のプロジェクトに貢献するのは有益なことだ。2017でGitHubに貢献することについて語った。Heuser氏とKenst氏は、GitHubのアカウントを作り、貢献を始める方法を聴衆に示すことから講演を始めた。講演の動画は再生可能なので、一度動画を見て"要点を掴み"、2度目に見るときは、示された方法をなぞりながら、2人が実行したコマンドを手元で実行することができる。InfoQは両氏にインタビューして、GitHubをコード以外で活用する方法、テスターがGitHubを使うことで得られる利益、テスターによるGithubやその他のオープンソースツールの活用を促進する方法について話を聞いた。Githubはコード以外でも便利だと話していましたね。テストの成果物、テスト計画、セッションノート、テスト方法などはバージョン管理の下に置けます。Word形式の)もGitHubに置けます。(AMA)を置くこともできます。Pagesを使ってウェブサイトを作成、ホストしたり(テスターはオンラインの世界でもある程度の存在感を出すべきです)、本を書いて公開することもできます。制限は創造性だけです。創造性は事例によって刺激されます。下に紹介するのは、私が作ったり、見つけたりした、公開されているテスト関連の資材です。Charterを書く方法とその説明です。3つ目は文字列が入力されるフィールドに入力されると問題を起こしそうな文字列の一覧です。Pageで公開されている事例はたくさんあります。Balter氏の個人のウェブサイトです。2つ目はとてもシンプルなページでソーシャルメディアへのリンクがあるランディングページのようなものです。GitHubのウェブサイトのすごいのは、気に入ったらフォークして、少し手直しして、自分のサイトとして公開できるという点です。3つ目はオープンソースで、ソフトウェアテストのカンファレンスやワークショップの情報が載っている、コミュニティが運営しているサイトです。GtiHubへの貢献を始めたいなら、テストのカンファレンスに貢献するというのは良い選択肢かもしれません。GitHubでコード以外のものを扱う場合、GitHubのすべての機能が使えるのでしょうか。すべてのプロジェクトはほぼ同様に扱われます。リポジトリを作れば、バージョン管理、Issues、Wikiなどの主要な機能を使うことができます。コードではなくても、プルリクエストを作り、少しづつ手を加えることができます。バイナリファイルのマージとdiff以外はシームレスです。Wordのドキュメントには使えません。テスターがGitHubを使うことにどのような利点がありますか。開発者のワークフローを理解でき、開発者の言葉で話すことができます。これによって、テスターと開発者の間で軋轢が生まれにくくなります。次に、ビルドの成果物とコードそのものに対して、一歩近づけます。コードを少し読めば、ソースコードレベルでピンポイントでエラーを指摘できるかもしれません。コードを読めるようになり、コードレビューにも貢献できるかもしれません。Chrisも指摘すると思いますが、Github自体をワークフローツールとして使うこともできます。プッシュされたものを承認したり、バグを整理したりできます。Githubのアカウントがあり貢献をしているということは公開されたポートフォリオです。雇用されやすくなりますし、顧客のリスクを少なくなります。Project)でもGitHubを使ってコードを管理しています。これは、ますます多くのソフトウェア開発者がGithubのワークフローを仕事をするようになっているということです。このワークフローではコードの変更はプルリクエストを通じて提案され、テスターや開発者はコードの差分を視覚的に確認でき、マージする前に独立して変更をテストできます。自動テストもプルリクエストに対してさまざまなレベルで実行できます。これは、チームのテストとプロセスに巨大な利点を与えます。Issuesを使ってバグを指摘できます。多くの組織やリクルーターがGithubのアカウントを候補者の評価に使うようになります。公開されているポートフォリオがあるのになぜわざわざ履歴書を見る必要があるのでしょうか。ポートフォリオにサイドプロジェクトや日常業務に関係のないものがあったとしても、履歴書だけよりはより価値のある材料になります。Conferenceでは、まず最初にGitHubへのサインアップ方法、プロジェクトの始め方、そしてどのように使うかを説明しましたね。このようにしたのですか。私たちのプレゼンの目的は聴衆がGitHubのリポジトリを作り、貢献ができるようにすることでした。時間の制約があることを加味すると、まずデモをして、それから付随する背景情報や事例を紹介するという方法になりました。開始するとデモが長く、追加の資料はもっと長かったです。時間切れになるのではと心配しました。うまく切り詰められたと思います。ほとんどChrisがやったのですが(笑)。テスターがGithubのようなオープンソースのツールを使うことを促進したいと考えている人にアドバイスをお願いします。正直に言って、"まずやってみろ"と言ってみたり、"なんでテスターは新しいツールを使わないんだ"と言ったりするリーダーやコーチをたくさん知っています。テスターとペアになって新しいツールを使えるようになるのを支援するのがいいでしょう。GithubでもSeleniumでも構いません。思っていたより難しく馴致する時間が必要でサポートするのが正しいと感じるかもしれません。簡単でペアになって支援することで抵抗を克服できるとわかるかもしれません。いずれにしろ、成功です。いくつか、アドバイスがあります。プロジェクトを始めましょう。型からコーディングを学びます。ループ文についてのGoogleで検索して情報を探すことと、実際に書いてみることの違いは巨大です。型となるコードを何度か実行してみることで経験が得られます。私の型のリポジトリをフォークして、katagenerator.rbを実行してみてください。ローマ数字を十進数に変換する簡単なコードです。コミットしてプルリクエストを追加してください。これで実際にプロジェクトへのコミットの仕方がわかりました。次にソフトウェアが必要になり、予算獲得のための長く辛い道のりを歩み始めるなら、代わりにオープンソースを探しましょう。SeleniumはUFTの代わりになります。プロジェクトを探し、貢献できるかどうか探ります。バグの報告でもいいでしょう。単なるバグ報告でも、gitのフローの別の側面を学習できます。テストツールについて言えば、この10年の最大の進歩はオープンソースコミュニティによって成し遂げられました。Seleniumはウェブアプリケーションテストの標準(今はW3C標準になろうとしていますstandard)です。モバイルアプリ自動化ではAppiumが同じ位置を占めようとしています。私たちが感謝したいブラウザやブラウザツールもオープンソースコミュニティ(例えばChrome)から生まれています。Gitもそのひとつであり、オープンソースです。関係を持ち続けるためには、テスターはこれらのプロジェクトを追いかける必要があります。これらのプロジェクトはどこで見つかるでしょうか。