このエントリーをはてなブックマークに追加

2017年2月10日金曜日

Swift3でSCLAlertViewを使ってみた

こんにちは、onukiです。

今回はSwiftでフラットなデザインの
アニメーション付きアラートビューが扱える
SCLAlertViewを試してみたいと思います。

準備

おなじみCocoaPodでインストールします。
pod 'SCLAlertView'

実装

今回はボタン付きのアラートを表示したいと思います。
まずはSCLAlertViewをインポートします。
import SCLAlertView
アラートビューを表示します、ボタンは二つ用意します。
let alertView = SCLAlertView()
//ボタンの追加
alertView.addButton("ボタン1") {
    //タップ時の処理
    print("ボタン1をタップしました")
}
alertView.addButton("ボタン2") {
    print("ボタン2をタップしました")
}
//表示実行
alertView.showSuccess("ボタン付きアラート", subTitle: "説明")
そうするとこのように表示されます。

今回は基本的なボタン付きのアラートでしたが、
他にもテキスト入力できるもの、ボタンなしで時間指定で閉じるもの等
色々あるので、興味を持たれた方は作者のgithubを拝見してみてください。

2017年2月9日木曜日

はじめの一歩 -Rails ActiveRecord編- UPDATE2


どうも、はじめです。
前回はUPDATEについて書いてみました。
はじめの一歩 -Rails ActiveRecord編- UPDATE
今回はUPDATEの際readonlyやvalidationで更新ができなかった場合に関して書いていこうと思います。


はじめに


今回も前回と同じテーブルを使用しようと思います。
usersテーブル
[id: 1, user_name: 'Aさん'],
[id: 2, user_name: 'Bさん'],
[Id: 3, user_name: 'Cさん']

itemsテーブル
[id: 1, item_name: 'Rubyの本'],
[id: 2, item_name: 'Railsの本'],
[id: 3, item_name: 'PHPの本']

user_itemsテーブル(userが持っているitemを管理するテーブル)
[id: 1, user_id: 1, item_id: 1],
[id: 2, user_id: 1, item_id: 2],
[id: 3, user_id: 2, item_id: 3]

関連性
user : user_item => 1 : n
item : user_item => 1 : n


ではまず【readonly】で更新できなかった場合の対処法を書いてみます。

readonly


下のように更新をしてみます。
[id: 2, user_id: 1, item_id: 2]
↓
[id: 2, user_id: 1, item_id: 3]
手元でなかなかreadonlyになる状況を再現できなかったため
以下の方法でreadonlyにしました。
user_item = UserItem.readonly(true)

この状態で変更しようとしても更新できません。
user_item.find(2).update(item_id: 3)
# ActiveRecord::ReadOnlyRecord: UserItem is marked as readonly

これだとreadonlyでrollbackされてしまいます。

モデルからインスタンスを取得する際にreadonlyをfalseにしてあげれば更新が可能になります。
user_item = UserItem.readonly(false)
user_item.find(2).update(item_id: 3)


次に【validation】でエラーになった場合です。

validation


ユーザーの登録の際、user_nameを入力必須にしていたとします。
入力必須のバリデーションを定義するにはUserモデルに対し以下のように定義します。

# app/models/user.rb
class User < ApplicationRecord
 validates :user_name, presence: true
end

この状態でユーザー名を空で登録しようとするとエラーになります。
user = User.new
user.save

次のように記述することで一時的にバリデーションを無効にすることができます。
user = User.new
user.save(:validate => false)


最後に


validationを一時的に無効にすることは可能ですが、
今回例としてあげたのケースの場合、
DBでuser_nameにnot null制約がかかっているとバリデーションを無視することができても、
DBへの登録時にエラーになってしまいますので気をつけましょう。

次回はupdate_attributeとupdate_attributesを使ってみようと思います。

2017年2月8日水曜日

アニメーション









どうもーデザイナーのnottyです。

先日AirbnbDesignからAfter Effectsで作成したアニメーションをレンダリングして
iOS・Android・React Native向けのアニメーションに変換してくれる、『Lottie』が公開されました!

In the past, building complex animations for Android, iOS, and React Native apps was a difficult and lengthy process. You either had to add bulky image files for each screen size or write a thousand lines of brittle, hard-to-maintain code. Because of this, most apps weren’t using animation — despite it being a powerful tool for communicating ideas and creating compelling user experiences. One year ago, we set out to change that.
複雑なアニメーションを作るためには、保守が大変で大量のコードを書かないといけない必要だったが、Lottieによって、それは変わりました。的なことが書かれています。

『Lottie introducing』




現在、私が使用しているアプリで
お気に入りや、ローディング、いいねボタンなど
いたるところにアニメーションが使用されています。

