Activity Graph

Page 1 of 38 | Next »


[09:39:12] mwlang: has joined #ruby
[10:29:13] mwlang: Quit: mwlang


[17:39:11] mwlang: has joined #ruby
[17:40:45] mwlang: Typically when I want to not have to do a check if a variable contains an array of values before starting a loop, I’ll do something like Array(foo).each { … } Works fairly well except for when foo is a Hash.
[17:41:58] mwlang: Array({foo: :bar, fiz: :batz}) => l[[:foo, :bar], [:fiz, :batz]] instead of what I was expecting, which would be: [{foo: :bar}]
[17:43:01] mwlang: although I can work around this with conditional, I’m curious as to why Hashes are treated differently by the Array() “cast” method than other types are.
[17:45:55] mwlang: looks like I can get away with not converting Hash variable into arrays themselves by using [foo].flatten.each { … }
[17:53:32] mwlang: well, I am parsing an XML document. if an element appears multiple times, it’s returned as an array…it it appears only once, it’s returned as just that element (not in an array)
[17:54:10] mwlang: so to be “safe” in following nested sections, I want to cast to Array so I always “have an array” and then loop to go deeper in the nest.
[17:56:12] mwlang: so [foo] on an array gives me [[foo]] while [foo] on hash gives me [foo]. Thus the flatten call to keep things unchange.
[17:57:05] mwlang: right. I already came to that conclusion. I’m just wondering about the reasoning behind ruby treating hashes differently with the Array cast.
[17:57:25] mwlang: seems to violate principle of least surprise, at least for me.
[17:58:27] mwlang: I agree with you on that. but I didn’t write the XML => hash parser, so I’m regularizing it after the fact.
[17:59:30] mwlang: LOL — then he and I think too much alike…:-p
[18:00:41] mwlang: ah-ha. Now that makes sense to me from the design perspective.
[18:01:06] mwlang: it’s rare that I go between arrays and hashes
[18:02:06] mwlang: except looping over key/value pairs of a flat hash, but that’s pretty much part of the Ruby syntax magic there.
[18:04:05] mwlang: Nice way to do that.
[18:06:09] mwlang: I only have one place in the code (so far) where I’m dealing with coercing a Hash variable into an array of Hash variables for all depths of processing elements in the XML, so getting fancy isn’t really called for here. But definitely a great tip to keep in mind for future.
[18:08:41] mwlang: speaking of looping hashes, has it always been possible to do this? {foo: 1, bar:2}.map {|k,v| puts [k,v].join(' => ')} => “foo => 1\nbar => 2”
[18:09:10] mwlang: I mean, using #map and #each and having both key and value in the loop
[18:09:41] mwlang: I used to use #each_pair for that, but at some point, I forgot the “_pair” when writing a loop and it worked.
[18:10:04] mwlang: made me wonder if I learnt wrongly in the beginning or if this capability came along after Ruby 1.8.6
[18:22:26] mwlang: I did a little digging. I think it has always had ability to return two variables with Hash#each and Hash#each_pair made it clear two variables were passed, so I learned #each_pair for iterating hash keys way early on.
[18:23:17] mwlang: I’m sure back then I didn’t know that if I provided two variables, Ruby would intelligently assign individual variables.
[18:24:27] mwlang: @syndikate pretty sure that’s the case.
[18:25:10] mwlang: depends on the language for sure.
[18:27:28] mwlang: @syndikate some languages that byte-compile may optimize away the array destruction on out of scope.
[18:28:37] mwlang: oh, gosh…I haven’t even thought about the variants other than MRI ruby as an option in years.
[18:29:16] mwlang: @syndikate python, crystal, java
[18:30:41] mwlang: personally, I’d do what havenwood suggests just because having “magic” numbers and constants other than 0, 1, nil inside the methods is poor practice.
[18:34:54] mwlang: you’ll have to go ask the python experts, but I do know python pre-compiles pretty aggressively so it has strong potential to optimize static variables inside methods.
[18:35:22] mwlang: two very different beasts
[19:03:45] mwlang: @IGnorAND must specify…same for sort_by.
[19:04:10] mwlang: the rest of the parameters are optional since you provided defaults.
[19:05:12] mwlang: if you want everything optional…then use nil… (list_type: "ALL", search_term: nil, page: 1, page_size: 20, sort_by: nil)
[20:14:20] mwlang: Quit: mwlang


