HABTMのテーブル作成方法

2017年06月19日
区分
ruby
報告者:
endo

こんにちは、endoです。

今回は「HABTM」のテーブル作成の方法です。

「has_and__belongs_to_many」の多対多の関係性を頭文字で略語で表示しているものです。

発音はなんて発音されているのでしょうか。 自分は「ハブトゥム」って読んでいますが、どんな呼び方をしているのか気になります。 こんな呼び方があるよって方は、ぜひ教えてください!

さて、「HABTM」ですが、テーブル作成で便利に作成することができます。

rails g migration create_join_table_facility_prefecture facility prefecture

こんなファイルが出来上がります。

class CreateJoinTableFacilityPrefecture < ActiveRecord::Migration
  def change
    create_join_table :facilities, :prefectures do |t|
      # t.index [:facility_id, :prefecture_id]
      # t.index [:prefecture_id, :facility_id]
    end
  end
end

これでもいいのですが、foreign_keyに対して爪が甘いなと思います。

そこで、これを改造します。

class CreateJoinTableFacilityPrefecture < ActiveRecord::Migration
  def change
    create_join_table :facilities, :prefectures do |t|
      t.references :facility, index: true, foreign_key: true
      t.references :prefecture, index: true, foreign_key: true
      # t.index [:facility_id, :prefecture_id]
      # t.index [:prefecture_id, :facility_id]
    end
  end
end

なお、改造しなくてもrails5.1.1は下記のコマンドでいけます。

rails g migration create_join_table_facility_prefecture facility:references prefecture:references
class CreateJoinTableFacilityPrefecture < ActiveRecord::Migration[5.1]
  def change
    create_join_table :facilities, :prefectures do |t|
      t.references :facility, foreign_key: true
      t.references :prefecture, foreign_key: true
    end
  end
end

issue自体は下記で上がっていました。

create_join_table should include indexes and foreign key contraints

取り込まれて使用できるようになっております。

foreign_key好きが突っ込むよな!って思ったので、嬉しかったです。

アクトインディではHABTMについて語りたいエンジニアを募集しております。

DroidKaigi2017に行ってきました。(2日目)

2017年03月17日
区分
android
報告者:
honda

こんにちは、hondaです。

DroidKaigi2017に行ってきた(1日目)

こちらではDroidKaigi2日目で聴講したセッションを簡単にまとめたいと思います。

2日目に見てきたセッション

ウェルカムトーク

DroidKaigi参加者には事前にアンケートを取っていてその結果がスライドで紹介されていました。 気になった項目を抜粋してみました。

・参加者の年齢

年齢 割合
20代  46%
30代  45%
40代  6%

私は30代の部類です。今後40代も増えてくるのでしょうか。

・事業分類

事業分類 割合
自社サービス  68.2%
受託開発  23.5%

受託開発ではなかな参加出来ないのでしょうか。弊社は自社サービスですが、参加させてもらえた事に感謝ですね。

・開発規模

開発規模 割合
3〜5名  36%
2名  25.8%
1名  24.7%
6〜9名  7.9%

1名〜2名での開発規模が5割行ってますね。職場でアプリエンジニアが少ないとこういったカンファレンスが本当にありがたいです。アプリ開発で6〜9名って逆に開発を回すのが大変そうなイメージなのですがどうやって回していっているのでしょう。

minSdkVersion

minSdkVersion 割合
4.1〜4.3  36%
4.0.x  33.7%
4.4.x  15.2%
5.0.x  12.4%

6,7はさすがにないですねー

DroidKaigi公式アプリ

  • 296PRs
  • 126issues
  • 68contributors

@konifarさん、ありがとうございました!アプリ助かりました。

Android ORMの選び方

