はじめに お疲れ様です! おおくまです! 今回は、「【Rails】カラム修飾子 precision について」ということで、Ruby on Railsのカラム修飾子であるprecisionについてまとめてみました! 少しでも皆様の参考になりますと幸いです! 対象読者
Rubyでは配列やハッシュに抽出や検索の機能を与えることができるEnumerableというモジュールがあります。 ArrayやHashがselectメソッドを使えるのも、このモジュールのおかげです。 というわけで、Enumerableに実装されているもののうち、配列の抽出/検索系のメソッドをまとめてみました。 select / find_all {}ブロック内の式が trueになる要素だけ を抽出します。 find_all は select と同義です。 なお、trueになる要素がない場合は空の配列が返ります。 # 2で割り切れるものを抽出する [1, 2, 3, 4, 5, 6].select { |n| n % 2 == 0 } # => [2, 4, 6] # 9で割り切れるものがないので空の配列が返る [1, 2, 3, 4, 5, 6].select { |n| n % 9 ==
この記事は、技術系同人誌としてまとめるはずだった原稿をほぼそのまま転載しています。諸事情により向こうかなり長い間同人誌即売会に売り手として参加することが難しくなったためです。 長いですが、お楽しみいただければ幸いです。 まえがき この本は、Rubyコミッタである卜部昌平に、その妻である私、卜部一恵がRubyのtrueとfalseについて突っ込んで聞いてみた話です。本文は両者の対話形式で進んでいきます。 私は昌平と同じ大学同じ研究室に所属していたのでプログラミングについての基礎は一応ありますが、エンジニアとして職を得たことはありません。つまり、プログラミング初級者です。この本はそのくらいのレベル感の本だと思います。 私自身が初級者なりにRubyを使っていて、if文が思った通りに動かない、そんなときに抱いた疑問からこの本が生まれました。 同じような疑問を抱いている方の一助になれば幸いです。 は
「自分の未来予測を信じてちょっと意地を張ってみる」 まつもとゆきひろ氏がRubyに型宣言を入れない理由 #17 動的型付け言語と大規模開発 テーマは「動的型付け言語と大規模開発」 まつもとゆきひろ氏:まつもとゆきひろです。Matzチャンネル17回目ということでお送りします。ちょっと前になりますが9月28日に私が技術顧問を始めたクラウドサーカスという会社さんがテックイベントを開催されて、その時のテーマが「動的型付け言語と大規模開発」というテーマでした。 その時に話したこととか、話そうとしたこと、話そうと思っていたんだけど時間の関係で話せなかったことなどを補足する意味も含めて今日はちょっと放送しようかと思います。というか、分量が多いので2回に分けて話そうかなと思っています。 このクラウドサーカスのイベントのテーマは別に私から指定したわけではなくて、先方が「こんなテーマで話したいんだ」とか「聞き
2006年からほぼ毎年、日本で開催されているオブジェクト指向スクリプト言語Rubyに関するイベント「RubyKaigi」。 世界中のRubyistにとって“祭り”と言えるような一大イベントですが、この「RubyKaigi」が発足した経緯や、過去から現在までの歴史をみなさんはご存知でしょうか。 今回は「RubyKaigi」の創始メンバーのひとりである荻野淳也さんと、第1回の「RubyKaigi 2006」から運営に携わっている角谷信太郎さん、「RubyKaigi 2015」からチーフオーガナイザーを務めている松田明さんにインタビュー。イベントの歴史を語っていただきました。 「RubyKaigi」が産声をあげるまで ――そもそもの発端として「RubyKaigi」を立ち上げた経緯を教えてください。 荻野:過去から歴史をたどると、最初、「RubyConf」が2001年にアメリカで開催されたんですよ
オープンソースソフトウェアの開発においては、コミュニティメンバーからのコードのコントリビュートだけでなく、さまざまな立場の人々から「この機能がほしい」「この動作はバグではないか」といった意見が寄せられます。 有名なオープンソースプロジェクトであるほど、そうした多くの意見やコメントを受け止めつつ開発は進んでいくわけですが、そうした状況は一方でさまざまな気苦労を生むであろうことは容易に想像が付きます。 人気のあるプログラミング言語として知られるPythonの生みの親であるGuido van Rossum氏は2018年7月、Pythonを開発する過程で生ずるさまざまな意思決定の気苦労から離れたいとの理由で、Pythonにおける「優しい終身の独裁者」からの引退を発表しました。 ちょうど新バージョン「Ruby 2.6」が登場したばかりのRubyに対しても、米国の掲示板redditで「[whining
Ruby1.8.5、1.8.6、1.8.7のリリースマネージャを務め、現在は株式会社マネーフォワードでフルタイムのRubyコミッター職として働く卜部昌平(うらべ・しょうへい/@shyouhei)さんは、deoptimizationと呼ばれるアプローチを用いてRubyの高速化に取り組んでいます。 本稿ではその足跡から、いかなる思想のもとでデザインや実装を行っているかを、卜部さん本人が解説します。 Deoptimizationの着想に至るまで デザインとは、やらないことを決めること 「最適化が間違っていたら、戻す」をどう実装するか? インストラクションを消し、跡地をnopで埋める 「メソッド呼び出しが省略可能であること」を判定するために 省略可能な呼び出され方を増やす 大き過ぎる問題ではなく、実現できる規模の問題に取り組む Deoptimizationの着想に至るまで 言語を高速化するときに、
追記(2018/07/19) 処理速度ではなくてプログラムの起動時間というご指摘を受けたのでタイトルを修正しました🙏🙏 純粋な処理時間の測定は別途行おうと思います.後半の感想の部分は読み流して頂けると 🙇 🙇 目的 今回は以前のエントリで書いたようなPerl6の正規表現などを使い同じ処理をするプログラムが,各言語でどういったパフォーマンスの差が出るかの検証を行います. 題材 題材としてはmac os Xの /var/log/system.logのデーモンの回数を数え上げるというプログラムです. 処理の流れとしてはまずコマンドライン引数を確認し,それに応じてファイルを開きます. 開くことが想定されている/var/log/system.logファイルは次のような形式になっています. Jul 18 01:31:55 anatofuzMBP Dropbox[96084]: [0718/01
オラクル、JavaやJavaScript、Ruby、Pythonなど多言語対応を単一ランタイムで実現する「GraalVM」をオープンソースで公開。Twitterが本番環境で採用 JavaやJavaScriptなどには、それぞれその言語を実行するためのランタイムが存在します。JavaならJavaVM、JavaScriptならJavaScriptエンジンといった具合です。 米オラクルがオープンソースで公開した「GraalVM」は、これまで言語ごとに個別に用意されていたランタイムを統合し、単一の高性能なVMにするという同社の研究の結果開発された汎用仮想マシンあるいは汎用ランタイムです(米オラクルのブログ、日本語訳)。 GraalVMのWebサイトには、次のような説明が記されています。 GraalVM is a universal virtual machine for running appli
開催アナウンス以来いろんな人に訊かれるし、ネット上でもあれこれ憶測が飛び交ってるようなので、当事者として、髙橋さんがるびま55号の巻頭言に書いてたやつよりもう少し主観的に、自分なりに解釈した経緯や考えていることを書いてみます。 さて、先にタイトルの問いに対する結論から書くと、なぜ広島開催なのか、の直接的な理由はすこぶる単純で、つまるところ以下の2点です。 広島国際会議場に、たまたま僕らの希望の日程で空きがあったから 日本中探しても、そこ以外に僕らが探している条件にマッチした会場が見つからなかったから ここで言う「条件」は、今回の2017年では概ね以下のようなものでした。 3日間連続開催 できれば3日中の1日は休日を絡めたい。休日は日曜日よりは土曜日または祝日が望ましい トークは大ホール・小ホールの2会場で並列開催 参加者の2割程度は非日本語話者なので、両方の部屋に日本語 -> 英語の同時通
1 アセットパイプラインについて アセットパイプライン(asset pipeline)は、JavaScriptとCSSアセットの配信を処理するためのフレームワークを提供します。これは、HTTP/2のような技術や、アセットの連結や最小化といった技術を活用することによって行われます。アプリケーションは、最終的に他のgemのアセットと自動的に結合できるようになります。 アセットパイプラインは importmap-rails gem、sprockets gem、sprockets-rails gem によって実装されており、デフォルトで有効になっています。新しいアプリケーションを作成する際に、以下のように--skip-asset-pipelineオプションを渡すとアセットパイプラインを無効にできます。 本ガイドでは、CSSの処理にsprocketsを、JavaScriptの処理にimportmap
Rubyの正式なコーディング規約はありません。しかし、複数人のプロジェクトやチームで同時にコーディングする場合や、継続的なメンテナンスが必要とされるシステム開発においては、コーディングスタイルを統一しておくことで可読性を高め保守性を向上することができます。参考となるコーディング規約を紹介します。 Rubyコーディング規約(日本語) Ruby のコーディングスタイル(日本語) The Unofficial Ruby Usage Guide (Ruby Style Guidelineのところ)(英語) Christian Neukirchen's Ruby Style Guide(英語) Elements of Ruby Style(英語)
2015/2/17にみんなのウェディングさんで開催された 『Ginza.rb 第20回 Rubyを使っているプロジェクトのコーディング規約を見てみよう』 に参加してきました。コーディング規約をじっくり議論できる場所はなかなかなかので、かなりおもしろかったです! 🏈 スタイルガイド今回Ginza.rbで一緒に読んだコーディング規約。 Rubyのコーディング規約ruby-style-guide/README.ja.md at japanese · fortissimo1997/ruby-style-guide Railsのコーディング規約rails-style-guide/README-jaJA.md at master · satour/rails-style-guide 🐮 おもしろかった規約議論に聞き入りすぎて、あんまりメモしきれませんでしたが今日から使いたいコーディング規約の俺得メ
Hamlコミッターになった RubyKaigi 2015で「Hamlは遅いしメンテされてないので使わない方がいい」と言ったところ、じゃあ自分でメンテして速くしろということになりコミッターになった*1。 当時から2年ごしなのは、当時のHamlのオーナーがあまりアクティブではなく、最近a_matsudaさんがオーナーになったため。 HamlのTemple化・高速化を行った Templeというのは、テンプレートエンジンをパイプライン的に構築するためのフレームワークで、テンプレートエンジン用の中間表現とその最適化エンジンを持つ。実装をTempleベースにすると、SlimやHamlitに使われているような中間表現を使った最適化を適用しやすくなる。 コミット権をもらったので、RubyKaigi 2015でマージされないと言っていたパッチを自分でマージし、コード生成とattributeのコンパイルをTe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く