[17:22:56] mwlang: has joined #RubyOnRails
[17:23:12] mwlang: greetings, folks
[17:24:58] mwlang: I’m looking into building a new Rails 5 app that needs to be multi-tenanted. Thus, apartment gem comes to mind, but also perhaps the better route in this day and age is to dockerize the rails app and spin up docker images per tenant/domain served instead of building logic into the app itself.
[17:25:28] mwlang: Has anybody recently weighed pros and cons of the two approaches and have some insights or links to share?
[18:33:25] mwlang: havenwood: Ah yes, radar was writing that book when I was last hanging out around these parts....
[18:34:00] mwlang: there will be some shared model data — mostly in the form of templates they can choose to rapidly launch their sites.
[18:34:10] mwlang: after that…not sure there will be all that much “sharing"
[18:40:26] mwlang: yeah, hence the idea to simply dockerize the whole thing.
[18:40:53] mwlang: well, it’s a new app, but idea is 1000’s of tenants.
[18:41:28] mwlang: but it’ll probably grow slowly enough that I do not have to worry about it until much later in the life-cycle.
[18:44:20] mwlang: the way I see it…if using something like apartment, can have many, many “small tenants” on one server and one deploy updates many at once.
[18:45:27] mwlang: the tenants are law firms, for reference….so you can probably imagine most of these sites will only draw local traffic for local business in their geographical areas…not like a national company with a million page hits a month.
[18:45:55] mwlang: so it’s conceivable one rails app deployment can handle a few hundred tenants.
[18:46:51] mwlang: which specifically? from apartment gem or from dockerized containers?
[18:48:03] mwlang: the concern there is density. that is, how many “tenants” can I run on one server — i.e. how many docker containers per server.
[18:48:37] mwlang: intuition is telling me, an apartmentized rails app would have much higher density than I can achieve with docker.
[18:48:55] mwlang: it’s almost peanuts.
[18:49:11] mwlang: either way, cost can be shouldered by the tenants with subscription prices.
[18:49:56] mwlang: truth be told, more concerned about the ability of a small team to handle large number of tenants effortlessly.
[18:53:05] mwlang: exactly. That’s what I’m churning through right now with the math.
[18:53:45] mwlang: one concern I have with multiple firms in one database…experience with current clients tells me they’re often targeted for hacks.
[18:53:51] mwlang: defacing kind of hacks.
[18:54:27] mwlang: so I’m already thinking “sharding” (in the loose sense of the word) for spliting up tenants across servers
[18:54:39] mwlang: just to prevent one compromised server from taking everyone down.
[18:55:13] mwlang: I just don’t know *why* lawyers are hated by so many people…. (he says sarcastically...)
[18:55:57] mwlang: A first-class Rubyist and lawyer, too!?
[18:58:34] mwlang: no, not going to go the multiple apps route.
[18:58:55] mwlang: ugh….that’s the very definition of never-ending technical debt.
[19:00:03] mwlang: the more I think about it, I think best to start at #2 with ability to introduce #3 for scaling purposes.
[19:00:22] mwlang: but multiple app here will mean, multiple servers, not multiple code-bases.
[19:00:41] mwlang: multple servers == docker containers, roughly.
[19:03:20] mwlang: dumb question: selling front-end and tenant front-end all in one rails app or split ‘em out?
[19:04:52] mwlang: LOL — I was thinking in the context of #1 and #2
[19:05:18] mwlang: welll, #1 isn’t really happening — not sure why I keep entertaining it…so, #2.
[19:05:25] mwlang: subscription
[19:06:28] mwlang: The selling frontend will control setting up the subdomains and controlling whether to show tenant’s content based on whether subscription is paid up or not.
[19:07:27] mwlang: actually, that just answered my internal debate questions entirely.
[19:08:06] mwlang: it is simple enough to control the tenanted app with API and use background jobs to setup/suspend/teardown tenants.
[19:37:02] mwlang: Let subscription class instantiate an updater class and call some general function, say #perform or #update! or whatever it’s going to be for the updaters.
[19:37:38] mwlang: updater itself then calls it’s own private methods with whatever parameters the subscription class instantiated it with or passed on the call to perform said action.
[19:39:11] mwlang: Oh, I was thinking the Updater classes were themselves the active model.
[19:39:18] mwlang: or at least that’s what I would’ve done.
[20:47:21] mwlang: Quit: mwlang


