この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
Ruby技術者認定試験（Silver）合格経験
初心者向けです。
Ruby リファレンスマニュアル（オンラインのドキュメント）
Ruby公式資格教科書 Ruby技術者認定試験Silver/Gold対応
①Stringクラス、Arrayクラス、Hashクラスのメソッドを覚える。
②教科書のとおりに、Silver範囲のみを読んで大丈夫です。
ガイドの説明をしっかり読んだほうが効率的です。
③irbで試す
関数に関する問題が多いです。
教科書しっかり把握すれば、合格できます。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
ruby の学習をしていたときに * (アスタリスク)の使い方で面白いと思ったことがありましたので紹介します。
※ 文字列に数字を*するとその数字の回数文字列を繰り返すのも勿論言語として面白いです。
そこで、例えば12文字の英数パスワード生成スクリプトは下記の書き方ができます。
[*0..9, *’A’..’Z’, *’a’..’z’].sample(12)*”
内容は下記となります。
どんなオブジェクトにどんなオブジェクトを渡すかによってメソッドの挙動が変わるところが興味深いです。
rubyでパスワードを自動生成するプログラムの紹介
http://doruby.kbmj.com/nakahira_on_rails/20091026/ruby_password_
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
以前、Postgresqlで日付を列挙する方法を書きましたが
今回はOracleでの列挙方法について書きます。
postgresqlの場合→ http://doruby.kbmj.com/hotdog/20120920/Postgresql_generate_series_
今回はOracle、どうやったら実現できるのだろうか？
SELECT TO_DATE(STARTDATE + ROWNUM -1, ‘YYYY/MM/DD’) AS CALENDAR
FROM
(SELECT TRUNC(TO_DATE(‘2014-02-01’)) AS STARTDATE,
TO_NUMBER(TO_CHAR(LAST_DAY(TO_DATE(‘2014-02-01’)), ‘DD’)) AS DAYS
FROM DUAL),
ALL_CATALOG
WHERE ROWNUM <= DAYS
以下出力結果
CALENDAR
14-02-01
14-02-02
14-02-03
14-02-04
14-02-05
14-02-06
14-02-07
14-02-08
14-02-09
14-02-10
14-02-11
14-02-12
14-02-13
14-02-14
14-02-15
14-02-16
14-02-17
14-02-18
14-02-19
14-02-20
14-02-21
14-02-22
14-02-23
14-02-24
14-02-25
14-02-26
14-02-27
14-02-28
次回はMySQLでの取得方法を書きたいです。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
表は、、表表のグラフ、表表、DBの表表、レコード数をします方法を書きます
選択する
relname、
reltuples、
tablesizeとしてのpg_size_pretty（pg_table_size（oid））
FROM pg_class
WHERE relnamespace =（SELECT oid FROM pg_namespace WHERE nspname = ‘public’）
およびrelkindin（ ‘r’、 ‘t’）;
表→表名、レコード数、サイズがコメントあります。
選択する
table_name、
TO_NUMBER（
extractvalue（
xmltype（
dbms_xmlgen.getxml（ ‘SELECT COUNT（*）c FROM’ || table_name））
、 ‘/ ROWSET / ROW / C’））rec_ccount、
trunc（bytes / 1024,0）テーブルサイズ
FROM user_tables
user_segments.segment_name = user_tables.table_nameでuser_segmentsに参加します
表→表名、レコード数、サイズがコメントあります。
たちあり。いきたいです。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
「protocalendar」を利用すると「date_select」で日付入力していた所がJSのカレンダーで入力できるようになります。
Ruby 1.8.7,1.9.3
Rails 2.3.15
事前に「protocalendar」用のディレクトリを各場所に作っておきます。
protocalendar-js-1.1.0/images/* → RAILS_ROOT/public/images/protocalendar/
protocalendar-js-1.1.0/javascripts/* → RAILS_ROOT/public/javascripts/protocalendar/
protocalendar-js-1.1.0/stylesheets/* → RAILS_ROOT/public/stylesheets/protocalendar/
protocalendar-js-1.1.0/lib/* → RAILS_ROOT/public/javascripts/protocalendar/
Railsの「date_select」の様に使いたいのでへルパーを作成します。
$ vim app/helpers/base_helper.rb
======================
def calendar_date_select(object,method,option= {},js_option= {})
tag = <<-EOS
#{date_select object,method,option}
#{image_tag("../images/protocalendar/icon_calendar.gif",:id => method)}
<script type="text/javascript">
SelectCalendar.createOnLoaded({
yearSelect: '#{object}_#{method}_1i',
monthSelect: '#{object}_#{method}_2i',
daySelect: '#{object}_#{method}_3i'},
triggers: ['#{method}'],
lang: 'ja',
showEffect: 'SlideDown',
hideEffect: 'SlideUp',
startYear: #{option[:start_year]},
endYear: #{option[:end_year]}
EOS
js_option.each do |(key,value)|
tag << ',' + key.to_s + ": #{value}"
end
tag << '});</script>'
return tag
end
======================
JSを読み込み、今まで「date_select」だった所を「calendar_date_select」に置き換えるだけで使う事ができます。
~~~~~~~~~~~
~~~~~~~~~~~
<%= javascript_include_tag '/protocalendar/protocalendar'/ %>
<%= javascript_include_tag '/protocalendar/lang_ja'/ %>
<%= javascript_include_tag '/effects'/ %>
<%= javascript_include_tag '/prototype'/ %>
~~~~~~~~~~~
~~~~~~~~~~~
<%= date_select(:page, :updated_at_from %>
↓このように置き換えるだけ
<%= calendar_date_select(:page, :updated_at_from %>
<%= date_select(:page, :updated_at_to, :use_month_numbers => true, :include_blank => true %>
↓オプションを付ける場合は{}がいります。
<%= calendar_date_select(:page, :updated_at_to, {:use_month_numbers => true, :include_blank => true}%>
目次
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
rails MySQLでの文字列エスケープ
今回はセキュリティ系のネタです。
Ruby on RailsではActiveRecord内部で文字列のエスケープを行うため、
SQLインジェクション対策を気にする場面が少ないかもしれません。
しかし、希にSQLのすべてや一部を生で記述する必要があったりして
文字列のエスケープに気を遣わなければならないこともあります。
そのときになって慌てないためにも、
今一度MySQLでの文字列エスケープについて考えてみたいと思います。
まずはMySQLでの文字列のエスケープ/クォートでの囲み方の一部について例をあげます。
mysql> select 'string \'' AS `name```;
+----------+
| name` |
+----------+
| string ' |
+----------+
1 row in set (0.00 sec)
上記のSQLでは文字列リテラル「string’」を出力しています。
リテラルはシングルクォート「’」 またはダブルクォート「”」で囲み、
文字列中に含まれるクォートやバックスラッシュ「\」の前に
バックスラッシュ「\」をつけてエスケープします。
AS句でカラム名の別名をつけますが、この別名はバッククォート「`」で囲みます。
別名中にバッククォートが含まれる場合はバックスラッシュ「\」ではなく、
バッククォート「`」をふたつ続けてかきます。
mysql> SELECT `name` FROM `some_table`;
<結果省略>
上記のSQLではテーブル some_table からすべてのレコードのnameカラムを出力しています。
カラム名・テーブル名ともにバッククォート「`」で囲みます。
文字中にバッククォートが含まれる場合はバッククォート「`」をふたつ続けてかきます。
なおSELECT句の「`name`」は「’name’」としてはいけません。
「’name’」とした場合リテラルとみなされ、
レコード数だけ文字列「name」が出力されてしまいます。
mysql> SELECT `name` FROM `some_table` WHERE `name` LIKE '\%abc\_%';
<結果省略>
上記のSQLではテーブル some_tableからnameカラムが「%abc_」で前方一致するレコードのnameカラムを出力しています。
LIKEの後ろにくる「’\%abc\_%’」は文字列リテラルですが、
パーセント記号「%」やアンダースコア「_」はそのまま書くとワイルドカードとして機能します。
そのためパーセント記号「%」やアンダースコア「_」自体をヒットさせたい場合は
それぞれの文字の前にバックスラッシュ「\」をつけてエスケープします。
これを忘れると強制的に前方一致させるつもりでも、
入力値によっては部分一致検索が可能となってしまいます。
mysql> SELECT `name` FROM `some_table` ORDER BY `name` ASC;
<結果省略>
上記のSQLではテーブル some_tableからすべてのレコードのnameカラムをnameカラムの昇順で出力しています。
ORDER BY句でもカラム名はバッククォート「`」で囲むパターンです。
カラム名に続く ASC or DESCについては定数のようなもので、エスケープやクォーティングは行いません。
ASC or DESCに文字列を入力する場合は入力する文字列がASCかDESCのいずれかのみを入力させるよう注意する必要があります。
以上複雑なようですが、エスケープ・クォートの方法は以下4パターンになると思います。
railsでの実装例とともにまとめてみます。
シングルクォート「’」 またはダブルクォート「”」で囲み、
文字列中に含まれるクォートやバックスラッシュ「\」の前に
バックスラッシュ「\」をつけてエスケープする。
str = "test'"
puts ActiveRecord::Base.connection.quote(str)
#「'test\''」と出力
文字列リテラルパターンの方法に加えて
パーセント記号「%」やアンダースコア「_」の前に
バックスラッシュ「\」をつけてエスケープする。
str = "%_test"
puts "'%s'" % ActiveRecord::Base.connection.quote_string(str).gsub(/([%_])/){"\\" + $1}
#「'\%\_test'」と出力
カラム名・テーブル名ともにバッククォート「`」で囲みます。
別名中にバッククォートが含まれる場合はバッククォート「`」をふたつ続けてかきます。
str = "test`"
#rails3.1以上
puts ActiveRecord::Base.connection.quote_column_name(str)
#「`test```」と出力
#rails3.0
puts ActiveRecord::Base.connection.quote_column_name(str.gsub("`", "``"))
#「`test```」と出力
クォートで囲まない。入力する場合はホワイトリスト方式で厳密にチェックする。
注意が疎かになりがちなのが
カラム・テーブル名パターン
です。
まずバッククォート「`」で囲むのを忘れているケースをよくみます。
また、囲んでいてもrails3.0ではquote_column_nameする前に
文字列中のバッククォート「`」を自前で「“」に変換しなければいけません。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
Rails+MongoDBアプリケーションのテストを高速化する際にparallel_testsを導入してハマッた点を紹介したいと思います。
説明を割愛します。
他の文献を参考にしていただければと思います。
PostgreSQLなどの SQLとあわせてMongoDBを利用する場合でも、parallel_tests向けにDBの保存先を複数に分ける設定が必要になります。
当然といえば当然ですがこれを忘れると、複数インスタンスで同時書き込みが発生して、テストに失敗するケースがあるので注意が必要です。
これはMongoDBに関わらず当然注意すべき点になります。
単純に「Railsインスタンス*並列実行数」なので、１インスタンスが300Mbytes必要であれば８つ並列実行する場合は2.4GBytesのメモリが必要になります。
とくにMongoDBを利用している場合は、定期的にDBデータの整理/削除が必要になります。
実際のアプリでも、１回のテスト実施で合計1〜2GBytesの再利用されないデータが生成されるケースがあったので、注意が必要かと思います。
parallel_tests+MongoDB用のDBを初期設定できるRakeタスクを作成しました。
下記の内容を lib/tasks 以下に設置してご利用ください。
require 'parallel_tests/tasks'
namespace :parallel do
namespace :mongoid do
rails_env = ENV['RAILS_ENV'] || 'test'
desc "db:mongoid:drop --> parallel:mongoid:drop[num_cpus]"
task :drop, :count do |t,args|
run_in_parallel("rake db:mongoid:drop RAILS_ENV=#{rails_env}", args)
end
desc "db:mongoid:purge --> parallel:mongoid:purge[num_cpus]"
task :purge, :count do |t,args|
run_in_parallel("rake db:mongoid:purge RAILS_ENV=#{rails_env}", args)
end
end
end
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
rick No31です。
今回は、railsログを解析するgemの紹介です
request-log-analyzer 1.12.10
ruby 1.9.3p484
rails 3.0.19
$ gem install request-log-analyzer
$ request-log-analyzer –format rails3 log/development.log.20131212
// 解析するコントローラーを指定
–select controller TopController
// 解析するアクションを指定
–select action index
// 特定コントローラーを除外
–reject controller TopController
// html出力
–output HTML –file hoge.html
※横棒は長いため比率関係なく短くしています
// リクエストのサマリー
Request summary
ーーーーーーーーーーー
// 解析したファイル
Processsed File: xx/log/development.log.20131212
// 解析した行数
Parsed lines: 1103450
// スキップした行数
Skipped lines: 55814
// 解析したリクエスト
Parsed requests: 276218
// スキップしたリクエスト
Skipped requests: 0
// 警告数
Warnings: no_current_request: 55814, teaser_check_failed: 73, unfinished_request_on_eof: 1
// 最初のリクエスト日時
First request: 2013-12-12 00:00:12
// 最後のリクエスト日時
Last request: 2013-12-12 23:59:11
// 解析した期間
Total time analyzed: 1 days
ーーーーーーーーーーー
// 時間あたりのリクエスト数
Request distribution per hour
0:00 ┃ 16532 hits/day ┃ ░░░░░░░░░░░░░░
1:00 ┃ 10732 hits/day ┃ ░░░░░░░░░
2:00 ┃ 6915 hits/day ┃ ░░░░░░
3:00 ┃ 4140 hits/day ┃ ░░░░
4:00 ┃ 2641 hits/day ┃ ░░
5:00 ┃ 1882 hits/day ┃ ░░
6:00 ┃ 3322 hits/day ┃ ░░░
7:00 ┃ 3991 hits/day ┃ ░░░
8:00 ┃ 6072 hits/day ┃ ░░░░░
9:00 ┃ 8218 hits/day ┃ ░░░░░░░
10:00 ┃ 8585 hits/day ┃ ░░░░░░░
11:00 ┃ 9568 hits/day ┃ ░░░░░░░░
12:00 ┃ 11037 hits/day ┃ ░░░░░░░░░░
13:00 ┃ 10558 hits/day ┃ ░░░░░░░░░
14:00 ┃ 10930 hits/day ┃ ░░░░░░░░░
15:00 ┃ 10990 hits/day ┃ ░░░░░░░░░░
16:00 ┃ 10870 hits/day ┃ ░░░░░░░░░
17:00 ┃ 18972 hits/day ┃ ░░░░░░░░░░░░░░░░
18:00 ┃ 17312 hits/day ┃ ░░░░░░░░░░░░░░░
19:00 ┃ 16320 hits/day ┃ ░░░░░░░░░░░░░░
20:00 ┃ 19573 hits/day ┃ ░░░░░░░░░░░░░░░░░
21:00 ┃ 23065 hits/day ┃ ░░░░░░░░░░░░░░░░░░░░
22:00 ┃ 22965 hits/day ┃ ░░░░░░░░░░░░░░░░░░░░
23:00 ┃ 21028 hits/day ┃ ░░░░░░░░░░░░░░░░░░
// リクエストの多い順
Most requested
xxController#index.XML ┃ 213045 hits ┃ 77.1% ┃ ░░░░░░░░░░░░░░░░░░
xxController#index.JSON ┃ 24953 hits ┃ 9.0% ┃ ░░░░░░░░░░░░░░░░░
#. ┃ 3120 hits ┃ 1.1% ┃ ░░
//HTTPメソッド毎のリクエスト数
HTTP methods
POST ┃ 193989 hits ┃ 70.2% ┃ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
GET ┃ 82221 hits ┃ 29.8% ┃ ░░░░░░░░░░░░░░░░░░░
HEAD ┃ 8 hits ┃ 0.0% ┃
// HTTPのステータス毎のリクエスト数
HTTP statuses returned
200 ┃ 225536 hits ┃ 100.0% ┃ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
302 ┃ 2 hits ┃ 0.0% ┃
500 ┃ 1 hits ┃ 0.0% ┃
// リクエストの所要時間の合計
Request duration – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.XML┃ 171190 ┃ 4h21m19s ┃ 0.09s ┃ 0.05s ┃ 0.00s ┃ 5.73s ┃ 0.05s-0.23s
xxController#index.JSON┃ 9626 ┃ 27m38s ┃ 0.17s ┃ 0.09s ┃ 0.00s ┃ 0.79s ┃ 0.05s-0.36s
#.┃ 2518 ┃ 4m15s ┃ 0.10s ┃ 0.07s ┃ 0.00s ┃ 1.00s ┃ 0.01s-0.32s
// リクエストの所要時間の平均
Request duration – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.JSON┃ 9626 ┃ 27m38s ┃ 0.17s ┃ 0.09s ┃ 0.00s ┃ 0.79s ┃ 0.05s-0.36s
xxController#index.HTML┃ 1 ┃ 0.13s ┃ 0.13s ┃ 0.00s ┃ 0.13s ┃ 0.13s ┃ 0.13s-0.13s
#.┃ 2518 ┃ 4m15s ┃ 0.10s ┃ 0.07s ┃ 0.00s ┃ 1.00s ┃ 0.01s-0.32s
// 一部のレンダリング時間の合計
Partials rendering time – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
layouts/_hoge.html.erb┃ 14 ┃ 0.41s ┃ 0.03s ┃ 0.05s ┃ 0.00s ┃ 0.17s ┃ 0.00s-0.17s
// 一部のレンダリング時間の平均
Partials rendering time – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
layouts/_hoge.html.erb┃ 14 ┃ 0.41s ┃ 0.03s ┃ 0.05s ┃ 0.00s ┃ 0.17s ┃ 0.00s-0.17s
// ビューのレンダリング時間の合計
View rendering time – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.XML┃ 170223 ┃ 1m03s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.13s ┃ 0.00s-0.00s
xxController#suggest.JSON┃ 23254 ┃ 7.93s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.06s ┃ 0.00s-0.00s
#.┃ 2503 ┃ 0.99s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s-0.00s
// ビューのレンダリング時間の平均
View rendering time – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.HTML┃ 1 ┃ 0.09s ┃ 0.09s ┃ 0.00s ┃ 0.09s ┃ 0.09s ┃ 0.09s-0.09s
#.┃ 2503 ┃ 0.99s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s-0.00s
// DBからの応答時間の合計
Database time – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.XML┃ 170223 ┃ 14m39s ┃ 0.01s ┃ 0.01s ┃ 0.00s ┃ 0.83s ┃ 0.00s-0.01s
xxController#index.JSON┃ 15672 ┃ 3m34s ┃ 0.01s ┃ 0.04s ┃ 0.00s ┃ 0.49s ┃ 0.00s-0.14s
#.┃ 2503 ┃ 14.58s ┃ 0.01s ┃ 0.01s ┃ 0.00s ┃ 0.30s ┃ 0.00s-0.01s
// DBからの応答時間の平均
Database time – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.HTML┃ 1 ┃ 0.04s ┃ 0.04s ┃ 0.00s ┃ 0.04s ┃ 0.04s ┃ 0.04s-0.04s
xxController#index.JSON┃ 15672 ┃ 3m34s ┃ 0.01s ┃ 0.04s ┃ 0.00s ┃ 0.49s ┃ 0.00s-0.14s
#.┃ 2503 ┃ 14.58s ┃ 0.01s ┃ 0.01s ┃ 0.00s ┃ 0.30s ┃ 0.00s-0.01s
// 停止したプロセス
Process blockers (> 1 sec duration)
xxController#index.XML ┃ 2 hits ┃ 66.7% ┃ ░░░░░░░░░░░░░░░░░░░░░░░░░
#. ┃ 1 hits ┃ 33.3% ┃ ░░░░░░░░░░░░░░
// 遷移エラー
Routing Errors
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
サーバ内の任意のポートへのアクセスはSSHトンネルでも出来ますが、毎回SSH接続しなければならないのは面倒と言う事で、CentOSにstoneをインストールしてみました。
stoneはTCP/UDPのリピーターです。指定したサーバへ中継してくれます。
# cd /usr/local/src
# wget http://www.gcd.org/sengoku/stone/stone-2.3e.tar.gz
# tar zxvf stone-2.3e.tar.gz
# cd stone-2.3d-2.3.2.7
# vi Makefilelinux:
$(MAKE) FLAGS=”-O -Wall -DCPP=’\”/usr/bin/cpp -traditional\”‘ -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_EPOLL -D_GNU_SOURCE $(FLAGS)” LIBS=”-lpthread $(LIBS)” stone
↑makeに失敗するので、「-D_GNU_SOURCE」を追加します。# make linux
↑linux-sslだとmakeに失敗するので、linuxにしました。
※エラーが出なければOK
# mv stone /usr/bin/
# ln -s /usr/bin/stone /usr/local/bin/stone
# cd ..
# rm -fr stone-2.3d-2.3.2.7
今回はTCP80/443に来たリクエストを同じネットワーク内の192.168.x.xに同じポートで流す事にしました。
ApacheのProxyPassでも同じような事は出来ますが、スマートじゃない気がしたので、stoneを採用しました。
iptables等でポート制限している場合は解除してください。
# stone 192.168.x.x:80 80 &
# stone 192.168.x.x:443 443 &
再起動しても自動起動するようにrc.localに追加しておきます。
# cd /etc
# cp -a rc.local rc.local,201311
# vi rc.local/usr/bin/stone 192.168.x.x:80 80 &
/usr/bin/stone 192.168.x.x:443 443 &
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
よしだです。Rubyで破壊的メソッドを自作する方法がわからなくて調べたので紹介します。
Stringクラスのインスタンスメソッドなどで定義されている、インスタンス自身を変更するメソッドです。
たとえば文字列の末尾に含まれる改行を消したい場合、
irb> text = "テスト\n"
irb> text.chomp
#=> "テスト"
irb> text
#=> "テスト\n"
のように「chomp」メソッドを使って実現できます。このときインスタンスであるtext自体に変更はなく、「chomp」のあとにtextを呼び出すと改行がついたままであることが確認できます。
これに対して破壊的メソッド「chomp!」の場合は、
irb> text = "テスト\n"
irb> text.chomp!
#=> "テスト"
irb> text
#=> "テスト"
と、text自体に変更が加わっていることがわかります。
本稿では、このような破壊的メソッドを自分で定義する方法を紹介します。
答えは簡単で、「replace」メソッドを利用することで可能です。
たとえば『文字列の末尾に「hoge」という文字列をくわえる』という破壊的メソッド「hoge!」を定義するには以下のように記述します。
class String
def hoge!
self.replace(self + "hoge")
end
end
たったこれだけです。
今回はStringクラスを例にしましたが、「replace」メソッドはいろいろなクラスで利用できるようです。適当なクラスに適当な破壊的メソッドどんどん定義していくのも面白いかもしれません。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
よしだです。最近Ruby技術者認定試験(Silver)を受けたので、そのときの手順を紹介したいと思います。
Ruby技術者認定試験はその名の通り、プログラミング言語Rubyの技術試験です。現在レベルがSilver、Goldとあるようです。このうちSilverはそこまで難易度が高くなので、本校では書籍を購入するほどではない・できるだけ勉強にお金をかけたくないという浅はかな考えで試験に挑み、合格することを目的とします。
書籍も買わないとなると試験でどのような問題がでるかも検討がつかず、対策のしようがありません。そこでウェブ上で疑似問題を出題してくれるミニツクを利用します。このサービスはRubyの産みの親、まつもとひろゆきが所属する組織によって開発されたサービスのようです。
いろいろな内容に対応していて、Ruby技術者認定試験(Silver)用にも全６章の問題セットが用意されています。だいたい１時間くらいで全問回答できる程度の内容になっています。問題の形式は４択で、難易度もそこまで高くなく、普段からRubyを使っていて簡単なコードなら対話コンソール(irb)なしでも読めるような方なら、ほとんどつかえることなく解き進むことができると思います。
勉強は次のような流れでおこなうとスムーズかと思います。
これを全６章、２周くらいすればおおよそ試験合格水準まで学習できると思います。時間にして２時間程度で試験勉強完了です。
試験勉強・受験に際して必要な注意点をまとめてみました。
Rubyは、現在2.0系まででていて、1.8系は2013年6月時点でサポート対象外となっています。多くの方がすでに上位バージョンを使っている中で、あえて古いバージョンの動作に付いて学ぶことになるので注意が必要です。
受験には写真入の証明書＋その他の証明書（免許証＋保険証）の２つが必要になります。どちらか一方が欠けても受験資格がないと見なされ、安くない受験費が水の泡になってしまいます。僕はここでやってしまいました・・・（免許証の有効期限が切れていないか確認することをお勧めします！）。
今回はRuby技術者認定試験(Silver)とその勉強方法について紹介しました。少しでも参考にしていただければ幸いです。近々Goldの方も受験するつもりなので、次はそちらの紹介もしたいと思います。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
rick No30です。
今回は、MySQLのプロセスの確認方法と負荷が高すぎて止めたいプロセスを強制的に停止するときなどに使用する停止方法の紹介です
MySQL5.0.95
$ mysql -u root
> show processlist;
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| Id | User | Host | db | Command | Time | State | Info |
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| 3840 | root | localhost | hoge | Sleep | 105365 | | NULL |
このようなデータが表示されます。
何度か実行して消えないものは常駐しているプロセスか、固まって動かないプロセスとなります。
Id：接続識別子
User：接続しているユーザ名
Host：接続しているホスト名
db：接続しているDB名
Command：状態を表し「Sleep、Query、Kill」このようなステータスが表示されます。
Time：接続時間
State：現状の情報が表示される
Info：SQLが表示される
$ mysql -u root
> show processlist;
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| Id | User | Host | db | Command | Time | State | Info |
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| 3840 | root | localhost | hoge | Sleep | 105365 | | NULL |
> kill 3840
これで完了
すぐに消える場合もあれば、処理が重い場合、StateがKillになりしばらくかかる場合もあります。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
今回、アップル社はOSX 10.9を無償配布した。すでに多くのユーザーがOSX 10.9を利用しており、様々な感想を持っているだろう。今回は、このフリーソフト化したOSXとそれをとりまくセキュリティ事情について考えてみよう。
OSXの配布は、過去にも数千円程度で配っていたこともあり、今回の配布においても、同様の価格帯での配布が以前よりささやかれていた。このため、今回のアップデートも1500円くらいかな？と、筆者は考えていたこともあった。今回のアップデートは、従来のアップデートと異なる点がほかにも存在している。旧来のアップデートでは、セキュリティパッチの兼ね合いもあり、新しいOSを出す際には、必ず旧来のOSに対してもセキュリティパッチを提供していた。しかしながら、今回のアップデートには、旧来のOSXにアップデートが含まれておらず、数多くの脆弱性のあるOSXを使わずに、新しいOSXを使わせようとした風潮が見て取れる。
また、従来のアップデートでは対象外とされていた古いMacも今回のアップデートでは利用可能となり、今から5年以上前に提供されたMacも最新OSを利用可能となる。
旧来の古いMacで、最新のOSを利用しようとした場合、確かに利用することは可能だろう。しかし、快適に利用するにはほど遠いと考えられる。まず、めもりの消費量が非常に多いことがすでに予測されている。手元の、この原稿をタイプしているMacの場合、起動時のメモリ使用率が、すでに99%近く埋まっていることがある。このMacは、12Gバイトのメモリを搭載しており、従来の発売されているMacに比べても、遜色のないメモリであることはおわかりだろう。
確かに、バックグラウンドで利用しているアプリはOSX 10.9に於いては、メインメモリ上で圧縮されているため、ほとんどの場合はメモリにそれほど気を遣う必要はないかもしれない。しかしながら、それは高速なメモリと高速なSSDを搭載しているためであり、従来の古いメモリや古いハードディスクを搭載している場合は、遅く感じることもあるだろう。
まず、OSX 10.9が利用できるユーザー数を圧倒的に増やすことで、マイクロソフトとの差を縮めようとしていることが容易に予測できる。
また、従来のMacユーザーが利用した場合、遅さに耐えきれずに従来のMacを手放し、新しい「リーズナブル」なMacを買ってくれるかもしれない。こうして、アップルは虎視眈々と、古いMac利用者を新しいMacへ導き、Windowsにいくのをブロックしているように見える。いずれ、この結果はわかることだが、きっと、アップルとしてはOSXをフリーにすることで、新しいMacの購入数を増やすことに成功するだろう。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
CentOSでyum updateしたらcrmコマンドが無くなりました。
理由は解らないけど、crmを捨てて、新しい(？)pcsコマンドに移行する感じなのかと。
crm使って、今までやっていた事がpcsだとどうやるか、よく解らなかったので、updateを暫く凍結してました。
が、それじゃいけないと思い、ググったり、ヘルプ見たり、試したりして、やっと同じ事が出来るようになったので、対照表と言いつつ、表じゃないけど、纏めました。
これをやらないと始まらない。
# yum -y install pcs
それぞれが何をするコマンドかは別の所で調べてください。
# crm configure property stonith-enabled=”false” no-quorum-policy=”ignore” default-action-timeout=”240″ default-resource-stickiness=”200″
↓
# pcs property set stonith-enabled=”false” no-quorum-policy=”ignore” default-action-timeout=”240″ default-resource-stickiness=”200″
# crm configure rsc_defaults resource-stickiness=”INFINITY” migration-threshold=”1″
↓# pcs resource rsc defaults resource-stickiness=”INFINITY” migration-threshold=”1″
↑コマンドが変わったみたいで使えなくなった(2013/11/16)
# pcs resource defaults resource-stickiness=”INFINITY” migration-threshold=”1″
# crm configure primitive mailto ocf:heartbeat:MailTo params email=”warning-root@localhost” subject=”[Pacemaker]”
↓
# pcs resource create mailto ocf:heartbeat:MailTo params email=”warning-root@localhost” subject=”[Pacemaker]”
※更新はcreateの代わりにupdate
# crm configure primitive vip ocf:heartbeat:IPaddr2 params nic=”eth0″ ip=”192.168.11.210″ cidr_netmask=”24″ op monitor interval=”20s”
↓
# pcs resource create vip ocf:heartbeat:IPaddr2 params nic=”eth0″ ip=”192.168.11.210″ cidr_netmask=”24″ op monitor interval=”20s”
# crm configure primitive drbd ocf:linbit:drbd params drbd_resource=”r0″ drbdconf=”/etc/drbd.conf” op monitor interval=”20s”
↓
# pcs resource create drbd ocf:linbit:drbd params drbd_resource=”r0″ drbdconf=”/etc/drbd.conf” op monitor interval=”20s”
# crm configure ms drbd-clone drbd meta master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true”
↓
# pcs resource master drbd-clone drbd master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true”
# crm configure primitive cluster ocf:heartbeat:Filesystem params device=”/dev/drbd0″ fstype=”ext3″ directory=”/cluster” op monitor interval=”20s”
↓
# pcs resource create cluster ocf:heartbeat:Filesystem params device=”/dev/drbd0″ fstype=”ext3″ directory=”/cluster” op monitor interval=”20s”
# crm configure primitive mysql ocf:heartbeat:mysql params binary=”/usr/bin/mysqld_safe” op monitor interval=”10s”
↓
# pcs resource create mysql ocf:heartbeat:mysql params binary=”/usr/bin/mysqld_safe” op monitor interval=”10s”
# crm configure primitive apache ocf:heartbeat:apache params configfile=”/etc/httpd/conf/httpd.conf” port=”80″ op monitor interval=”20s”
↓
# pcs resource create apache ocf:heartbeat:apache params configfile=”/etc/httpd/conf/httpd.conf” port=”80″ op monitor interval=”20s”
# crm configure group nfs-group mailto vip cluster mysql apache
↓
# pcs resource group add nfs-group mailto vip cluster mysql apache
※リソース削除はaddの代わりにremove_resource
# crm configure colocation nfs-group_on_drbd inf: nfs-group drbd-clone:Master
↓
# pcs constraint colocation add nfs-group drbd-clone INFINITY with-rsc-role=Master
# crm configure order nfs-group_after_drbd inf: drbd-clone:promote nfs-group:start
↓
# pcs constraint order promote drbd-clone then start cluster
# crm
# cib new ~/pcs_cfg
# configure ・・・
# cib commit ~/pcs_cfg
# quit
↓
# pcs cluster cib ~/pcs_cfg
# pcs -f ~/pcs_cfg ・・・# pcs cluster push cib ~/pcs_cfg
↑コマンドが変わったみたいで使えなくなった(2013/11/16)
# pcs cluster cib-push ~/pcs_cfg
# crm configure show
↓
# pcs cluster cib
# crm_mon -1
↓
# pcs status
※crm_monも使えます。
# crm resource move nfs-group host1 force
↓# pcs resource move nfs-group host1 force
↑ホスト名とforceは指定出来ませんでした。(2013/11/25)
# pcs resource move nfs-group
※host1は実際のホスト名
# crm configure edit -> 「node host1」の行を削除
↓
# cibadmin –delete –obj_type nodes –crm_xml ”
# cibadmin –delete –obj_type status –crm_xml ”
※host1は実際のホスト名
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
MongoDBとNagiosをPacemakerで起動制御出来るようにした時のメモです。
ApacheやMySQL等は専用のスクリプトが用意されていますが、MongoDBとNagiosのは無くて、作るのも労力なので、汎用的に使えそうなanythingで代用しました。
既にyum updateしてcrmコマンドが無くなっているので、pcsを使います。
crmの方は、yum updateしたらcrmコマンドが無くなった！(pcsコマンド対照表)も参考にしてください。
Nagios Pluginのcheck_tcpを使って、死活監視をしています。
# pcs resource create mongodb ocf:heartbeat:anything params \
user="mongodb" \
binfile="/usr/bin/mongod" \
cmdline_options="-f /etc/mongodb.conf > /dev/null 2>&1" \
pidfile="/var/run/mongodb/mongodb.pid" \
monitor_hook="/usr/lib64/nagios/plugins/check_tcp -H localhost -p 27017" \
op monitor interval="20s"
# pcs resource group add nfs-group mongodbNagiosはサービスに影響がないので、落ちてもフェールオーバしないように死活監視はしてません。
Nagios自体は外部監視するのが良いと思います。
# pcs resource create nagios ocf:heartbeat:anything params \
user="nagios" \
binfile="/usr/bin/nagios" \
cmdline_options="-d /etc/nagios/nagios.cfg" \
pidfile="/var/nagios/nagios.pid"
# pcs resource group add nfs-group nagios上記で終わりと思いきや、実際には動きません。
理由はanythingで作ったPIDファイルをMongoDBやNagios側でも作成して上書きしてしまう為です。
anythingが使いたいPIDではなくなってしまう。。。
別のファイルを指定したりもしましたが、上手く動かず断念！
なので、少し細工します。但し、元々の挙動でも動くように。
# cd /usr/lib/ocf/resource.d/heartbeat
# cp -a anything anything,201309
# vi anything### START 2013/09 taka ###
# eval $cmd > $pidfile
eval $cmd > $pidfile.tmp
sleep 1
if [ -e $pidfile ]; then
rm -f $pidfile.tmp
else
mv -f $pidfile.tmp $pidfile
fi
### END ###これで無事、意図通り動くようになりました。
見ての通り、起動ユーザやコマンド(起動スクリプトを見れば解ります)と監視コマンドを用意すれば、MongoDBやNagios以外にも利用出来ます。
yum updateしたらanythingが無くなり、Corosyncが停止出来なくなりました。（crmに続き、またか〜）
幸いバックファイル(anything,201309)が残っていたので、そいつをベースに再度カスタマイズを施し修復！
新規構築等で最初からない場合は、下記等から入手してください。
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/anything
そもそもyum updateする時はCorosync止めてからじゃないと危険だね。
再起動したまま帰ってこないくて、最悪、オンコールリブートになりそうな。
目次
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
「ThinReports Editor」と「ThinReports Generator」 があればエディタで作成した形に
データを出力できるようになり、納品書等の帳票が簡単に作れます。
Ruby 1.8.7,1.9.3
まずはRailsから出力するための必要な「ThinReports Generator」をインストールします。
$ gem install thinreports
※Ruby1.8.7の場合は、別途 json のインストールが必要
$ gem install json
次にPDFのデザイン作成に必要な「ThinReports Editor」 をインストールします。
下記のURLにアクセスして自分のOSにあったものをインストールしてください。
http://www.thinreports.org/download/
インストールするものは以上です。
参考：http://osc.matsukei.net/projects/thinreports/wiki/Installation_Guide
先ほどインストールした「ThinReports Editor」をつかい.tlfファイルを作成します
下記のURL先で使い方がわかると思います。
http://osc.matsukei.net/projects/thinreports/wiki/Getting_Started
.tlfファイルを作成し終わったらRailsの/public/の下にでも置いてください。
このアクションが呼ばれればPDFをダウンロードできます。
require ‘thinreports’
~~~~~~~~~~
~~~~~~~~~~
def pdf_download
#Reportオブジェクトの生成、先ほど作ったレイアウトの読み込み
report = ThinReports::Report.new :layout => ”/public/pdf_layout”
#新しいページを作る際にここが呼ばれます
report.events.on :page_create do |e|
e.page.item(:page_num).value(e.page.no) #現在のページ数入力
end
#PDFを生成するときにここが呼ばれます
report.events.on :generate do |e|
e.pages.each do |page|
page.item(:page_total).value(e.report.page_count) #総ページ数入力
end
end
#ページを作成し、データを入力していきます。
report.start_new_page do |page|
page.item(:name).value(‘名前’)
#リストを作っていた場合はリストに入力していきます。
for i in 0..10 #10行分
page.list(:list_test).add_row do |row|
row.item(:quantity).value(“数量#{i}”)
row.item(:price).value(“値段#{i}”)
end
end
end
#PDF生成
send_data report.generate, :filename => ”ファイル名.pdf”,
:type => ’application/pdf’,
:disposition => ’attachment’
end
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
先日、某所で行われたペンテスター（脆弱性診断を行っているひと）たちにの寄り合いに出かけ、そのときに議題として上った話を、いくつかかいつまんで解説してみよう。
ペンテスター業界全般で、システム上の後継者問題が浮上している。後継者問題といっても、人としての後継者ではなく、システム的な後継者の話だ
この３つで共通している問題がある。それは、webアプリケーションを診断する上で、比較的見つけやすい脆弱性である、XSSを検知することが出来ないブラウザだ。
ユーザーにとって、XSSは時にはセッションハイジャックをもたらすやっかいな存在だが、各ブラウザーベンダーが、ブラウザそのものでXSSが出来ない対策を施し始めた。
この事は、ユーザーそのものとして見た場合、非常にウェルカムな考え方だが、脆弱性診断を行っている場合、診断に用いているブラウザによっては、XSSが存在しているにもかかわらずあたかもそれが存在していないかのように誤検知してしまう恐れがある。
代替案として、ブラウザに搭載された互換モードを利用するという考え方もある。しかしながら、互換モードはあくまでも表示上の互換性を維持するための物であり、XSSをはじめとするいくつかの再現しない脆弱性について、互換表示する物ではない。そのため、
まもなくサポートが終了する、Windows XP を利用し、IE6とIE7を確保する
といった解決策が必要となってくる。当然、これらのOSを使用することはウイルスに感染したり、外部からの攻撃を受けやすくなる等の問題があるため、現時点に於いて、一般利用者に通常はWindows XPの採用は推奨することはない。しかしながら、今回の様に誤検知の恐れがある以上ペンテスターにとっては、完全な再現性を担保するため、仮想環境の中でWindowsを稼働させ、診断が終わるたびに、元の安全な状態に戻すといった方法や、復元ポイントを用いた、環境の確保が必要不可欠となる。
先ほど述べたとおり、Windows XPは来年春にマイクロソフトによる正式サポートが終了する。このため、現状できうる限りのセキュリティパッチやサービスパックなどは適用しておき、その状態をマスターとして保存し、必要に応じて呼び出すのが良いだろう。当然として、アンチウイルスは導入し、EMETと呼ばれる、脆弱性を緩和させるフレームワークを導入することも慣用だろう。
今後、ブラウザが進化するに従って、従来は検知出来た脆弱性が益々検知することが難しくなることが十分予測される。もしかしたら、IE7やIE8といった、比較的最近のバージョンも保持対象となる日が訪れる事になるかもしれない。一般利用者にとっては、セキュアな方向にすすむため、非常にうれしい状況に有るだろうが、ペンテスターとしてみると、非常に悩ましい問題の1つと言えよう。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
Unicode正規化 norm_KCとnorm_KDの注意点特殊な文字に対して、別文字になってしまいます。
例：
irb(main):004:0> query=”２５０℃”
=> “２５０℃
irb(main):005:0> q = query.downcase.to_u.norm_KC.to_s
=> “250\xC2\xB0C”
irb(main):006:0> q.force_encoding(“UTF-8”) if q.respond_to?(:force_encoding) => “250°C”
| input | NFD,NFC | NFKD,NFKC |
|---|---|---|
IDSPU+3000和字間隔 | IDSPU+3000和字間隔 | SPU+0020スペース |
‥U+2025二点リーダ | ‥U+2025二点リーダ | ..U+002E U+002Eピリオド＋ピリオド |
…U+2026三点リーダ | …U+2026三点リーダ | …U+002E U+002E U+002Eピリオド＋ピリオド＋ピリオド |
″U+2033秒 | ″U+2033秒 | ′′U+2032 U+2032分＋分 |
℃U+2103摂氏度記号 | ℃U+2103摂氏度記号 | °CU+00B0 U+0043度＋ラテン大文字C |
∬U+222C二重積分記号 | ∬U+222C二重積分記号 | ∫∫U+222B U+222B積分記号＋積分記号 |
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
文字列のblank?メソッドは正規表現を使っていますので、UTF-8的に正しいバイト列ですかチェックしています。
型によって、blank?の処理が違います。
文字列の場合、正規表現で判断しています。
配列の場合、Arrayのempty?と同じです。
ハッシュの場合、Hashのempty?と同じです。
blank.rbの一部ソースコード：
class String
def blank?
self !~ /[^[:space:]]/
end
end
class Array
alias_method :blank?, :empty?
end
class Hash
alias_method :blank?, :empty?
end
Ruby 1.9 でUTF-8的に正しくないバイト列がある文字列を扱っていると、
正規表現マッチや gsub といったメソッドを使っているところで ArgumentError: invalid byte sequence in UTF-8 例外が発生します。
文字列を生成したときではなくて正規表現マッチなんかをしたときに始めてエラーが出るのです。
例：
str = “\xC1\xB9\xA4\xB1\xA4\xF3\xA4\xC1\xA4\xF3\xBD\xC1”
begin
str.blank?
rescue => e
p e # ArgumentError: invalid byte sequence in UTF-8
end
文字列のblank?メソッドは正規表現を使っていますので、UTF-8的に正しいバイト列ですかチェックしています。
配列の要素に対して、正しいUTF8バイト列をチェックするため、要素に対して、blank?を使用します。
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
今回は、脆弱性検出ツール「iFuzzMaker」の有効性と想定外データの受け取りに伴う脆弱性診断について考えてみよう。
iFuzzMakerは、IPAがオープンソースで提供している、画像閲覧ソフトの脆弱性検出ツールだ。このツールを使うことにより、意図的に加工した画像を作成し、この画像を検査したいツールに入れることにより、システムクラッシュやバッファオーバーフローの脆弱性などを見つけることが出来る。この様な、様々な情報を相手に入れる（食わせる）ことにより、診断する手法をファジングと呼び、知識が無い状態でも脆弱性の有無を確認することが出来る。
上記の場合は画像表示ソフトを対象としているが、これを他のシステムに流用することが出来る。たとえば、画像表示ソフトが厳密に画像であるか否かをチェックしていない場合、ワードファイルの拡張子を、.jpg や .jpeg に変更する事により、画像表示ソフトが厳密に画像処理を行っているかを確認することが出来る。
また、同様に他のサービスやシステムに於いても、通常受け入れるサイズ以上のデータを無理矢理入れることにより、バッファオーバーフローの脆弱性を発見することが出来る。
たとえば、データの受け入れサイズが、30バイトしかないところに、厳密にその受け取りサイズをチェックしていない場合、60バイトのデータを受け入れたとする。30バイトはそのままスタックされるが、残りの30バイトはプログラムの一部を書き換え、その先に意図的なプログラムコードを入れて権限昇格を狙う。これがバッファオーバーフローの脆弱性を利用する、主な考え方だ。
バッファオーバーフローの脆弱性が発生するのは、データの受け入れが明示的に示されている物だけでは無い。たとえば、80/tcp では、通常webサービスが稼働している。このポートに対して、通常はwebブラウザを使って接続しているが、明示的にtelnetを使って接続する方法もある。このほか、予め作成したデータを強制的に流し込む場合は、次のように入力する。
cat 送り込むデータ | nc 接続先IP ポート番号
この方法で、強制的に情報を流し込むことが出来る。通常のサービスでは、特定通信の内容と異なる場合は、その時点で接続を切って、受け入れを中止する。しかしながら、作りが甘いと、こうした情報を受け入れ続け、システムのメモリを食い尽くすまで受け入れが続く場合も有る。こうなると、復旧するにはシステムを再起動するしか方法はなくなる。
複数アプリを用いて、データの受け渡しを行う場合、送り出す側と受け取る側で、厳密にデータの内容をチェックする必要が有る。先ほどの例のように、データ送信側を偽装したデータ送信が行われた場合、最悪アプリがクラッシュしたり、OS毎巻き込んでスマートフォンが終了したり再起動したり、フリーズすることも十分に考えられる。受け取るデータが常に正しいと考えず、必ず受け取ったデータが正しい情報で有るかをチェックしてから、加工するようにしないと、大変なことになるかもしれない。
目次
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
Rubyでuse_resultを使い、Mysqlから大量データをSELECTする
MySQLで大量データを扱うコツは、フロントエンドとバックグラウンドでは結構異なることがあります。
代表的なもので言えば、インデクスが挙げられます。
フロントエンド処理において大量データから必要なデータを抽出するためには、インデクスの作成がかかせません。
もしインデクスがなければ、テーブル内をフルスキャンを行わなければならず即時に応答を返すことができなくなります。
対してそのテーブルがバックグラウンド処理でしか使用されない場合、インデクスが必要不可欠かと言うとそうでもありません。
即時応答の必要がないからです。
インデクスがあることでテーブルの更新処理が遅くなり、足かせとなってしまう場合もあります。
今回はバックグラウンド処理でMySQLから大量データを取得する際のノウハウの一つが題材です。
数千万レコードレベル以上のデータが保存されているテーブルから全レコードを取得しなければいけない場合、
通常軽量言語で使用するMySQLライブラリのqueryメソッドで全レコードを取得するような処理を実行すると
データがメモリに乗りきれなくなり、Out Of Memoryエラーとなります。
回避策としてLIMIT・OFFSETを使って、例えば数千件程度ずつに区切ってデータ取得するといった方法もあるでしょう。
しかし、SELECTの途中でテーブルの内容が更新されたりした場合、並び順が変わってしまって正しく全件を取得できない可能性があります。
MySQLのC言語のライブラリにmysql_store_resultというメソッドが用意されています。
SELECTの結果すべてをメモリに乗せて取得するものです。フロントエンド処理で通常使用されているものはこの仕組みです。
対して、mysql_use_resultというメソッドがあります。
これはSELECTの結果を一度に取得せず、一行ずつ取得するものです。一度に使うメモリは一行分のみになるので省メモリとなります。
今回はMySQL/Ruby(version. 2.9.1)を使用します。
以下のように使います。
#-*- coding: utf-8 -*-
require "rubygems"
require "mysql"
dbh = Mysql.new("localhost", "user", "passord", "database")
dbh.query("set net_write_timeout=9999") #注意点 後述
dbh.query_with_result = false #query()実行と同時にresultオブジェクトを返さなくなります。
dbh.query("select * from big_table") #大量データテーブルからのSELECT
res = dbh.use_result # use_resultを実行してresultオブジェクトを取得
res.each do |row|
#処理
end
res.free
dbh.close
use_resultの便利な面を説明しましたが、少しクセがあります。
そのうち代表的なものをあげます。
net_write_timeoutは通常デフォルトが60秒となっています。
use_resultは一度に結果取得をしない分、net writeの時間が長くなりこのtimeoutを超えてしまうケースがあります。
そのため上記コード例でもあげたとおり、
set net_write_timeout=9999
などとしてtimeout値を伸ばしておく必要があります。
一度はじめたSELECTは全件を取得し終えるまでresultオブジェクトを開放できません。
つまり、use_resultをしているDBハンドラは全件を取得するまで別の行動ができません。
どうしてもSELECTの途中でMySQLの別の処理を行う必要がある場合は、
もうひとつDBコネクションを作成し、作成したハンドラで処理を行います。
