SteenJobs

Activity Graph

Page 1 of 58 | Next »

2018-11-15

[16:33:00] SteenJobs: has joined #RubyOnRails
[16:43:48] SteenJobs: Read error: Connection reset by peer
[16:45:17] SteenJobs: has joined #RubyOnRails
[18:00:54] SteenJobs: Quit: SteenJobs
[18:05:33] SteenJobs: has joined #RubyOnRails
[18:50:09] SteenJobs: Quit: SteenJobs
[18:56:08] SteenJobs: has joined #RubyOnRails
[22:06:54] SteenJobs: Quit: SteenJobs

2018-11-14

[01:26:11] SteenJobs: Quit: SteenJobs
[01:33:00] SteenJobs: has joined #RubyOnRails
[03:15:25] SteenJobs: Quit: SteenJobs
[03:41:07] SteenJobs: has joined #RubyOnRails
[05:07:04] SteenJobs: Quit: SteenJobs
[05:16:06] SteenJobs: has joined #RubyOnRails
[05:16:10] SteenJobs: Client Quit

2018-11-13

[19:37:06] SteenJobs: has joined #RubyOnRails

2018-11-10

[07:57:08] SteenJobs: Quit: SteenJobs

2018-11-09

[04:19:17] SteenJobs: has joined #RubyOnRails
[04:20:27] SteenJobs: Client Quit
[19:20:04] SteenJobs: has joined #RubyOnRails
[19:50:55] SteenJobs: Read error: Connection reset by peer
[19:51:46] SteenJobs: has joined #RubyOnRails
[21:23:25] SteenJobs: Quit: SteenJobs
[21:35:07] SteenJobs: has joined #RubyOnRails
[23:14:44] SteenJobs: Quit: SteenJobs
[23:15:57] SteenJobs: has joined #RubyOnRails

2018-11-08

[05:59:08] SteenJobs: Quit: SteenJobs
[06:00:36] SteenJobs: has joined #RubyOnRails
[06:00:42] SteenJobs: Client Quit
[19:14:55] SteenJobs: has joined #RubyOnRails
[21:01:17] SteenJobs: Quit: SteenJobs
[21:07:07] SteenJobs: has joined #RubyOnRails
[22:19:28] SteenJobs: Quit: SteenJobs
[22:24:18] SteenJobs: has joined #RubyOnRails
[22:24:30] SteenJobs: Client Quit

2018-11-07

[18:02:11] SteenJobs: has joined #RubyOnRails
[20:13:09] SteenJobs: Read error: Connection reset by peer
[20:13:46] SteenJobs: has joined #RubyOnRails
[21:05:39] SteenJobs: Read error: Connection reset by peer
[21:07:17] SteenJobs: has joined #RubyOnRails
[21:43:55] SteenJobs: Quit: SteenJobs
[22:37:26] SteenJobs: has joined #RubyOnRails

2018-11-06

[03:15:48] SteenJobs: Quit: SteenJobs
[03:16:27] SteenJobs: has joined #RubyOnRails
[04:39:31] SteenJobs: Quit: SteenJobs
[05:22:33] SteenJobs: has joined #RubyOnRails
[05:22:43] SteenJobs: Client Quit
[17:26:35] SteenJobs: has joined #RubyOnRails
[22:42:57] SteenJobs: Quit: SteenJobs

2018-11-05

[16:24:10] SteenJobs: has joined #RubyOnRails
[19:31:05] SteenJobs: Quit: SteenJobs
[21:29:08] SteenJobs: has joined #RubyOnRails

2018-11-01

[03:04:50] SteenJobs: has joined #RubyOnRails
[08:21:11] SteenJobs: Quit: SteenJobs
[18:29:45] SteenJobs: has joined #RubyOnRails
[18:39:48] SteenJobs: Quit: SteenJobs
[18:44:05] SteenJobs: has joined #RubyOnRails
[21:39:36] SteenJobs: Read error: Connection reset by peer
[23:56:24] SteenJobs: has joined #RubyOnRails
[23:56:31] SteenJobs: Client Quit

