GoとRubyの言語特性を理解して構築した“いいとこどり“アーキテクチャとは？ - Findy Engineer Lab
ファインディでは「次に学びたい言語」として注目集めるGoについて理解を深める『注目の言語Go、開発現場でどう使われる？活用企業の現場に聞く』を開催しています。 11月25日には第3回目を開催。ウォンテッドリーの竹野さん、マネーフォワードの櫻さんをお招きし、Goの特徴やメリット、採用理由について伺いました。モデレーターはファインディの大原が務めます。 パネリスト 竹野 創平さん/(ウォンテッドリー株式会社 開発チーム アーキテクト)[@Altech_2015] 2016年にウォンテッドリーに入社。プロダクトのグロースや機能開発・基盤開発を行なったのち、プロダクトの責任者としてプロダクトマネジメント・エンジニアリングマネジメントを行う。現在は開発チーム全体のアーキテクトとして、ソフトウェア・技術・組織の設計に携わっている。 櫻 勇人さん/(株式会社マネーフォワード バックエンドエンジニア[@y
RubyGems 開発速習会 - Qiita
この記事は、RubyGem 開発速習会@Wantedly の資料として作られたものです この資料は、 Ruby 2.3.1 RubyGems 2.5.1 Bundler 1.12.4 の環境で執筆されました。 この速習会のゴール gem を一から作れるようになる ただ作るだけじゃなく、テスト駆動開発を取り入れた効率のよい開発ができるようにある 開発支援系のサービスに詳しくなる gem とは gem は、最もメジャーな Ruby ライブラリの形式です。 Ruby on Rails も1つの gem として提供されており、rails gem の中でもまた多くの gem が利用されています。 現在公開されている Ruby のソフトウェアや Ruby on Rails 上の Web サービスは、多くの gem を組み合わせることで成り立っているのです。 ちなみに www.wantedly.com
Rubyでforkを利用したマルチプロセスでコアを使い切りたい気持ち - Qiita
Rubyで書かれたちょっと重たいバッチ処理があって速くする必要があったので、fork(2)とpipe(2)を使ったマルチプロセス化でコアを活かした並列処理に書き直した話します。 以下の記事に詳しく書いてあるので、TL;DRはそちらを見てな? Forking and IPC in Ruby, Part I Forking and IPC in Ruby, Part II なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会 Threadじゃいかんの? — GILについて 並行プログラミングとしてまず最初に思いつくのはマルチスレッド化ですが、RubyにおいてはGVL(Giant VM lock)があるためマルチコアを活かすことは難しいのです。 ネイティブスレッドを用いて実装されていますが、 現在の実装では Ruby VM は Giant VM lock (GVL) を有し
enhanced-ruby-modeの概説 - Qiita
enhanced-ruby-modeはEmacsのメジャーモードのひとつ。標準で付属しているruby-modeの代替を目指して開発されている。Ripper（Rubyの標準添付ライブラリ）によって構文解析を行うのが特徴。 機能 インデント シンタックスハイライト リアルタイムの文法チェック よいところ Ripperを使っているので、厳密な構文解析を行わないruby-modeではパースに失敗するコードでも正しく扱うことができる。 わるいところ たまにパースが止まる。 ruby-modeとの互換性 enh-ruby-forward-sexp, enh-ruby-backward-sexpなどのコマンドの振る舞いがruby-modeと異なる。 シンタックスハイライトの色の対応が一部異なる。 開発状況 2010年にGeoff Jacobsen氏によってjacott/Enhanced-Ruby-Mod
ActiveRecordを速くしたいだけの人生だった - Qiita
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
Ruby でラインメモリプロファイラ - Qiita
プロファイラ好きなモニタの前の皆さんこんにちは。@sonots です。この記事では、Ruby コードのどの行がどのぐらいメモリを消費しているか調べる方法を紹介します。 オブジェクトの数を数える Ruby には ObjectSpace というオブジェクトの情報を集めたり操作したりする module があります。 このモジュールの each_object メソッドを使用すると、RubyVM 上の全てのオブジェクトを取り出すことができます。 このメソッドを使って、以下のようなコードを書くと、実行した地点で、RubyVM 中にどのクラスのオブジェクトが何個存在しているのかカウントできたりするわけです。興味深いですね! ObjectSpace.each_object.inject(Hash.new 0) {|h,o| h[o.class]+=1; h } #=> {Class=>241, Strin
RubyでBoolClassではなくTrueClass/FalseClassな理由を理解する - Qiita
@mattn_jp BoolClassを入れるとkind_of?でチェックしたくなってduck typingを阻害するから。 — Yukihiro Matsumoto (@yukihiro_matz) 2015, 12月 4 30回くらい読みなおしたけど何のことを言っているのか分からなかったので、周りのRubyistに質問して理解を深めたメモ。 まずDuck Typingというのは、Wikipediaによると ダック・タイピング（duck typing）とは、Smalltalk、Python、Rubyなどのいくつかの動的型付けオブジェクト指向プログラミング言語に特徴的な型付けの作法のことである。それらの言語ではオブジェクト（変数の値）に何ができるかはオブジェクトそのものが決定する。つまり、オブジェクトがあるインタフェースのすべてのメソッドを持っているならば、たとえそのクラスがそのインタフェ
gemspecとGemfileの役割をはっきりさせておく
gemspecとGemfileの役割をはっきりさせておく Original: URL: Clarifying the Roles of the .gemspec and Gemfile Date: Thursday, December 16th, 2010 at 9:41 pm Translation: URL: gemspecとGemfileの役割をはっきりさせておく (Not Found) Salvaged from Internet Archive 要約 GemfileGemfile.lockは依存関係を厳密に指定するのが目的なので、アプリケーションを開発するときはレポジトリにチェックインすべき。 一方Gemを開発するときは依存関係を緩やかに定義し柔軟性を持たせることが重要なポイントなので、GemfileGemfile.lockはレポジトリにチェックインしてはいけない。 他、Gemf
[その1] Ruby 2.0のガベージコレクタを使いこなす - ワザノバ | wazanova
http://samsaffron.com/archive/2013/11/22/demystifying-the-ruby-gc Ruby 2.1のガベージコレクタ (GC) については、「RubyとPythonの違いからガベージコレクタを理解する [その1] [その2] 」で取り上げましたが、今回は、DiscourseのSam SaffronがまとめているRuby 2.0のGCを利用するにあたっての学びを紹介します。 1) Heaps of heaps MRIはヒープにRVALUEとして知られているオブジェクトをもつ。各ヒープは約16KB。RVALUE構造体は、マシンのアーキテクチャによって異なる量のメモリを消費する。x64マシンでは40 byte、x32マシンではサブアーキテクチャー次第で20 byteから24 byte。RVALUEはマジカルなC構造体で、Rubyの様々なローレベル
Railsの基本理念 : Railsの生みの親が掲げる8つの原則 | POSTD
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
leah blogs: Introducing Rack
Dabbling in my own web framework experiments, I noticed that there is a lot of code duplication among frameworks since they essentially all do the same things. And still, every Ruby web framework developer is writing his own handlers for every webserver he wants to use. Hopefully, the framework users are satisfied with that choice. However, in essence, dealing with HTTP is rather easy. In the end,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
