Dhiraj Chaudhary

Okay. So, uh, I believe in Indore, and I've been working as a Ruby on Rails developer for last four and a half years. And, uh, I've worked in 2 companies previously. Uh, uh, in one company, I worked for three and a half years, uh, and another company for 1 quarter, 1 year and, uh, 2 months, basically. So in that time, I worked in Ruby on Rails. I worked in JavaScript, uh, uh, use the Jquery, AJAX, Axios, and the database technologies that I've worked on are MySQL and Postgres, basically. Uh, and other than that, I have a good knowledge of our specs as well, the test cases that, uh, we'll be covered of the controllers, the request specs, basically, uh, uh, the model specs, the service specs, uh, and also the database schema specs as well. So I basically covered that. Uh, and, uh, I work with the front end technologies like React as well. And the VueJ is basically used on the product products that I have worked on. Uh, and, um, I have the experience of working with the product based company as well as the startups as well. So I have the knowledge about, uh, uh, connecting with the developers around the world, I have worked with the developers from UK, US, uh, Ukraine, Russia, many places, work for the client foreign clients like US clients, UK clients, uh, and Canadians as well. So I'm having the, uh, knowledge about connecting with the people of different areas as well, uh, working on the team also, having experience of managing the team as well for few months, at least we can say that. And, uh, I have also the knowledge of the sprint plannings, the, uh, scrums as well, how we do the management, have the knowledge of version control system like Git, uh, for more than 4 years, basically. Uh, and, uh, multiple technologies I have used inside them. I have used Liquid as well. I have knowledge about the CICD tool, Jenkins as well. So, basically, the deployment part as well, I know. Uh, I have the the cloud cloud platform that we are having, Google Cloud Platform. I have knowledge about that as well. Uh, so I have pretty much good understanding about multiple these areas that I've worked on 3 projects basically till now. So, yeah, that's

Okay. So, uh, basically, how we can, uh, how we can ensure that our code adheres to solid principles. So, basically, we look upon the code. We follow the standards of the code uh, that we follow in the Ruby on Rails, we have to go with the naming conventions that Ruby on Rails provides. We have to follow that particular rule. We have to follow the, uh, every line, uh, RuboCop issues as well, we have to solve them. So our code should be in more optimized manner, uh, in the most uh, safest manner as well, like, they should not be vulnerable to any particular part or to any particular scenarios. It should be clear, uh, kind of clear and everything should work perfectly uh, uh, in a more optimized manner. And our code should be durable and should exist for a longer period of time. Our code should be independent. They should follow all the basic, uh, ops concepts as well that we are having in Ruby on Rails, like, they should not go against them and, uh, should follow we should utilize all the uh, functionality is that is that was provided by Ruby on Rails in our code, uh, whenever it was necessary, uh, instead of, uh, using the external gems as well until and unless it was uh, uh, sorry. So that way we can actually cover all the solid principle. So which can make our, uh, code and platform more secure and safe.

Yeah. Okay. So, basically, I was working on a project where I have to build the, uh, auctions functionality. So when the options were there, we have to create the tutorial. Like, basically, uh, automatic, uh, auction should happen where the participants will automatically they will Enter their own values, uh, and the changes will come on the front end. So basically, the view was the real view in which we were having multiple slots, Uh, multiple, uh, line items. And, basically, each line item is having their own particular value, the, uh, the quantity and the amount values. So to solve them, basically, it was kind the view was a complex one. So deal to deal with that, like, the value should be changing on the emitted basis. The amount should should reflect on the front end. And the request should also be made to the back end basically there. So for that purpose, I have to use a JavaScript there. And, uh, it was the most challenging part for me because, uh, to deal with that, there were multiple data complexities that we were facing. Multiple scenarios were there, Which one needed to be solved and in a manner up to a time, like, how we cannot break the other things because it was kind of a complex area there. So it was one of the hardest part that I did to deal with the creating the auctions and their values. And they'll to fill out the values that we were having, give out the particular amount for particular line items and to for all the multiple values that we are having. So it was kind of a hard thing to do there.

