Activity Graph

Page 1 of 512 | Next »


[08:16:50] Radar: GOOD EVENING
[08:19:28] Radar: Hit 120wpm on typeracer again
[08:20:08] Radar: https://data.typeracer.com/pit/result?id=|tr:ryanbigg|86


[00:22:38] Radar: "I am working on an ancient ruby app, in 1.8.7" <- holy moly
[00:23:13] Radar: That belongs in a museum!
[00:24:25] Radar: A tomb recently unearthed in Egypt has hieroglyphics that were only decoded this week: RUBY_VERSION == 1.8.7
[00:24:37] Radar: That is how old your app is 😂
[00:24:51] Radar: Scriptonaut: It would be... educational!
[00:25:24] Radar: Scriptonaut: You're getting paid for this, yeah?
[00:28:50] Radar: Scriptonaut: Hearing stories like this makes me wonder at what it's going to be like in like 10 or 20 years time when the world has _even more_ legacy software. We have ways and means of assessing and repairing collapsing buildings, bridges / etc. But we don't seem to have a clear way of assessing software quality in the same way. Pieces don't fall off software, usually. So I wonder how we'll handle this into the future.
[00:31:02] Radar: &>> 'A..A..'.gsub(/A(\.+)A/) { |x| x.gsub('.', 'A') }
[00:32:05] Radar: mroutis_: usually >> but ruby[bot] is failing
[00:36:19] Radar: I can't think of a clean way to do that.
[00:36:38] Radar: A slightly shorter way is using tr
[00:36:42] Radar: &>> 'A..A..'.gsub(/A(\.+)A/) { |x| x.tr('.', 'A') }
[00:37:52] Radar: What do you mean? It's doing everything. Without it, the replacement wouldn't happen
[00:38:29] Radar: Yes, but then the block for that first gsub is replacing it
[00:52:10] Radar: ACTION finds a bucket
[00:52:16] Radar: Scriptonaut: Did you take this code from your 1.8.7 app?
[00:52:43] Radar: it's gross :P
[00:53:12] Radar: 'A..A..'.gsub(/A(\.+)A/) { |x| x.tr('.', 'A') } <- I like mine
[00:53:17] Radar: It's easy enough to read
[01:06:05] Radar: Scriptonaut: ohhhhh right
[01:09:10] Radar: ivanskie: y u no use GitHub's gem?
[01:11:22] Radar: Well this will help with the gist thing :) Rugged is what I've been using for git automation myself.
[02:52:05] Radar: jidar: input and expected output please
[02:54:05] Radar: jidar: I think zip + include would be your best bet:
[02:54:21] Radar: sorry, zip + select
[02:54:41] Radar: &>> ["a1", "b1", "c1"].zip(["a", "b"]).select { |a, b| b && a.include?(b) }
[04:30:51] Radar: hnanon: what do you have now?
[04:33:48] Radar: If that's the one that always has the file, then I would suggest params[:variant][:image_attributes].select { |_index, image| image.key?("file") }
[04:34:10] Radar: But I would first look to see if I could get rid of the nested attributes altogether if you only care about one bit of data
[04:37:15] Radar: hnanon: yeah, spree has a master variant for a product.
[04:37:22] Radar: the variant is added to the cart
[04:37:27] Radar: line_item had a variant_id
[04:47:33] Radar: I think at the same time the product was created
[04:57:45] Radar: hnanon: possibly. Might not work if you're calling it from params because image_attributes is an array
[04:57:56] Radar: Oops, sorry, it's a hash isn't it?
[04:58:08] Radar: params.dig(:variant, :image_attributes, "1", :file)
[05:12:29] Radar: sarink: well that looks like fun. What version of Rails?
[05:12:59] Radar: thank you
[05:13:34] Radar: I'll try to reproduce it.
[05:14:19] Radar: sarink: I can't reproduce it locally.
[05:17:20] Radar: sevenseacat: good point
[05:19:17] Radar: (tbh that was going to be my next guess)


