Activity Graph

Page 1 of 13 | Next »


[17:13:22] mordof: Ping timeout: 265 seconds


[21:27:00] mordof: has joined #RubyOnRails
[21:31:25] mordof: after a .new, not when it's going to put the record in the database
[21:31:25] mordof: i've got a little bit of a chicken and egg situation happening. i've got a model with a string on it - which validates the presence of that string. but the first time it's saved, that string will be empty and it should generate a new string. i was using before_validation on :create, but that's happening even if i just call .validate on the record
[21:31:58] mordof: is there any spot where i can have a callback on a model that happens before validation, but only from a call where it's trying to save it for the first time to the database? using rails 5
[21:32:23] mordof: that happens after validation i thought
[21:33:40] mordof: validation is one of the first things that happen, unless i'm mistaken.
[21:33:55] mordof: that'd be false for the first time creating it though wouldn't it?
[21:36:04] mordof: ah, mb.. validates presence and unique* sorry. think bitly with generating a url for something. that's kind of what i'm trying to do
[21:36:38] mordof: i want to create a new record, and give it a path, but that path needs to be unique.. and only generated when a record is going to be committed to the database
[21:37:50] mordof: hmmm maybe i'm just approaching this wrong..
[21:38:42] mordof: mlt-: i'll keep it in mind.. right now that doesn't quite fit what's in my head about how to tackle this... but i'm potentially just locking myself in a corner using both a generator and a validator
[21:43:30] mordof: that field should only be written once, yes. other details can be updated but i don't think that's relevant.
[21:44:31] mordof: ah - so instead of having a normal validator for presence and unique, just have the before_validate do both and ensure it makes sense
[21:44:48] mordof: mlt-: that also makes for some ridiculously long urls
[21:46:04] mordof: hmm yeah if i'm doing that.. then it makes sense to put it in a before_create so that it only happens in that step then
[21:46:32] mordof: before_validation isn't scoping to the create even though the docs suggest it should, so it's problematic to try and use that


[15:34:24] mordof: has joined #RubyOnRails
[15:37:03] mordof: i've got nginx proxying to unicorn with rails. currently if a request takes too long, our nginx times out (we get a 404.. not sure if that's our config or default) - what is the expected behavior of unicorn/rails in that situation? our production logs just stop after that (for that request). is that what we should be seeing?
[15:38:06] mordof: allcentury: looks like our config is set to 60s
[15:40:13] mordof: allcentury: so let's say it goes over both timeouts. ignoring the actual response to the browser(client.. w/e) - would it make sense for the rails production.log to just not spit out anything further for that request?
[15:40:39] mordof: currently looking through my unicorn logs
[15:41:39] mordof: allcentury: found one - it does
[15:41:54] mordof: allcentury: lists a SIGKILL and to which worker it brings down. then shows when it's ready again
[15:42:23] mordof: so that means it's 100% making sense that the production.log just stops
[15:42:26] mordof: because it's a kill -9
[15:45:35] mordof: allcentury: awesome. so that properly explains the production logs, and those timeouts. the 404 i guess is a different issue. can i ask how you've got yours configured (roughly) to show a 503?
[16:18:54] mordof: allcentury: looked into the error page grouping. turns out we're doing that for all of our 5xx codes - just not 404. We've got a fancy page we use for errors - and you're right, it'd be nice to have it grouped under that. my one concern is that for any 5xx we have rails set up to email us when there's a problem.. here, we wouldn't get any notificat
[16:18:55] mordof: ion. Should i move the timeout into a rails middleware so I can dispatch emails properly?
[16:19:02] mordof: not sure if it's appropriate to move the timeout handling into rails
[16:19:36] mordof: ACTION looks into if unicorn can do that
[16:22:37] mordof: allcentury: makes sense. i think it'd be nice to log it somewhere though.. to show the request details and then have it be a stat in our monitoring dashboard or something..
[16:23:20] mordof: allcentury: some of our larger clients end up getting timeouts in lots of different places because stuff just wasn't built with that in mind. right now the only way we know if it happens is when they tell us directly, lol... not a good approach
[20:32:23] mordof: Remote host closed the connection


[14:30:55] mordof: Remote host closed the connection
[15:48:28] mordof: has joined #ruby


[15:46:05] mordof: has joined #ruby