JavaScript was basically the right solution because, uh, we needed the exact change at the right time only at that particular moment. Basically, on the If you like, uh, we have to reflect any particular value or a particular click only. So without any reloadish, uh, reloading the page, we needed the JavaScript for that purpose because JavaScript was the more advanced part. And, uh, is the suits with the Ruby on Rails perfectly? Like, uh, with Ruby on Rails, like, uh, it adds up perfectly for our particular, Uh, use case that we needed, like, uh, to be on the same view and to be on the same page and without reloading, uh, reflecting the value there. So and also to for the particular Ajax calls that we needed, like, in our in our past project. So for that, we were using the JavaScript as well. So it, uh, perfectly connects with that multiple use cases where there are many were there which were helping us from that.

I basically am not having the, uh, idea about the client 6, uh, 69 yet, But, uh, I may be having the idea about the CICD, uh, the Jenkins there that we were having for the deployment purpose while Google Cloud Platform was there to deploy our code to the server, basically, to run the application. So I'm I'm having the idea about that where we are basically configuring the Our environment configuring the setup, we are doing the using the services multiple to run the instance, the project ID. The project, basically, we got creating on that instance, applying that, Configuring our application there, installing all the requirements that we needed, and running our application, and maintaining it at the end. So that's the same, uh, done with the AWS as well, where we are creating our instance. We are having the our EC two there, basically. And then going with the database services as well, then the storage part as well. Yet. So and at the end, configuring that and maintenance. So that's how I've done. I haven't used the Cloud 69. Uh, Cloud 66, basically, but went ahead with that.

I haven't actually used the DigitalOcean, uh, for my, uh, project yet. I haven't got the chance

Uh, basically, we are looking here is that we are making our show action, but we are not rendering any particular page here. And we are not, uh, giving, but okay. You know, directly we are having the page. It will be there. Okay. That's for a simple view only. This is not an API based. Basically, I think, uh, application controller, users controller is their user. Okay. Okay. Basically, what we are doing here is that we are actually, uh, fetching the user from the params we are having, And then we are giving a condition if user is nil. Like, if user is not present, then we are fetch, uh, sending it redirecting it to the dashboard. Basically, the landing page, we can say. The root URL we are having. Uh, there we are re redirecting if the if the user is not present. Uh, there are no issues other than that. Uh, there are no issues

I think communication can be between, like, if we can store the values in the cache Uh, the cookies, we can have them. Inside them, we can store the village, which can be used afterwards. So, basically, uh, that we can do that or asynchronous communication you are saying um

We have to particularly create a good structure which can be perfectly fine. Like, uh, it should not fail while we have created the application, and it should not be causing any issues. Like, The complexity should be 0. Like, it should be maintainable. We can say it should be easily maintainable even if we are getting any issues and can be easily modified modify modifiable as well. Like, we can modify them. So that's we can do to create any particular Rails application. The architect should be correct there. For. Things should be perfectly covered previously. Even before creating, we should perfectly clear all those scenarios, cover everything there, off, and, uh, everything should be planned on that purpose.

Basically, worked on, uh, worked on a particular controller, the particular area of the project, which was, uh, previously built but needed the changes because it was built on the old concepts, and the, uh, code was not, good refactored, it was in very bit bad condition. So, basically, I have to create the whole functionality, how to set up the new controller for that purpose. I'll say the I'll I have modified that controller, but from the 0th level. Like, I went ahead with that, created the functionality there, did all the refactoring of the code that was necessary, covered all of the parts which can create any issues, and there were actually many issues at that moment also. So we went ahead with, like, solving all those issues. All those issue inside that fix. Like, all the things that we were having in past, we fixed all of that and created a good maintained code that optimized one as well, followed the current principle, everything, like, uh, the studying co standard of the code that we uh, we need to follow followed all of that.