タグ

ブックマーク / dev.classmethod.jp (7)

  • JsDoc Toolkitを使ってJavaScriptのAPI仕様書を作る(環境構築から出力まで) | DevelopersIO

    そんな訳で、JsDocについて少し調べたので、備忘録としてここに残しておくとします。 はじめに - JsDocについて Java開発者の方々ならば、JavaDocというのは馴染み深いを通り越して、もはや聞き飽きているかもしれません。同様にFlashのActionScriptにはASDoc、PHPにはPHPDocなるものがあります。ちょっとした規模のアプリケーションを開発すると、後々の保守を考慮してこういったAPI仕様書を作成し、後から「あれ、ここの処理って何の為にあるんだっけ?」となっても、ソースコードを直接追いかけることなく、概要を大まかに確認できるようにしておくのが慣例かと思います。※あくまで慣例です。実際にやっているかどうかは・・・(ry JsDocは、名前のとおりJavaScriptAPI仕様書を指し、JavaDocと同様にHTMLドキュメント形式で出力されたもので、Webブラウ

    msykxxx
    msykxxx 2016/05/24
  • 突撃!隣の開発環境 パート12【Treasure Data編】 in シリコンバレー | DevelopersIO

    こんにちは!しんやです。今回はおおはしりきたけが書き連ねている人気シリーズ『突撃!隣の開発環境』に乗っかる形で私もこのシリーズエントリを書かせて頂きたいと思います。 突撃!隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思いますが、この突撃!隣のシリーズでは様々な会社さんのイケてるツールの使い方や、仕事が捗る開発体制についてインタビューを行っていく予定です。 Treasure Data社紹介 今回第12回目として

    突撃!隣の開発環境 パート12【Treasure Data編】 in シリコンバレー | DevelopersIO
    msykxxx
    msykxxx 2015/10/19
  • Backbone.js -JavaScriptのMVCフレームワーク- | DevelopersIO

    Backbone.jsとは? Backbone.jsは、JavaScriptによる大規模なアプリケーション開発を行う際に力を発揮するMVCフレームワークです。データバインディングとカスタムイベントを備えたModel、配列情報を表すCollection、イベントをハンドリングするView、サーバーサイドのアプリケーションと連携するためのRESTful JSONなどをフレームワークとして備えています。 大規模な業務アプリケーションのユーザーインタフェースをJavaScriptでゴリゴリと作ろうとした場合、100%に近い確率で失敗するかと思います。これは、Flexのようなビルド時のコンパイラエラーを検出できないこと、存在するフレームワークがインタラクションやビジュアルに特化していること、ブラウザーやOSの組合せでAPIレベルの仕様が異なる事、同じブラウザーでもバージョンの違いにより挙動が異なる事

  • Jenkinsの使い勝手をよくするための見直し6点 | Developers.IO

    今回の課題 こんにちは植木和樹です。7月にserverspecを使ったChefの自動テストのエントリを書きました。 【AWS】JenkinsとserverspecでChefのテストを自動化する このエントリは初めてJenkinsを触った時に書いたので、いろいろと流儀がわかっていませんでした。その後弊社にJenkinsマイスターの渡辺修司さんが入社したということで、Jenkinsの設定について見てもらいました。その時に次の6点を見直すよう指摘がありました。 ジョブは意味ある単位で1つにまとめるべし ジョブで実行するシェルスクリプトもgitから取得すべし EC2の起動に失敗したら後続処理を停止させるべし serverspecの実行結果はJUnit(XML)形式で出力すべし 実行結果のXMLをJenkinsで読み込んで統計グラフを出力すべし 定時実行でなくgit push hookを入れるべし

    Jenkinsの使い勝手をよくするための見直し6点 | Developers.IO
  • ユニットテストにまつわる10の勘違い | DevelopersIO

    渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード(または実行結果)を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

    ユニットテストにまつわる10の勘違い | DevelopersIO
  • ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | Developers.IO

    ドキュメントベースの単体テスト ソフトウェア開発では、テストケースをExcel等で管理し、テストをテストフェイズで実施する方式(以下、ドキュメントベースの単体テスト)が行われてきました。 ドキュメントベースの単体テストでは、テストフェーズが明確に切られています。テストフェーズでは、テスト担当者がテストを実施し、結果をドキュメントに記録します。必要に応じてエビデンスも残すでしょう。もし、テストが失敗したならば、不具合管理票(バグ票)を起票します。そして、不具合の原因を分析し、仕様書やソースコードを修正します。不具合が修正されたならば、もう一度テストを実行し、不具合がなくなるまでこのサイクルを繰り返し、品質を高めていきます。 このようなドキュメントベースの単体テストは、機能や画面を対象としています。そして、ほとんどの場合は品質保証を目的としています。テスト件数や不具合件数、不具合の発生原因や修

    ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | Developers.IO
    msykxxx
    msykxxx 2013/10/22
  • 第1回 はじめてのSpring Framework | DevelopersIO

    今やすっかりAWS屋、しかもアプリではなくインフラ寄りのプロダクトばかり触っている都元です。しかし元々はサーバサイドアプリ屋ということで、ボスのAWSへの想いとは裏腹に、ぼちぼちとサーバサイドJavaの話も出して行こうと思っています。 というわけで、Spring Frameworkについて色々書いて行こうと思うのですが、どう考えても1回で終わる内容ではないため、シリーズ形式(連載)とさせて頂きたいと思います。ただ、書くネタは無限にありそうなので、回数は反響に応じて調整しようかな、と思っています。ギブミー・いいね。 Javaフレームワークの世界 Javaはフレームワークがいっぱいあることが利点でもあり欠点でもあります。多くの言語にはデファクトと言えるフレームワークが存在します。あまり知らない分野なので深く触れてヤケドしたくはないのですが、例えばRubyだったらRailsでしょうし、Pytho

    第1回 はじめてのSpring Framework | DevelopersIO
  • 1