 Ya, so hi, so my name is Ruben so I'm going to share a little bit about what I did last year I took some time off to travel so while travelling I was trying to do some freelancing work just to supplement my travel expenses so I got a phone call from my friend he asked me hey, do you want to do a small project together and he is new to Rails so I was like sure, why not so the thing is about Jenkins and Rails Engine but it's more like working remotely with new Rails developers so the situation is I have two friends there's newly converted Rails developers they are from Java background and PHP background but they know NVC pretty well so I think it's quite easy for them to transit to Rails more agile development basically it's just always a working software so the client is able to log into the staging server to see the latest updates, what not working remotely of course because I'm travelling so this picture is taken in Centaurini the cat overtook my workplace so the picture of them and of course low budget because it's a small project so there's still things that we need to work together with so at the end of the day we decided so how we set up the environment basically for project management we use Trello so the client has access to Trello too he'll be able to create cards some e-bugs and what not Google Docs for basically all the documentation whatever that my friend talk to the client whatever will be on Google Docs communication is slack CI is Jenkins so the purpose of Jenkins is to ensure that at least the staging server don't break because dealing with a new Rails developer we do want as much as possible to not have more bugs that is needed and then Alessian for the Git repo so moving forward a bit of Trello so this is basically how we split the cards client will always submit cards on the left hand side and then to do, doing, done, review and complete is when the client will to look at the done and then move it to review and complete so that's how we roughly keep track of how to progress like slack so basically obviously Trello is integrated with slack so you can so the client is able to move cards do screenshots and yup, so that's how we talk to one another so every time when I login I need to know the status basically I login here and there's a build management so Jenkins, whatever build will goes to this so this is like my to-go place to know the status of the server or to know what is happening in the project so Jenkins so this is the build pipeline so the first pipeline is bundled install then you run our spec and test coverage the test coverage is more so for my, more so for us to write enough test so that you will not fail so we put the test coverage at 80% so every time when the test coverage drops below 80% of the entire application it fails so kind of try to force us to write more spec to cover the application code analysis and then lastly to deploy to staging so every time when you push to a branch this pipeline will run and every time it fails it will alert slack and then somebody else has to go and fix or rather usually I'm the one that go and fix okay when I have internet of course and a little bit of code coverage so this is our code simple code so this is what we use so in Jenkins you will able to see everything what is tested, what is not tested how much percentage so code analysis truth be told we don't really use much of this it does that so if there is anything that is really really bad we can go in here to see so this is code analysis so what CI is to make sure that at least when they do development there is a certain check and procedures in place so that they won't push codes that will break staging and then the client won't be able to see anything at all so moving forward while we are developing we encounter some issues so there will be so what happen it's okay now the app so the app has 3 parts to it there is an app portal which usually the management will go in to view reports basically the app means so they can do everything and then there is API interface the interface with android application and there is a main application where the regular users will go in and fill in data and what not so there are 3 main apps so initially when we first started off was basically one big rails structure and inside there we do name spacing so you have the controller for main app controller for admin portal and API interface but what happen is that the view start to get really crowded so we start to see things like if it's admin display this if it's not then display that and then it start to get also getting more and more crowded so it's really hard for all of us to develop on it because we tend to conflict with one another so i did a bit of research and found about rails engine so rails engine is many popular because device use rails engine rails app mean also use rails engine so there's a few that use it so i went to do a bit of research since it's small project and it's good to learn something new so with rails engine this is what we get basically it's MVC in each of the engine itself and then it's writing on a rails application so in that case my friend can work on the admin i can work on the API the views does not clash with one another it's good because at the end of the day what the client want was the admin portal and the main application to be two separate UIs so when they login they can see the difference otherwise they won't tell the difference beside the URL they can't tell the difference visually so it's really good in that sense that this rails engine so we split up this way but when you deal with rails engine we have to consider a few facts so by default rails engine is built like a gem so you just do in your gem file it does include the rails engine but it doesn't it kind of doesn't make sense because for gem the idea is that you can put it into multiple other projects but this is not exactly gem by itself it's more like refactoring so it's either use a gem or you can energize some boot where should you put the spec file should you put everything in one main application or should you put individually in and then how do you do testing so if you do a bit of googling you will like some decide to put it in one main application and some decided to put it into different engine itself and generators because I'm dealing with a lot of new new rails developers so we tend to use rails generate controller and then it generates the controller it generates the spec files and the models and what not so definitely the engine itself will also have to produce generators like that so that was the thought process how should we structure the rails engine so at the end of the day we decided to go look on boot so in the application.rb basically it does initialize the rails engine and just run it by itself okay and the next one it's generators so thank god for pivotal even migration can be placed in the engine itself so on the main application if you do like rate db migrate it actually takes whatever from the engine migration files too so you can split it but yet you can do it in one line command and it runs everything from the engine side perspective and then you have the generators so we use our spec and so within the engine itself you can do rail generate and it generates the codes that's available so my friend will just have to go in and change accordingly so that's how we implement it and then at the end of the day the aspects are living in their own rails engine so so basically you just write a rig file and just run all the aspect so basically that is placed in the ci in the Jenkins part of it Jenkins run it runs the main application spec it runs the interface spec it runs the admin spec and that's how the Jenkins work with this aspect so how did it turn out it turned out well at the end there's less overlapping of codes in the view it's very nicely segregated the developer can work on one specific vertical and not touch the other things there's no bottleneck for deployment of codes because it's run by Jenkins so every time when they need to deploy something it just push to git and the build pack blind will automatically deploy everything so even though when I'm not okay this is my flux oh how do I sorry yeah okay oh ya so where were I? ya no bottlenecks for deployment of codes so deployment of codes everything is done by Jenkins itself so anybody can deploy so by the build process we ensure certain code quality there's cases where the build break and then it alerted my friend and they realized that oh I forgot to change a certain variable in the view it's giving me a 500 error some code quality and also there's a clear separation for application so for anybody else that wants to enter into the project they can see the difference so you can see the engine and they know where to look for for the piece of codes ya so I guess that's it, thank you I work in NCS but this project has nothing to do with my job so by the way we are hiring how do you deal with the shared components i assume the models will be shared between the main application oh yes so if the shared component we put in the main application under the leap folder models you can call directly at the engine models the engine is admin portal so it will be admin portal colon colon whatever model there is there is there is like users are also shared models so they live in the main application you mentioned that the views get entered easily can you run layouts since you are main spacing your controllers can you just run a second layout ya you can actually initially we did that but what was the issue the issue is that even even for the CSS files sometimes we want to split nicely also so that is also another thing ya definitely so what initially happen was there was admin portal main application controller all the other controllers inherit from that but then your view itself everything is in that one view folder ya so i think it is more of a structure issue if you code it in that way in the inheritance way it still can be done it does that this is more clear separation ya sorry sorry for now for now when we did it it is completely separate ya if we most so what we decided is if things that is shared it should be placed in the main application ya ya ya ya ya ya so jengkit is open source which means free so travis ci firstly it is paid unless you put it your code on github which is a client project so you can put the code on the github so in the end of the day because of budget constraint and also something that i want to explore i think that is also the mentality behind ya it is a way that share you wat ya correct so that is why we didn't go with the jem perspective so that is why we loaded the engines because the idea of a gem is take it out and place it everywhere else but it is not really that case mempunyai kota. Jadi, ya. Bagaimana hari ini mempunyai tiga ripu separat? Atau mereka semua di ripu yang sama? Oh, di ripu yang sama. Mereka semua di ripu yang sama. Jadi, mana negara yang anda melihat? 1 tahun? 1 tahun yang anda melihat? Ya, jadi, semasa saya melakukan projek ini, saya berjalan selama satu tahun, bermula dengan seluruh Amerika. Kemudian, Eropa. Kemudian, Turki. Kemudian, Kuala Lumpur. Kemudian, Kuala Lumpur. Dan ya, itu yang saya selamatkan dengan. Untuk satu tahun, projek ini satu tahun? Tidak. Projek ini, saya rasa, berjaya sekitar enam bulan. Selepas enam bulan. Tetapi, setiap hari, ia tidak seperti itu. Sebab itulah jenki ada di sana. Untuk melihat sesuatu. Ya. Ya. Macam mana anda telah menerima kode untuk mencoba mana negara yang terbaik untuk koneksi internet? Saya rasa saya boleh beritahu anda mana negara yang terbaik untuk koneksi internet. Saya rasa saya ingat lebih banyak itu. Ya. Ya. Okey, terima kasih.