2018-10-31

[20:28:20] SteenJobs: has joined #RubyOnRails
[23:50:57] SteenJobs: Quit: SteenJobs

2018-10-30

[01:12:15] SteenJobs: Quit: SteenJobs
[04:21:24] SteenJobs: has joined #ruby
[04:21:24] SteenJobs: has joined #RubyOnRails
[08:40:28] SteenJobs: Quit: SteenJobs
[08:51:03] SteenJobs: has joined #ruby
[08:51:03] SteenJobs: has joined #RubyOnRails
[08:51:06] SteenJobs: Client Quit

2018-10-29

[17:49:10] SteenJobs: has joined #RubyOnRails
[17:49:24] SteenJobs: has joined #ruby
[21:15:48] SteenJobs: Quit: SteenJobs
[21:26:57] SteenJobs: has joined #ruby
[21:26:57] SteenJobs: has joined #RubyOnRails

2018-10-25

[06:53:29] SteenJobs: Quit: SteenJobs
[07:02:25] SteenJobs: has joined #ruby
[07:02:25] SteenJobs: has joined #RubyOnRails
[08:01:35] SteenJobs: Quit: SteenJobs
[14:30:10] SteenJobs: has joined #ruby
[14:30:10] SteenJobs: has joined #RubyOnRails
[16:15:58] SteenJobs: Quit: SteenJobs

2018-10-24

[05:17:24] SteenJobs: has joined #ruby
[05:17:24] SteenJobs: has joined #RubyOnRails
[06:58:27] SteenJobs: Quit: SteenJobs
[14:35:13] SteenJobs: has joined #ruby
[14:35:13] SteenJobs: has joined #RubyOnRails
[15:58:19] SteenJobs: Quit: SteenJobs
[16:15:44] SteenJobs: has joined #ruby
[16:15:44] SteenJobs: has joined #RubyOnRails
[18:10:50] SteenJobs: Read error: Connection reset by peer
[18:11:29] SteenJobs: has joined #ruby
[18:11:29] SteenJobs: has joined #RubyOnRails
[18:30:37] SteenJobs: Read error: Connection reset by peer
[18:31:54] SteenJobs: has joined #ruby
[18:31:54] SteenJobs: has joined #RubyOnRails
[20:20:51] SteenJobs: Quit: SteenJobs
[20:25:23] SteenJobs: has joined #ruby
[20:25:23] SteenJobs: has joined #RubyOnRails
[23:48:13] SteenJobs: Quit: SteenJobs
[23:57:37] SteenJobs: has joined #ruby
[23:57:37] SteenJobs: has joined #RubyOnRails

2018-10-23