[00:15:34] Radar: Does Haskell have no side effects because it's not used in production? :P
[00:54:36] Radar: Well, yeah, that's what you're telling it to do.
[00:54:53] Radar: You're telling it to delete that item immediately. That link should go to an action that runs that destroy code.
[00:55:56] Radar: Are you deleting the link between a product and its collection? Is that the intention?
[00:56:50] Radar: Then I would put it in the products controller
[00:57:03] Radar: and it doesn't necessarily have to be called destroy. It could be called something like "unlink"
[01:00:46] Radar: Sure, you could do that too.
[21:23:04] Radar: GOOD MORNING
[22:51:40] Radar: maletor: is there a larger stacktrace than that?
[22:56:13] Radar: maletor: !gist
[22:56:52] Radar: thank you
[22:57:11] Radar: maletor: Can you add # ./app/models/user.rb:895 and the containing method to the Gist too please?
[22:58:12] Radar: Thank you
[22:58:40] Radar: Nothing seems to be amiss here. Should be fine. Can you repro in a new app?
[22:59:31] Radar: Right, but there's only a few moving parts here. Set the cache_store, copy over the method...
[23:01:08] Radar: not right now
[23:01:17] Radar: not without being able to view the app myself
[23:02:35] Radar: The block there shouldn't be returning a string. iirc, it should be returning a Tempfile.
[23:02:40] Radar: For it to be returning a string is very wrong.
[23:03:13] Radar: https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/file/atomic.rb#L24
[23:06:37] Radar: what is the string at that point?
[23:06:47] Radar: I can't interpret what "0x00000000175b8080" means :)
[23:07:12] Radar: Looks like a zipcode to me.
[23:07:28] Radar: maybe. Now track back along the stacktrace to see how it arrives at that point
[23:08:36] Radar: Ok, but how does the string 99016 arrive in there? Did you follow it all the way from user.rb?
[23:08:42] Radar: Debugging at each line in that stacktrace?
[23:09:06] Radar: Yes, we have an A point and a Z point. What's the middle bits?
[23:29:43] Radar: maletor: that'll do it ;)
[23:29:50] Radar: maletor: is it iwthin tests?


[00:04:43] Radar: Great :) Sorry it took so long for us to fix.
[01:42:38] Radar: hnanon: I probably last gave that advice in 2014 :P
[01:43:24] Radar: hnanon: But yes, that was the gist of it. Carts and orders are the same thing. I am less convinced of that modelling now and I would have them be separate entities.
[01:43:49] Radar: hnanon: Carts are _potential_ orders, and go through their own state transitions. Orders never go back into the "address" or "delivery" or "payment" states.
[01:44:00] Radar: Similarly, carts never reach a "refunded" state.
[01:44:34] Radar: To keep the model separate and simpler, I would now have a Cart model and an Order model.
[04:29:31] Radar: elcontrastador: you probably want "allow_blank"
[04:29:35] Radar: !validations
[04:29:56] Radar: Section 3.2.
[21:39:38] Radar: GOOD MORNING
[21:40:13] Radar: orbyt_: hi. Only a few hours late, but do you have the rest of the code around that? I'd be interested about what it's doing.
[21:50:27] Radar: orbyt_: you could probably use httpie
[21:50:31] Radar: http options <route>
[21:50:51] Radar: depends on if your controller actions are verifying an authenticity_token to prevent CSRF attacks though
[21:51:04] Radar: if they are, then httpie won't work unless you're passing an authenticity token through
[22:44:13] Radar: orbyt_: seems good then. null_session makes Rails not define a session cookie, so each request is completely isolated from every other request for that client.
[23:19:36] Radar: orbyt_: it wouldn't affect those
[23:19:44] Radar: they would still be able to make the request
[23:19:53] Radar: I only mentioned httpie because it's a good way to make http options request.
[23:19:55] Radar: requests*
[23:43:57] Radar: relyks: what's the method?
[23:45:34] Radar: begin; TheirCode.a_method; rescue => e; <do something with e, the exception>; end
[23:48:43] Radar: relyks: Exceptions could happen for many, many different reasons. Maybe it's a timeout because it failed to connect to a HTTP endpoint? But maybe it's an ArgumentError because of a typo in the code. It's hard to predict exceptions. They are exceptional.
[23:49:06] Radar: It is not possible to predict.


