RailsでERBからJavaScriptに変数の値を渡す方法

このエントリーはWeb開発初級者向けです。

JavaScriptでViewを動的に更新したい場合、Controllerで定義したインスタンス変数の値などをJavaScript側に渡したい場合があると思います。

数値や文字列の場合はhiddenフィールドなどに出力していますが、Hashの場合はそのまま出力してもJavaScript側で取得すると文字列になり、そのままでは使えません。

Hashを受け渡したい場合は、事前にHashを.to_jsonでJSON化し、JavaScript側でparseJSONしても良いのですが、
下記のようにカスタムデータ属性を使うと、そのままHashとしてアクセスできます。

変数

@test = { 'hoge' => 'huga', 'hogehoge' => 'hugahuga' }

ERB

<div id="hoge" data-hoge-id="<%= @test.to_json %>"></div>

JavaScript

var test = $('#hoge').data('hoge-id');

実行結果

test
Object {hoge: "huga", hogehoge: "hugahuga"}

「嫌われる勇気」＝「他人はどうでもいい」ではない

今回の書籍は、2013年頃にかなり話題になっていたらしい(私は全く知りませんでした…)、「嫌われる勇気」です。
通して読んでみて感じたのは「とても有益な内容だけど、拾い読みやつまみ食いは危ない」でした。
少しでも本書に興味をお持ちの方は、途中を読み飛ばさず最後まで通読することをおすすめします。

というのも、文中にアドラー心理学のキーワードがいくつか出てきますが、分かりやすいスローガンや指針ではありません。
その言葉の意味するところを理解しないまま行動に移すと、むしろ痛い目を見るのでは…と思います。

例えば、本のタイトルである「嫌われる勇気」ですが、「他人なんてどうでもいいから嫌われても構わない」という論旨では全くありません。
対人関係を築く上で大切なのは「他者貢献」と「他者信頼」、そして「自己受容」だと説いています。
他にも「承認欲求は不要」と強くバッサリ切り捨てていたり、他者を評価してはいけないと言いつつ、
上で述べたように「他者貢献」が重要というのがアドラー心理学の肝です。

本書の文章は「青年」と「哲人」の会話形式で進み、青年が哲人にアドラー心理学の教えを請う形になっていて
青年は文中で何度も、哲人の言葉に矛盾があると噛み付いています。
この本をネタにした当日のドトール会でも、あれこれと肯定・否定の意見が出てきて、議論の題材としては良い本でした。
アドラー自身、「それまで生きてきた年数の半分」が、アドラー心理学の理解に必要だと言っていますし、
今後も折に触れて開けば、その都度発見がありそうな本です。

PHPer （PHPプログラマー）から Rubyist （Rubyプログラマー）へ

初めて投稿させていただきます。
よろしくお願いします。

今回とあることをきっかけに初めてRubyを勉強することになり、
その上本格的にRuby on Railsを触れる機会を頂くことができました。

これまで実戦で使っていた言語は基本的にPHPが中心だった私からすれば、
驚きだらけだったので下記のブログを参考にPHPとRubyとで比較をしてみました。

Rubyで使える配列関連のメソッドを学習した

まず先ほどのブログと同様に前提として以下のようなテーブルがあるとし、
[books]という連想配列にデータを取得したとして比較をしていきます。

id	name	price	description
1	Rubyの本	1000	Rubyの本です。
2	JavaScriptの本	1000	JavaScriptの本です。
3	PHPの本	1000	PHPの本です。
4	HTMLの本	2000	HTMLの本です。
5	CSSの本	2000	CSSの本です。

1. IDのみを取得して配列にしたい

where句でin演算子を使用したいときなどによく使うと思います。

PHP

$ids = array();
foreach ($books as $book) {
 $ids[] = $book['id'];
}
# => [1, 2, 3, 4, 5]

Ruby

ids = books.map { | book | book.id }
# [1, 2, 3, 4, 5]