Ormaが個人的に気になっていたので聴講しました。 なぜデータをローカルに保存するのか?どうやって保存するのか?そして、複数のORM(ActivitAndroid,greenDAO,Requery,SQLBrite & SQLDelight,Realm,Orma)を比較して、良し悪しを浮き彫りにするような内容でした。 プロダクトでRealmを使っている分、若干色眼鏡気味ではありますがはやり今のところはRealmなのかなと。 ただ、マイグレーションの煩雑さやequalToでの型安全の指摘は納得できるものでした。 Ormaは型安全に関しては解決されていて、Realmに比べて実装の軽さを感じました。 サービスや作るアプリの性質次第では採用してみたいですね。

未熟なチーム開発

弊社でもアプリチームは1年ちょっとでチームらしくなってきました。 さらに成熟させるヒントなどありそうだと思ったので聴講しました。 秩序づくりのところは大いに活かせそうでした。秩序とそのドキュメント化は面倒ですが大事ですね。 あとはよりテストブルな実装は大事。 実業務を進めながら新人教育をするのはなかなか難しい。。。

Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ

より実践的な内容でいこーよアプリに活かせそうだったので聴講しました。 早口ではありましたが、DroidKaigiのアプリのコントリビュータをgithubから取得して表示するサンプルアプリを使っての説明でした。 とりあえず、RxJavaあたりから導入してみて、楽していきたい気持ちになりました。 Dagger2はテストとかも絡みそうなのでもうちょっと後から入れていこうかと。

4年続くアプリにおけるチーム開発

未熟なチーム開発と同じ理由で聴講しました。 UIファースト(UI駆動?)な開発スタイルでのバージョンごとでのアーキテクチャーの移り変わりと規約やドキュメントの整備やユーザインタビューでのアプリの質を高める話でした。 いこーよでもアーキテクチャーの見直しや規約、ドキュメントの整備は今まさに行っていることでとても参考になりました。 あと、目的別での部署を超えたチーム編成はとても興味深いものでした。

コマンドなしでぼくはAndroid開発できない話

コマンドで楽したい!という動機で聴講しました。

特に気に入ったコマンドを紹介します。

端末のワイヤレス接続

adb shell ip addr show wlan0 | grep 'inet ' | cut -d' ' -f6|cut -d/ -f1  ←端末のローカルIPを取り出す
adb tcpip 5555
adb connect "取り出したローカルIP":5555

条件としては端末とPCは同じWifi環境下にいる必要があります。 端末をUSBケーブルでPCとつなげて、上記コマンドを実行するとUSBケーブルが外れた状態でもコマンドを送ることが出来ます。

キーイベント送信

adb shell input keyevent KEYCODE_POWER ←電源キーを押す
adb shell input keyevent KEYCODE_SLEEP ←スクリーンをOFF

端末再起動

adb shell reboot 

Activity情報取得

adb shell dumpsys activity top

今表示しているActivitiyのクラスがわかる 今表示しているActivityのレイアウト構造がわかる!このアプリどういうレイアウトしてるんだろう?って思った時はレイアウト構造を丸裸に出来ます。

/data/data/packageName配管のファイルを見たい

adb shell run-as packageName

アプリの設定画面が見たい

shell am start -a android.settings.APPLICATION_DETAILS_SETTINGS -d package:"アプリのパッケージ名"

UIをカスタムしてあって、設定アプリが探しにくい端末だと使えます。

上記以外の使えるコマンドがここにまとめれてるそうです。

サンプルアプリをサクッと試したい

dryrun adbのコマンドではないですが、Githubに公開しているアプリをサクッと試すときにすごく重宝するツールです。

dryrun "GitHubリポジトリURL"

エンジニアが武器にするMaterial Design

まだMaterialDesignをものに出来ていないところがあるのでものにしたいために聴講しました。 ナノハさんではスピードも機能の1つと捉えてアニメーションもユーザに対するコンテンツの提供スピードを損ねないように実践されていて、とても興味深かったです。 その中でもアニメーションの改善で離脱率が半分に削減した話は特に興味深く登壇後やアフターパーティーでお話しを聞いてslackで弊社内のアプリチームに展開したところとても反響が大きかったです。 いこーよでも上手にMaterialDesignを活用して、ユーザに心地よくアプリを使っていただけるように改善していきたい。しよう。

