 Okay, thank you. So, we have a new one. It's going to be called the OPAC Development Experience, by Eric. And this is also Robert, who is currently with us as well. And before we begin, I just want to let you start hanging out there for a few more seconds, for you to endure. And now we can move on to today's agenda. Just turn it off the table. Okay, we are going to start here very still. So, in this agenda, we are going to talk about the one-ist development experience. And we are going to look at three different kinds of categories of tools related to development experience. We are going to look at the commercial problem, building, testing. And then when I ask you, you can put it all together into one beginning workload that you can apply in your day-to-day work on the OPAC. But before we begin, I'm Eric. I work at CERCEL in the hotspot in Amsterdam. This is it. As my colleagues know, I tend to work a little bit for the vertical ways, particularly with some other between the structures. I also have to make sure that the test systems works cool too, such as catering, getting all these corners. You can find it on the ARC channel on either CERCEL.net under my OPAC username. She has it. So, let's get on with the development experience. What is it? I want to start off by defining the other term, actually. The two experiences. The beginning of the user experience is the person, the motion, the activities, what people can actually do from the system for service. Now, the thing is that developers, we are users too. We have to use a lot of tools, to work with worker control, with field systems, testing systems, with frameworks, IEDs, about services. And the development experience is the experience of using all the development tools for a project. Now, if we apply this to OpenADK, we'll see that we actually have quite a few tools that we may use of when working on OpenADK. We have EZS tools, for example, 8G or material. The various plugins that OpenADK provides to the VCS tools, such as Vabran, Daphon, GateCheck. We have the field system itself, mainly consisting of Configure and Make. We have the testing tools and system. We have G2A, the test harness and the driver. We have Google tests, for those of you who are working in HotBot. But we also have a bunch of libraries and frameworks. We can use the tested V and V unit to run with that. The IED support, not only generating project files for those field files, but also the IEDs themselves, such as Eclipse, NetBeans, IntelliJ, E-Max, the other bin. And also a bunch of services that we use, the JBS, the bug system. You upload your web apps to CR and you communicate. We make requests on IOC and maybe something else. And all of these files together are from the developer experience. Now, the good thing about being a developer is that you know a lot of these tools. You're not only going to be a consumer, you're also going to be a producer. We can change a lot of these tools and thereby enhance our day-to-day life and our developer experience. And in this talk, we're going to have a look at the three first categories. We're going to see a look at the GCS tools, and we're going to look at the build system and the testing systems. So that's getting into this So OpenADK uses Mercurial or 8B for short as the version control system. And the big thing that happened in the last year with regards to the developer experience here was in 1996. From some of the data needed for us in the single repository, which consisted of eight. So OpenADK, the project for a new German sort of coherent repository was edited at three of the repositories, eight of them. We wanted to work with both OpenADK and it was a bit of an issue there, but the great news is that in 2006, OpenADK was editing from eight into one repository. If you want to work on the latest mainline, you can have a single HG code command and get the GADK, GADK source code. The values here are multiple. As you can see on the slide, it's easy to get started. It's easier to wrap your head around how the repository is laid out. You get a ton of commits. If I make a change to multiple and I make a change to the GADK, I can now commit to this one atomic commit previously done in different repositories, so we had to correlate changes, but now it's one commit going into the project. We also have one hash for one year commit describing the entire state of the project during the entire time, which is great if you want to describe like, yeah, I'm working on a change here that applies to this commit. You're going to have to describe one commit and one repository. You can see this guy, eight different hashes or eight different commits. We're going to say what you work at 5.2. Now, more only as we've got work on our side, Mercurial Hub Suite has done tremendous work in 2017. Mercurial is approximately releasing every three months new features in the new HG releases and the latest one 4.5 is just around the corner. So a few things that I think really stand out in 2017 is that the story around editing local commits and history is much better now than Mercurial. You have commands now such as amend, unamend, uncommit, split, split, we base and shell. Also in a safe way, change of history is a little bit nice to work with before we push it off up-speed. The interface has improved. We are getting some extensions moving into core material. We see that the pager extension is the UI of HG8. The core extension is also available in UI of course I think. Show has been introduced and you play in for getting a better overview of the work. Graph log for getting a better look at history. And the performance has also been greatly improved. And as we go through working on OVNK I can highly recommend the FS monitor extension which uses watchman and therefore get final notifications when things are changed. So if you're on command such as HG status they will execute much, much faster. Now just to grow it up here this is actually my HGRC my configuration file that I use when working with it. This is my computer 4.5. I put my OVNK user name in there I turn on the page in it and cover it the settings so I get a better output and I set the wiring in my terminal. I even have a bunch of extensions some of these are experimental some are more stable but to me they're all vital to my workflow at least. If you want to get more into the detailed details of this you can come and talk to me afterwards. So with that, once you have the source code and what you're going to do with it yes you want to build it. So that's what we want to film in a bit. Since around September 2016 the so-called new build system has been in place. And it's used for OVNK so nowadays you just type that computer and it will build the product. The great thing here is that Confidium is actually very helpful if you're missing something at the terminal somewhere it will help you out in a good way. For example here I removed the C++ from my Devian system so Confidium would tell me I could not find a suitable C++ but since it knows that I'm running Devian it suggests that maybe you should go ahead and get this build center package and find it. The documentation has been improved for the building and you will now find it in the doc directory in the OVNK repository. Now one thing that's always been a little bit problematic for those of you working on the latest mainline version of Devian K completely new features, bug fixes has been finding a proper boot Devian K so if you want to build the OVNK you should require a dedicated image to bootstrap the build process and for example the building of the Devian K9 you need a Devian K8 distribution and it can be a little bit more to find a suitable boot Devian K when you're working. For example the Devian K8 repository currently requires Devian K9 it might soon require Devian K10 and it shares a lot of Linux institutions to do not package that recent Devian Ks and the work dedicated to the proprietary. Now the great news here as Mark announced is that upstream build by the builds of OVNK under the decal to inspire the available you can find the builds at jdk.jov.next at 9 for OVNK 9 builds and this makes for excellent boot GDKs for your build process. So we actually try this out so now we're going to build from scratch on Devian 9 desktop and middle system thanks to the consolidation a single HD code we see the internet extreme we use Wget to get a boot GDK a GPL license, find a build of OVNK and we use that as a boot GDK when we're working here and then we try to make images so in five steps I have a completely properly built image and you know hopefully if you're doing this on our build you're going to miss a few packages but again configures here to help you and will guide you so you just repeat a few times and then you're good you're going to have a properly built OVNK image locally off your machine there has been a lot of developer experience improvements in the build system there's been a lot of improvements overall to the main files and the build system but there are a few developer experience improvements here, for example there's the body symbols and they're longer shipped by default so if you're working on hotspots and you get a little crash when you work on your picture you can now much more easily the body can be made the font config library is no longer bundled without the update I know that this is good news for the packages out there for different distributions you can now provide even more easily after a font config package the compiler errors are repeated at the end of the build output you no longer have to scroll multiple pages of output to find out one little test compilation error that causes the build to go over another good feature is you were mainly working on your own tools you were basically scripting on your own is that all compiler commands are available in .commandline files for each source code files that means that you're going to look at the exact command that was used to produce for example .o file you can find that in either .commandline file with the same name as the source file and finally that not the least at all the run test project was introduced and this is actually a bit more deeper in terms of my work though a lot as this was introduced so run test is a new top domain project for the run that test and it is used to execute all the different kind of progression tests we have in OK&K run that test then you set the test variable to whatever kind of test you want to execute you can set it to a single test file you can set it to a test group like a gathering test you can set it to a directory containing multiple test files it supports all the test frameworks we make use of in OK&K particularly the gathering and global test and you can run was actually anything you provided in the run looks like test for example here we are going to run the tier one test a tier of test really good for sound testing as we try to make run that test test equals tier one now if you do this a lot there are also a short hand station for running as sweep of tests you can just type make run-test-tier one and in the other example here on the bottom of the slide you want to run all the easy tests of what K-DRAG is in directory and so then we just set the test variable to test of what K-DRAG is and run-test will find all the K-DRAG tests in this directory and execute them correctly now correct-tier is important because run-test it's not that easy to run all the tests in a proper way and run-test will do this for you it will ignore tests that are in problem list of GSD because those tests might have an error or there might be something going on they might be unstable but it will pay you a fine and they are at least in the problem list of GSD and they will be properly ignored for example if you execute all the tests in the directory you will not run those that you ignore it always uses spader numbers so if the test fails a few actions will begin maybe you will get a core file those will be run it always uses a fresh clean directory and running all the tests is important if you run K-DRAG tests it uses multiple cores it doesn't want you to speed up the execution or run all the tests alright that's the correct GDM flag which tests appropriately but it doesn't work as I am used to say in the afternoon you can pass options under the test runner and or test framework on the slide here it will pass the repeat equals minus 1 option to the test runner and you can also pass more specific GDM options to the GDM if you have that need there is extensive documentation available under the docs that testing.ed and if you want to use this feature it is very important that you pass that GDM to configure because one test needs to know where to find a GDM image so you can find a GDM binary and use it as a test format for executing your test now this last bit we will use in the next section about testing because getting a hold of a proper GDM image hasn't always been the easiest and if you want to use this you also feature runners to pass a proper GDM image to pass that with GDM to configure now building GDM used to be a little problematic Java help depends on GDM only available in the ancient subversion of the GDM another dependency of GDM actually requires a proprietary library the third one the dependencies for GDM you will not properly specify which version should I use which one should I get from the third one the dependencies if you didn't actually find out the version you would realize that they were a bit outdated and not only are they directly compatible with each other you won't find getting a correctly built GDM version the good news is that all this has been fixed so nowadays you only need to clone the GDM repository since you need to ensure that you have a GDM image on your workstation I'm running that now so I just can't get installed or communicate the 8-digit and then I use the new build-all script and I pass it to the directory of the GDM image and I will automatically get a properly built GDM image the script will download verify and build require third-party tools if there's something needed from OpenAT those will be downloaded from the HID.OpenAT verify that it's being downloaded correctly build it and also if we have there are multiple third-party yards that we depend on download it from Naver Central and also verify that it checks out that we got the right bits down to the computer and the great news here is is that if you use build-all to build GDM you will get an image that is very suitable for passing to the actual GDM to configure so now not only can you build from scratch on that day and night thanks to the new build-all script for GDM you can actually build and run tests in very few commands from scratch on that day and night so you get the source code as a real HID code command CD to the directory and when you build a computer make sure that you pass that a detailed license of the GDM and also pass that to the recently built GDM image and now when you run make run-test tier 1 no longer will you get a proper OpenAT image as a result of all the tier 1 and 7 tests on that will be an image to do at least get some kind of verification that takes you to build together but there has been more going on in the last year thanks to the consolidation effort when we consolidated all these different repositories we could take the opportunity to fix a little issue we had because when we are writing the GDM tests we make use of helpers or sorts that are available in the test library but one possible to provide GDM tests and the GDM was also one of them to provide GDM tests so we had to get copies of this test library in two different repositories now that the repositories have been consolidated we could take the opportunity to merge those test libraries into one and here you get the sorts you get tools for handling processes you get staffing helpers etc and if you want to get started and maybe buy a little GDM test you can find information you need I know that there are quite a few hotspot developers in here and those of you who mainly write the Zbustas in your native video working on hotspot a group of tests has been available for quite some time providing unit tests in Zbustas for hotspot so on the slide here we have a very small unit test for hotspot we start off it's a regular HTTP file and as for hotspots then we assume the necessary headers and then there's a small difference where we include unit tests for HTTP and we use a macro called testVM to set up our test and these little tests will just ensure that a newly created instance of the G1 analytics files is actually initialized correctly if you want to get started the Google Test Optimum documentation applies deeply well to open a gate test and providing that there are a few minor details that differs particularly around the test macros so we have to define it a little bit to suit our needs if you use the test macro you would say that my test will run fine without even having an initialized JVM this is great if you do require an initialized JVM for a test to execute you can use the testVM macro but you would rather share a JVM to make the test execute faster if you need an isolated separate JVM and if you want to check if the JVM actually fixes with an assert you can use the testVM macro to write such a negative test and remember always make the unit test as it is the last in-cube in your TPU test this has to do with some macros running to many reasons so let's now see if we can put all the information together it's a one hopefully coherent work though so if you want to fix a valuable work in a feature just start off by doing this and if you want to get the source code down you might want to create a branch for the issue you want to work on so you create a new branch with material you run a configure and here it's pretty at least I find it efficient to name there's a support for build profiles in the build system so you can have multiple build directories for a single repository it's quite appropriate to name them after the branch you're working on and just doing random build all the time so here I'm going to name my build profile in the same name as the HD branch and the issue I'm working on of course I'm going to pass my jQuery image to dash dash with jQuery I'm going to pass it off to my downloaded APM to the binary build of my ADK as the boot ADK I'm going to do some hacking I'm going to write some tests of course I'm going to write tests for the new features and I'm going to run those tests locally and here I can now use make and I need to provide to make which configuration which build profile I need to run to pass the contributing variable set it to my computer to my branch name and I'm going to run the tier 1 and tier 2 tests to do some sound testing and checking now as Mark announced we do have a release sort of submit repository as you can now to your HD configuration file for this repository and it pops to both the submit repository and the sandbox repository so to do some final testing remember as Mark says we do trust that you're using these services so if you use one as much testing you can look at it but for the final testing when you want to do multiple platforms you can push your branch to the submit repository and then if you want to share the code with other developers to get some feedback you can push it to the sandbox repository so it can be easily used by other developers and of course if you finally want to get upstream you can do an e-mail so you can be discussed on the main list and finding that through so we're looking towards the next tier in the pipe one is one feature that I think is pretty cool which is a new make command called compile commands so those are the ones we see as faster a lot more recent years might go of the CMake build system that conveniently creates a compile command so it gives you some file for it this file contains for every native disability file you will contain the exact code online that was run and executed to compile that file which can then be hooked into a load tooling if this has been sort of inefficiently standardized for single test tools to use to find out what defines a particular source file this means that we can get much better integration with tools such as C9 tools in the C9 suite and also C querying to get some condition for our C++ and please join us in all this work what can be improved in all these develop experience tools what can it fix if something is working well please provide feedback too without the help of things that are actually working please and this does not require any super GVM skills or I need to be some language the cycle of some sort start hacking on the tool tools maybe the version of the tool tools if you are working with MAKE files that will be greatly efficient to do or just write a test or two to see if things are holding together and get into that and keep in touch with us I just said no, no in the game channel no IRC, no optical masks and just introduce yourself or tell us if something is working so thank you very much if you mind if I talk more in person I'll ask you to find me outside the stage