lupine

Activity Graph

Page 1 of 15 | Next »

2019-06-16

[16:35:39] lupine: Remote host closed the connection
[16:36:49] lupine: has joined #RubyOnRails
[16:36:49] lupine: has joined #ruby

2019-06-15

[06:27:27] lupine: *.net *.split
[06:37:51] lupine: has joined #RubyOnRails
[06:37:54] lupine: has joined #ruby

2019-06-14

[03:22:01] lupine: *.net *.split
[03:38:01] lupine: has joined #RubyOnRails
[03:38:05] lupine: has joined #ruby

2019-06-03

[07:41:57] lupine: *.net *.split
[07:53:21] lupine: has joined #RubyOnRails
[07:53:27] lupine: has joined #ruby
[20:12:01] lupine: Disconnected by services

2019-06-02

[13:18:42] lupine: Remote host closed the connection
[13:19:52] lupine: has joined #RubyOnRails
[13:19:52] lupine: has joined #ruby
[21:29:19] lupine: > sudo gem install
[21:29:22] lupine: that's the wrong big
[21:29:55] lupine: you probably want to take our your hard drive, set fire to it, and start again
[21:30:23] lupine: a chruby/rvm/etc-installed ruby will help you to manage you ruby and gem dependencies relatively sanely
[21:30:33] lupine: all hope is lost, then
[21:33:01] lupine: we should probably set up a gulag for container users
[21:36:25] lupine: it's not, though, is it?
[21:38:45] lupine: as I said, step 1 is some ruby version manager or another
[21:38:53] lupine: step 2 is `gem install bundler`, then `bundle install`

2019-05-24

[20:37:31] lupine: Ping timeout: 250 seconds
[20:44:19] lupine: has joined #RubyOnRails
[20:44:19] lupine: has joined #ruby

2019-05-23

[08:11:02] lupine: Remote host closed the connection
[08:12:11] lupine: has joined #RubyOnRails
[08:12:11] lupine: has joined #ruby

2019-05-20

[17:31:30] lupine: just run it in thin and be done with it
[18:06:44] lupine: there's plenty of evented async frameworks for ruby, but one does have to question why you'd bother when real threads exist
[18:06:51] lupine: event-machine used to be popular

2019-05-19

[11:42:21] lupine: you can put them anywhere you want, syntactically
[11:42:32] lupine: 1_0_00_000 perhaps
[11:45:28] lupine: particularly, consider fractional cents
[11:45:43] lupine: as superman proved, you will have to handle them from time to time
[20:54:55] lupine: nevada1: consider Array#pack

2019-05-16

