Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Rails 5.0.0.beta1が2015年12月18日にリリースされました。 また、それにあわせてRuby on Railsの公式ブログに主な変更点がまとめられています。(投稿者はあのDHH氏のようです) Rails 5.0.0.beta1: Action Cable, API mode, Rails command beta1がリリースされたということは、Rails 5.0の正式リリースもそろそろ近いということです。 (ちなみにRails 4.0ではbeta1の4ヶ月後に正式版がリリースされました。) Railsユーザー
こんにちは、金子です。 普段はRailsを書いたりしています。 今回は2016/4/6に発表された、RubyGems.orgの脆弱性についてまとめました。 脆弱性について RubyGems.org gem replacement vulnerability and mitigation をざっと読んでみると、 特定の状況で、RubyGems.orgにupdateされているファイルの内容が不正に書き換えられる可能性があった 特定の状況とは、2014-6-11から2016-4-2までの間に登録されたgemのうち、'blank-blank'のように名前に'-' (dash)が入っているもの ただし2015-2-8以降に登録されたgemはRubyGems.orgがsha256 checksumを計算しており、それと実際のファイルの突合をして、書き換えられていないことを確認ずみ つまり、2014-6
ご存知の方には何を今更感があるかとは思いますが、パッとググった限り誰も書かれていなかったので、 Object#sendやそれとよく似たObject#public_sendの使い方は注意して使わなければ結構危ないセキュリティホールを作ってしまうよ、 というお話をしたいと思います。 TL;DR Object#sendはevalやsystemの次ぐらいに危険です。ユーザーの入力など、外部から入力された値をObject#sendやpublic_sendメソッドにそのまま渡すのはやめましょう。 これらのメソッドに渡す文字列は、(特殊なメタプログラミング用のライブラリを作る場合などを除いて)必ずどこかにハードコードした、信頼できるメソッドの名前のみにしてください。 危険なケース 例えばあからさまな例ですが、次のようなRailsのコントローラーのアクションがあったとしましょう。 みなさんはこれに近いよう
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
はじめまして、ティッシュ配り1もするエンジニア @ru_shalm です。 今日は社内(非公式)ツール「Togelack」のお話をさせていただきます。 Slackは最高にイカしたチャットツールだぜ ドワンゴエンジニアブロマガ などでも取り上げられていますが、ドワンゴではチャットツールとしてSlackが導入されています。Slackは最高にイカしたサービスでみんなから愛されており、社内には1000を超えるチャンネルやカスタム絵文字が存在すると言われているくらい幅広く活用されています。 埋もれゆく知見、そして神展開 日々行われる会話の中には、とても有用な情報が含まれていることもあります。ですが、チャットという性質上、次の話題が始まれば流れてしまいますし「あー、あれってどっかで話したよなー?どこだっけー??」ということが稀によくあります。 もちろん、常日頃からそういった情報を整理して社内ブログなど
Posted by usa on 16 Dec 2015 Ruby の標準添付ライブラリである Fiddle と DL に、信用できない tainted な文字列の使用に関する脆弱性が発見されました。 この脆弱性は、CVE-2015-7551 として登録されています。 詳細 Ruby の標準添付ライブラリである Fiddle と DL で、信用できない tainted な文字列を使用すると、本来禁止されるべき危険な操作が可能となる問題が発見されました。 この問題は、元々は DL において CVE-2009-5147 として報告され、修正が行われていました。 しかし、DL が Fiddle と libffi を用いて再実装された際に、同じ問題が再び発生してしまいました。 また、DL に関しても、Ruby 1.9.1 ではこの問題は修正されましたが、他のバージョンでは修正が行われなかったため、
PerfectSched is a highly available distributed cron built on top of RDBMS. It provides at-least-once semantics; Even if a worker node fails during process a task, the task is retried by another worker. PerfectSched also guarantees that only one worker server processes a task if the server is alive. All you have to consider is implementing idempotent worker programs. It's recommended to use Perfect
Sansan Advent Calendar 11日目の記事です。 弊社には BtoB と BtoC、2つのサービスがあります*1。BtoB のほうは C#、BtoC のほうは Ruby で開発されています。エンジニアのスキルセットとしてもかなり違っているようです。世の中的には C# と Ruby はいろいろ違いすぎて、並べられること自体あまりないです。これらが比較にあがるのは弊社ならではだと思うので、弊社カレンダーを機に比較してみようと思います。 ちなみにぼくは BtoB のほうで C# を使って開発をしています。Ruby については、弊社の採用選考時に何か見せるものがないとあかんな…と思ってRuby で適当に何か書いた記憶がありますが、ほぼ完璧に忘れました*2。そんなわけで、C# に対して若干愛着はありますが、今回は公平に比較するため、比較項目としては世間一般に受け入れられている標準的
RailsのAsset PipelineとPrecompileをNode.jsのみで処理できるgulp-sprocketsを作った 仕事ではRailsアプリを書いていて、JSやCSSなどのフロントエンドはRailsのAsset Pipelineの仕組みに則ってビルドしてる。 普通にRailsアプリ作ってると普段Sprocketsについて特に意識しないと思う。 Sprocketsはそこが凄くて、あまり考えなくてもドキュメント通りにやってれば、必要なAssetを結合できて、リリース時は変更がなければブラウザキャッシュから、変更があれば 新しく読み込まれるみたいなことをやってくれる。 なんだけど、もうそろそろ新しい機能はES2015で書きたいよねという人が増えてきた。 とはいえSprocketsは独自のディレクティブ以外は使えなくて、SprocketsWayから外れると途端に脆い。 ES2015
参考文献 今回紹介するサンプルコードは下記のサイトにあったコードをベースにしています。 New features in ruby 2.3 - BlockScore Blog ただし、実行結果を確認するために Minitest を使ったり、コードをいくつか変更したりしています。 サンプルコードはGitHubにあります この記事で使ったサンプルコードはGitHubに置いてあります。 興味のある方は手元で動かしてみてください。 JunichiIto/ruby-2.3-sandbox それではここからRuby 2.3の新機能を紹介していきます。 深い階層にあるハッシュの値を一気に取得する Hash#dig Ruby 2.3で追加された Hash#dig を使うと深い階層にあるハッシュの値を一気に取得できます。 また、Keyが見つからない場合はエラーにならず nil が返ります。 def test_
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く