[14:55:36] mordof: has joined #RubyOnRails
[14:57:20] mordof: question about developer environments: has anyone here ever worked with a development environment that is ENTIRELY located somewhere like AWS - and then used sshfs, or some form of network drive to make the files available locally to work with your editor?
[14:57:54] mordof: i'm wondering about options for putting all of the running processes into a remote machine, so the dev machines i have don't have to do so much processing
[14:58:13] mordof: at this point, the thought is *without* a GUI on the remote server
[15:22:26] mordof: fryguy: so you did things like vim - or an actual gui on the server?
[15:22:47] mordof: fryguy: are there any better alternatives for remote file system that oyu know of?
[15:23:07] mordof: nevermind - that last question is kind of off-topic here... this whole thing is a stretch
[15:24:29] mordof: lupine: nope, not at all
[15:24:54] mordof: lupine: we just have crappy desktops that we're working on - and work doesn't seem to care about the money we spend on aws... but they don'tw ant to shell out for good computers, lol
[15:25:16] mordof: so if i optimize our production environment a bit, i can provision good vm's to push most of our development needs up to
[15:26:51] mordof: fryguy: our office latency can be kind of trash at times... that's probably gonna cause problems for most file system situations i guess
[15:27:49] mordof: that's why my thoughts went away from things like vim, and towards something that could *potentially* be pushed to the background a bit more
[15:29:34] mordof: fryguy: thanks for the feedback :) looks like some more investigation is in order
[15:30:35] mordof: fryguy: indeed - but with latency spikes that's just not gonna be a good experience
[15:31:44] mordof: the internet is mostly reliable, but latency fluctuates quite a bit...
[16:49:56] mordof: Quit: - A hand crafted IRC client


[15:32:58] mordof: Quit: - A hand crafted IRC client


[20:31:35] mordof: has joined #RubyOnRails
[20:32:38] mordof: I'm trying to take a hash passed in a variable for my view, and use a tag helper (tag :div, class: 'foo', data: @my_obj) with nested hashes. is anyone familiar with how i would accomplish this? the nesting is casting the hash to a string and then escaping it...
[20:42:58] mordof: nevermind.. it's json serialised. i find that to be rather strange, but it still works


[19:29:44] mordof: has joined #RubyOnRails
[19:30:42] mordof: using rails 5.0.2, anyone know how i would manage to call a content_for - starting the process in a controller? (can i just call a render on a random partial?)
[19:31:18] mordof: so... that might be too simple an example for what i'm trying to do
[19:32:06] mordof: essentially I'm trying to create a class that a person can initialize within a controller method (responding to a route action). that class would then set up a content_for so a bit of html would be spit out in the footer
[19:32:55] mordof: some way that i can get something in the DOM as a result of using this class in the controller
[19:33:01] mordof: without the dev needing to specify that each time
[19:34:09] mordof: Guest73301: does execute not work?
[19:36:50] mordof: Guest73301: would this help any?
[19:38:03] mordof: those are more to copy the data into a table i think.. but could the same principle be used to get it out
[19:38:47] mordof: there's also the suggestion (last answer) of using psql and running it as a system command to export to the csv
[19:39:00] mordof: but that means depending on psql being available on the server
[20:25:21] mordof: arup_r: heh, sorry about that. just trying to get basically a div with a bunch of data attributes into the view when i initialize a class i'm making inside any controller in my rails application
[20:26:37] mordof: at the moment i ended up settling for making use of a helper method included in ApplicationController called 'prep_courier', so i can call my class like so: prep_courier and the prep_courier takes what it needs and puts it into an instance variable, where view helpers can then pick those up and render the appropriate div d
[20:26:41] mordof: but it's so clunky
[20:28:00] mordof: my original attempt was to have a content_for :courier_details in my footer of my layout, and was looking for a way that my Courier class could just call content_for and have it show up in that spot
[20:28:28] mordof: since that would remove the need for an extra controller helper, a view helper, and a partial
[21:05:27] mordof: it depends on what file you're editing. some of them will reload (it may depend on configuration? not sure)
[21:06:41] mordof: config.cache_classes = false <- make sure that's in your config for development environment first of all
[21:07:11] mordof: config.action_controller.perform_caching = false and that... ? i guess
[21:07:41] mordof: this is your rails config i'm talking about though
[21:10:49] mordof: using a random file to flag if it should cache requests i guess
[21:12:05] mordof: loads the file to generate details - but uses the in-memory loaded one for execution...
[21:12:13] mordof: i don't know enough about how things are done to help any further :( sorry
[21:12:42] mordof: this is a rails craziness thing, heh
[21:14:48] mordof: anyway i gotta run. good luck
[21:15:59] mordof: Quit: - A hand crafted IRC client


[12:52:49] mordof: Quit: - A hand crafted IRC client


