TIM Labs

nishioによるエントリー一覧

前回のAngular2入門 Component編 その1 では、 Componentの基本的な使い方について紹介いたしました。

今回は以下の様な2つのComponentを作成し、お互いにデータのやり取りをする方法を紹介致します。

HelloComponent_boushoatnohua.png

  • 今回作成するサンプルについて
    • app Component と custom-button Componentの2つを作成する
    • app Component は テキスト入力欄 を持っている
    • テキスト入力欄の値と、custom-button Component内のボタンのラベルは同じものを表示する
    • custom-button をクリックすると、Consoleに今表示しているボタンのラベルを出力する
    • custom-button をクリックすると、親Component(=app)にボタンが押されたことを通知する
    • app Componentは、custom-button からのクリックイベントを受け取り、Consoleにメッセージを表示する

Angular2は、コンポーネント志向なJavascriptフレームワークです。

画面一つ一つの要素を部品化しコンポーネントとして切り出すことで、保守のしやすいソースを記述することができます。

今回は、Angular2の基本的な機能であるComponentの使い方を説明いたします。

世はまさにJavascriptフレームワーク戦国時代。 新たなJSフレームワークが登場したと思えば、1年後にはオワコンとか言われていたりする、恐ろしい世界です。

React.js が流行ったと思えば、ReactはViewしか面倒見てくれないからFlux 入れようとか、 いやFluxちょっと使いにくいから Fluxxor 入れたほうが、いや Flummox の方がよさそうとか、redux だとか、もうわけわからん状態です。

実案件では今は Marionette.js を使っているんですが、そのことをフロントエンドエンジニア(jsの達人)の方に話したら、Backbone (Marionette) とかオワコンですよみたいな感じに言われたのが、ちょっとショックでした。

Javascriptフレームワークが乱立している世の中ですが、数あるフレームワークの中で人気を誇っているのがAngularとReactだと(私は)思っています。そのAngularの次期バージョンであるAngular2 のBeta版がついに登場したので、今回から数回にわたってAngular2を触ってみたいと思います。

なおAngular2はBeta版(2.0.0-beta.0)を利用していますが、今後大きな変更が入りサンプルコードが動かなくなる恐れがあります。

今回の目標

Angular2を開発できる環境を構築 & Angular2をとりあえず動かしてみる

皆様、Spec(コードベースの単体、機能、結合テスト)書いてますか? 私はあんまり書いていません。

「テスト書かないとかありえない!」と怒られそうなので一応弁解しておきますが、C0レベルのテストは、そこそこ書いているつもりです。 プロジェクトでカバレッジはXX%以上!(XXの部分は95だったり100!だったりします)という決まりがあるため、書いてます。消極的な理由ですね。

時としてカバレッジを満たすためのテストを書く、という意味の分からない事をしてしまったことは、反省しております。

しかし、C0は所詮C0であり、このレベルのテストをいくら一生懸命書こうが、バグがでるときはでるものなのです。 だからといってC1、C2、またはそれ以上を満たすようなテストを一生懸命かけばバグが無くなるか?という話でもありませんが、バグ発生率が少しは下がるかと思います。

さて、最近お固い業務システムで、そこそこ致命的なバグをやらかしてしまいました。 今後もC0レベルのSpecを書いてて良いのか? という話題がプロジェクト内から湧き上がったので、いろいろ考えてみることとしました。

DBのスキーマ、皆様どのように管理されているでしょうか。

Railsを利用されている方の多くは、ActiveRecordのマイグレーションを利用して管理をされているかと思います。

私もいままでいくつかのRailsプロジェクトに関わってきましたが、 ほぼ全てのプロジェクトでActiveRecordのDBマイグレーションを利用してきました。 (一部のプロジェクトはActiveRecordを使っていないため、マイグレーションも独自のものを利用しています)

ActiveRecordのマイグレーションでは、DBスキーマ変更の差分情報をマイグレーションスクリプトとして保存しておきます。例えば、新しいテーブル「users」を作成する場合は、下記のようなマイグレーションスクリプトを作成します。

class AddUsers < ActiveRecord::Migration
  def up
    # ここにマイグレーション適用時の操作を書く
    create_table :users do |t|
      t.string :name
      t.datetime :created_at
      t.datetime :updated_at
    end
  end

  def down
    # ここにマイグレーション破棄した時の操作を書く
    drop_table :users
  end