私は普段PHPではこのように書いていましたが、
 Rubyで書くとすごく単純にかけてしまうものだなと思いました。 

調べてみたところPHPでもこのような書き方があるそうです。

$ids = array_column($books, 'id');

このarray_columnですが、 第一引数に値を取り出したい多次元配列を、
第二引数に取り出したいカラムのkeyや名前を設定していますが、
第三引数値を設定すると、その値をkeyとして連想配列を生成してくれます。

例

$id_to_names = array_column($books, 'name', 'id');
# => [1 => "Rubyの本", 2 => "JavaScriptの本", 3 => "PHPの本"...]

こんな便利なものがあったなんて。。。 知らなかった。

2.特定の値でのグループ分け

参考にした記事ですごいと思ったのでPHPとの比較をしてみました。

PHP

  function group_by_price(array $books, $keyName) {
    $keys = array_column($books, $keyName);
    $books_group_by_price = array();
    foreach ($books as $book) {
      $books_group_by_price[$book[$keyName]][] = $book;
    }
      return $books_group_by_price;
  }
  $books_group_by_price = group_by_price($books, 'price');

Ruby

books_group_by_price = Books.all.group_by{ |book| book.p }

どちらも同様に下記のような出力結果になります。

  # [1000] =>
  #  [0] => ["id" => "1", "name" => "Rubyの本", "price" => "1000", "description" => "Rubyの本です。"],
  #  [1] => ["id" => "2", "name" => "JavaScriptの本", "price" => "1000", "description" => "JavaScriptの本です。"],
  #  [2] => ["id" => "3", "name" => "PHPの本", "price" => "1000", "description" => "PHPの本です。"]
  # [2000]=>
  #  [0] => ["id" => "4", "name" => "HTMLの本", "price" => "2000", "description" => "HTMLの本です。"],
  #  [1] => ["id" => "5", "name" => "CSSの本",  "price" => "2000", "description" => "CSSの本です。"]

こちらはもう全然変わってきますね。 PHPで書く場合ほかの書き方もあるのかもしれませんが、 Rubyではこのように1行で端的に書けてしまうんです。

3. その他個人的にここが良いと思ったことをいくつか

・変数名 先ほどまでも例として挙げているソースを見ていただいてもわかる通り、
PHPでは変数名の前に「 $ 」を付けますが、Rubyでは何も記載する必要はありません。
その他にも、PHPでは1行の最後には必ず「 ; （セミコロン）」を付けなければエラーとなりますが Rubyでは省略可能です

 このようにRubyでは省略可能なものが多く存在するという印象を強く受けました。
「省略可能 = 文字数が少なくなる = すっきりする = コードが見やすくなる」
といったメリットがあります。

連想配列やハッシュの書き方でもかなり変わってくると思います。



  ・文字列結合
どんなアプリやサイトを作っていてもかなりの確率で文字列結合をする場面はあると思います。
PHPにもRubyにもsprintfはありますがその他での記述方法を用いた場合かなり差が出るなと驚きました。
"「Rubyの本」の価格は1000円です。"と表示する例を挙げてみます。

PHP

echo('「'.$book['name'].'」の価格は'.$book['price'].'円です。');

Ruby

puts "「#{books.name}」の価格は#{books.price}円です。"

この例だけではあまりわからないかもしれませんが、
もう少し入り乱れてくるとPHPよりもRubyの方が見やすいのではないかと思いました。

全体的に見てもRubyで書くと比較的シンプルに書けるといった印象を受けました。
私自身PHPに関してもRubyに関しても未熟で知らないことばかりなので、
こんな書き方もあるぞ！とかこういった面ではPHPのほうが優れている！とかがあれば
コメントしていただければと思います。

 では、最後まで見て頂きありがとうございました。
 メントしていただければと思います。

Amazon RDS 一般クエリログとスロークエリログの削除

　こんにちは、Hiroです。Amazon RDSでのテーブルに保存されている「一般クエリログ」と「スロークエリログ」の削除方法について、簡単にまとめたいと思います。