[18:01:51] mordof: has joined #RubyOnRails


[03:25:58] mordof: Quit: - A hand crafted IRC client
[15:11:01] mordof: has joined #RubyOnRails
[17:10:12] mordof: so nginx proxy is still the desirable way to handle that?
[18:45:11] mordof: Quit: - A hand crafted IRC client


[23:11:17] mordof: has joined #RubyOnRails
[23:12:01] mordof: does anyone know of a good example of implemention a quick back and forth with action cable? all examples i see either leave out javascript sending messages back, or something is broken, or involves the database, etc... and i'm having difficult pulling the pieces out that i need
[23:16:58] mordof: oh nevermind, i think i've got it figured out
[23:18:07] mordof: was getting a maximum stack exceeded - because i named my method 'send' -.-


[21:00:32] mordof: Quit: - A hand crafted IRC client


[15:12:17] mordof: Quit: - A hand crafted IRC client
[17:44:09] mordof: has joined #RubyOnRails
[17:44:19] mordof: this is such an annoying problem to resolve....
[17:44:40] mordof: Trying to run an rspec unit test for what we call "staging" - and in that process, a postgres table gets renamed
[17:45:24] mordof: so I basically do TableName.count == 0, postgres_conn.exec("ALTER TABLE table_names RENAME TO foo"); and because i've done a count initially, the alter table gets denied an exclusive lock by postgres, so it just hangs
[17:45:46] mordof: if i comment out the .count == 0, everything works fine