ユーザーにとって、ストレスにもなりうるウォークスルーなどに
見てて気持ちの良いアニメーションを作成すると非常に効果的かもしれません。

このライブラリがでて非常に良かったのですが、
それ以上に事業会社からこういった技術(デザイン)をシェアするという事に
毎回興奮します。日本からもこういうプロダクト(技術)などもっといっぱいでると良いなと思う次第でございます。

2017年2月7日火曜日

関連するレコードを一緒に作成する方法

こんにちは。h_ono_222です。

フォームからレコードを作成する際に、関連するレコードを一緒に作成する基本的な方法をまとめます。

1. モデルの作成

# user.rb
class User < ActiveRecord::Base
  has_many :books
  accepts_nested_attributes_for :books
end

# book.rb
class Book < ActiveRecord::Base
  belongs_to :user
end

2. コントローラを作成する

# users_controller.rb
class UsersController < ApplicationController
  def new
    @user = User.new
    @user.books.build
  end

  def create
    @user.new(user_params)
    if @user.save
      redirect_to @user
    else
      render :new
    end
  end

  private
  def user_params
    params.require(:user).permit(books_attributes: [:name])
  end
end

3. フォームを作成する

# _form.html.erb
<%= form_for(@user) do |f| %>
  <%= f.fields_for :books do |field| %>
    <%= field.label :name %>
    <%= field.text_field :name %>
  <% end %>
  <%= f.submit %>
<% end %>

以上です。

2017年2月6日月曜日

配牌からあがれる可能性を予測する!(その5 実際にテストしてみる)

こんにちは、Taroです。
前回の記事の記事の続きになります。
配牌からあがれる可能性を予測する!(その4 勾配を求める際に詰まったこと)
今回は実際にテストしてみたいと思います。

テストに使用した配牌について


Youtubeであがっていた○凰のプレイ動画を1半荘分試しました。

結果


# 第一要素があがれる方、第二要素があがれない方
# 重み
[[-0.09800755  0.09915648]    # 順子
  [ 0.15426824 -0.17342399]    # 対子
  [-0.61190551  0.61323983]]  # 暗刻

# バイアス
[-0.84420447  0.84420447]
この結果だけ見ると、対子の数があがれる方に寄与しているように見えます。
逆に暗刻があるとあがりにくいようです笑
ちょっとリャンメンやカンチャンの形も要素に入れた方が良かったかな、と後悔し始めておりますが、とりあえずこのまま進めたいと思います。

結果を記載しますが、配牌を記載するとおさまりきらないので、「あがれた」か「あがれなかった」を記載します。
結果 あがれる確率 あがれない確率
東1局 あがれない 17% 83%
東2局 あがれない 29% 71%
東3局 あがれない 7% 93%
東3局1本場 あがれない 17% 83%
東4局 あがれない 33% 67%
南1局 あがれる 20% 80%
南1局1本場 あがれない 26% 74%
南2局 あがれない 17% 83%
南3局 あがれる 26% 74%
南4局 あがれる 23% 77%

パッと見、ちゃんと予測できているようには見えないです。
よく考えたら、麻雀は4人のうち1人があがれるゲームなので、単純計算でアガれる確率は25%です。
教師データが足りないのかもしれないと思い、とりあえずプロの対局1局分追加してみました。

結果②


# 第一要素があがれる方、第二要素があがれない方
# 重み
[[ 0.17258578  -0.17396835]    # 順子
  [ 0.20088727 -0.20564398]    # 対子
  [-0.33262621  0.34681625]]  # 暗刻

# バイアス
[-1.07893278  1.07893278]
先ほどとは重みが変わり、順子もアガれる確率に寄与するようになりました。
それではこちらのパラメータをもとに同じテストデータで実験してみます。
比較しやすいよう先ほど求めた結果を①とし、アガれない確率のみ記載します。
結果 結果①のアガれない確率 結果②のアガれない確率
東1局 あがれない 83% 73%
東2局 あがれない 71% 64%
東3局 あがれない 93% 92%
東3局1本場 あがれない 83% 80%
東4局 あがれない 67% 72%
南1局 あがれる 80% 85%
南1局1本場 あがれない 74% 79%
南2局 あがれない 83% 80%
南3局 あがれる 74% 79%
南4局 あがれる 77% 73%

結果の方も変化しました。
10局のうち、6局の「アガれない確率」が下がっています。
つまり「アガれる確率」が上昇しています。
このことから、結果①の時点では、「アガれる」可能性を過少評価していることが考えられます。

おわりに


今後の目標としては、
  • 教師データを増やす
  • レイヤーのノードを追加(リャンメン、カンチャン、ペンチャン)の数

とりあえず、まずは教師データを作成するのが楽になるインターフェースを実装したいと思います。
参考のソースコードはこちらになります。
https://github.com/naoki85/python_mahjong