Ruby 初心者スレッド Part 63
■ このスレッドは過去ログ倉庫に格納されています
プログラミング言語Rubyについての、初心者向けスレです。質問・要望・雑談などどうぞ。
質問するときは、OSやRubyのバージョン、エラーメッセージを書いたほうがいいお
Ruby on RailsについてはWEBプログラミング板で
前スレ
Ruby 初心者スレッド Part 62
https://mevius.5ch.net/test/read.cgi/tech/1511451329/
るりまサーチ （リファレンス検索）
http://rurema.clear-code.com/
Rubyist Magazine - るびま
http://jp.rubyist.net/magazine/
逆引きRuby
http://www.namaraii.com/rubytips/ なんや?
アンチはRubyの文字環境の設定もしらんのか？
しったかばっかりしとるツケやな WindowsでRails開発してるけどcloud9使ってるからWindows環境に依存しない
そもそも環境構築すらいらん
クッソ楽だよ VSCode から、PowerShell を使えば、UTF-8 だから問題ない
ただし、Windows で、irb は日本語でバグるから使えない。
irb を使う時は、WSL から使う おいおいRubyistはVSCode使っちゃダメだぞ
VSCodeはJSをわざわざ静的型言語に魔改造したTypeScriptによって作られている
そんなものをRubyistが使うということは、静的型の勝利を認めるようなものだ そんなこと言ったらそもそもさんざんバカにしてきたjavascriptで動いてるVSCodeなんて恥ずかしくて使えないだろｗ >>603
chcp 65001 は糞だな
git for windows の bash 使うと utf-8 で統一出来る 故Coffeeが押されてた頃以来しばらくRails触ってないから最新の事情に疎いんだけど、今のRailsでは生JSかbabelが普通?
さすがにまさかTypeScriptは意味不明なダブスタ状態になるからありえないとは思うけど そうなんです
物凄いコンプレックスがあるんです
夜も眠れません そもそもWindowsで開発ってエンジニアとして恥ずかしいからやめな
ド素人専用OSだから そんなこと言ったら、rubyで開発とか恥ずかしいよ >>632
> 外部ツールを使うこと前提は普通対応しているとか使えるとはいわなくね？
対応して無くていいよ。Unicode（UTF-8）だけに対応していれば十分 >>640
Webpackerが基本だから好きなの使えばよろし Pythonが2018年も人気ナンバーワン言語に - Rubyは13位へ
https://www.softantenna.com/wp/software/ieee-spectrum-top-programming-languages-2018/
>日本生まれのプログラミング言語Rubyの順位は昨年の12位から13位へと一つ順位を落としています。 RubyInstallersのRuby + Devkit 2.5.1-2（x64） でインストールしたら
トロイの木馬検知したんだけど、これ大丈夫なんか…… 基本、主流のレンタルサーバではどこもRuby標準装備だろ
個人でやるならRubyしか手は無いぞ？ pythonも標準装備です。
ただしどちらもかなり古いのしか入っていないです。
https://help.sakura.ad.jp/hc/ja/articles/206053142--さくらのレンタルサーバ-基本仕様
今だに1.8.7って・・・ >>650
管理者権限のないレンサバでやるとか拷問好きの変態だけだろ xxenvが使えりゃ取り敢えずなんとかなるけどな。
pathに嵌ったりするけど。 今はVPSとかHerokuとかそういうの使う方が主流だよね >>651
教祖がWindowsアンチだから仕方ない
残念だがRuby界においてWindows使いに人権はない 宗教以外で今時Herokuを選ぶ理由はないでしょ
PaaSならGCPとかAWS Lightsailとかにしとけ
HerokuとAWS/GCPじゃスキルとしての価値にも差がありすぎる いやしかし機械学習という神風でPythonがRubyを吹き飛ばしたよね
特にこれから始めようとする人で、Ruby選ぶ人って激減なんじゃないかと >>661
このお盆休みに Rails をやっているのだけれども… >>661
機械学習とWeb系は別物だからね
適材適所ということだね Rails使う奴らが他言語使いを見下しているから嫌われるんだよ 今更Railsはなあ
第2のPHPとして当分は健在だろうけど、もう美味しい時期をとっくに過ぎてRails専のエンジニアは買い叩かれてるのが現状 python用のwebフレームワークもいくつかあるけど、railsの出来には全然かなわんの？
rubyもnumpyとかあればなあ >>666
Rubyの言語仕様はイカれてるからな。
よくもわるくも。 >>666
Django が一番有名なんだろうけど、開発スピードは Rails の足元にも及ばないね >>576,577
関数型プログラミングという視点であれば、JS は良い言語だね
どちらも出発点として関数型言語をベースに設計された言語だから、当然の帰結と言える：
http://peace.5ch.net/test/read.cgi/tech/1409526637/857/
ただし、あえて「Rubyによる関数型プログラミング」に慣れると
JS にイラッと感じる(=楽しくない)のは：
・条件分岐の if/switch が(式ではなく)文であること
Ruby であれば if/switch (を含めて「あらゆるすべて」)は式だから、ML や Haskell と同様、
いちいち一時変数を持ち出さずに書ける
・匿名関数の function() は煩わしい
匿名関数が多用されるのは map/filter といった関数を引数渡しするケースだけど、
Ruby であればブロック引数という独特な構文があるから簡潔に書ける
ってことかな(あくまで個人の感想ですが)
ちなみに、これらの感想は以下の文書からの受け売りだったりします：
・Rubyによる関数型プログラミング
(*1) URL はNGワード規制によってカキコできないので、
もしも興味のある人は「Rubyによる関数型プログラミング Arnau Sanchez」でググッてください
なお、この文書で筆者は：
Rubyは基本的には命令型言語であるけれど、 関数型プログラミングへの際立った潜在能力がある
と断じています
(*1)：規制されるほど、この文書はム板管理者にとってヤバイ内容が含まれているんですかねぇ？
2012年と５年も昔に公開された、今のRuby使いにとっては常識的な中身だと思うんですけど def式じゃないじゃんjsのfunctionは式だぞ >>577
>Rubyは第一級関数ではないという致命的な欠陥がある
JSとは異なり、Rubyだと関数は一級市民ではない」という指摘を
具体的なコードで示したのは、おそらく自分が最初だと思うけど：
https://mevius.5ch.net/test/read.cgi/tech/1503644351/210/
そこでもカキコしたように「制限」であって「致命的な欠陥」ではないんだよね
>>670でも書いたように、一級市民としての関数が重要になるのは
メソッド(or 関数)の引数値として匿名関数を渡すケースだけど、
Ruby ではまさにその目的のためブロック引数という特殊な構文が用意されている
もし反論があるなら、具体的なコードで示したほうが理性的ではないかと思われます >>671
関数型プログラミングを実践すると自然に匿名関数を多用することになるわけですけど、
JS はいちいち function とタイプしないといけないから煩わしい、という意味です
たとえば ML族の Standard ML だと fn、同 OCaml だと fun、Haskell に至っては
¥ が匿名関数を表すキーワードです
ここまで「JavaScript による関数型プログラミング」が普及し常識になった現時点で
振り返れば、function ではなく fn とか fun という予約語にできなかったのか？と
なお、関数宣言のキーワード function は、それが宣言を目立たせる意味で長いキーワードを
採用したと考えれば、納得できるのですけどね Ruby にはブロックスコープがあるし、
関数スコープでは、関数外部からの変数を通さない
Rubyの偽は、false, nil の2つだけ
Rubyは厳格だけど、JS, Python, PHP などは、ややこしい >>673
> JS はいちいち function とタイプしないといけないから煩わしい、という意味です
なるほど。ではこのコードのどこにfunctionがあるのでしょう？
var materials = [
'Hydrogen',
'Helium',
'Lithium',
'Beryllium'
];
console.log(materials.map(material => material.length));
// expected output: Array [8, 6, 7, 9] ruby狂信者に「他言語では…」って話しすると黙りこくって見下すのは経典に書いてるのか？
どんなruby狂信者に聞いてもどいつも同じ精神なのがものすごく気持ち悪い
アレなんなんだろうな >>670
rubyに関する内容がヤバイんじゃなくて
archive。fo
がだめなだけ >>675
それ、もうブラウザでも使えるんだっけ？
JavaScriptは新機能を使っていいかどうか、いちいち考えないとイカンのがめんどくさい。
なおRubyも、バージョンのよる差異がうざい模様。 rubyって昔複数引数取る関数
foo bar baz
って書けたよね。
でも今は
foo bar, baz
だよね。 >>681
1.8.7でも foo bar baz は foo(bar(baz)) なんだね >>675
失礼しました、ES2015(ES6)で導入されたアロー関数ですね
ということで、>>670 の：
>・匿名関数の function() は煩わしい
という項目に関しては取り下げます
>>680
調べてみると、主要なブラウザの最新版であれば利用できるようです
まあ JS も Ruby も新機能の扱いを「めんどくさい」とか「うざい」と
感じることはあります
ただし、どちらも「後方互換性の維持」という言語進化の基本原則を
遵守しているのは共通していますから「新機能を使わない」という
選択肢も残されているわけです >>679
情報提供、ありがとうございます
MANGO板にて特定のページが規制されているのではなく、
サイト全体が規制されていることを確認できました
・NGワード絞り込みスレッド★118
http://agree.5ch.net/test/read.cgi/mango/1533547792/324-326/ >>681
昔って、いったいいつの時代なんだろう
自分は 1.6 の時代だからかれこれ20年は使ってるけど、
foo bar baz と書けたという記憶が無い
もしかすると 1.4 とかそれ以前には書けたのかな？
興味深いね >>683
JavaScriptはともかく、Ruby は「後方互換性の維持」を遵守しないぞ。
バージョンアップは、過去のコードをだいたい壊す。
次も、文字列の原則immutable化が控えているだろ。 それはjs以外たいていみんなそうなんじゃ？pythonしかり。 >>168
今どきにbabelも使わずフロント開発してるところなんて業務系SIerくらいしかないでしょ >>688
互換性維持の優先が高い言語はあるぞ。
C,C++,C#,Perl5はずっと更新されてきてるが、過去のコードを壊したことがほとんどない。
RubyやPythonと違って、システムの重要なところを担ってる自覚がある模様。 >>687
>JavaScriptはともかく、Ruby は「後方互換性の維持」を遵守しないぞ。
いや、Ruby は(も？)新機能の導入には保守的ですよ
たとえば Ruby の特徴である既存のクラスの振る舞いを後から上書きできる
オープンクラス、これには利点と欠点が共存してるけど、これに対応しようとする
refinement の提案は「後方互換性の維持」を理由に却下され続けたけど、
その壁を乗り越えてようやく 2.1 で採用された
もしも遵守しない例があるなら、具体的なコードで示してね(>>675 みたいに)
>次も、文字列の原則immutable化が控えているだろ。
え、frozen_string_literal オプションがあるでしょ？
>>688
いやぁ、バージョンアップしたら Hello world すら構文エラーになる Python みたいな
言語などとは一緒くたにされたく無いですね
・Rubyの設計上の欠点とは何か？
https://mevius.5ch.net/test/read.cgi/tech/1413113999/123-126/
Python2 の時点ですら全プログラミング言語でも人気トップ10、スクリプト系言語に限れば
圧倒的に首位を独走というメジャーな言語が、Hello world すら構文エラーになるという
基本原則「後方互換性の維持」を頭から無視したバージョンアップを断行するなんて、
過去のプログラミング言語の歴史を振り返ってもあり得なかった歴史的快挙(暴挙？)ですよ
とうていマイナー言語の Ruby なんかじゃあ到底まねできないですわ >>692
結局、互換を壊してるじゃん。ｗ
そんなのは保守的と言わないんだよ。
多少の不満は飲み込んででも、過去のコードを重視しないといけない。
オプションで選択できるとか、いいわけにならん。
例が知りたきゃググれ。
スコープとかメソッドとかいろいろあって、思い出すのもバカらしい。
ま、それがRubyの道なんだろうから、それはそれでいいんだよ。
ヘンに言い繕わずに、互換性は低いと冷静に受け入れてれば。 現実無視の机上の空論ｗ
昔のC/C++コードを一切の修正なしで再利用できるケースが実際にどれだけあるというのだ >>683
JS のアローと、function()無名関数は、スコープ・this の挙動が異なる
非同期処理などで異なる。
別のもの
JSは、Rubyの影響を受けて、ドンドン変化していく >>693
>オプションで選択できるとか、いいわけにならん。
では、以下のコードを python3 で動かす方法はあるんですか？
https://mevius.5ch.net/test/read.cgi/tech/1413113999/126/
え、オプションすら存在しないのぉ？？？
オプションすら許さない >>693氏のオレ様基準に従えば、
いいわけ以前の「後方互換性の断絶」であり「致命的な互換性の問題」ですね
>例が知りたきゃググれ。
>スコープとかメソッドとかいろいろあって、思い出すのもバカらしい。
え、これだけ「Rubyはゴカンセイガァー」と騒いでおいて、
ご自身では具体的なコードすら書けないんですか？
情けないですね、自分ならスコープやらいくつかRubyに関する
「些細な互換性の問題」を示してあげることもできるんですけど
>ヘンに言い繕わずに、互換性は低いと冷静に受け入れてれば。
いやぁ JS と比較すれば互換性は低いですよ
あちらはECMAScriptという国際標準の強い縛りがありますからね
でも Hello world すら動かなくなる最底辺 Python と比較すれば遥かに高い
そもそも具体的なコードも示せないくせに、
ナゼか「上から目線で」オレ様理論を押し付けるのは、
Rubyアンチに共通する性癖ですね Selenium WebDriver を使って、Nokogiri で、DOM を構築して、
JavaScript(JS) を使って、そのDOMで、body 以下を更新しようとしたが、エラーになる
つまり、DOMの構築には、JSではなくNokogiriを使った。
なるべく、JSではDOMを構築したくない。面倒だから
p inner_body = %(<div class="thread">あ</div>) #=> "<div class=\"thread\">あ</div>"
jsCode = <<"EOT"
var element = document.querySelector('body');
element.innerHTML = "#{ inner_body }";
EOT
driver.execute_script jsCode # JavaScript を実行
ただし、下のように書くと、body以下は正常に更新される。
element.innerHTML = '<div class="thread">あ</div>';
違いは「\"thread\"」の、ダブルクォーテーションのエスケープなのかな？
Nokogiriで構築したDOMを、JSにどうやって渡せば良いのか？ > Nokogiriで構築したDOMを、JSにどうやって渡せば良いのか？
うん、でもいま面倒なことになってるよね？ >>697
Rubyアンチアンチは、だからめんどくさいんだよな。
そんなに必死にならんでもええよ。ｗ それがルビリスト
皆呆れてるだろうが
個人的にすごく良い流れなので
もっと頑張れ 一言で言えば左翼と同じメンタル
何故そうなるかは長くなるから書かないけどな p inner_body = %(<div class="thread">あ</div>) #=> "<div class=\"thread\">あ</div>"
以下は、jsCode を、puts, p したもの
(A) element.innerHTML = "#{ inner_body }"; の場合
var element = document.querySelector('body');
element.innerHTML = "<div class="thread">あ</div>";
"var element = document.querySelector('body');\n
element.innerHTML = \"<div class=\"thread\">あ</div>\";\n"
(B) element.innerHTML = '<div class="thread">あ</div>'; の場合
var element = document.querySelector('body');
element.innerHTML = '<div class="thread">あ</div>';
"var element = document.querySelector('body');\n
element.innerHTML = '<div class=\"thread\">あ</div>';\n"
A は、" の対応が崩れるから、ダメ。
一方、B は正常に処理される
どうやれば、変数をBのように展開できるのか？ p inner_body = %(<div class="thread">あ</div>) #=> "<div class=\"thread\">あ</div>"
以下は、jsCode を、puts, p したもの
>>706 の、
(C) element.innerHTML = '#{ inner_body }'; の場合。
>>705 の(B) と全く同じになった！
var element = document.querySelector('body');
element.innerHTML = '<div class="thread">あ</div>';
"var element = document.querySelector('body');\n
element.innerHTML = '<div class=\"thread\">あ</div>';\n"
"#{ inner_body }"
'#{ inner_body }'
まさか、シングルクォーテーションで変数展開できるとは！
神！ 5ch ブラウザみたいに、スレに書き込んである画像のURL を、
自動的に、<img> に展開して表示するものを自作している
Selenium WebDriver を使って、Nokogiri で、DOM を構築して、
JavaScript(JS) を使って、そのDOMで、body 以下を更新しようとしている
わざわざ、Sinatra, Vue.js などを使うまでもない。
標準添付ライブラリのERB は、使っても良いかも Action Cableを使用してるアプリってもうある？ BIOSが夏時間に対応していると、OSの時刻までずれてしまう
これ比較的最近の話だからな
http://naitaku.hatenablog.com/entry/2017/04/06/012238
> RTCにはタイムゾーンや夏時間を扱う仕組みは一般にはありませんので、
> OS側でタイムゾーンや夏時間を管理することになります。
> (実はRTCに夏時間を扱う仕組みがあって誤発動したというのが今回の原因なのですが）
> RTC の Daylight Savings Enable (DSE) という機能について
> 現代のOSでは上で述べたようにタイムゾーンや夏時間を管理しているのですが、
> 昔（DOSとかの時代？）はOSはそんな賢い機能はなくRTCの時刻がそのままローカルタイムでした。
> そんな時代に夏時間を扱うためにハードウェア的に実装されたのが DSE という機能です。
> またブコメで「日本のタイムゾーンにしていれば夏時間は自動的にオフになるはず」というものがありましたが、
> DSEの設定値はOS上の夏時間の設定とは無関係です。OSは上で述べたように夏時間を管理していますので
> RTCが勝手に1時間進んだり遅れたりすることは想定していないはずです。
> したがって現代のパソコンではDSEは無効になっているのが正しいです。 p inner = %(a"あ"b) #=> "a\"あ\"b"
outer = <<"EOT"
'#{ inner }'
"#{ inner }"
'X'
"Y"
EOT
以下は、outer を、puts, p したもの
'a"あ"b'
"a"あ"b"
'X'
"Y"
"'a\"あ\"b'\n
\"a\"あ\"b\"\n
'X'\n
\"Y\"\n"
つまり、#{ inner } だけが変数展開されているだけ。
ヒアドキュメント内の、', " は、そのまま表示されているだけだった Ruby FFIを使ったエクステンションの作り方
http://kazegusuri.hateblo.jp/entry/2014/03/02/192729
FFI(Foreign function interface)
コンパイルがいらない、多言語を呼び出すためのインターフェイス
RubyにおけるFFIは、libffi
こんなのがあるのか
Windows で、クリップボード機能を使おうとして、
win32-clipboard gem の文書を見ていて、FFIを見つけた だからなんだよいちいちうるせえな
リファレンス全部読んでこい str.chomp!.strip!
末尾の改行を削除して、先頭末尾の空白を削除するのを、メソッドチェーンで書いたけど、
chomp! は、改行がない場合に、nil を返すのでエラーになる
メソッドチェーンに出来ないから、分けて書くしかない
str.chomp!
str.strip!
nil を返す可能性があるものは、メソッドチェーンに出来ない 拡張子で、画像ファイルかどうかを判別する際に、
大文字の拡張子を、downcase で小文字に変換して判別していますが、これで良い？
それとも、String#casecmp を使う方が良いの？
どう書けば良いの？
file_extname = ".JPG"
# . を削除して、小文字にする
file_extname.delete!(".").downcase!
extnames = %w(png jpg jpeg gif) # 画像の拡張子
extnames.include? file_extname # 含まれている？ >>717
str = " \tfoo\t \n" #=> " \tfoo\t \n"
str.strip! # => "foo" >>719
file_extname.delete!(".").downcase! は
file_extname.delete!(".")&.downcase!
とでもしないとfile_extnameにドットがない時にエラーになる
ドットから始まることが分かってるなら
hoge = file_extname[1..-1].downcaseとでもすべきだし
ドットから始まることが分かってないなら
file_extname[/\.\K[^.]+$/]的なことでもしないとだめ
そもそもfile_extnameを破壊的に変更するのがそもそも気持ち悪い
extnames = %w[jpg gif png]
path = '/hoge/fuga/hage.jpg'
file_extname = File.extname(path)
extnames.include?(file_extname[1..-1].downcase) if file_extname[0] == '.' ていうかこのくらいの処理なら正規表現で書くわ
files = [
'/hoge/fuga/piyo.jpeg',
'/hoge/fuga/piyo.piyo.JPg',
'/hoge/fuga/png',
'/hoge/fuga/gif.txt'
]
files.each {|f| p f.match?(/\.(?:jpe?g|gif|png)\z/i) }
#=> true
true
false
false Ruby de GUI for Windows
RScript(ActiveScriptRuby)→良くも悪くもHTA、要インストール、最新版に追従していない
wxWidgets(wxRuby)→高機能、環境構築が面倒、機能によっては罠があったり不安定だったり、コントロール類のデザインに手間がかかる
Tcl/tk(Ruby/Tk)→導入が容易、機能面はwxRubyに劣る、コントロール類のデザインに手間がかかる
fiddle(WindowsAPI)→何でもできる、配布サイズが小さい、茨の道
(Webブラウザ組み込み型→現状なし？、出てきたとしても配布サイズの肥大化は不可避) 拡張子発明したやつ天才だわ
名前にファイルの種類を埋め込むとか一見ダサそうだけど理にかなってる
一方でマックバイナリは糞だわ 拡張子の何が凄いって
あくまでそれが何であるか種類を表しているだけで
どう扱われるかはOSの設定次第ってところ
これがRubyみたいな古い考えの頭のやつがやると
ファイルは自身がどう扱われるべきか知っているべき
とかアホみたいなこと考えだして
マックバイナリみたいな糞が出来上がる
だが実際には拡張子ぐらいが一番使いやすい >>721
>file_extname.delete!(".")&.downcase!
&. こういう演算子が出来たのか
Ruby の &. と #try の違い
http://secret-garden.hatenablog.com/entry/2016/09/02/000000
Ruby 2.3 で、Safe Navigation Operator(&.)という新しい演算子が追加された >>729
メタプログラミングのため
ソース上に現れる変数名やメソッド名とかってソースを解析する時点で全て把握できてるわけだから、
それを予め数値に置き換えてしまうことで効率よく扱おうという伝統的なコンパイラ技法があるんだけど、
Rubyはメンバ検索の動作を独自に定義できたりするので、その置き換え後の数値をRuby上のデータとして扱えなければならない
そのために用意されてるのがシンボルオブジェクトでありシンボルリテラルである
一方で、数値じゃなくて変更不能な文字列を使えばそんなもん要らなくね？という説もあって、実際Matzもそうすべきだったと失敗を認めている
というわけで、今となっては変更不能でちょっと不便な文字列のようなもの、以上の意味はない ちなみにRails専用DSLに成り下がって以降のRubyではRailsの影響でシンボルをキーにしたHashを引数に渡すということがよく行われるけど、
これはクォーテーションより:の方が書くのが楽だからとか、
文字列よりシンボルをキーに使ったほうがハッシュの検索が速いと信じられていた(今のRubyではこれは正しくない)からといった
あまり本質的でない理由によるもので、シンボルじゃなくて文字列でも何の問題もないよ >>729
不変性と同値時の同一性が保証された文字列は便利でよく使うから
不変だと特にハッシュのキーとして安全に運用できる
多数出現する同値を同一にできるとメモリが節約できる ＞シンボルじゃなくて文字列でも何の問題もないよ
うわあああああｗ ■ このスレッドは過去ログ倉庫に格納されています