[17:01:36] mwlang: has joined #RubyOnRails
[17:03:46] mwlang: I think I’ve forgotten something subtle about ActiveRecord. Why would deleting a child record that belongs to a parent class issue a DELETE for the parent record? The child class depends on the the parent, so if parent is being destroyed, sure, delete the child, but not the other way around...
[17:04:31] mwlang: has joined #ruby
[17:29:28] mwlang: I figured it out.
[17:29:51] mwlang: I started a transaction block, deleted all the child records, then deleted the parent record at the end of that transaction block.
[17:30:23] mwlang: it’s the call to delete the parent record that’s triggering the FK constraint on the child table (whose records I’ve already deleted…)
[17:30:55] mwlang: the DBMS just isn’t seeing the record as deleted yet, so it’s the DBMS raising the FK constraint error, not AR.
[19:16:14] mwlang: broppk: 12 years later, Ruby is still my go-to language of choice and I don’t see myself giving it up any time soon. I do some Node JS, but mostly within context of a Rails project, which means React and Webpack, etc. tied into a Rails-driven backend serving the databased JSON to the JS frontends.
[19:16:40] mwlang: In short, my experience is Ruby makes for some pretty good glue.
[19:19:57] mwlang: most of the latest JS stuff is still arm’s length for me. I can usually do all the JS I need with simple jQuery widgets written in coffeescript. If I need more, I usually step up to VueJS instead of React, Webpack and all that. Only two projects are utilizing the heavier weight JS tooling.
[19:21:22] mwlang: I guess it all goes back to the RJS days of Rails and since that big ball of mud, I’ve always tried to keep external components to a bare minimum.
[20:06:01] mwlang: Quit: mwlang


[00:39:54] mwlang: has joined #ruby
[03:04:27] mwlang: Ping timeout: 240 seconds