テスト0から目指すクラッシュフリー率99%

テスト以外でも品質担保や不具合改善などの知見が得られそうだと思い聴講しました。 すごく当たり前のことですが、テストうんぬんの前のテスタブルにコードを書くというのが一番大切なんだなーと改めて感じました。 Activityからモデルを分離して、Interfaceを定義し、コンストラクタで依存するインスタンスを渡すようにするだけどすごくテスタブルでコードの見通しがよくなります。 あと、Fragment実装で一度は目にしたことがあるIllegalStateExceptionで悩んでる方はvultureを使うと幸せになれるようです。 最後にこの言葉は忘れないようにしよう。

まとめ

2日間ずっとお話しを聞き続けるっていうのは結構疲れました。 が、知見だらけの2日間はすごくエクサイティングで楽しかったです。 ずっと言い続けてますが、参加させてもらえたことに本当に感謝です。 この思いと知見をチームメンバーに伝えつつ、より良いプロダクトを作りたいですねー。 来年もぜひともDroidKaigiに参加したい! できれば、チームメンバー全員で参加して、お互い見れなかったセッションを現地で共有しあいたい!

以上、DroidKaigi2017に参加した感想でした。

DroidKaigi2017に行ってきました。(1日目)

2017年03月15日
区分
android
報告者:
honda

こんにちは、hondaです。

2017/03/09〜2017/03/10に開催されたDroidKaigi2017に参加してきました。 まずはチケット代8000円を負担してくれた会社と通常業務がある中、参加することにLGTMを出してくれた会社のメンバー、そして、帰宅が遅くなっても文句も言わず子供の面倒を見てくれた妻に感謝です。本当にありがとうございました! あとDroidKaigiを運営している有志の方々にも感謝しかありません。

今回ぼっち参加でしたが、登壇者の方に質問してもちゃんと話くれましたし、DroidKaigiの協賛企業のブースは面白かったし、おやつは充実してたし、ごはんは美味しかったし、とても楽しめました。

今回は見てきたSessionなどの感想をざっくり書いていきたいと思います。

アプリについて

DroidKaigi2017アプリ DroidKaigiアプリリポジトリ 毎朝、リポジトリをチェックしてチャンスがあればPRを出してみようかと思ってたのですが、コントリビュータの方々のPRのスピードに圧倒されるばかり参加できなかったのが少し残念でした。 内部実装を眺めては「ここを参考にしたらいこーよアプリの改善で使えるかも」と妄想していました。 DroidKaigi当日はこのアプリのおかげで見たかったセッションはすべて見ることが出来ました。 アプリ開発に当たられた@konifarさん、そしてコントリビュータの方々には感謝しかありません。

1日目に見てきたセッション

ウェルカムトーク

今回は800人近くのエンジニアの方が来場したそうです。 すごーい!

How to apply DDD to Android Application Development

特定のアーキテクチャーではなく、アーキテクチャーを採用するまでの考え方を知りたくて聴講しました。 わかる! ドメイン駆動設計~もちこちゃんの大冒険~は読んだことあるのですが、とても分かりやすい説明でした。 ドメインとモデルを明確に定義し、それを意識した考え方とそれにあった設計を実装していくことが大事!

リリース自動化と効率のよいリリースフローを求めて

弊社アプリチームはまだ人数も少なく、少しでも効率よく開発を進めることが重要なので、そのヒントを掴みたいので聴講しました。 現状、CIを入れて内部の動作確認などで自動化は進めていて、製品版リリースでは自動化はまだなのでその辺のTIPSが聞けたり、裏付けが出来てとても良かったです。 ただ、サービスの規模などの状況によっては自動化の「やりすぎ」も起こり得るのでそのへんは注意が必要だなと感じました。

Androidリアルタイム通信アプリ作成Tips

弊社いこーよアプリでもリアルタイムの技術はのちのち必要な場面出てきそうだなと感じているので聴講しました。 リアルタイム通信を実現するライブラリの紹介でした。 200枚のスライドだっため、説明がとても早口で聞いてるが少し大変でした。 結果としてはrealm mobile platformはすごいなの一言でした。 弊社アプリでもRealmを使っているので状況によってはrealm mobile platformをうまく使ってサービスを大きくしていきたいですね。