[04:41:48] Radar: elcontrastador: :D
[05:03:32] Radar: &>> l = { 'lat' => 1, 'lng' => 2 }; (lambda { |location| (location['lat'], location['lng']) }).call(l)
[05:04:06] Radar: (location['lat'], location['lng']) this part is invalid :D
[05:04:20] Radar: &>> l = { 'lat' => 1, 'lng' => 2 }; p (lambda { |location| [location['lat'], location['lng']] }).call(l)
[21:25:34] Radar: matcouto: nope. All Rails versions must be the same.
[21:25:47] Radar: cgibsonmm: my guess: you're missing data
[21:26:21] Radar: cgibsonmm: How would you go about proving that I'm wrong? ;)
[21:27:11] Radar: cgibsonmm: yup.
[21:27:39] Radar: cgibsonmm: Computers don't lie. If it's returning an empty array, it's probably because user.forum_posts is doing a query like "SELECT * from forum_posts where user_id = 1" and that's returning an empty data set.
[21:27:56] Radar: cgibsonmm: So can you say -- for certain -- that there is definitely forum posts in your database for that user?
[21:28:27] Radar: cgibsonmm: And how are you knowing that?
[21:28:37] Radar: cgibsonmm: Show me a record that exists for that query.
[21:35:04] Radar: cgibsonmm: Are they using the same data?
[21:36:06] Radar: cgibsonmm: ForumPost.find_by_sql("SELECT * FROM forum_posts where user_id = '1'")
[21:36:13] Radar: What does that give you back?
[21:36:17] Radar: On production, not local.
[21:37:26] Radar: cgibsonmm: You see all the correct posts?
[21:37:54] Radar: cgibsonmm: What is `user.forum_posts.to_sql` showing?
[21:38:09] Radar: Is it that big long join query?
[21:39:28] Radar: Thanks :D
[21:39:57] Radar: Ok, I suspect this is happening because of that join. If a record along the "join chain" is missing, then you'll be seeing the behaviour that you're seeing.
[21:40:18] Radar: cgibsonmm: So to track down why this is happening, we'll need to go from post and along the join chain, verifying that all the expected records are there.
[21:40:51] Radar: cgibsonmm: Also, the end of your query says forum_categories.user_id = 1... is that intentional?
[21:41:12] Radar: I would think that should be forum_posts.user_id =1
[21:42:27] Radar: Going back to that first hypothesis: I would find a single post from the find_by_sql result, verify that its thread exists. Then that the thread's forum + category exists. If you can do that, then you can rule out the join being the cause.
[21:42:47] Radar: So two possibilities: 1) something along the join chain is missing 2) that forum_categories.user_id = 1 is wrong.
[21:45:05] Radar: Right. Your query is expecting the category to have a user_id set to 1. So if that's not the case, then your query is going to fail.
[21:45:19] Radar: If you don't have user_id set on the category then I would count that as missing data ;)
[21:46:27] Radar: np :) This was fun!
[21:49:17] Radar: cgibsonmm: Adding a column? forum_categories doesn't already have user_id?
[21:49:41] Radar: cgibsonmm: I'm finding it weird that forum_posts isn't scoping the find by forum_posts.user_id, but seemingly instead by forum_categories.user_id.
[21:52:33] Radar: cgibsonmm: can you show me how the forum_posts association is defined on users?
[21:52:34] Radar: in the model
[21:54:41] Radar: I'm going to be changing trains in a minute, so I'll be offline for about 15-20 mins
[23:31:18] Radar: cgibsonmm: how's that association defined in the model?
[23:33:05] Radar: cgibsonmm: missing the user model?
[23:47:19] Radar: cgibsonmm: taking a look
[23:47:35] Radar: https://gist.github.com/cgibsonmm/449d20c2cf1525fadcda937b39800068#file-user-rb-L1
[23:47:37] Radar: cgibsonmm: two arrows?
[23:48:02] Radar: Association seems fine. I don't know why it's putting user_id as a condition on forum_categories still
[23:51:32] Radar: cgibsonmm: right. That seems fine .
[23:51:50] Radar: my best guess is that it's a bug in Rails due to the many levels of has_many :through
[23:52:00] Radar: it's finding the first table with a user_id field and using that instead.
[23:52:53] Radar: cgibsonmm: I don't understand why the association for forum_posts on users isn't simply has_many :forum_posts. Why does it have to go through thread?
[23:53:08] Radar: cgibsonmm: you have a belongs_to :user on ForumPost, which would indicate to me that it has a user_id field there.
[23:56:34] Radar: Yes, that's better.
[23:56:39] Radar: That should return the right posts for the users.