[16:46:40] lupine: perhaps it's a rails application listening on a socket
[19:15:20] lupine: _why's poignant guide is the one, the only, the true source of ruby learnings
[19:15:25] lupine: chunky bacon me
[22:16:01] lupine: basic sanity check: see if it shows up when find it by id, and then by the two args directly
[22:16:08] lupine: when you find it by*
[22:19:40] lupine: so `Unit.where(non_revenue_status_id: 6, null_unit: nil)

2019-05-07

[15:48:15] lupine: Net: latest RoR can pool connections across threads, IIRC
[15:48:34] lupine: other than that, you can switch your testing strategy from transactions to truncate or delete
[15:49:43] lupine: database_cleaner supports the other strategies natively, we do the same in our own codebase
[15:49:57] lupine: I think we stopped using transactions altogether due to the other weirdnesses they introduce into the test suite
[15:50:04] lupine: (re-using IDs, etc)
[15:50:35] lupine: are you using database_cleaner at present?
[15:51:10] lupine: if so, it's just: DatabaseCleaner.clean_with(:truncation) instead of DatabaseCleaner.clean_with(:transaction)
[15:52:44] lupine: you could. what we do is specify rspec traits and assign different database-cleaner strategies to each
[15:52:56] lupine: config.before(:foo), etc
[15:53:12] lupine: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/support/database_cleaner.rb

2019-05-03

[04:14:07] lupine: Ping timeout: 250 seconds
[04:21:31] lupine: has joined #RubyOnRails
[04:21:31] lupine: has joined #ruby

2019-04-29

[21:07:49] lupine: Ping timeout: 250 seconds
[21:12:08] lupine: has joined #RubyOnRails
[21:12:08] lupine: has joined #ruby
[21:23:08] lupine: Remote host closed the connection
[21:24:17] lupine: has joined #RubyOnRails
[21:24:17] lupine: has joined #ruby

2019-04-26

[12:05:31] lupine: SSE is *really* simple for unidirectional stuff
[15:15:59] lupine: Momentum: probably easiest to just modify the gemfile to say 2.6.3

2019-04-22

[12:54:17] lupine: my favourite ruby+js primer: https://www.destroyallsoftware.com/talks/wat
[15:09:34] lupine: all of ruby is one giant SRP violation

2019-04-18

[18:41:19] lupine: yeah, that works fine
[18:41:26] lupine: everything in ruby is an expression
[18:44:25] lupine: ctrl+c will get you out of most irb-related fails
[18:44:49] lupine: related to case - anyone seen the upcoming ` case...in` pattern-matching thing?
[20:12:36] lupine: baweaver: does it make your spine crawl as much as mine? ^^

2019-04-13

[16:50:12] lupine: *.net *.split

2019-03-29

[12:51:53] lupine: RubyGuyNeedsHelp: f.rewind; f.write(...)
[12:52:07] lupine: you'll need to open it 'r+' and hope nobody else is concurrently editing it
[12:52:42] lupine: also, this approach only makes sense if your downcased data is the same number of bytes. this is a safe assumption for ascii files, but not generally safe

2019-03-26

[23:36:48] lupine: dependencies. not even once.

2019-03-24

[03:40:43] lupine: Read error: Connection reset by peer
[03:42:01] lupine: has joined #ruby
[03:42:01] lupine: has joined #RubyOnRails

2019-03-21

[11:24:59] lupine: Ping timeout: 250 seconds
[11:40:28] lupine: has joined #ruby
[11:40:28] lupine: has joined #RubyOnRails

2019-03-17

[03:11:07] lupine: Ping timeout: 240 seconds
[03:13:32] lupine: has joined #ruby
[03:13:32] lupine: has joined #RubyOnRails

2019-03-15

[01:02:28] lupine: Ping timeout: 264 seconds
[01:06:47] lupine: has joined #ruby
[01:06:47] lupine: has joined #RubyOnRails
[18:44:43] lupine: very normal, in rails 3(?)+
[18:44:56] lupine: in rails2, for sure, it was a direct database update. these days, that's called `update_columns`
[18:45:30] lupine: if you have an `ActiveRecord::Relation`, then `update_all` will be a database update that skips callbacks, etc
[18:45:59] lupine: hmm, sorry, I missed the parent / child aspect of the question
[18:46:11] lupine: is updating the child triggering a save of the parent via `autosave: `, I wonder

2019-03-03

[01:36:41] lupine: Ping timeout: 250 seconds
[01:45:46] lupine: has joined #ruby
[01:45:46] lupine: has joined #RubyOnRails

2019-02-28

[11:21:10] lupine: can I ask a model to reload only a single column value?
[11:49:22] lupine: yeah, I'm not finding it. so I'm just querying the database for the value directly :D
[11:49:46] lupine: (it's something of a self-made problem, since a bit earlier in the flow we update the database directly without going through the model)

2019-02-26

[22:58:57] lupine: hard problems #3, after cache invalidation and naming things

2019-02-12

[11:23:38] lupine: there's also the dirty `extend self` tricfk
[11:23:39] lupine: I wouldn't
[11:26:00] lupine: I really wouldn't :D
[11:27:03] lupine: it will lead to bad code
[11:27:29] lupine: class-level attributes invariably do, no matter how you implement them
[11:27:54] lupine: `extend self` is particularly bad because you'll invariably find that someone eventually includes the module elsewhere, and then you'll have two conflicting contexts for the same methods
[11:28:11] lupine: no, they're quite different
[11:29:26] lupine: class << self is better, in that it's more focused and the created methods won't be shared with anything you later include the module into, but I'd still generally avoid it
[12:44:34] lupine: those of us using the danger gem - how do you test the code in your Dangerfile and danger plugins ?
[12:58:41] lupine: oh dear :(

2019-02-07

[15:48:33] lupine: simplifies deployment
[15:49:55] lupine: I don't find a useful distinction TBH. you have a file that the environment interprets, and somewhere in that file is binary data representing your ruby code, surrounded by the full ruby executable + runtime
[15:50:25] lupine: whether that's a .msi or .deb or an executable with mruby + your script, it's all the same

2019-01-22

[01:03:33] lupine: you've probably got an ActiveRecord::Relation to run `each` on
[01:03:46] lupine: normally this is good, but if it's bad, you can always explicitly `.to_a` at the right point
[15:48:50] lupine: Quit: No Ping reply in 180 seconds.
[15:50:31] lupine: has joined #RubyOnRails
[15:50:32] lupine: has joined #ruby
[15:53:08] lupine: Excess Flood
[15:55:59] lupine: has joined #RubyOnRails
[15:56:00] lupine: has joined #ruby

2019-01-20

[00:27:57] lupine: the usual, you know
[23:37:45] lupine: end capitalism

2019-01-19

[19:58:19] lupine: there's a gem that lets you do "foo".color(:red)
[19:59:20] lupine: I don't think I'm thinking of https://github.com/fazibear/colorize but it also exists
[21:19:28] lupine: Remote host closed the connection
[21:46:11] lupine: has joined #RubyOnRails
[21:46:12] lupine: has joined #ruby
[23:34:07] lupine: File.join(Dir.pwd, __FILE__)

2019-01-12

[23:42:26] lupine: just because you can, doesn't mean you should

2019-01-11

[21:04:51] lupine: weird, I'd expect that to work
[21:06:45] lupine: this works: define_singleton_method(:foo, method(:foo))
[21:07:17] lupine: where `method(:foo)` gets a reference to a method created with `def`
[21:08:18] lupine: If I use a block rather than pass a method, then `yield`fails with `LocalJumpError`, which is really unexpected
[21:09:11] lupine: &>> def foo; yield ; end ; a = Object.new ; a.define_singleton_method(:foo, method(:foo)) ; a.foo { puts 'ok' ; 'ok' }
[21:09:34] lupine: &>> a = Object.new ; a.define_singleton_method(:foo) { yield } ; a.foo { puts 'ok' ; 'ok' }
[21:09:55] lupine: thanks ruby, very wise

2019-01-08

[01:32:22] lupine: Ping timeout: 250 seconds
[01:45:18] lupine: has joined #ruby
[01:45:19] lupine: has joined #RubyOnRails

2019-01-07

[11:20:08] lupine: it seems that eager loading doesn't pull `app/views/*` into memory at boot-up. Is there a setting or gem that would cause this to happen?
[11:23:07] lupine: deployments aren't atomic, so sometimes we have a process running with the old code, but new views
[11:23:31] lupine: if the process read the view files into RAM at bootup, that would stop being a problem
[11:31:33] lupine: sevenseacat: it's a consequence of not stopping the process while a package install is ongoing, a decision taken to minimise downtime
[11:31:58] lupine: .deb packages can use either mode when they include a service - stop it while upgrading, or not.
[11:32:24] lupine: if you don't, the files are updated while the old process is still running, then once the extraction is complete, the service is restarted. good for uptime, bad for correctness :/
[11:32:34] lupine: -> https://gitlab.com/gitlab-org/gitlab-ce/issues/55593

2019-01-01

[17:43:49] lupine: nothing quite so insane, but sure, you can define the "==" method for most classes
[17:43:50] lupine: (not all of them)

2018-12-30

[15:36:47] lupine: ACTION calls the file on disk `(eval)`
[15:42:54] lupine: prove it ;)
[17:38:49] lupine: ignore 95% of it, focus on building something small

2018-12-28

[14:50:08] lupine: I don't like either
[19:25:17] lupine: each_with_index
[19:26:18] lupine: >> [6,1,2,3].each_with_index { |a,b| puts "#{a} #{b}" }
[19:26:39] lupine: >> puts [6,1,2,3].each_with_index { |a,b| puts "#{a} #{b}" }
[19:26:51] lupine: works fine locally, anyway, and rings a bell from 1.8.
[19:27:01] lupine: &>> [6,1,2,3].each_with_index { |a,b| puts "#{a} #{b}" }
[19:27:25] lupine: also consider more words per line, and fewer imprecations per minute

2018-12-26

[21:59:24] lupine: maybe you want private_constant. I wouldnt though
[22:26:32] lupine: you really need a process boundary to protect anything from malicious users with eval rights in ruby
[23:08:26] lupine: oh very nice

2018-12-20

[01:23:27] lupine: Company.includes(:employees).all or so
[01:23:57] lupine: but you'd best not be writing software for recruiters
[01:24:02] lupine: that is truly of the devil

2018-12-10

[14:24:33] lupine: Remote host closed the connection
[14:28:44] lupine: has joined #ruby
[14:28:45] lupine: has joined #RubyOnRails

2018-11-26

[22:26:22] lupine: Remote host closed the connection
[22:29:01] lupine: has joined #RubyOnRails
[22:29:01] lupine: has joined #ruby

2018-11-21

[05:17:36] lupine: Ping timeout: 260 seconds
[05:26:46] lupine: has joined #RubyOnRails
[05:26:46] lupine: has joined #ruby

2018-11-18

[01:35:46] lupine: Ping timeout: 260 seconds
[01:48:38] lupine: has joined #RubyOnRails
[01:48:38] lupine: has joined #ruby

2018-11-06

[22:20:56] lupine: downsides of pry: not in stdlib

2018-11-03

[11:53:30] lupine: just use cookies

2018-11-02

[23:08:05] lupine: ACTION waves from shetland

2018-11-01

[08:54:05] lupine: Ping timeout: 276 seconds
[09:01:57] lupine: has joined #RubyOnRails
[09:01:57] lupine: has joined #ruby
[23:58:45] lupine: ruby mostly does pass by roulette
[23:58:59] lupine: never know what you're going to get
[23:59:25] lupine: come on, it deserves a sensible chuckle at minimum

2018-10-28

[22:17:12] lupine: the capitalists strike again

2018-10-25

2018-10-24

[02:57:10] lupine: openstruct: I'd expect that to get very messy, very quicklyt
[02:57:27] lupine: can you split into two separate processes, one for each version, each with their own Gemfile ?

2018-10-23

[16:44:12] lupine: doesn't work without JS :/

2018-10-20

[22:52:39] lupine: so don't?
[23:07:26] lupine: so don't return nil
[23:08:11] lupine: aww, `undef nil` doesn't work :D

2018-10-18

[12:48:59] lupine: Remote host closed the connection
[12:51:12] lupine: has joined #ruby
[12:51:13] lupine: has joined #RubyOnRails

2018-09-19

[11:34:07] lupine: Remote host closed the connection
[11:35:16] lupine: has joined #RubyOnRails
[11:35:16] lupine: has joined #ruby

2018-09-10

[23:13:39] lupine: anime4christ: it doesn't have type information associated with the `custom_at` name
[23:14:19] lupine: well, does it give you a `Time` object at-all?
[23:14:33] lupine: mysql, postgres?
[23:14:57] lupine: maybe you can specify a type in the AS part
[23:16:46] lupine: just guessing TBH

2018-09-04

[05:49:26] lupine: Remote host closed the connection
[05:50:51] lupine: has joined #RubyOnRails
[05:50:51] lupine: has joined #ruby

2018-09-03

[21:29:05] lupine: FWIW, we looked at this kind of memoization magic in our codebase, and ran a mile. We just `include Utils::StrongMemoize` and do def x ; strong_memoize { ... } ; end` instead
[21:29:29] lupine: just because you can, does not mean you should
[21:30:08] lupine: but yes, it's traditional(ish) OO, not prototypes
[21:30:34] lupine: you can emulate javascript behaviour in ruby quite easily by disdaining classes and using hashes everywhere
[21:30:54] lupine: you can even add prototypes with the `Hash.new {|h,k| h[k] = ... }` idiom
[21:31:10] lupine: or, you know, you could just write in javascript. nodejs exists for people who like to do that
[21:31:27] lupine: right, so it's not surprising that some things are different
[21:31:38] lupine: you wouldn't want to though :D
[21:32:33] lupine: here's an alternative. How about a Memoizer class that acts as a facade around an object and memoizes methods going through it?
[21:34:56] lupine: apeiros: one could optionally implement a list of memoable methods
[21:38:54] lupine: looks a bit like https://gitlab.com/snippets/1750773
[21:39:25] lupine: 'though ISTR you should implement responds_to or something as well
[21:40:06] lupine: heh, my solution works for that
[21:48:44] lupine: note that `@foo ||=` doesn't work well if hte result is `false` or `nil`, yet still expensive to compute
[21:49:42] lupine: aye, it's easily forgotten is all
[21:50:15] lupine: I still like mine. the internal vs. external question is by the by - ruby doesn't store data like that
[21:50:34] lupine: all we're asking is whether the memozied class holds a reference to its memoizer or not
[21:51:47] lupine: it can be useful to hold such a reference - for instance, you might want to clear memoized values based on some interaction or another. but you can always include the reference if you need it
[22:05:59] lupine: JJonah: one option would be to override the `new` method to return an always-memoized instance
[22:06:11] lupine: or to add a `build_memoized` class method that does the smae
[22:06:16] lupine: lots of ways to do this
[22:29:19] lupine: I've got production experience of jruby. it's pretty solid
[22:29:47] lupine: sometimes surprising things happen, and the gap between jruby and cruby is a lot narrower now than it was back then. I probably wouldn't use it again

2018-09-01

[17:56:31] lupine: *.net *.split
[18:02:19] lupine: has joined #RubyOnRails
[18:02:19] lupine: has joined #ruby
[22:43:25] lupine: 1.8 -> 1.9 was a bigger jump