　まず、RDSのデフォルトのDBパラメータでは、一般クエリログ、スロークエリログともにファイルにもテーブルにも保存されないようになっています。
　そこで、詳しくはAmazonのガイドページを見ていただければと思いますが、クエリログ関連の設定内容を転記させていただきます。

• slow_query_log: スロークエリログを作成するには、1 に設定します。デフォルトは 0 です。
• general_log: 一般ログを作成するには、1 に設定します。デフォルトは 0 です。
• long_query_time: ファストクエリがスロークエリログに記録されないようにするために、ログに記録されるクエリの最短実行時間の値を秒単位で指定します。デフォルトは 10 秒で、最小値は 0 です。log_output = FILE の場合は、マイクロ秒の精度になるように、浮動小数点値を指定できます。log_output = TABLE の場合は、秒の精度になるように、整数値を指定する必要があります。実行時間が long_query_time の値を超えたクエリのみがログに記録されます。たとえば、long_query_time を 0.1 に設定すると、実行時間が 100 ミリ秒未満のすべてのクエリはログに記録されなくなります。
• log_queries_not_using_indexes: インデックスを使用しないすべてのクエリをスロークエリログに記録するには、1 に設定します。デフォルトは 0 です。インデックスを使用しないクエリは、その実行時間が long_query_time パラメータの値未満であってもログに記録されます。
• log_output option: log_output パラメータに指定できるオプションは、次のとおりです。
• TABLE（デフォルト）– 一般クエリを mysql.general_log テーブルに、スロークエリを mysql.slow_log テーブルに書き込みます。
• FILE – 一般クエリログとスロークエリログの両方をファイルシステムに書き込みます。ログファイルは 1 時間ごとにローテーションされます。
• NONE – ログ記録を無効にします。

今回は、下記の設定した場合のケースでお話します。

• slow_query_log: 1
• general_log: 1
• long_query_time: 1
• log_queries_not_using_indexes: 0
• log_output: TABLE

上記の設定をすると設定内容に記載の通り一般クエリログは「mysql.general_log」に、スロークエリログは「mysql.slow_log」に保存され、ある一定サイズや空き容量をもとにローテーションされます。
　このテーブルなのですが、RDSのユーザ権限ではDELETEすることができないため、Amazonから2つのストアドプロシージャが提供されています。

CALL mysql.rds_rotate_slow_log;
CALL mysql.rds_rotate_general_log;  

　1回の実行ではバックアップにログがローテーションされ、2 回目の実行で完全に削除されることになります。

Amazonの公式ガイドページ

Swift3で消えたadvancedBy

Swift2で部分文字列を取得するのにadvancedByを使用してindexを取得していたのが
Swift3では以下の方式に変更されました。

Swift2

str.startIndex.advancedBy(2)

これが
Swift3

str.index(str.startIndex, offsetBy: 2)

のような形になります。

Rubyで使える配列関連のメソッドを学習した

---

はじめに

こんにちは、Taroです。 Rubyの勉強を始めて早3ヶ月。
これだけはRubyを使う上で覚えておけ、という配列関連のメソッドを教えていただいたので、簡単にまとめてみました。
イメージしやすいよう、下記のようなテーブルとレコードを使います。

ID	name	price	description
1	Rubyの本	1000	Rubyの本です。
2	JavaScriptの本	1000	JavaScriptの本です。
3	PHPの本	1000	PHPの本です。
4	HTMLの本	2000	HTMLの本です。
5	CSSの本	2000	CSSの本です。

---

Enumerable#map (collect)

要素の数だけ繰り返しブロックを実行します。
collectはmapの別名で、同様の動きをします。

items = Item.all
item_ids = items.map { |item| item.id }
# => [1, 2, 3, 4, 5]

上記のように各要素に対してメソッドを適用する場合は&を使って以下のようにも書くことができます。

item_ids = items.map(&:id)

---