Data Bindingで開発を気持ちよくしよう

弊社アプリでは100%Kotlinで実装されているのですが、KotlinとData Bindingは相性が悪いという情報を聞いていたので採用を控えていました。 本セッションでその辺が触れられなかったので残念でしたが、たしかにActivityの見通しはよくなったのでタイミングを見て採用したいですね。

実践アニメーション

現状のいこーよアプリでは積極的にアニメーションを採用していません。 今後はユーザの使い心地のためにMaterialDesignの積極的に採用すると思い聴講しました。 実践的な説明もあり、聴講してよかったです。

オフラインファーストなアプリケーション開発

いこーよアプリではAndroid、iOS両方でRealmを採用しています。同じ時間帯で他のセッションも気になったのですが開発メンバーの強い要望もあり、こちらを聴講しました。 Androidリアルタイム通信アプリ作成Tipsでも出ていましたが、realm mobile platformはやはり素晴らしいテクノロジーですね。 他の聴講者も興味が強かったようで、聞いてきたセッションの中で一番質問数が多かった気がします。

How to remodel current testing environment

テストコードはアプリの動作保証をする上で重要ですが、アプリやサービスの規模、リソースの関係でなかなかガッツリと取り組めていないのが現状です。 なのでその辺をうまくバランスとりながら、保証を担保していく方法がないかと思い聴講しました。 テストをやる理由からBDDやTDDでのテスト方針的なことがとてもロジカルに語られていました。 当たり前なことではあると思いますが、全くテストがない状態から部分的にテストコードを拡充させていく際もテスト方針や設計は明確にして進めるべきだなと感じました。

Android Bikeを作ろう

個人的に今年はIOTやってみたいなーと思い聴講しました。 実際の実装した話を元にしたスライドだったので具体的な話が聞けて良かったです。 まずはうちにあるものでIOTを実感してみようと思わせてくれるセッションでした。

以上、DroidKaigi1日目の感想でした。

ActiveRecord::enum を拡張する gem を作りました

2017年03月13日
区分
rails
報告者:
kawaguchi

kawaguchiです。
iko-yo.net で使われている module を別プロジェクトで使いたくなったので gem にしました。
https://github.com/jiikko/active_record-enum_with_label

class User < ActiveRecord::Base
  include ActiveRecord::EnumWithLabel

  enum_with_label :alert_status, {
    alert_status_none: 'なし',
    alert_status_mail_sent: 'メール送信',
    alert_status_telephoned: '電話',
  }
end

User.alert_status_labels # => ['なし', 'メール送信', '電話']
user = User.create(alert_status: :alert_status_none)
user.alert_status_label            # => 'なし'
user.alert_status_before_type_cast # => 0

ビューが綺麗にかけます。

iko-yo.net を rails4.2 にアップグレードしました

2017年03月08日
区分
rails
報告者:
kawaguchi

kawaguchiです。
先日、iko-yo.net の rails を 4.1 から 4.2 へアップグレードしました。

大きなアップグレードといえば、 変更行数が多くなるので github.com のプルリクではすべての差分が表示できなくなったり、 コードレビューに時間がかかり開発者にストレスがかかりがちです。

この問題を避けるために、今回のアップグレードは master ブランチでも動く変更に限り、 適宜 master ブランチへマージしていくことにしました。

その結果、master ブランチでも動くように動作確認が若干のオーバーヘッドになりましたが、 巨大ブランチのマージをしないことで、コードレビュー負荷の軽減や精神的に余裕ができました。

以上。

 | 

技師部隊からの
お知らせ

【求人】エンジニア募集しています。

本頁の来客数
八十七万千百七十六名以上(計測停止中)

メンバー一覧

アクトインディ技師部隊員名簿

アクトインディ技師部元隊員

アクトインディへ

カテゴリー

アクトインディ

aaaa