end

テーブル作成/削除やカラム変更を行う際には、マイグレーションスクリプトを1つ作成します。 このように変更を管理することによって、DBスキーマを最新版へ移行させたり、任意の時点のスキーマに戻したりすることが可能です。また、スキーマの一貫性を保つことができます。

便利な機能なのですが、プロジェクトが始まったばかりの初期開発フェーズで、このマイグレーション運用をするのはかなり辛いです。

プロジェクト初期の段階では、DBの設計もちゃんと固まっていないため、スキーマ変更が頻繁に発生します。 スキーマ変更のたびにマイグレーションスクリプトを書かないといけないのは手間がかかるもので、DB修正を気軽に行うことができなくなります。

何か楽できる手立てはないものでしょうか。

他人の開発画面、覗いてみた事ありますか。

覗いてみた事が無い方は、是非見せてもらってください。意外と面白いですよ。 gitのコミットの仕方ひとつとっても、人によって全く違うんだなと思うはずです。

git使いが10人いれば、使い方も10通りなんだなと、他人のコンソール覗きこむたびに感じます。

私の場合、プロジェクトが数ヶ月から半年に一度変わる(または並行して複数のプロジェクトに入る)という事が多く、いろんなgit使いの方に触れる 機会が多いです。

コンソール上でgitを操作する人、SourceTreeやEclipseプラグイン等のGUIツールで操作する人、git rebaseを多様する人、全くしない人、コミットグラフが綺麗な人、汚い人(そもそもあんまりこだわりを持っていない人?)、コミットメッセージを日本語で書く人、英語で書く人。。。

私は、「git pull」というコマンドを使う事はほぼ無いのですが、たぶんそういう情報は私の開発画面じーっと覗き込んでないと知りえない事だと思います。 gitを長い間使っている方は、自分流のgitの使い方を持っているかと思います。

今回は私のローカルでのgitの使い方を晒してみます。

ちょっと記事が長くなってしまいました。以下、今回の要点を最初に書いておきます。

  • コマンドは短く
  • 必要な情報は常に表示する
  • とにかくcommit
  • コミットコメントは一行で、かつ自分が分かりやすいコメントを
  • hookを活用する
  • 余計なものは無視する、または消す

その1 - その4 まで、Arelの内部構造について説明してきました。 魔法のような技術に思われるArelも、意外と単純な構造をしていました。

今回は、Arelの内部構造をGraphvizで出力する方法を紹介します。 図で構造を出力してみると、クエリがどういうノードで構成されているのかイメージでき、Arelへの理解がもっと深まるかと思います。

以下、目次となります。

今回はArelがjoinクエリを生成する過程を学んでみます。 使用するサンプルコードは以下の通りです。

product = Arel::Table.new(:products)
corporation = Arel::Table.new(:corporations)
product_detail = Arel::Table.new(:product_details)

product
  .project('*')
  .join(corporation)
  .on(product[:corporation_id].eq(corporation[:id]))
  .to_sql
# "SELECT * FROM `products` 
# INNER JOIN `corporations` ON `products`.`corporation_id` = `corporations`.`id`"

product
  .project('*')
  .join(corporation)
  .on(product[:corporation_id].eq(corporation[:id]))
  .join(product_detail)
  .on(product[:id].eq(product_detail[:id]))
  .to_sql
# "SELECT * FROM `products` 
# INNER JOIN `corporations` ON `products`.`corporation_id` = `corporations`.`id` 
# INNER JOIN `product_details` ON `products`.`id` = `product_details`.`id`"

まずは、joinがどういう動きをするのか、から見ていきましょう。

以下、目次となります。

今回は以下のようなSQL生成の過程を学んでみます。

product = Arel::Table.new(:products)
product.project('*').where(product[:price].eq(1000)).to_sql
# "SELECT * FROM `products` WHERE `products`.`price` = 1000"

まずは

product[:price].eq(1000)

の部分から読んでみます。

以下、目次となります。

今回は、以下のような単純なSQLをarelで生成してみます。

select * from products;

Arelで書くと以下のようになります。

product = Arel::Table.new(:products)
product.project('*').to_sql # select * from products;

上記コードでなぜ select * from products; というsqlが生成されるのかを見ていきましょう。

以下、目次となります。

このアーカイブについて

このページには、nishioが最近書いたブログ記事が含まれています。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。