[13:23:52] mordof: our stuff is all in amazon, so we just have regular snapshots of the disk the db is on
[13:24:04] mordof: ACTION chimes in just to show variety of ways to deal with it
[13:24:50] mordof: in that case i'd probably just pgdump to a backup drive or something with a cron task
[13:25:08] mordof: no kidding, lol
[13:26:14] mordof: especially at 3-5mb a piece
[13:26:40] mordof: 420mb for 7 days worth of backups
[13:31:59] mordof: francuz: unless you're running something with crazy high load on the db, or really need some form of redundancy - the size of your database won't need it's own box for quite some time
[13:32:39] mordof: francuz: you can also just add a really small hard drive where the database stores the data, and do snapshots of that drive itself (connected to the same server)
[13:33:02] mordof: if the vps environment you're in allows you to add individual hard drives
[14:01:39] mordof: the question, restated, was basically just "is it ok to make private methods in models?" the answer being, yes - whenever something isn't explicitly needed to be public, make it private
[14:02:11] mordof: that's the way i understood it anyway *shrugs*
[14:53:32] mordof: has joined #ruby
[14:54:43] mordof: we're currently running ruby 2.3.1 in production, and having issues with lambdas and arguments with default values, so we're upgrading to 2.3.4. I saw this on the release for 2.3.4 "An API incompatibility has been found for Ruby 2.3.4. It is the accidental removal of the API function rb_thread_fd_close" Can anyone help me understand what this
[14:55:05] mordof: there is a patch for it, but i'm wondering what I should look out for, if anything, since that is mentioned
[15:03:16] mordof: centrx: struggling to find a good changelog from ruby 2.3.1 up to ruby 2.4.1 in human terms related to the regular ruby code, not the commit log, lol
[15:03:20] mordof: otherwise it'd be an easier choice
[15:04:59] mordof: the patch versions don't change anything though right? so really i should just be looking for an article that shows what's different between ruby 2.3 and 2.4?
[15:06:23] mordof: 2.2 had some stuff that completely broke our application (though that may had been a patch fix which resolved those)
[15:06:32] mordof: so we skipped that version entirely, heh
[15:07:07] mordof: regardless - i'll check out the differences, thanks :)
[15:19:23] mordof: I'm a little nervous about the changes to the Hash, but it looks like it still preserves order (we're depending on that in some places) so i guess we'll just go for it and see how that goes
[15:19:31] mordof: i like the potential speed increase though
[15:23:17] mordof: havenwood: cool, thanks for the confirm. i thought that's how it looked with the explanation, but was kinda difficult to tell as i'm not terribly familiar with how the doubly linked list implementation preserved/set order of elements either
[15:26:04] mordof: splats in keyed parameters for methods
[15:26:21] mordof: the new parameter definition style for methods*
[15:26:33] mordof: it wasn't passing the values into the method properly like 2.1 or 2.3 were
[15:26:36] mordof: so we just skipped 2.2
[15:28:33] mordof: i don't remember the exact situation, it was a weird edge case for how we were calling something... so it ended up being a *args that came from one method, passing it through to another - both using the new parameter definition....
[15:29:46] mordof: the final result was that, instead of the method being called with it matching the key: values properly, it tried to pass everything in as the first key'd value... so then it was complaining that the other keys had no values
[15:30:02] mordof: meanwhile the data being passed in clearly had all the keys satisfied
[15:31:49] mordof: at the time, we weren't trying to do a full production upgrade. we were in the process of bumping up from 2.1, and one of our developers was running 2.2... i think a bunch of us were testing out 2.3 on our dev machines but he upgraded a bit earlier before 2.3 was available
[15:32:03] mordof: so he encountered some oddities, and we just said "whatever, 2.3 is already here and it works.. so ditch 2.2"
[15:33:24] mordof: agreed - everythign has been pretty smooth i guess... we usually upgrade rails at the same time, so that's where a lot of the craziness comes from, lol
[17:15:34] mordof: whoever told me the update to ruby 2.4 from 2.3 wasn't big lied, lol
[17:16:55] mordof: Fixnum deprecated *sighs*
[17:16:58] mordof: that breaks soo many things
[17:17:31] mordof: Fixnum class itself is deprecated in ruby
[17:17:34] mordof: can't be used anymore
[17:18:31] mordof: hrm.. right.. i may just be panicking/an idiot here... that means it still functions as normal for the time being then right?
[17:19:33] mordof: k... 0.is_a? Fixnum still evaluates to true
[17:19:38] mordof: ACTION sighs a giant sigh of relief
[17:20:48] mordof: ACTION nods
[17:21:04] mordof: apeiros: gems are the main concern here. i'm not referring to Fixnum anywhere in our code
[17:21:26] mordof: it triggered some pretty big version bumps on a number of gems that could be pretty volatile
[17:21:28] mordof: so i panicked
[17:22:22] mordof: ACTION runs rm -Rf * inside his working directory
[17:22:34] mordof: ACTION leaves work permanently
[17:22:52] mordof: ACTION deactivates the aws account
[17:23:01] mordof: ACTION deletes source control
[17:23:34] mordof: elasticsearch version bump... 1.0.14 -> 5.0.4 ... :/
[17:23:38] mordof: i'm not sure how i feel about this, lol
[17:25:01] mordof: hey maybe... *checks*
[17:25:31] mordof: they went from 2 to 5.. so i missed a single major revision
[17:35:54] mordof: what is this new class 'Warning' about also?
[17:37:15] mordof: to be able to give deprecation warnings and the like i guess?
[17:38:18] mordof: ACTION renames his Warning class
[17:40:13] mordof: in a pry console... it behaves identically to just using puts...
[17:40:18] mordof: i'm so confused why this is added :/
[17:40:46] mordof: ah, so the same as STDERR.puts
[17:41:21] mordof: using the constants are bad?
[17:41:24] mordof: why is that
[17:42:25] mordof: i'm guessing because $stderr could be reconfigured to point somewhere else?
[17:42:34] mordof: good point.
[17:43:07] mordof: so STDERR/STDOUT are the default interfaces, but you can configure to use different ones across the board easily by setting $stderr and $stdout
[17:43:18] mordof: and *everything* uses those?
[17:43:43] mordof: apeiros: thanks :)
[18:28:18] mordof: dru`: i *think* def foo(&block);; end ends up being the same thing? if yield 5 still works in that, i'm not sure...
[18:28:21] mordof: i haven't done much of that
[18:28:31] mordof: and i have no idea what the implications are
[18:31:50] mordof: you're welcome
[21:00:40] mordof: zenspider: you can put those inside operating system checks
[21:01:02] mordof: the gemfile entries at least
[21:18:49] mordof: Quit: - A hand crafted IRC client
[21:19:41] mordof: has joined #ruby


[18:08:28] mordof: when i call TestModel.test([1, 2, 3, 4, 5, 6, 7, 8]) it's complaining that i'm passing it 8 arguments instead of 1
[18:08:43] mordof: do scopes automatically use splat here? rails 4 didn't behave this way and i'm quite confused
[18:08:56] mordof: why would it think i'm passing it 8 arguments... am i doing something wrong?
[18:17:55] mordof: one would think... lol
[18:18:22] mordof: ACTION sets up a completely new model to test it
[18:19:35] mordof: interesting
[18:19:53] mordof: tbuehlmann: my example is wrong. the actual code is scope :test, -> (foo = nil) { where( ids: foo ) }
[18:20:03] mordof: when the = nil default is there, it causes it to do the expanding
[18:20:55] mordof: i'm gonna set up a pure ruby test for this though
[18:22:56] mordof: :/ a plain lamba literal in the rails console does not exhibit this same behavior.....
[18:23:00] mordof: ACTION tries the test on a different model
[18:24:10] mordof: it blows up in my other model too.. this is really strange
[18:24:48] mordof: i think i need to figure out how scope is calling the lambda to solve this mystery
[18:33:48] mordof: so... i am on rails 5.0.2, maybe it's been fixed already :/
[18:33:53] mordof: maybe that's why rails 5.0.3 is a thing, lol
[18:37:28] mordof: the lambda itself works fine - it's when rails calls it that it blows up
[18:37:34] mordof: what could i be doing wrong there?
[18:39:01] mordof: i always find that a bit tedious to do - was gonna test updating to 5.0.3 first, but sure. i'll try a clean 5.0.2 install and see if the same behavior persists
[18:50:49] mordof: tbuehlmann: before i set up a new application, i made a clean model and tried it - which didn't blow up.. so it's something to do with the models i tried it on i guess. i have to isolate this before there's even a possibility it's a rails thing to reproduce the behavior
[18:51:08] mordof: so this might take a bit of digging
[18:54:18] mordof: oh well this is fun
[18:54:44] mordof: all of the testing where it's been exploding has been in the production rails console, but i can't reproduce it at all locally in development *sighs*
[18:54:48] mordof: even more strangeness
[18:56:08] mordof: hmmm i'm using ruby 2.3.1p112 in production - but 2.3.3 locally
[18:56:20] mordof: gonna downgrade (rbenv) to 2.3.1 locally and see if that changes anything
[18:57:55] mordof: hobodave: normal ruby.. if that makes sense
[19:05:11] mordof: seems like that person is having a great afternoon..
[19:24:06] mordof: confirmed - making a new rails application for testing/reproduction
[19:24:46] mordof: ruby 2.3.1 + rails 5.0.2 or 5.0.3 (none others tested) - scopes on a model with a default argument it splats the argument passed (or at least that's the behavior) so an array passed complains about too many arguments
[19:24:54] mordof: but ruby 2.3.3 does not exhibit this behavior
[19:26:55] mordof: tbuehlmann: do i just paste the link to the repo once it's available in here? or is there a specific place to send it to (rails issues on github is the only place i know of so far)
[19:29:33] mordof: will be back shortly with a link
[19:43:32] mordof: hurray reproducable... though it would've been nicer to have it be a "oh it's just a small fix thing".. lol
[19:44:26] mordof: i got pulled away from this for a short bit - still setting up a clean rails app.
[19:44:44] mordof: 'gem install rails' 'rails new' wasn't working.. had to create a gemfile or 'rails' complained like crazy
[20:25:47] mordof: tbuehlmann: whoa... thanks for putting that together. i was making a full rails application using the test helper and all that fun stuff, lol. your post is much cleaner than mine
[20:26:07] mordof: also kept getting pulled away from it (at work).. so you beat me to it
[20:51:52] mordof: SloggerKhan: yes
[20:52:41] mordof: SloggerKhan: we put this at the top of our application.rb:
[20:53:08] mordof: you're welcome
[20:53:28] mordof: that was in rails 4, honestly i'm not 100% sure that still applies to rails 5
[20:53:31] mordof: nothing stopped working though, lol
[20:54:14] mordof: it only binds to for mine starting up, so i'm assuming that bit of code still works
[20:54:56] mordof: yeah - that's why i ended up using the route i pasted, because otherwise it causes multiple listeners
[20:55:06] mordof: this was one that just reconfigures
[20:55:51] mordof: it is kinda hacky the way i did it.. lol. really you could just put an alias or another small script to call it for you
[20:56:05] mordof: that's the opposite of what i would expect
[20:56:11] mordof: why is that?
[20:57:18] mordof: why does that make you want to avoid using the command line?
[20:57:34] mordof: i understand the whole "don't use" thing.. sure
[20:58:02] mordof: but... a simple script to call bin/rails -b is not that big a deal really
[20:58:18] mordof: call it rs and it's even shorter to type
[21:02:55] mordof: make a small script 'rs' - and include a raise inside rails if it's bound to
[21:02:58] mordof: break that habit, lol
[21:03:30] mordof: gives you more capability later if you want to add configuration to it requiring command line stuff, or prep commands, or anything really
[21:03:38] mordof: ACTION shrugs
[21:04:41] mordof: it feels like you should be doing more about locking down your computers access with firewall stuff also.. which would solve the issue too
[21:04:52] mordof: ACTION wanders off to go home