Ruby の 定番対話ツール pry 徹底攻略 | Normal Input #pry #ruby - Qiita
概要 Ruby の 定番対話ツール pry 徹底攻略 Normal Input について How to Intput & Execute Ruby のコードを入力しすると入力した内容を実行し、戻り値を標準出力します 例： 入力と実行 [2] pry(main)> 'hello, pry' => "hello, pry" [3] pry(main)> [*1..5] => [1, 2, 3, 4, 5] [4] pry(main)> [*1..5].reduce(&:+) => 15 Clear Input Buffer メソッドやクラス定義など、複数行の記述をしている途中に 間違えてしまった場合は、 ! を利用すると通常の入力モードに戻ります。 入力途中に def を defa と入力してしまってキャンセルしたい場合は、 下記のようになります。 例： ! によるバッファクリア
Ruby の private と protected 。歴史と使い分け - Qiita
概要 Ruby の private と protected の歴史と使い分けについて説明します。 いろんなところで断片的に書かれていることなのですが、有益な情報を 一箇所に集めると自分の理解が深まりそう＝＞他の人にも役立つかな？ と思ったのでまとめてみました。 具体的には、伊藤淳一さんのブログ・るりま・Rubyメーリングリストの内容を 一箇所にまとめた上で、私が書いたサンプルコードを少し足した内容になっています。 ちなみに Java や C# 畑の人が Ruby の private / protected を使って驚いた、 的な情報が多いですが、私も例にもれず Java => Ruby 勢で驚いたパターンです。 Java の private と protected public => どこからでもアクセス可能 protected => クラス内、同一パッケージ、サブクラスからアクセス可 p
Ruby 2.2.0 の新規フィーチャーをネチっこくおさわりする #ruby - Qiita
Ruby 2.2.0 の新規フィーチャーを ネチっこくおさわり する #ruby 概要 2014/12/25 にリリースされた Ruby 2.2.0 の新規フィーチャーを ネチっこくおさわり してみます リリースノート Ruby 2.2.0 リリース | Ruby Official Ruby NEWS | GitHub Ruby 前提 下記記事で作成した環境を利用 Vagrant + CoreOS + Docker + Itamae で使い捨ての Ruby 2.2.0 環境を構築する pry を利用して、一部の新規仕様のドキュメントを参照します 1 Binding Binding#local_variables pry で doc を確認 [6] pry(main):1> ? local_variables From: vm_eval.c (C Method): Owner: Kernel
Ruboty のコードリーディングで Ruboty の仕組みを理解すると共に Ruby の設計・実装の定石を学ぶ #ruboty - Qiita
Ruboty のコードリーディングで Ruboty の仕組みを理解すると共に Ruby の設計・実装の定石を学ぶ #rubotyRubyRuboty 概要 Ruboty のコードリーディングで Ruboty の仕組みを理解すると共に Ruby の設計・実装の定石を学びます。 確認対象は、コマンドラインで ruboty を実行して Ruboty が起動するまでの部分です。 はじめに Ruboty の構成を理解するために、この解説を作ろうと思ったのですが、 Plugin による拡張などを含めた高レイヤの設計技法 適切な命名により、単一責務で分割されたメソッド群 メモ化、 alias method chain , ..etc など様々な Ruby のイディオム など、 Ruby の良い作法を 高レイヤの設計技法 から 低レイヤのイディオム まで幅広く学ぶ素材として 非常に魅力的なソフトウェアであ
GitHub Flow 図解 - Qiita
概要 Git・GitHubを利用したシンプルで強力なワークフローであるGitHub Flowを図にまとめました。 GitLabでも利用可能なFlowです。GitLabの場合は Pull Request を Merge Request に読み替えてください。 前提 実際にGitHub Flowを実践したことはありません。（2014/06/12時点） これからチームで導入予定で、メンバーとワークフローを共有するために図を作成しました。 ワークフローの誤りなどご指摘いただけると幸いです。 アクティビティ図をベースに作成してありますが、厳密な記法よりも 相手に伝わればいいかな、という点を重視しています。 基本原則 masterブランチは 常時デプロイ可能 である 機能追加、バグフィックスなどは 説明的な名前のブランチ をmasterから作成する 機能追加の例： add_user_notice (ユ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
