はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この話はある開発チームのリードエンジニアがそれまでのチームの非効率的なテストの管理に嘆き苦しみ、改革を行ったごく最近の物語である ■対象読者 プロジェクト管理ツールJiraを現在使っている、もしくは導入検討中である テストの管理で苦しんでいる、改善したい 例.ExcelもしくはGoogleスプレッドシートでテストを書いているが、もやもやを抱えている テストが非効率であることに自覚がない方 上記のいずれにもあてはまらないが、何かおもしろそう プロローグ〜僕達はテストの無駄を無くしたいと願った〜 僕達の開発チームではマニュアルテストケースは

New Year Calendar 4日目 New Year Calendarって何ぞという方はまずこちらをご覧ください。 つい最近プロジェクトでAPI仕様を管理する為にPostmanというREST APIクライアントツールを導入しました。 その時の経緯と調査内容、そして導入結果を共有します。 導入の経緯 それまでのAPIの管理 僕らのプロジェクトではドキュメンテーションツールとしてConfluenceを使用しています。 いくつかのAPI仕様はConfluenceに記述していましたが、全体のAPIの半分も満たしていませんでした。 その上、新しい機能で必要とされる新しいAPIは記述していなかったし、既に記述があるAPIで仕様の変更があっても更新がされていませんでした。 なので、開発者が自分が知らないAPIについて詳しく知りたいと思ったら 誰か知っているメンバーに教えてもらう 誰も知らなかった

皆さんAWSのOpsWorksはご存知でしょうか？ 僕が現場で開発しているサービスではアプリケーションのデプロイやサーバー構築の自動化としてOpsWorksを使用しています。 OpsWorksを使用している理由としては、サーバー構成管理ツールChefによりEC2インスタンスの設定、デプロイ、および管理を自動化が可能であること、つまり環境一式を自動構築できることにあります。 要件に応じて柔軟に環境構成を変更できる、Elastic BeanstalkとCloudFormationの中間の特性を持った新たなサービスとなっています。 またローカル環境も同じChefクックブックによりVagrantを利用して構築出来ることも利点の一つです。 しかし・・！OpsWorksを長く利用している内に、「ここが辛いなあ・・」というストレスフルな点が少しずつ出てきたので、その辛みをこの記事にまとめることにしました

#相対パスの悲劇 ##実話1. 階層をさかのぼってimportするのがツラい 最初の内は相対パスでもまだ良かったんです・・ 階層も少なかったしシンプルな構成だったので import TextBox from "./**/TextBox" という風に書いても別に問題なかったんですよ、ええ。 でもですよ？アプリケーションが大きく複雑になるにつれて相対パスを書くのが辛くなってきたんです・・！ commonディレクトリにアプリケーション共通のComponentを置いたのは良いんですが、そうするとパスをさかのぼってimportするのが煩わしい import TextBox from "../**/**/common/**/TextBox" もうパスを書くだけで、「えーとこのファイルは今この場所だから2階層さかのぼってからこういって・・、あ、違った！3階層だった！・・ってもうこんなんやってられんわ！」

#はじめに JavaScriptで配列やオブジェクトをループする時どのように書きますか？ シンプルにfor文？ Array.forEachを使う方法もありますね。 あるいはES6から取り入れられたfor-of文でしょうか？ ただこうしたいくつかの方法がある中、僕が以前思ったのは 「で、結局何が良いんだってばよ？？(￣へ￣|||)」ということです 単なる文法の違いでどれでも良いのか？それともリスクやパフォーマンスがそれぞれ違ったりするだろうか・・？ その疑問の答えを出すために、ループの各手法を主にリスク・パフォーマンスの面で比較・調査して「配列やオブジェクトをループする良い方法」の結論を出してみました。 もし良ければ参考にしてみてください。 #どんなループ方法があるか まず配列とオブジェクトそれぞれでどんなループ方法があるかを挙げます。 ※jQueryやUnderscore.jsでのループ方

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

#はじめに 僕自身は以前までサーバーサイドを主に担当してきたエンジニアでした。 HTMLとCSSについての基本的な知識はありましたが、例えば業務でWebサイトの画面を一から新しくマークアップ出来るレベルには達していませんでした。 しかし少しずつフロントエンドにも興味を持ち始めてきて、業務でマークアップを担当できるようになりたいと思うようになりました。 ではマークアップを習熟するには一体どうすればいいか？ 単純に世の中に出ているWebサイトがどのようにHTMLとCSSを書いているのか参考にし、それを自分でなぞればいい、つまりWebサイトのトレースをひたすら行いました。 そうした結果、業務でもマークアップを段々と任されるようになり開発領域が広がりました。 ただ最初Webサイトのトレースを始めようとした時は結構困りました。 そもそもどのようにトレースをする為の環境を整えてよいのか分からなかったの

FuelPHPで配列のバリデーションを行う場合はいくつかパターンがあるのでここで紹介します。 パターン1：配列の要素毎にバリデーションルールを設定 Validationインスタンスのadd/add_fieldメソッドで配列の要素を一つずつ設定することが出来ます。 要素一つ一つの形式をチェックしたい場合はこの方法が良いと思います。 例. $validation = Validation::forge(); $options = Input::post('option'); if (is_array($options)) { foreach ($options as $i => $v) { // 要素毎にバリデーションルール設定 $validation->add_field("option.$i", 'オプション', "required|numeric_between[1,10]"); } }

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?