はてなブックマーク

Draft Pull Requestをリリースしました を読めばおわりです Draft Pull Requestとは GitHub Flow などを利用してチーム開発をしていると、すぐマージはできなくても Pull Request(PR) を出したくなる場面があると思います。 そのような時は、 WIP(Work in Progress) を利用することが多いでしょう。 作業中の PR のタイトルに WIP: PR title や [WIP] RP title のようにつけるのが一般的です。 WIP を利用することで以下のような恩恵があります 作業ログやコメントを残せるため、思考の整理になる PR を見ることでコンテキストをレビュワーと共有できるため、レビューが楽になる また、マージ目的ではなく他のメンバーからのフィードバックをもらうために PR を出すこともあります。 このような場合に便利

CircleCIとは CircleCI はSaaS型のCI/CDサービスです。 CI/CDとは「Continuous Integration / Continuous Delivery」の略であり、ビルドやテスト、デプロイを自動化して継続的に行うものです。 GitHubやBitbucketなどのGitホスティングサービスと連携することで、コードがPushされるなどのトリガーに応じて任意の処理を行うことができます。 今回は、PRを出した時にフロントエンドのテストが走るような設定を行ってみます。 CircleCIでHello Worldしてみる アカウント登録 まずアカウントを作る必要がありますが、GitHubやBitbucketを既に利用している方は Signupから「Sign Up with GitHub」や「Sign Up with Bitbucket」で簡単に登録できます。 confi

git init をすると、 .git と言うディレクトリが作られます。 Gitに必要なファイルは全てこのディレクトリに含まれているのですが、普段はあまり意識しない人の方が多いと思います。 今回は .git ディレクトリの中身を少し探検してみましょう。 .gitディレクトリの構成 まずは git init して .git ディレクトリを作成してみます。 .git の中身はこのようになっています。 . ├── HEAD ├── branches ├── config ├── description ├── hooks │ ├── applypatch-msg.sample │ ├── commit-msg.sample │ ├── fsmonitor-watchman.sample │ ├── post-update.sample │ ├── pre-applypatch.sample │

テスト初心者がいきなりテストケースを考えようとしても、最初から適切なテストケースを書いて品質やテストの効率性を高めることは難しいです。 今回はテストの中でもユーザ側に立ったブラックボックステストの種類と概要を見てみます。 ブラックボックステスト ブラックボックステストは、ソフトウェアが要件や仕様を満たしているかを確認するためのテストです。 「実際に関数が何をしているのか」といった具体的な実装に関する知識は必要としません。 要件定義書を元にしてテストケースを考えます。 ブラックボックステストは、単体テスト・統合テスト・システムテスト・受け入れテストといった全てのレベルのテストで行うことができます。 単体テスト：ソフトウェアの最小単位で行うテスト、関数やクラスなど 統合テスト：単体を組み合わせたときの挙動を確認するテスト、複数の関数を利用するプログラムなど システムテスト：ソフトウェア全体から

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? リレーションシップ駆動要件分析(RDRA)とは？ 要件定義において、重要な要素が3つあります。 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている 「整合性」：各要件の整合性が取れている 「表現力」：それぞれの要件が分かりやすく表現されている 複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。 リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するた

何かサービスを開発する時に、以下のような状態に陥ることがあります。 「要求」だとか「要件」が曖昧なまま開発に入ってしまう 形だけの要件定義書を作り、開発に入ると見返さない(形骸化してしまう) このような状態になってしまうと、大体は大きな手戻りが発生したりプロジェクトに損失を与えてしまいます。 これを防ぐためにも、要件定義の役割と重要性を理解しておくことは大事です。 「タクシー配車アプリを開発する」というプロジェクトを例に出しながら考えてみます 要求・要件・仕様の違い ざっくりとですが、プロジェクトを始める際には要求・要件・仕様の3つを考える必要があります。 要求とは 要求とは、**「ユーザーがサービスで実現したいこと」**です。 タクシー配車アプリでは「手軽に近くのタクシーを呼びたい」など。 ニーズとウォンツのような話だと、ニーズ(=目的)ということになります。 要件とは 要件とは、**「

概要 Microsoftが開発したAltJS
 (みんな大好きVSCodeと相性がいいよ！) 静的型付けとクラスベースのオブジェクト指向 JSの大規模開発に対応するために設計 JSのスーパーセット(上位互換)で
コンパイルすることでJSにトランスパイルできる 何が嬉しいのか コンパイルで事前に怒られるのでエラーが一目瞭然 (JSのエラー追うの辛い) コードの影響範囲の抽出が容易なため変更に強い 型が付くことでメソッド・変数の意図がわかりやすい 型と付くことと、自然と行儀の良いコードになることで可読性向上 エディタの補完機能が強い (VSCode) 型推論によって初期値の型を採用してくれるため慣れてなくても書きやすい 基本の型 公式：Basic Types // Boolean let isDone: boolean = false; // Number let decimal: numbe

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Hooksは、classを記述せずにstateやその他のReactの機能を使えるようにしたもので、今は提案段階です。RFCはこちら 現在はReact v16.7.0-alphaで試せます。 Hooksの概要はこちら https://qiita.com/tatane616/items/01d6358be5e4e4779232 IntroductionにHooks導入の動機が書いてあったので理解しようとしてみました。 ステートフルなロジックをコンポーネント間で再利用するのが難しい Reactではストアに接続するなどと言った再利用可能なロジッ

Hooksは、classを記述せずにstateやその他のReactの機能を使えるようにしたもので、今は提案段階です。RFCはこちら 現在はReact v16.7.0-alphaで試せます。 Hooks導入の動機はこちら https://qiita.com/tatane616/items/9d667e32b6f82f9f7a9f State Hook よくあるボタンを押すとカウントが増えていくサンプルです。 import { useState } from 'react'; function Example() { // Declare a new state variable, which we'll call "count" const [count, setCount] = useState(0); return ( <div> <p>You clicked {count} times