[21:30:30] Radar: GOOD MORNING
[23:13:46] Radar: mzo: I have never been paid more as a Rails developer than this year.
[23:14:07] Radar: mzo: Is it, though>
[23:14:12] Radar: [citation needed]
[23:15:06] Radar: mzo: what are your feelings towards haskell?
[23:15:46] Radar: mzo: there is a ton of institutional knowledge of how to build / scale / deploy Ruby applications. People aren't going to piss that away for Rust applications.
[23:16:51] Radar: mzo: With dry-rb & friends, I think building a Ruby application is getting even _better_ than it has been recently. Rails is, despite its _many_ flaws, still better than it was three years ago.
[23:17:47] Radar: elcontrastador: Shrine
[23:19:04] Radar: mzo: I don't think Ruby is necessarily _fading away_. I think there are now more alternatives out there than there have been in the past. Elixir, Go and Rust all didn't exist in 2008.
[23:19:20] Radar: JavaScript was also not anywhere near as popular back then.
[23:20:08] Radar: If you've been involved in this community for a long time, I think you might have a tendency to view Ruby as being a great programming language because there weren't many competing programming languages 10 years ago. That has changed. JavaScript has gotten better. Go has come along. Rust arrived. Elixir took Ruby's syntax and made it _fast_
[23:21:04] Radar: Just like in natural evolution, just because something _better_ comes along it doesn't mean that all existing things die off -- at least, immediately. They can all thrive together in a shared ecosystem _at the same time_
[23:21:41] Radar: mzo: If I had to pick a programming language for anyone busting into this industry to learn, I would not recommend Ruby. Not at all. I would recommend JavaScript instead.
[23:22:37] Radar: I would recommend Ruby probably as a second language still just because it's really easy to learn and it gets the job done.
[23:23:06] Radar: I think Rust's documentation is absolutely shit for a true beginner and I would only recommend it if I wanted to scare someone away from programming. Go is much in the same boat, but getting better.
[23:23:43] Radar: Elixir is most of the way to being an approachable language for a beginner too. It's not quite there, but it's closer than anything else I've seen.
[23:24:40] Radar: Ruby is still a competitive language. There's lots of startups (and large, established companies) still using it for their day-to-day work. There's lots of great tutorials, books, screencasts, etc. out there about Ruby. It is a very, very fine language to introduce someone to and there's market demand for Ruby programmers.
[23:24:59] Radar: To speak about market demand a bit more: a local Ruby shop in Melbourne wants to hire 40 new developers by the end of Q1 next year.
[23:25:27] Radar: I know that the company I work for has grown two-fold in developer numbers (that's frontend & backend, btw) over the course of the last year: from 40 to 80.
[23:25:39] Radar: mzo: World's most liveable city 6 years running ;)
[23:26:24] Radar: baweaver: Will you ever see that kidney again that you had to pay in rent?
[23:26:51] Radar: elcontrastador: It's the easiest to understand one and least magical, at least in my experience. I've tried Paperclip, Dragonfly, Carrierwave and now Shrine and I'm going to continue to use Shrine.
[23:27:55] Radar: oh yeah, that's right
[23:27:59] Radar: mzo: where do you live now?
[23:29:46] Radar: mzo: Shopify is probably hiring a bazillionty Ruby devs too atm. They're probably the biggest Ruby shop on that side of the world.
[23:30:25] Radar: elcontrastador: great to hear you've at least looked at it. The DSL can be a bit confusing to start off with, you're right. I hope you come back around to it :)
[23:31:06] Radar: https://www.shopify.com/careers/search
[23:31:13] Radar: They have just a few open positions.
[23:31:23] Radar: Almost 100 by the looks of it!
[23:41:13] Radar: But there are 8 lemurs in the photo :D
[23:41:52] Radar: And yay for announcing the book at RubyConf :) I think it will be well received.


[00:35:54] Radar: baweaver: I get the distinct impression that Liz's computer contains three applications: a browser, Word, and an email client.
[00:36:05] Radar: And she knows how to use two of those very well.
[00:36:21] Radar: baweaver: does Liz have access to the GitHub repository?
[01:26:42] Radar: cxl: what does this method do?
[01:26:51] Radar: cxl: Could you gist it?
[01:27:14] Radar: cxl: My rule of thumb is that if it has to work with something from the request / response it goes in the controller. If it is working more with information from the model, then it should go in the model.
[06:41:35] Radar: elcontrastador: I agree with tbuehlmann. They go into app/validators.
[06:41:40] Radar: elcontrastador: Are you using dry-validation by chancE?
[06:42:51] Radar: cgibsonmm: You could do an after_create in your User model.