Enumerable#select

ブロックを各要素に対し実行し、真となった要素を返します。

item_price_array = Item.all.map(&:price)
# => [1000, 1000, 1000, 2000, 2000]
only_price_1000 = item_price_array.select { |price| price == 1000 }
# => [1000, 1000, 1000]

上記では、mapを使用して1回値段のみの配列にしてしまったが、下記のようにすればprice = 1000だけ配列で取得できます。
（ちょっと例が悪かったため、whereで解決できてしまいますが。）

only_price_1000_items = Item.all.select { |item| item.price == 1000 }
# => [#{Item id: 1, name: "Rubyの本", price: 1000, description: "Rubyの本です。", created_at: "2016-10-02 05:32:52", updated_at: "2016-10-02 05:32:52"}, #{Item id: 2, name: "JavaScriptの本", pricdescription: "JavaScriptの本です。", created_at: "2016-10-02 07:42:16", updated_at: "2016-10-02 07:42:16"}, #{Item id: 3, name: "PHPの本", price: 1000, description: "PHPの本です。", created_at: 09:24:55", updated_at: "2016-10-02 09:24:55"}]

なお、selectとは逆で、偽を返す場合はrejectを使用します。

not_price_1000_items = Item.all.reject { |item| item.price == 1000 }
# => [#{Item id: 4, name: "HTMLの本", price: 2000, description: "HTMLの本です。", created_at: "2016-10-02 09:25:12", updated_at: "2016-10-02 09:25:12"}, #{Item id: 5, name: "CSSの本", price: 2000tion: "CSSの本です。", created_at: "2016-10-02 09:25:59", updated_at: "2016-10-02 09:25:59"}]

---

Enumerable#reduce (inject)

`inject`は`reduce`の別名で、同様の動きをする。
畳み込み演算を行うメソッドをし、その結果を返す。

item_price_array = Item.all.map(&:price)
# => [1000, 1000, 1000, 2000, 2000]
item_price_array.reduce(0) { |result, price|
  result + price
}
# => 7000

