Engineering Complex Applications with Laravel 4

Comments

Comments are closed.

Anonymous at 16:36 on 31 Aug 2013

Anonymous at 16:54 on 31 Aug 2013

Anonymous at 17:05 on 31 Aug 2013

Anonymous at 17:22 on 31 Aug 2013

Not really suited for public speaking.

Appreciate the insights in this talk! Always great to see how somebody goes about engineering apps that are much more complex than "hello world".

Having been up on stage, I can really appreciate what it takes to get up in front of hundreds of people, and I think you went very well mate :)

Top job.

Good talk, showing some other ways of dealing with Laravel. If anything, Kapil demonstrated that you're not locked into any specific way of developing. The main problem however, was what appeared to be some flaws in the architecture, which may not have been too well communicated in the timespan allotted. I would like to hear more, as I feel the talk was too fast for the amount of content and the concepts being communicated.

I was looking forward to this talk but didn't feel the content really matched the title. To me it seemed a little more "show and tell" like.

Anonymous at 23:28 on 31 Aug 2013

I'll never outsource to India

Anonymous at 23:30 on 31 Aug 2013

My expectation based on the topic and what was delivered got me into some level of confusions, although this could have been a gap between what was communicated. I did expect this topic to cover more on the complexity of an application with real world use cases. The topic says "Engineering complex application" which certainly feels like it should have been better to if Kapil could show the stages of a complex application development which involves complex situations and dealing with such situations in a programming context, rather than just a structure. Something more like dividing the complexity to simple parts to solve the problems, or in other words "divide and conquer". I am trying to be honest here. Thanks.

I think Kapil's ideas are very interesting, writing a complex application will end up making a complex architecture, so hiding the 'ugly' code in the service-provider layer to provide yourself with the 'eloquent' code for normal stuff sounds pretty sensible.

Kapil is obviously a very talented programmer, but as Kirk said, I think we really needed more time with the codebase than the presentation afforded. I feel some of the low marks here may have come from people who didn't get it. I have a feeling that most people writing the kind of application Kapil appears to be doing in this talk would end up with much less maintainable and uglier code. I'm really interested to see where this goes and would certainly like to follow along with development.

Noticebly he had knowledge of Laravel and building complex stuff, but it could've been communicated better with more code examples of "bad" vs "good" ways of doing it as other speakers did. Did appreciate the talk though.

Anonymous at 15:59 on 1 Sep 2013

His time alloted could've been alloted on something more useful.

Anonymous at 18:31 on 1 Sep 2013

Too much ground to cover for a subject like this.

Hello, first of all, thanks for everyone who was there for being there.

What I tried to do with the talk is basically express what I think about software development and kind of try and put my own thought process when I am doing things out there. Yes the talk was kind of complex. But its because software development itself is complex. And I felt I couldn't have done it justice by simplifying it beyond a certain level.

I'm gonna try and cover the (valid)complaints people had with the talk over here.

For the anon guy who wanted stages of complex application development instead of structure, well, the structure is something that takes away a large number of pain points that one faces when developing complex applications. However I kind of get the idea that it would have been better to show how that structure evolved, but it really came out over such a large number of iterations that have been lost over time, and are very hard to trace back.(a blessing and a curse of being involved with 3 projects that change very rapidly and are very different of each other)

Hey Jason, I kind of agree that the talk was somewhat show and tell. I was trying to show what works, and why that works. I think the problem might have been that I first told and then showed :P


And for people who wanted more time with the codebase, I am sorry I wasn't able to cover it properly enough. You can of course check out the slides once they are up, and go through the code, and the accompanying slides. The code is very readable and probably going through it one more time would give you a better perspective.

I'd like to add that I am really grateful to the community for giving me this opportunity. When making this talk I kinda decided that since the talk is going to live on in the world wide web forever, its more important for the talk to have the ideas that i would like to share with all other developers and be something that people would try to think about, form their own ideas, and probably try and understand more. Just give it another look, and a bit more time.

And for the trolls, just fuck off

I liked what the talk tried to cover, but I was easily lost. There was definitely some interesting information in there - But it was just so much in one talk. Maybe next time "kill your own darlings" and focus on part of the project.

I also had a feeling that the speaker was talking too quickly and at times, it was hard to understand what he was saying. When someone has an accent they really need to speak a bit slower so that it's easy to understand.

I really appreciated taking a look in a complex infrastructure. What's nice about it is that every developer takes a slightly different approach towards it. So you always learn from looking at other people's code. You are clearly a talented developer. As for as presenting goes I must admit I didn't think it went that well. You raced through the slides and were basically so verbose that you became very hard to follow. You have quite a heavy accent so you would need to pay extra attention to structure and speed.