[15:59:07] SteenJobs: has joined #RubyOnRails
[16:04:56] SteenJobs: has joined #ruby
[16:07:53] SteenJobs: Hi all - been reading through the various different ways to execute system/shell commands, and I still can’t quite figure out which methods execute the given commands in a subshell vs as a subprocess (akin to python’s `shell=false`), so was hoping someone could help me clear things up
[16:36:38] SteenJobs: al2o3-cr: Great, thanks! - so in my script, i want to run a couple git commands, (1) `git fetch` and (2) `git pull`, and then (3) check `git status` - it seems like Open3#capture2 is a great candidate for (3), but for (1) and (2) I see no reason to execute in a subshell, but `exec` will replace the current process rather than creating a subprocess, so what would be a good option for (1) and (2)?
[16:37:42] SteenJobs: ugh *i’m writing the script based on a python script from a coworker, where the (1) and (2) equivalent is called using `subprocess.call` to provide some context
[16:49:53] SteenJobs: haha typing rn, ironing out my thoughts/questions, very much appreciated :)
[16:50:14] SteenJobs: al2o3-cr: my understanding is the parent process will inherit stderr when using Open3.capture2e/3, and i don’t really need to do anything with stderr other than display it and exit the script (which I understand I can do using the status object)
[16:50:45] SteenJobs: as for Process.spawn, it looks like the execution is done asynchronously without explicitly calling Process.wait, is that correct?
[16:52:07] SteenJobs: is the same true for Open3?
[16:53:05] SteenJobs: asking with regards to both Open3.capture* and Open3.popen*
[16:53:21] SteenJobs: ah ok - what exactly is the `wait_thr` param that gets passed into the block for the popen* methods?
[16:57:59] SteenJobs: ok got it, yea wasn’t sure what the object type was
[16:58:30] SteenJobs: so out of curiosity, if Open3 is by default synchronous, how would one use Open3 methods asynchronously? (not applicable to my use case since i need synchronous execution)
[17:02:37] SteenJobs: hmm just pulled up the Process::Waiter docs and looks like pid is its only instance method - but the docs for Open3 show `wait_thr.value` returning a Process::Status object
[17:08:50] SteenJobs: ah ok, missed that bit
[17:11:52] SteenJobs: al2o3-cr: i’ll look thru the docs - it does seem that Kernel#system is probably the most straightforward way for (1) and (2) above, and since there’s no input, i guess there’s no potential issue with running a subshell
[17:14:26] SteenJobs: al2o3-cr: do any of the methods for executing commands bubble up exceptions such that the parent process will simply fail and terminate execution without explicitly checking the Process::Status object?
[17:17:01] SteenJobs: al2o3-cr: for either Open3 or Kernel (are Kernel#spawn and Process#spawn identical?)
[17:21:49] SteenJobs: i guess for example if the subprocess executes a `git fetch` and for whatever reason origin doesn’t exist or something occured that would cause `git fetch` to fail, would all the methods we discussed require explicitly checking the status object?
[17:24:07] SteenJobs: Ok cool - oneeee last q - with Open3.capture*, if stderr is inherited, what exactly does that mean? I assume it means that the subprocess shares the same stderr as the parent process, so in the `git fetch` case, if the child process has a non-zero exit status, would that cause the parent process (the containing script) to stop execution?
[17:24:30] SteenJobs: but yea, in practice i’ll use system for 1 and 2
[17:56:59] SteenJobs: Quit: SteenJobs
[20:34:42] SteenJobs: has joined #ruby
[20:34:42] SteenJobs: has joined #RubyOnRails
[20:51:13] SteenJobs: al2o3-cr: thanks for the help before, sorry i suddenly disappeared, totally lost track of time and had to bolt to an appointment haha
[20:58:32] SteenJobs: Quit: SteenJobs
[21:02:33] SteenJobs: has joined #ruby
[21:02:33] SteenJobs: has joined #RubyOnRails
[22:15:46] SteenJobs: Quit: SteenJobs
[22:17:49] SteenJobs: has joined #ruby
[22:17:49] SteenJobs: has joined #RubyOnRails
[22:45:01] SteenJobs: Quit: SteenJobs

2018-10-19

[00:44:16] SteenJobs: Quit: SteenJobs
[15:36:35] SteenJobs: has joined #RubyOnRails
[19:34:11] SteenJobs: Read error: Connection reset by peer
[21:25:49] SteenJobs: has joined #RubyOnRails
[23:10:52] SteenJobs: Quit: SteenJobs

2018-10-18

[17:09:27] SteenJobs: has joined #RubyOnRails
[19:38:47] SteenJobs: Quit: SteenJobs
[19:50:36] SteenJobs: has joined #RubyOnRails

2018-09-08

[00:23:36] SteenJobs: Quit: SteenJobs
[00:24:12] SteenJobs: has joined #RubyOnRails
[00:28:48] SteenJobs: Ping timeout: 272 seconds
[09:00:46] SteenJobs: has joined #RubyOnRails
[19:04:48] SteenJobs: Quit: SteenJobs

2018-09-07

[04:49:56] SteenJobs: Quit: SteenJobs
[04:54:00] SteenJobs: has joined #RubyOnRails
[07:24:28] SteenJobs: Quit: SteenJobs
[16:36:00] SteenJobs: has joined #RubyOnRails

2018-09-06

[23:25:50] SteenJobs: has joined #RubyOnRails

2018-09-04

[22:25:09] SteenJobs: has joined #RubyOnRails
[23:09:58] SteenJobs: Quit: SteenJobs
[23:53:59] SteenJobs: has joined #RubyOnRails
[23:54:01] SteenJobs: Client Quit

2018-08-29

[00:00:05] SteenJobs: has joined #RubyOnRails
[00:00:29] SteenJobs: Client Quit
[01:57:43] SteenJobs: Client Quit
[01:57:43] SteenJobs: has joined #RubyOnRails

2018-08-28

[22:53:42] SteenJobs: has joined #RubyOnRails
[23:45:00] SteenJobs: Quit: SteenJobs

2018-08-22

[12:13:37] SteenJobs: has joined #RubyOnRails
[12:52:46] SteenJobs: Quit: SteenJobs
[13:02:17] SteenJobs: has joined #RubyOnRails
[17:10:09] SteenJobs: Quit: SteenJobs
[17:15:58] SteenJobs: has joined #RubyOnRails

2018-08-21

[05:08:42] SteenJobs: has joined #RubyOnRails
[05:24:43] SteenJobs: Quit: SteenJobs

2018-08-20

[20:18:44] SteenJobs: has joined #RubyOnRails
[21:51:42] SteenJobs: Quit: SteenJobs
[21:59:52] SteenJobs: has joined #RubyOnRails
[23:07:28] SteenJobs: Quit: SteenJobs
[23:10:02] SteenJobs: has joined #RubyOnRails
[23:17:20] SteenJobs: Ping timeout: 272 seconds
[23:18:56] SteenJobs: has joined #RubyOnRails
[23:22:12] SteenJobs: Client Quit

2018-08-10

[01:04:23] SteenJobs: has joined #RubyOnRails
[01:44:47] SteenJobs: Quit: SteenJobs
[03:27:32] SteenJobs: has joined #RubyOnRails
[03:57:48] SteenJobs: Quit: SteenJobs
[04:03:52] SteenJobs: has joined #RubyOnRails
[04:04:12] SteenJobs: Client Quit

2018-07-31

[00:05:22] SteenJobs: has joined #RubyOnRails
[00:25:42] SteenJobs: Quit: SteenJobs
[00:55:38] SteenJobs: has joined #RubyOnRails
[01:00:02] SteenJobs: Ping timeout: 256 seconds
[01:56:20] SteenJobs: has joined #RubyOnRails
[05:17:16] SteenJobs: Quit: SteenJobs
[05:19:14] SteenJobs: has joined #RubyOnRails
[05:27:23] SteenJobs: Quit: SteenJobs
[14:12:16] SteenJobs: has joined #RubyOnRails
[21:40:52] SteenJobs: Quit: SteenJobs
[21:42:47] SteenJobs: has joined #RubyOnRails
[21:42:48] SteenJobs: Client Quit

2018-07-30

[17:25:52] SteenJobs: has joined #RubyOnRails
[18:00:29] SteenJobs: Quit: SteenJobs
[18:01:53] SteenJobs: has joined #RubyOnRails
[18:58:35] SteenJobs: Quit: SteenJobs
[20:17:10] SteenJobs: has joined #RubyOnRails
[22:52:22] SteenJobs: Quit: SteenJobs

2018-07-26

[01:46:13] SteenJobs: has joined #RubyOnRails
[01:46:23] SteenJobs: Client Quit

2018-07-25

[17:02:15] SteenJobs: has joined #RubyOnRails
[20:22:23] SteenJobs: Quit: SteenJobs
[20:28:07] SteenJobs: has joined #RubyOnRails
[23:32:45] SteenJobs: Quit: SteenJobs

2018-07-24

[15:11:53] SteenJobs: has joined #RubyOnRails
[19:14:26] SteenJobs: Quit: SteenJobs
[19:33:30] SteenJobs: has joined #RubyOnRails
[19:38:34] SteenJobs: Read error: Connection reset by peer
[19:38:49] SteenJobs: has joined #RubyOnRails
[22:30:28] SteenJobs: Quit: SteenJobs

2018-07-14

[00:19:49] SteenJobs: has joined #RubyOnRails
[00:21:41] SteenJobs: Client Quit

2018-07-13

[15:01:50] SteenJobs: has joined #RubyOnRails
[16:28:47] SteenJobs: Quit: SteenJobs
[18:39:18] SteenJobs: has joined #RubyOnRails
[21:10:55] SteenJobs: Quit: SteenJobs

2018-07-12

[01:19:49] SteenJobs: been a few hours so figured i’d try again: based on the json api spec, from both the perspective of the backend and the client consuming the api, is there any non-semantic reason why including a related resource, e.g. `comments` on an `article`, in the `relationships` object is advantageous to making it a property on the `article` object itself - specifically in a case where there is no `links` object included?
[03:36:57] SteenJobs: hahuang65 much appreciated! yea, i mean that’s what i was originally thinking, but then i also realized that from the client side, even when using `relationships`, the programmer consuming the API still has to know what and how to parse the object when writing a deserializer, so the consumer still needs to know that there’s a `comments` property, whether as a property on the main resource or inside the `relationships` object -
[03:36:58] SteenJobs: granted it helps semantically to place it in the `relationships` object, but i also think it’s pretty clear if the main resource has a property `comments` that is an array of objects that look like `{type: “comment”, id: 50}`, i.e. resource identifier objects
[03:37:17] SteenJobs: full disclosure i do primarily iOS development now (but used to do rails dev some time back)
[03:38:42] SteenJobs: as for the backend side, i feel like attaching or removing a relational resource to the response inside the `relationships` object is no easier than adding or removing a property on the main object itself, but maybe i’m wrong about that?
[03:40:09] SteenJobs: privately consumed api, and someone on the backend team started pushing for following the spec, so i took a deep dive and just trying to figure out any non-semantic practical utility for doing things this way
[03:41:02] SteenJobs: but even the root level object is a dict, so why would adding or removing a key/value pair from the root level be different than adding or removing it from inside another dict?
[03:41:19] SteenJobs: not challenging what you said, it sounds right to me, just trying to figure out what i’m missing
[03:43:33] SteenJobs: on the client, let’s say somewhere in my code i have `var commentArray = article[“relationships”][“comments”]` or `var commentArray = article[“comments”]` - it seems that either way, the client code will have to account for the possibility of `commentArray` being nil
[03:46:09] SteenJobs: hahuang65: thanks a bunch, i’ve been at this all day
[04:00:41] SteenJobs: hahuang65: i’ll have to ruminate over it a bit more, but i definitely agree that it’s undoubtedly semantically more clear
[04:03:25] SteenJobs: hahuang65 have some more thoughts on your gist, i’ll keep an eye out for you tomorrow
[04:03:29] SteenJobs: really appreciate it
[11:39:49] SteenJobs: Quit: SteenJobs
[15:01:51] SteenJobs: has joined #RubyOnRails
[22:05:59] SteenJobs: Quit: SteenJobs

2018-07-11

[23:48:43] SteenJobs: has joined #RubyOnRails
[23:51:36] SteenJobs: based on the json api spec, from both the perspective of the backend and the client consuming the api, is there any non-semantic reason why including a related resource, e.g. `comments` on an `article`, in the `relationships` object is advantageous to making it a property on the `article` object itself - specifically in a case where there is no `links` object included?

2018-07-10

[02:48:15] SteenJobs: Quit: SteenJobs
[03:28:55] SteenJobs: has joined #RubyOnRails
[03:28:58] SteenJobs: Client Quit

2018-07-09

[19:02:57] SteenJobs: has joined #RubyOnRails
[19:03:51] SteenJobs: Client Quit
[23:54:26] SteenJobs: has joined #RubyOnRails

2018-07-06

[22:24:14] SteenJobs: has joined #RubyOnRails
[22:50:27] SteenJobs: Quit: SteenJobs

2018-06-19

[01:33:11] SteenJobs: Quit: SteenJobs

2018-06-18

[23:55:52] SteenJobs: has joined #RubyOnRails