まず、reduce(0)にある0は、次に記載するresultの初期値になります。
ブロック内に記載のあるresult(1つ目のブロック引数）はブロックの戻り値が入ります。
price(2つ目のブロック引数)は配列の各要素になります。

# 1週目
result = 0 (初期値), price = 1000
# 2週目
result = 1000, price = 1000
# 3週目
result = 2000, price = 1000
# 4週目
result = 3000, price = 2000
# 5週目
result = 5000, price = 2000
# 戻り値
=> 7000

なお、簡単な演算であれば下記のようにシンボルで記述することもできます。

item_price_array.reduce(:+)
=> 7000

初期値に配列を渡すこともできて、フィボナッチ数列などは下記のように書けるようです。 （引用：ちょっとわかりにくいけど非常に便利なinjectメソッド）

(0..5).reduce([1, 1]) { |fib, i| fib << fib[i] + fib[i+1] }
# => [1, 1, 2, 3, 5, 8, 13, 21]

Enumerable#index_by

特定の値をキーとしたハッシュを生成してくれます。

items_index_by_name = Item.all.index_by { |item| item.name }
# => {"Rubyの本"=>#{Item id: 1, name: "Rubyの本", price: 1000, description: "Rubyの本です。", created_at: "2016-10-02 05:32:52", updated_at: "2016-10-02 05:32:52"}, "JavaScriptの本"=>#{Item id: 2vaScriptの本", price: 1000, description: "JavaScriptの本です。", created_at: "2016-10-02 07:42:16", updated_at: "2016-10-02 07:42:16"}, "PHPの本"=>#{Item id: 3, name: "PHPの本", price: 1000, de"PHPの本です。", created_at: "2016-10-02 09:24:55", updated_at: "2016-10-02 09:24:55"}, "HTMLの本"=>#{Item id: 4, name: "HTMLの本", price: 2000, description: "HTMLの本です。", created_at: "20162", updated_at: "2016-10-02 09:25:12"}, "CSSの本"=>#{Item id: 5, name: "CSSの本", price: 2000, description: "CSSの本です。", created_at: "2016-10-02 09:25:59", updated_at: "2016-10-02 09:25:59"}

ここでも&を使用すると便利です。

items_index_by_name = Item.all.index_by(&:name)

Enumerable#group_by

特定の値をキーとしてグルーピングした、新しいハッシュを生成してくれます。

items_group_by_price = Item.all.group_by{ |item| item.price }
# => {1000=>[#{Item id: 1, name: "Rubyの本", price: 1000, description: "Rubyの本です。", created_at: "2016-10-02 05:32:52", updated_at: "2016-10-02 05:32:52"}, #{Item id: 2, name: "JavaScriptの本 1000, description: "JavaScriptの本です。", created_at: "2016-10-02 07:42:16", updated_at: "2016-10-02 07:42:16"}, #{Item id: 3, name: "PHPの本", price: 1000, description: "PHPの本です。", crea6-10-02 09:24:55", updated_at: "2016-10-02 09:24:55"}], 
#     2000=>[#{Item id: 4, name: "HTMLの本", price: 2000, description: "HTMLの本です。", created_at: "2016-10-02 09:25:12", updated_at: "2016-1:25:12"}, #{Item id: 5, name: "CSSの本", price: 2000, description: "CSSの本です。", created_at: "2016-10-02 09:25:59", updated_at: "2016-10-02 09:25:59"}]}

ここでも&を使用すると便利です。

items_group_by_price = Item.all.group_by(&:price)

Enumerable#partition

group_byと似たグルーピングのメソッドで、partitionというものもあります。
これはブロック内の要素が真か偽かで新しい配列を生成してくれます。

items_partition_with_price = Item.all.partition {|item| item.price == 1000 }
# => [
#       [#{Item id: 1, name: "Rubyの本", price: 1000, description: "Rubyの本です。", created_at: "2016-10-02 05:32:52", updated_at: "2016-10-02 05:32:52"}, #{Item id: 2, name: "JavaScriptの本", pri description: "JavaScriptの本です。", created_at: "2016-10-02 07:42:16", updated_at: "2016-10-02 07:42:16"}, #{Item id: 3, name: "PHPの本", price: 1000, description: "PHPの本です。", created_at2 09:24:55", updated_at: "2016-10-02 09:24:55"}], 
#       [#{Item id: 4, name: "HTMLの本", price: 2000, description: "HTMLの本です。", created_at: "2016-10-02 09:25:12", updated_at: "2016-10-02 09:25:12"},#{Item id: 5, name: "CSSの本", price: 2000, description: "CSSの本です。", created_at: "2016-10-02 09:25:59", updated_at: "2016-10-02 09:25:59"}]
#    ]

---

おわりに

簡単ではありますが、復習としてまとめました。
mapとcollectのように、同一の処理なのにメソッド名が異なるのは、LispとSmalltalkの影響のようです。
下記に詳しく記載されております。
map と collect、reduce と inject ―― 名前の違いに見る発想の違い
もし間違っている、もしくは他にもこんな使い方や便利なメソッドがある、といったことがありましたらぜひ教えてください！

GRIT（やり抜く力）

こちらの記事は下記に移転しました。
https://re-engines.com/2017/05/19/518/

自分を売り込め!

すっかり寒くなってきましたね。
寒さ関係なくエンジニアにすこぶる評判のsoft skills
「第2部 自分を売り込め! 」
を読んだ感想を書き出そうと思います。

見出しからいきなり自分を売り込めと来るんですが、
著者は自分を売り込むためには、マーケティングをする事が大事と語っております。
そのマーケティングというのも、この業界ならではのリスティング広告や、
一般的に言う市場調査といった事に限定するのではなく、
自分自身をセルフマーケティングをする事だと熱く語りかけてくれます。

 プロダクト、インフラ、ブランド、SNS、宣伝、といった要素を上手く組み合せ、
自分というコードモンキーな人間を、いかにして他者に認知して貰うという行為が、
この世界で生き抜く為に必要な要素なんだよと教えてくれます。

• セルフマーケティング
• ブランディングの確立
• ブログの作り方
• 自分がしている９０％は無料化 
• プレゼンテーション、講演
• 本や記事を執筆する
• バカにされるのを恐れるな

上記を引っ括めて、

「お客様に価値を提供してお金をいただくこと」

を目標に、淡々とセルフマーケティングを行うんだと刷り込まれます。

確かにこの業界で生き抜く為には、技術的な要素だけでなく、
人間としてブランドとしてアピールできるという事は、
ほんと大事なんだろうと思いますし、
著者の様に自己啓発を繰り返し、辿り着いた先で成功が待っていたら最高ですよね。

今回の第2部も日本とアメリカはちょっと違うので、？と思ったりする部分がありましたが、著者が言っている事はほんと間違ってはいないし、
今回も本気で実践しなきゃなと思わせる章は多々ありました。

その中でもこれは大事だなと思った章をピックアップすると
「最大の目標：他人のために価値を生み出せ！」

成功した人ではなく、価値を生み出す人になるよう努力せよ 
ーーアルバート・アインシュタイン

こうありたいと思った深夜0時。

Paginatorについて再確認（Ruby on Rails、FuelPHP）

こんにちは、Taroです。
寒くなってきた今日この頃、室内外の寒暖差でとても眠くなります。

Ruby on RailsのkaminariというGem（ライブラリ）に触れる機会を得ました。
何を今更、有名なGemじゃないか、と言わないでください。
確かに非常にページングが簡潔にできました。
普段PHPで頑張って書いている私からしたら感動です。

私はPHPのフレームワークとしてはFuelPHP、CakePHPに触れたことがあるのですが、どちらでもページングのクラスやライブラリを使っていなかった（勉強していなかった）と思い、この機に再確認しようと思った次第です。
なお、今回はRuby on RailsとFuelPHPを取り上げさせてください。
（普段はもう少し古いバージョンを使用していますが、とりあえず現在の最新ドキュメントを参考にしております。）

フレームワーク名	バージョン	ページングライブラリ	ドキュメント
Ruby on Rails	5.0	kaminari	https://github.com/amatsuda/kaminari
FuelPHP	1.7	Paginationクラス	http://fuelphp.jp/docs/1.7/classes/pagination.html

---

サンプル

説明しやすいよう下記のようなテーブルを使用します。
商品名、値段、説明を管理しているitemsです。

id	name	price	description	created_at	updated_at
ID	商品名	値段	説明	作成日	更新日

---

Ruby on Rails（kaminari）

# 2ページ目を取得(デフォルトは1ページ25件です。）
@items = Item.page(2);

pageメソッドで取得できるのはいいですね！
とはいえ、1ページあたりの表示件数を10件にしたい、などサービスごとに要望があるかと思います。
各コントローラーで制御もできるようですが、基本値はコンフィグにまとめるのが良いかな、と思います。

rails g kaminari:config

これでkaminari用のコンフィグファイルが生成されます。

Kaminari.configure do |config|
  # config.default_per_page = 25    ページあたりの表示件数（デフォルトは25）
  # config.max_per_page = nil          ページあたりの表示件数の最大（デフォルトはnil=>無限）
  # config.window = 4                         表示中のページの左右何ページ分のリンクを表示するかを指定（デフォルトは4）
  # config.outer_window = 0             先頭ページ、及び最終ページから何ページ分のリンクを表示するかを指定（デフォルトは0）
  # config.left = 0                                先頭ページから何ページ分のリンクを表示するかを指定（デフォルトは0）
  # config.right = 0                              最終ページから何ページ分のリンクを表示するかを指定（デフォルトは0）
  # config.page_method_name = :page    モデルに追加されるページ番号を指定するスコープの名前（デフォルトはpage）
  # config.param_name = :page    ページ番号を渡すために使用するリクエストパラメータの名前（デフォルトはpage）
end

なお、それぞれの値は各コントローラーで再度記載することで上書きすることも可能です。
ビューにページング番号を出す際には、下記でOKです。
これでいちいちページング番号をループさせて表示させるような面倒とはおさらばです。

<%= paginate(@items) %>

参考資料：TECHSCORE BLOG

---

FuelPHP

FuelPHPにはPaginationクラスがあります。
このクラスのインスタンスを使用することで、ページャーを設定することができます。
以下、ドキュメントを参考にしました。

// 基本値の設定
$config = array(
    // ページネーションの対象URLを設定できます。（特に指定がなければnullにしておくのが良いかと思います。）
    'pagination_url' => null,
    // URLのどのセグメントがページ番号か？（ItemsControllerのinsexメソッドであれば、items/index/3と3つ目のセグメントになります。）
    'uri_segment'    => 3,
    // 表示するリンクの総数
    // 'num_links' => 5
    // 対象の総数。基本はcount()した結果になります。
    // 'total_items'    => 10,
    // 1ページあたりの表示件数
    'per_page'       => 5,
    // trueかつ最初のページではない場合に '最初のページヘ' のリンクが生成されます。
    'show_first' => true,
   // trueかつ最後のページではない場合に '最後のページヘ' のリンクが生成されます。
    'show_last' => true,
);

// 'mypagination' という名前のpaginationインスタンスを作る
$pagination = Pagination::forge('mypagination', $config);

// クエリ発行
$data['example_data'] = DB::select('id', 'name', 'price', 'description')
                            ->from('pagination')
                            ->limit($pagination->per_page)
                            ->offset($pagination->offset)
                            ->execute()
                            ->as_array();

// オブジェクトをビューに渡す
$data['pagination'] = $pagination;

// ビューを返す
return \View::forge('welcome/index', $data);

設定値にてインスタンスを作成することで、その後のクエリビルダーにて使用することができます。
なお、バージョン1.7では過去のページネーションの設定だとうまくいかないようなので、1.7以前を使用する際には気をつけてください。
セグメントからページ番号を取得するため、パラメータをわざわざ受け取る必要はありません。
ただ、基本設定をいちいちコントローラーに書くのも面倒なので、コンフィグファイルにまとめてしまって、適宜呼び出すのが良いかと思います。

Config::load('pagination');

ビュー側でページ番号を出すのは楽です。

render(); ?>

７つのゼロ思考

はじめに
本書の冒頭では著者がある部署に配属されて、それまで3人で行っていた業務を一人でやらなければならなくなった。
その部署の１人の一日労働時間が平均で１３時間だった。
一日平均１３時間×３人で一日あたりの作業時間は約３９時間。
一般的な週の労働時間とほぼ同じである。

その３９時間、一週間の仕事を１人で一日で終わらせなければならなくなった著者が実践した７つの思考法が各章で紹介されている。

１．ボール＝ゼロ
２．期待値＝ゼロ
３．デスク＝ゼロ
４．オリジナル＝ゼロ
５．作業＝ゼロ
６．モレ＝ゼロ
７．物まね＝ゼロ

個人的には第一章の「ボール=ゼロ」が感銘を受けました。
「ボール＝ゼロ」と「期待値＝ゼロ」はほぼ同じような事で切っても切れない関係だろうと感じた。
「デスク＝ゼロ」というのは平たく言うと何かを取り出すときにはすぐに迷いなく取り出せるように常に整理整頓しましょうね。って事だと思います。

「ボール」＝「タスク」と考えれば割とイメージしやすい。
ここで連想したのがメールやチャットの返事である。逆の立場で考えてみると自分が送ったメールやチャットに対して、すぐにレスポンスがある人と、あれ？無視されてる？嫌われてるのかなとか思う人もいます。どっちが友好的に感じるかは論に諭さずである。すぐに返事がある人に対してはそれ以降も頼みやすくなったりちょっとしたことでも聞きやすくなる。そうやっての積み重ねで返事が早い人に頼むことが多くなり、信頼関係も自然と出来上がっていく。
返事が遅い人に対しては早く返事が来るように文面とかも考える必要も出てきて、やはりレスポンスが遅いとストレスになりかねない。

「オリジナル＝ゼロ」というのは何かを作成するときには、いちいちゼロから始めるのではなく何か参考になるものや、テンプレートのようなものを使用して時間を節約しましょうねって事です。あとはその会社や部署の伝統的に受け継がれているノウハウを否定してはいけないことと、その古びた慣習の中にもなにか新しいアイデアが眠っている可能性もあるので無下に扱うことは内容にしましょうということですね。

「作業＝ゼロ」というのは人にやってもらえるものはやってもらおう！って事です。
ここではどちらかというと作業の頼み方や頼んできた人の心理などを利用して、うまく立ち回ろうということが印象的でした。
５分やそこらで終わる作業であれば、その場で待たせてしまいましょうという話が面白かった。
確かに調べ終わったりしたとして報告するのに、メールなら文章を書くのに時間がかかるし、電話にしても必ず繋がるわけでもない。電話で捕まらなかった場合が最悪のパターンで再度かけるにしても折り返しをもらうにしてもお互いがリマインドとして覚えておく必要があるからだ。
そうならないためにも５分程度で終わるものならその場で待ってもらったほうがお互いの時間が節約されるというものだった。ただすべてがこう当てはまるものではないと思うので、その時の状況で判断できればいいと思います。

「モレ＝ゼロ」というのはそのままの意味で、ミスはなくしましょう。ということ。
ミスをしたらその対応にも時間がかかるし、大体の場合は自分以外の人の時間も割いてしまうからである。
ミスというのは大きく分けて２つあって

ひとつめは、【間違った】というミス。
ふたつめは、【忘れていた】というミス。

一つ目のミスに対しての対応としては
１．再チェック体制を作る
体制を作ることで結果的に再チェックを行ったほうが時間的にお得になる
２．システム化、自動化すること
身近なもので言えばエクセルのマクロを使用するなど

この章ではロジカルシンキングやロジックツリー、MECEや経営環境分析に用いられる３Cやマーケティングに用いられる４Pなどが紹介されている。このあたりにも興味があるので別途詳しく専門書を読んでみたい。



「より広く選択肢を探り、より確かに選択肢を絞る」
この思考の本質が「モレ＝ゼロ」で著者がいいたいことなのであろう。


「物まね＝ゼロ」
これは要するに差別化を図りましょうねってことだと思います。

本書では各章の間にコラムがあり、そのなかで特に印象に残ったひとつを紹介します。

「俺は超能力が使える」
この出だしで始まるこのコラム。この人やべえやつなんじゃないか。少し思いましたが実はちゃんといいこと書いてありました。
昨今便利な時代になりまして本を聞ける時代なんですよ。ポットキャストとかオーディオブックとかね。ながらで本の内容を知ることができるんですね。通勤しながら読書、満員電車で前の人にぶつかってでも本読んでる人がたまにいますけどちょっと迷惑と感じています。でもイヤホンから聞こえ、、、読めるのでほぼ誰にも迷惑がかからないすばらしいです。
あとは料理しながらとか、帰り道とぼとぼ１０分～２０分歩いたとしても往復で考えると結構な時間になりますね。これも読書の時間にしてしまえます。すばらしい。
一日往復３０分だとして一ヶ月２０日。１０時間の読書時間が出来上がるわけです。
しかもスピード調節機能が付いているそうで２倍速にして聞けば２０時間分の読書時間が錬金されます。真理に近づきましたね。

本書の表紙にも書かれていることですが
「その仕事、もう終わったの？」こういわせたら勝ちです。
７つのゼロ思考