Page 1 of 1
[09:38:58] forcer: Software collections are a pain to use, but work, if you're stuck in RHEL6/CentOS6
[09:48:08] forcer: acosonic: foo["something"] calls the  method on the food object with one argument, the string "something". foo.something calls the method named "something" on the foo object with no arguments. You could use some tricks to handle unknown messages, but remember that most objects implement a lot of methods you would miss, then.
[09:53:59] forcer: Also, pizza. We should use "pizza" as a metasyntactic variable anyhow. It's a great word, and with most people it evokes warm and happy feelings.
[08:48:36] forcer: Just because you can do something does not necessarily mean it's a good idea to do ...
[14:41:37] forcer: sevenseacat: You said there are better resources out there - do you have any specific recommendations?
[18:02:32] forcer: mrbubble_: Views won't help you, then. You'd need materialized views. But what you describe should be fixable with an index on the timestamp. If the table gets too large (500k is not large), partitioning over timestamp is sensible - per-day or per-month are options.
[18:05:14] forcer: As far as I know, in PostgreSQL, view results/contents are not cached, using them is equivalent to just adding their code as an inner select. There's no performance advantage, only a readability advantage. If you want the contents cached, you need materialized views.
[18:07:16] forcer: mrbubble_: You can add one each. If you have only few meter_ids, it's not worth it, though. Also, try to do the calculation in Postgres, not in Ruby.
[18:26:18] forcer: When you have complex JSON objects, it's often a good idea to have a wrapper object so you can hide all the details of validation, conversion, default values, specific knowledge of the layout etc. behind some helper methods. So that the calling code does not have to concern itself with that. Separation of concerns, basically.
[19:54:57] forcer: tubbo: Thank you for the link to Sandi's talk on "all the little things", that was excellent!
[08:49:34] forcer: clorisu: This seems to be an ok intro: http://www.tutorialspoint.com/ruby/ruby_classes.htm
[08:56:47] forcer: So I'm curious. Class#method seems a common way of referencing methods in a class, but that's not Ruby syntax. Where did that syntax come from? :-)
[09:01:29] forcer: hanmac: Ah! Well, it would at least *also* refer to class methods. Do you know where the # syntax came from? Or is that just something that was used and stuck around?
[09:10:59] forcer: They probably started to wonder if they need all of #count, #count_pair, #count_key and #count_value, and then thought meh, never mind.
[17:45:08] forcer: nohitall: Kernel::p, a method that prints its arguments to stdout: http://ruby-doc.org/core-2.2.2/Kernel.html#method-i-p
[19:44:25] forcer: Mainly because they're usually not really the *same* things, just similar. And A being similar to B, and B being similar to C, does not mean that A is similar to C.
[19:59:17] forcer: I was looking for RSS feeds or feed aggregators about ruby, but found mainly RSS feed parsers and generators :-D planetrubyonrails seems dead, too. Are there any around still?
[22:06:18] forcer: nuck: A lot of the recommendations for 12factor apps are useful even outside of the web context. Not sure why that is not general best practice yet. :-)
[22:09:20] forcer: Though you can do some of that stuff - log to stdout, config via environment, etc. - quite easily with systemd already. I keep telling people writing new-style daemons for systemd is ten times easier than anything before, but I keep getting blank stares. :-D