[01:22:08] Radar: a.bs.flat_map(&:cs).map(&:some_property)
[01:22:17] Radar: Your issue is that your 2nd collect is returning an array of arrays.
[22:13:11] Radar: ule: did you see what phaul showed you?


[00:26:48] Radar: renlo: gist the code next time please
[00:26:52] Radar: ?gist renlo
[00:28:04] Radar: ok I'll need proprietary dollars to help out with that
[00:28:42] Radar: Inside: wow
[00:29:46] Radar: SomeBlah::Blahh::SomeThing
[00:29:51] Radar: renlo: you work for Vague Inc?
[00:30:39] Radar: biberao: Well Grounded Rubyist is the one typically recommended here. It's a thick tome.
[00:30:49] Radar: biberao: If you've got other programming experience, POODR might be a better book for you.
[01:14:30] Radar: Inside: can I see the controller test?
[01:14:50] Radar: or is it proprietary?
[01:25:08] Radar: I'm having connectivity issues to GitHub at the moment
[01:25:15] Radar: "gist.github.com took too long to respond."
[01:28:49] Radar: Inside: I wonder if there is a better way of approaching this: https://gist.github.com/Insood/a24b12eea9999a47e8cc7692734c8636#file-section-rb-L26
[01:29:12] Radar: Like, could you make that sample user already have that role somehow?
[01:51:18] Radar: Yeah, that is where you might run into some trouble. I'd probably have a proxy class that decided which to use: ActiveDirectoryLookup or FakeActiveDirectoryLookup, depending on Rails.env.test?
[01:51:53] Radar: FakeAD would just be some plain Ruby methods that would return true in some cases... maybe backed by a DB? I'm not convinced of my own idea. It would take some playing around.
[21:21:56] Radar: GOOD MORNING
[21:22:27] Radar: davidh38: it works because the other arguments are optional
[21:58:53] Radar: I cannot reproduce it on Ruby 2.5.1
[21:59:18] Radar: Sorry, I _can_ reproduce it on 2.5.1
[21:59:23] Radar: => ["Password", "Email"]
[21:59:23] Radar: irb(main):001:0> ["Password", "Email"].sort
[21:59:37] Radar: On 2.3.7 I see:
[21:59:38] Radar: => ["Email", "Password"]
[21:59:38] Radar: ["Password", "Email"].sort
[22:18:34] Radar: => [["P", "a", "s", "s", "w", "o", "r", "d"], ["", "E", "m", "a", "i", "l"]]
[22:18:34] Radar: ["Password", "Email"].map(&:chars)
[22:18:59] Radar: >> ["Password", "Email"].map(&:codepoints)
[22:19:00] Radar: => [[80, 97, 115, 115, 119, 111, 114, 100], [65279, 69, 109, 97, 105, 108]]
[22:19:11] Radar: ruby[bot]: dead to me
[22:19:19] Radar: what Inside said
[22:30:18] Radar: al2o3-cr: Depends on when apieros deploys it
[22:30:20] Radar: could be years
[22:39:02] Radar: al2o3-cr: I don't think access list == bot access
[22:39:36] Radar: phaul: I'd be okay with it if it meant we had an interpreter that worked in-channel
[22:40:02] Radar: thank you
[22:40:55] Radar: sounds good to me


[09:55:06] Radar: Yeah, that's right. The offset is correct, but +11 is not always going to be _my_ offset. It's going to be either +10 or +11, depending on the time of year.
[09:55:15] Radar: drale2k_: what problem are you aiming to solve with this? Timezones are pretty tricky.
[09:58:22] Radar: Different regions transition to + from DST at different times. I think this might be tricky if you only have the UTC offset?
[10:01:15] Radar: drale2k_: well, you can store a UTC time with the relative offset at that point in time, if you've got that information.
[10:01:54] Radar: drale2k_: psql has a "timestamp with time zone" type that would be good for that.
[10:02:07] Radar: I suspect Rails datetime fields use that type already
[10:03:00] Radar: yeah, that's right.
[10:03:10] Radar: db supports it so no real reason it should be 2 separate fields imo
[10:21:07] Radar: There's probably a Rails helper to create a similar field _with_ the timezone.
[21:38:07] Radar: marahin: does braintree support your client's country?
[21:39:03] Radar: marahin: They have an API which is _almost_ as good as Stripe, so I'd recommend you go with them :)