[13:33:45] mwlang: has joined #RubyOnRails
[13:34:49] mwlang: How do I turn off logging ActiveJob in Rails 5? The method used in Rails 4 and everything I can google says “ActiveJob::Base.logger =” but this is not doing the trick any more
[13:36:21] mwlang: It may be that resque is injecting the info into the log since I’m seeing… “Performing BroadcastOrderBookJob (Job ID: 168a169c-11f1-4ee6-9af7-fa13ffcf907d) from Resque(default) with arguments:” rather than ActiveJob proper?
[13:45:07] mwlang: nevermind, it turns out that placing the code in an initializer file was the trick vs. placing it in application.rb or in the environments/*.rb files.
[13:53:44] mwlang: Quit: mwlang


[01:52:23] mwlang: Quit: mwlang


[17:31:08] mwlang: has joined #ruby
[17:32:47] mwlang: is there a gem out there supporting .Net’s signalr websockets? I’m having trouble tracking one down.
[17:33:53] mwlang: majuk I can compile and build nokogiri gem on a 1st and 2nd edition Raspberry Pi
[17:34:18] mwlang: it may not be horse power of the arm board, but rather a lack of necessary system packages.
[17:39:00] mwlang: havenwood: You are the queen - that package indeed has a signalr client in it.
[17:46:43] mwlang: gizmore: sequel gem will let you interact with the DBMS with ruby hashes.
[17:47:29] mwlang: and with that library, it’s all symbols instead of strings.
[17:48:07] mwlang: ok, gotcha. FWIW, I prefer symbols for hash keys over strings.
[17:49:11] mwlang: I learned a lot of good Ruby tricks from the Sequel source. Definitely worth a study.
[17:49:58] mwlang: neat idea.
[17:50:15] mwlang: where do you hook the autoloader in?
[18:04:23] mwlang: I don’t know if “associative array” is correct term for a Hash. key/value mapping seems more appropriate.
[18:11:57] mwlang: havenwood: that may be it for me as well.
[18:36:06] mwlang: why switch from SipHash24 to 13? performance?
[20:02:18] mwlang: havenwood: embed #ruby irc channel in irb console!? You gotta build that! I can just see it now…an interactive Ruby shell that emits IRC messages as they come through while you’re working on something…and you can reply back with simple command => irc :ruby, “yeah, I got it.”
[20:05:37] mwlang: for any of you that are into crypto currencies and trading on exchanges, I put out a new open source gem that wraps cobinhood’s api: I’d love some feedback on how to improve this code (aside from the most obvious: writing some specs for it…)
[20:07:18] mwlang: speaking of writing specs, for open source projects that may have sensitve server exchanges, what’s the typical approach to implementing? last thing I want to do is accidentally expose my private API keys through VCR cassettes and/or other means of fixture capturing.
[20:20:35] mwlang: Good points on all, but I didn’t understand one: Frozen string literal magic comment?
[20:21:43] mwlang: Ah! That’s a new feature to me.
[20:22:14] mwlang: does it go in every file or just the primary lib/cobinhood.rb file?
[20:23:01] mwlang: what’s practically gained from freezing all the literal strings?
[20:30:35] mwlang: learnt a couple of something new today!
[20:32:07] mwlang: I’ve been using !~ and =~ for quite some time just because I like it better than reading “match?” but an performance boost is enough for me to change.
[20:32:45] mwlang: truth be told, most time lost on the actual API call/response than anywhere else.
[20:35:12] mwlang: now that I did not know!
[20:39:03] mwlang: good point. I forgot that one.
[20:42:59] mwlang: *havenwood all suggestions adopted.
[20:43:22] mwlang: thanks. how was the structuring? was it easy to follow?
[20:45:03] mwlang: on the frozen literal string magic comment, if I add that, I should remove the #freeze call, right? for example.
[20:50:25] mwlang: havenwood: thanks for that detailed look and feedback. I definitely wasn’t expecting that and really appreciate it. I’m probably going to do a few more of these for various exchanges, esp. if the current ones out there royally suck like the cobinhood_api one did.
[20:50:57] mwlang: kucoin comes to mind. terrible implementation of a ruby wrapper on the existing gem.
[20:52:49] mwlang: one other performance idea: someone told me to switch the Faraday default adapter to Typhoeus. any opinions here on the merits of that suggestion?
[21:00:53] mwlang: hmmm…are you sure about “ ENV::[] always returns a String” ? I just tried this in IRB console: ENV["SOMETHING"] => nil
[21:04:58] mwlang: apeiros: thanks for clarifying.
[21:05:20] mwlang: I just simply did ENV[“SOMETHING”].to_s
[21:06:27] mwlang: but you know…better idea is to change where I call #to_s
[21:07:09] mwlang: if only nil.empty? => true
[21:07:40] mwlang: all I needed to know at the point of using an api_key is whether it was blank/empty or not.
[21:08:11] mwlang: *sigh* any ideas they *didn’t* bolt on?
[21:08:31] mwlang: rails is a two-edged sword, for sure.
[21:09:56] mwlang: that’s all I really need. sweet and simple.
[21:12:25] mwlang: pushed a new version with the nitpicks cleaned up. @Eiam this is where I’m using that #to_s:
[21:12:40] mwlang: line #6 sets it, line #10 uses it.
[21:15:10] mwlang: because there’s a public set of endpoints that do not require an api_key
[21:15:24] mwlang: if I raised it then, it would prevent using the library without an api_key
[21:15:54] mwlang: this way, error’s raised only first time an endpoint requiring the key is called.
[22:26:13] mwlang: @Jiaoyin original investor as in pre-pre ICO investor? :-o
[22:26:34] mwlang: @Jiaoyin What I produced is just Ruby API wrappers to the Cobinhood API
[22:27:02] mwlang: I needed it for algorithimic trading bots I’m building.
[22:28:47] mwlang: Ah. I’ve been a long-term “investor” from point of view of simply holding and growing COB stack simply trading the gap in the spreads on the platform.
[22:29:18] mwlang: trying to automate what I’ve been doing manually until now.
[22:29:50] mwlang: Ah. welcome to the Ruby community.
[22:30:20] mwlang: If you’re into cryptocurrencies, you may also like another open source Ruby project I have going:
[22:30:43] mwlang: I do. They seem to have a great team and constantly working on improving the platform.
[22:30:59] mwlang: their marketing needs help, but they’re getting better there.
[22:32:32] mwlang: they’re fun and keeps me busy.
[22:37:09] mwlang: Jiaoyin: thanks! you, too.


[08:06:51] mwlang: has joined #ruby
[17:50:37] mwlang: Ping timeout: 265 seconds
[19:51:42] mwlang: has joined #ruby
[20:33:57] mwlang: Ping timeout: 264 seconds
[20:40:15] mwlang: has joined #ruby
[20:49:30] mwlang: Quit: mwlang


[20:26:10] mwlang: has joined #ruby
[20:48:03] mwlang: Quit: mwlang


[17:33:20] mwlang: Quit: mwlang


[19:34:57] mwlang: has joined #ruby


[18:05:08] mwlang: has joined #ruby
[18:05:08] mwlang: has joined #ruby-offtopic
[18:05:23] mwlang: has joined #RubyOnRails
[18:06:52] mwlang: So I’m building my first Rails 5.1 app with ActionCable subscription. I can successfully trigger a broadcast from a web browser that will eventually update back to the browser client that triggered the action (like the demo chat program).
[18:07:24] mwlang: but when I fire up rails console and submit a broadcast, it never reaches the browser client that is subscribed to the channel.
[18:08:04] mwlang: Is this because of the rails server and consoles running in separate threads?
[18:08:54] mwlang: My goal is to have a background job running every 5 ~ 10 seconds that will send a trigger a broadcast to all subscribed clients.
[18:09:51] mwlang: So a background job via ActiveJob that’s running in it’s own worker is never going to successfully trigger broadcasts to the server connected clients?
[18:11:44] mwlang: ok, one sec.
[18:18:28] mwlang: decided to open-source it…nothing proprietary in the app…need a couple minutes to get it published so I can gist some code properly.
[18:20:19] mwlang: crap, I think I just found the problem....
[18:20:42] mwlang: cable.yml has adapter: async instead of adapter: redis
[18:38:34] mwlang: hiya, baweaver - hope all’s well with you.
[18:48:14] mwlang: dminuoso: the adaptor was the problem!
[18:50:05] mwlang: isn’t that puppy open source?
[18:50:21] mwlang: Ah, it’s a snake… (just looked it up)
[18:50:33] mwlang: I don’t mess with snakes. only precious gems.
[18:55:28] mwlang: maybe one day…colloquy has been my standby for far too many years now.
[19:14:11] mwlang: Quit: mwlang
[19:16:31] mwlang: has joined #ruby
[19:16:31] mwlang: has joined #ruby-offtopic
[20:10:14] mwlang: has joined #RubyOnRails
[20:31:30] mwlang: Quit: mwlang
[21:23:33] mwlang: has joined #ruby
[21:23:33] mwlang: has joined #ruby-offtopic
[21:36:46] mwlang: Quit: mwlang
[21:44:44] mwlang: has joined #ruby
[21:44:44] mwlang: has joined #ruby-offtopic
[21:59:08] mwlang: has joined #RubyOnRails
[22:07:27] mwlang: Ping timeout: 240 seconds


[17:15:54] mwlang: has joined #ruby
[17:15:54] mwlang: has joined #ruby-offtopic
[17:16:05] mwlang: has joined #RubyOnRails
[17:22:51] mwlang: Quit: mwlang


[00:21:22] mwlang: Quit: mwlang


[22:24:55] mwlang: has joined #ruby
[22:24:55] mwlang: has joined #ruby-offtopic
[22:25:06] mwlang: has joined #RubyOnRails
[22:25:48] mwlang: is it possible for a rails session that’s a database/activerecord store to be explicitly set by passing the session_id in on URL?
[22:26:20] mwlang: For example, we want to implement Google Docs preview functionality whereby a logged in user can view a document.
[22:27:12] mwlang: since the request for the document’s data payload is coming from, we need to “auto-login” to the user’s current session.
[22:39:56] mwlang: blindMoe: in config/application.rb, set config.active_record.default_timezone = :local
[22:40:13] mwlang: and you’ll also want to set the timezone you want while you’re at it: config.time_zone = "CET"
[22:40:18] mwlang: (for example)
[22:42:01] mwlang: I’m reasonably sure the second setting is crucial to getting the behavior you want.
[22:42:18] mwlang: albeit it’s been a while since I’ve fiddled with these settings.
[22:45:02] mwlang: ok, monkeying with UTC in the DB probably isn’t the solution you want anyway…if you have multiple timezones serviced by the app, it’s best to keep it UTC in the DBMS.
[22:46:33] mwlang: If you’re running in a cluster and the expectation is each server serves a specific timezone, then my thought would be to try setting the server’s timezone so that it’s cronjob scheduler is firing the midnight tasks at midnight local time for that server.
[22:49:26] mwlang: Greetings


[01:23:11] mwlang: Quit: mwlang
[07:12:36] mwlang: has joined #ruby
[07:12:36] mwlang: has joined #ruby-offtopic
[07:23:07] mwlang: Quit: mwlang


[14:48:18] mwlang: has joined #ruby
[14:48:18] mwlang: has joined #ruby-offtopic
[14:50:06] mwlang: I’m trying to use to get back the right value in UTC timezone. The problem is, I’m getting back that time interpreted to my local timezone. How do I cast the local time to correct UTC time?
[14:52:38] mwlang: actually, I just realized the fallacy of my reasoning…casting the local time to UTC with #utc appears to be the number I expected.
[14:53:12] mwlang: I was thinking initially that the integral value was in UTC terms to begin with.
[14:53:30] mwlang: so getting a local time out of that initially would be an incorrect result.


[01:35:54] mwlang: has joined #ruby
[01:35:54] mwlang: has joined #ruby-offtopic
[01:41:22] mwlang: Quit: mwlang


[00:38:21] mwlang: has joined #ruby
[00:38:21] mwlang: has joined #ruby-offtopic
[02:12:48] mwlang: Quit: mwlang
[02:23:39] mwlang: has joined #ruby
[02:23:39] mwlang: has joined #ruby-offtopic
[02:23:45] mwlang: Client Quit


[15:33:41] mwlang: has joined #RubyOnRails
[16:04:58] mwlang: Quit: mwlang
[16:10:05] mwlang: has joined #ruby
[16:10:05] mwlang: has joined #ruby-offtopic
[16:10:26] mwlang: has joined #RubyOnRails
[20:31:50] mwlang: Quit: mwlang
[20:33:00] mwlang: has joined #ruby
[20:33:00] mwlang: has joined #ruby-offtopic
[20:33:08] mwlang: has joined #RubyOnRails
[21:56:07] mwlang: Quit: mwlang