This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[09:42:55] * ChanServ sets mode: +o temporalfox [14:31:06] <wj> Hi Guys, Can anyone recommend any books on Vert.x 3 ? [14:36:17] <AlexLehm> i am not aware of any books for 3.x, there are some for 2.x [14:36:46] <temporalfox> wj unfortunately nobody has worked on a vertx 3 book [14:37:02] <temporalfox> wj that being said, our documentation covers pretty much everything [14:37:06] <AlexLehm> temporalfox: Julien, you should write one [14:37:26] <temporalfox> wj I'm thinking we should have an open collaborative book effort [14:38:20] <temporalfox> AlexLehm a book is so much work [14:38:26] <AlexLehm> i figure [14:38:42] <AlexLehm> who wote the books about vert.x 2? [14:40:06] <temporalfox> I don't know - I wasn't much in the vertx community at this time [14:44:49] <AlexLehm> me neither [14:49:15] <temporalfox> AlexLehm there is going to be soon a poll about vertx new features [14:49:19] <temporalfox> like last year [14:49:28] <temporalfox> do you have some ideas to share ? [14:50:33] <wj> Is temporalfox related to timfox? (Just kidding), I agree vertx is heavily documented on its website. The reason why i am asking about a vertx 3 book is because of my background.(JEE way of doing things) and since everyone is screaming micro-services am thinking of switching stack. [14:51:04] <temporalfox> wj I used to work with Tim and now I'm leading the project [14:51:17] <wj> In essence, am looking for some material that would make it easy for someone with JEE background to move into vertx land and be feel at home. [14:51:20] <temporalfox> the reason my nick ends with fox is purely coincidental [14:51:33] <temporalfox> wj I see [14:52:01] <temporalfox> I wrote this article a few months ago [14:52:10] <temporalfox> that could be helpful [14:52:14] <AlexLehm> i may have some very small things to suggest, i will think about it a bit [14:52:49] <wj> i would check it out, thanks. [14:52:50] <temporalfox> wj yes the concurrency approach is not the same [14:52:56] <temporalfox> I could write an article on that [14:53:04] <temporalfox> as a brother of this article [14:53:15] <temporalfox> I'm preparing a talk also on Vert.x concurrency patterns [14:58:12] <wj> Also, i have issues i have coming from a JEE background is …….(App Servers), usually these app servers give you assumed assurance that when it comes to serving ALOT of users, you are covered. Now Vertx comes along and says hey….you dont need an App Server. just write a class (extend AbstractVerticle) and booom! You are Done!!! [14:58:27] <wj> Feels like too much magic going on. [14:58:47] <temporalfox> wj can you elaborate ? [14:59:35] <temporalfox> you mean that the more complex a solution is, the more reinssuring you feel ? [15:00:17] <temporalfox> I think it's a perception issue [15:00:28] <temporalfox> after all how many lines do you need to start a service ? [15:01:18] <wj> I personally don't feel that way….. But that is how people try to justify the complexity of the app servers. It's got to be complex for a reason right? [15:02:03] <temporalfox> vertx inside is not trivial [15:02:14] <temporalfox> though [15:06:54] <wj> I know its not. Based on what i have read so far about it. All i am saying is…..if a developer has been building apps the JEE way, it might take some convincing to say……. “take this vertx jar and you become faster than most app servers.” [15:07:38] <temporalfox> yeah… [15:07:48] <temporalfox> the point is about scalability and not speed actually [15:09:20] <temporalfox> I've build a talk around this recently [15:09:22] <temporalfox> using HTTP/2 [15:10:33] <temporalfox> explaining why an HTTP/2 app with vertx will be better than the traiditional blocking model [15:25:38] <wj> Keep up the good work, i see vertx going alot more places. [15:33:47] <temporalfox> wj thanks, we are working hard on building the vertx community [15:39:01] <AlexLehm> temporalfox: while reading the release notes from Clement, I notice that the issue says fix http proxy errors not being reported, I think I forgot to check the same issue on NetClient connections [15:39:25] <temporalfox> AlexLehm what do you mean ? [15:39:35] <temporalfox> I think on NetClient we allow either CONNECT or SOCKS [15:40:09] <AlexLehm> the previous issue [15:40:30] <AlexLehm> Proxy based http connections do not throw Proxy errors - [15:45:38] <AlexLehm> i will try to check that later and if necessary create an issue [15:47:33] <temporalfox> ah on connect error ? [15:47:40] <temporalfox> it would be good to fix it in 3.2.2 [15:47:44] <temporalfox> 3.3.2 [15:47:50] <temporalfox> I thought both were covered [15:48:14] <temporalfox> and it should be done kind of now :-) [15:48:43] <AlexLehm> i am trying to remember but I am not sure, i have to check the unit tests later. It might be that I only considered the http case since the guy who wrote the issue found it with http [15:48:47] <temporalfox> [15:48:51] <temporalfox> it seems to be generic [15:48:56] <temporalfox> although it is not tested for NetClient [15:49:11] <temporalfox> no ? [15:49:43] <AlexLehm> ah, if it inside the ProxyChannelProvider it should work for both cases since they use the class, then only some unit tests may be missing, we can do that later [15:49:56] <AlexLehm> ok, then we are good there [15:50:01] <temporalfox> yes that's what I'm thinking too [15:50:12] <temporalfox> I would like to be *ok* with 3.3.2 for a while :-) [15:50:24] <temporalfox> otherwise I won't have any holidays :-) [15:50:32] <AlexLehm> ok, from my point of view its ok [15:51:30] <AlexLehm> no last minute changes i can think of [15:51:40] <temporalfox> yeap [19:18:39] * ChanServ sets mode: +o temporal_