All right, five random Ruby tips for October. So I have this thing where I really don't want to go with a theme when I do the five random Ruby tips because it's supposed to be random, right? So it feels a bit like cheating. So these tips are going to be a bit all over the place. So make sure you don't get lost. But first, as Gosian said, my name is Ted and I work for Tinkerbox, which is a local Ruby on Rails agency. So up to the first tip. So this is a bit of a warm up, which is that you can pass an offset to the with index method. So if you're not familiar with it, you can call with index on an enumerator. And it will also give you an index inside the enumerating block. And one of the reasons I wanted to include this was I actually didn't know this myself until one of our interns showed this in one code review that I was doing. So I think it's a good point to make that even as seniors, we can still learn things from our interns that are fairly basic, but that we might have overlooked. And quite frequently I have seen from my other seniors that they will just, for example, add one to the index inside of the loop, which is now no longer necessary. So it's quite common that you want to change from a zero based index to a one based index, for example. All right, moving fast. Using refinements for domain semantics. So if you remember roughly a year ago, there was a lot of talk about this new feature called refinements that lets you monkey patch things in a very limited scope. And it all seemed really cool, but I for one didn't really know how to use this. So I just idly waited and waited for someone smarter than me to just tell me how to use it. So the credit for this one goes to Justin Searles. The idea and all the examples are blatantly copied from a gist that he posted. In his example, there is some calculation done that is relating to a marketing effort. One nice feature of Enumerable is that you can change things together and get this sort of neat looking chain of things. But if we are frank, then we probably need quite a lot of time to figure out what this does, even though we might have written it ourselves just a few minutes ago. And one of the nice things that Justin came up with was that we can use refinements to add some semantics to this. So here he's creating a marketing refinement. So he's refining the array class with some new instance methods. So he refines an exclude incomes under method that basically just takes part of all this and wraps it in a more meaningful method. And he also refines to separate people by method, which does some grouping. And he refines hash with another method that says average income by smoking. And the final result, to use refinements, you just put using and it will apply in the lexical scope where you refine it. And now we can write the same method like this. And I think any new developer and even myself, like two weeks from now, can come back to this method and immediately understand what it does. And I just put the original method here as a comparison. So this is what we started with, which is a bit obscure. Like if I had to explain to someone in plain English what this does, it's a bit of a hassle. But with this, I can just say, oh, it excludes incomes under 10,000, then it separates people by smoker or not and takes the average income by smoking. All right, so the third tip is about running tests in Atom. So I recently started using Atom myself for no other reason than being a bit of a GitHub fanboy. And I'm using the Ruby test package, which seems to be fairly standard in Atom, to run my tests, which gave me all these nice things. Like I can use shortcuts to run all the tests for my projects, or I can run all the tests for the current file or run the tests at my cursor location, which turns out to be super convenient because I don't have to leave my editor to run the test case that I just wrote to see that it's failing, for example. So I can just demonstrate here. So here I have a test file for RuboCop, for example. So I'm not going to run all the tests for RuboCop because it's going to take way too long. But I might, for example, run all the tests for this file by doing command control t. So it's a bit tiny here, but you can see that 47 examples were run and they are passing. Or I could go to this particular line and run the tests for this test case only. And you can see now two examples are passing. Or if I am somewhere completely unrelated, I can just do command control e, and it will rerun the previous test. So the way I use this is I will write usually a failing test case. I'll run it using command control r. Then I will go to the actual code file and start implementing the method that the test is testing. And from there I can just use command control e to rerun the tests for this particular method, which saves me a lot of context switching with having to go to my terminal and specify the particular line of the test and things like that. All right, so the fourth tip is how to use RuboCop to help fix legacy code. So the way you use RuboCop is you run it from your command line using the RuboCop command. I think most people using it now know about the auto correct feature, which is really convenient if you have say thousands of tiny style offenses. You probably don't want to go and manually fix all those. So if you're brave enough, you can run the auto correct, and it can auto correct most of the cops, but not all of them. But what I want to highlight is the second much less known option, which is auto gen config. So even if you auto correct all the style offenses, RuboCop also has metrics cops that checks, for example, how complex methods are or how many lines are in a block and things like that. And what you do when you run auto gen config is you generate a RuboCop to do YAML file. And I can show you, so there's actually a RuboCop to do in RuboCop because there's some legacy code in there. So you can see, for example, we're overriding the ABC size max to allow it to be 18, which is the most smelly code that we have right now. And what makes this so nice is that now I don't have to go and fix everything in one go. So I can do a concentrated effort, for example. Say we want to bring the metrics ABC size down to 17. I think it was 19 originally. So you can see right now there are no offenses because it was set to 19. Now I want to make a concentrated effort to reduce the ABC size of my code base. I'll change the RuboCop to do to 18. We'll rerun RuboCop. And suddenly we have all these offenses. And these are all the places where the ABC size is higher than 18 but lower than 19. So one important thing to remember if you generate this to-do file, you also need to intend to actually do these things because while this is here, I can write new methods that are up to 19 complexity without RuboCop saying anything. So I could potentially make the situation worse if I keep this file for too long without actually fixing the problems. All right. So the last tip and the most abstract one is about the robustness principle. What the robustness principle says is that we should be conservative in what we do and liberal in what we accept from others. And the way at least I think about this in programming in particular, in general and in Ruby in particular is something like this. So what does this actually mean? So this symbol might look familiar because it sort of looks like the filter symbol that you have in Excel or Google Sheets. And that is sort of how I think about it. In that to satisfy the robustness principle, I should accept different inputs but I should be very conservative in the number of outputs that I generate. So you can think of these different shapes as ducks or other animals except ducks. And then you can see as soon as I call a method, I automatically reduce the number of things that something can be in my application. Whereas if I do the opposite, I only allow one thing to come in but I have two possible outputs. And I'm actually increasing the number of things that anything can be at one point in time. And one of the struggles of working with a dynamic language is that we need a strong understanding of what am I actually going to receive when I call this method because there are no interfaces or contracts like that. So I gave a talk at the July Meetup called An Object Existential Crisis and I talked about some rules of non-existence which were a special case of this when dealing with NIL because NIL tends to be the other thing that you return instead of a duck. So I thought I would just clarify by expressing those things in terms of this sort of funnel analogy. So the first rule I set up was that methods with basic return types must never return NIL. So if the method normally returns a string instead of NIL, maybe it's appropriate to return an empty string or not available or whatever string makes sense as the null object. Which in terms of what we just talked about means you should avoid things like this that increase the entropy of your application and especially so in public interfaces that others can use because a lot of programmers will think about the positive path which might be this one. And forget about this one because you actually have to go in and read and understand the method to see that, oh, I can actually get this other thing as well.  And the other thing, the other rule I set up was that a method depending on another which can return NIL must itself not return NIL. And what I meant by this is that if your method needs to return NIL as the other thing, then design its collaborators so they can undo the entropy that you just introduced. So it would look something like this. Your first method, you know that it can now return a duck or NIL. So you must let its collaborators handle that, of course. But that collaborator might not itself need to return NIL because one of the downsides of NIL is they tend to cascade down until someone doesn't handle it and then the application blows up there but the issue was actually somewhere much higher up in your application. So I think this is fine internally, the private API of objects. But in the end, in the public side, only one thing comes out. And those were the five random Ruby tips. Then all the box with the Ruby aspect and the test with this aspect. So in the configuration, you actually tell it which command to run when you, yeah. So you can run this with Minitest or anything, basically. Or any environment variables. Yeah, yeah, you can pass any flags you want as well. Oh, okay. Take a look at the snarky remark as a big fanboy. We had it five years ago. It looks like a cat after the end of the meetup if you have any questions. So once again, thank you, Pat, for sharing us with us.


Hello my name is Shahran, I'm a student of grade 9 and today I got vaccinated and I felt really happy that I got vaccinated because rest of I have the youngest in my family and the rest of my family members all of them got vaccinated and I was kind of feeling safe but now since I got vaccinated I feel safer and I really want to thank all the people who are actually taking the initiative of trying to vaccinate all of us. Hi I'm Aditya, I'm studying in grade 11, I got my first job for vaccination today after a year and it felt really nice to be vaccinated because finally my things are slowly getting back to normal and I'm the second youngest in our family so I definitely felt safer and cheers to all the doctors who are doing their best to vaccinate you


What's going on guys got Kyle here with Layton sports cards, and we are ripping this is one box of 2023 WWE prism, and this is gonna be for Jason B. Good luck Jason. Let's see what we got What up, Sam? What up, Sam? All right, good luck Jason. I don't know what's going on here One second, so it's complete your order just a second here. All right. Good luck Jason. Sorry about that 2023 WWE. Good luck. Good luck. Yes, Sam. Big Colorblast coming. It's been a while man. It's been a while We're doing the prism Colorblast here. I think Kenzie on drip was the last time a couple weeks ago We still been opening a good bit. So Hopefully you can get one here. There's a red wave of a Mari Miller and Silver's Brett the hitman heart There's Wahoo's boy Brett Hart, San Martino Robert Rude. Nothing too crazy yet, Sam. Nothing too crazy yet That's a nice, uh, had a nice gold auto. I think it was the same Houston guy you got for a for Alvin had a gold auto Had a bowman earlier. We got to 99. It's gonna be an orange E. O. Sky To 99 and a red to 299. We got a Seth freakin Rollins To 299 Seth freakin Rollins Charlotte flair. There is hyper Ricky the dragon I get a dragon steamboat and a silver. Mr. Perfect's Kurt Hennick. Mr. Perfect is a confident nickname Say that for sure. Mr. Perfect Again guys, we got six boxes of bowman hobby after this for Oren. So we got about 30 minutes on the queue right now la night purple Anybody is trying to get on the get on the list got plenty of time going till three and Then Sam will be back at five with Sunday Funday group breaks Sunday Funday with Sam. I don't know if it's his first one, but it's probably pretty close probably pretty close Usually with forest on the Sundays Forest had to get moving first auto It is gonna be a superstar silver auto of Montez Ford Montez Ford on the superstar silver auto and a silver Emma Roman Reigns top tier Red wave Bobby Lashley not numbered the almighty Bobby Lashley in a blue to 199. That's gonna be Carmella Carmella always think of the Sopranos can't help it Anytime I see Carmella Sopranos immediately the wave mr. Perfect Kurt Hennick Silver of Sarai What would my wrestling gimmick be? That's tough. That's tough. I don't know man. I can't even uh, I can't even begin to you begin to think I did uh, I Think I just need vents to give me one We've got Duke Hudson hyper and Purple the 149 is scarlet with a silver Booker T ring royalty there King Booker. There's King Booker there And you can raro the Piper There's Ariana grace red wave sticky on these and red to 299 is Austin theory That's the the money in the that's what the Austin theory was right carry on the flawless briefcase. I'm down I'm down money in the bank. I'd hit somebody with a flawless briefcase if I needed to have an Emojo Superstar auto of Kevin Owens nice KO there Here you go Jason nice hit on the Kevin Owens mojo auto That is a sweet one KO that is 16 at 25 very nice mojo auto I'm a superstar got a silver edge behind it Berto see why who's the problem with being the uh?  What's up Tony? How you doing today? Tyler bait to 99 like cactus jack. He uh, he would drop the uh He would drop the tax but he always got he always got hit right into him as well He knew it was coming too. There's a Mari Miller on the red wave and Silver Brock Lesnar nice hit on the last parallel Brock Lesnar silver triple H ring royalty Seth freakin Rollins and Jinder Mahal on the back Alright Jason that will do it for your one box of WWE really nice mojo KO auto. Thank you so much. We'll get him right out to you


therefore it's time for members statements the member from Whitby Oshawa. Thank you speaker I rise today to speak about girls incorporated of Durham and the issues that young women face in our communities are real and profound bullying sexual harassment of violence all have severe negative physical and mental health consequences girls incorporated of Durham is a local charity in my community serving 1600 young women each year and dedicated to supporting mentoring and guiding young women in a safe environment the staff and volunteers deliver in school and community-based programs that tackle self-esteem bullying sexual assault and healthy relationships speaker girls incorporated of Durham also works to improve the conditions in which all young women live by advocating for legislation and policies that improve their chances to succeed speaker girls incorporated of Durham seeks to inspire all young women to be strong smart and bold to reach their full potential and I want to recognize the outstanding work of staff and volunteers and the effect they have in the broader region of Durham community thank you speaker thank you thank you Mr. Speaker two weeks ago this house passed my motion which was to put a gender lens on any budget that comes forth and this is what that means and this is what we expect to see this afternoon because poverty has a woman's face in Canada and in Ontario we want a minimum wage that's at least $15 an hour we want affordable childcare now and we want public affordable childcare now not after the next election now we want housing we want affordable housing and that means doing the repairs on TCHC housing but also new bills we need that because again homelessness is a woman's issue we need a rise in social assistance rates because again most women single-headed families the face of poverty is a woman's face they need that raise and again Toronto is a child poverty capital of Canada which means it's the woman's poverty capital of Canada we need that address and we need equal pay for equal work if Iceland can do it we can do it right here in Ontario and I would say Mr. Speaker that we do not get what we're asking for if we do not have a gender lens on the budget then this isn't a democratic budget it's not a budget for everyone it's only a budget for men that's not democratic that's patriarchal we need a gender lens thank you thank you thank you Speaker some 167 years ago in Massachusetts a special church service was dedicated to children first named rose day then flower day that special day is now known as international Children's Day Children's Day was first declared a national holiday by the Republic of Turkey in 1929 today international Children's Day is observed worldwide it focuses attention on the rights and potential of children it stresses the duty of governments companies families and communities to protect defend and enhance the conditions and environment in which children are born raised educated and cared for in southern Ontario the Turkish Society of Canada leads in celebrating the potential of young Ontarians each April international Children's Day attracts thousands of attendees to Nathan Phillips Square to showcase music dance song and art by children congratulations to the Turkish Society of Canada for organizing International Children's Day and to its enthusiastic core of volunteers special recognition goes to President Nalan Gokaj and to our Mississauga residents Vice President Cenk Sayin and Director Ruchan Akok thanks also to Turkey's Consul General Erdini Shen for the consulates ongoing support I was pleased to attend again this year I was I give thanks for my own special welcome and that given for our extraordinary family member Merlin thank you Speaker thank you for the member statements the member from Kitchener Conest, thank you I rise Speaker to continue to grow speak to the growing problem of the opiate crisis here in Ontario today I'll table my bill the illegal pill press act which would enact measures to combat the use of pill presses and other pharmaceutical equipment by criminals who flood our communities with illegal counterfeit narcotics in my consultation I heard many heartbreaking stories speaker from law enforcement crime prevention advocates and medical professionals on the impact of opiate use in the province the illegal pill press act would make it an offense with jail time to possess a pill press without authorization under the act health Canada has indicated that just two milligrams of fentanyl is a killing dose and RCMP officers are finding pills on-site bus containing up to six milligrams of fentanyl as we know from the Ontario Drug Policy Network two Ontarians die every day from the opiate overdoses and of course this is unacceptable these death machines can turn out 18,000 pills an hour and from basements and warehouses laced with doses of opiates like the fentanyl that is destroying so many lives in our province drug dealers are not pharmaceutical companies they don't care about quality control or patient safety any one of the pills they can produce have a daily hotspot fentanyl using these pills are playing Russian roulette with your life speaker there is no defensible reason for an individual to possess one of these machines we need to punish these criminals to protect our society to protect our communities and to protect our loved ones of course I want to thank our leader Patrick Brown the PC caucus for their support and I hope others will support the illegal pill press act thank you further member statements the member for Bramley Gore-Multon thank you very much mr. Speaker I want to share with you the story of Jamie Lee ball you might have heard the story of Jamie Lee ball in reported in newspapers recently just last month Jamie Lee ball was admitted to the hospital Brampton Civic Hospital in my in the region appeal when she was admitted she had felt some internal pain some pain in her stomach following an operation she was admitted and was kept in the hallways for five days while she was quote screaming in pain an ER doctor confirmed that she was indeed bleeding internally and that she would need an IV in addition to perhaps a blood transfusion for five days she was kept in the hallway with on a stretcher with no pillow and just three thin sheets of separating her from the public this is completely unacceptable and the reality is this is just the norm now in the province the Brampton Civic indicated they can handle 250 patients per day but last month they had on average 357 per day this is a direct result of a government that's cut hospital budgets for over five years their direct cut of this budget has resulted in a health care system that is eroding we need a government that's committed to funding proportional to inflation and population growth this government is not shown that they care the people of this province deserve better and new Democrats will deliver thank you mr. Speaker I want to make Ontarians aware of an extraordinary program that's starting my writing of Ottawa venue that I have the great honor of represent the dragonfly program for people with Elmer's see drum dance which offers incredible dance programs to all sectors of society children adults people with disability as the artistic director says she thinks the world is a better place if people know how to dance it was therefore very natural for this very proactive school of dance to host dragonfly program which for the last 10 years provides life skills training for learners with down syndrome it supports them in their schooling math literacy photography dance and really it's based on the best educational policies and practices from around the world the latest initiative is to have an entrepreneurial forum that will take place in June and the forum is designed by the school of dance with the learners with down syndrome indeed they know all these learners want to be autonomous and they know what they want to do but often they are told they put in places in jobs where people think about what they could do and this the entrepreneurship forum will allow them to gain life skills and career opportunity for them designed by them indeed there's going to sell photographs that have been made on postcards by by the learners I just want to salute these fabulous students in Ottawa venue thank you thank you mr. Speaker to separate church bombings in Egypt killed 42 people and injured more than 100 this past Palm Sunday the Islamic State claimed responsibility for the deadly blasts which took place on one of the holiest days for the Christian church this was yet another example of persecution resulting from a historical campaign of persecuting Coptic Christians based on their faith more than a hundred Coptic Christians have been killed in Egypt since 2011 more than in the previous 10 years combined radical extremists have painted marks on Christian-owned businesses to indicate potential targets and warn people not to make purchases forcing many of their shops to close down violence against Egypt Christians in Egypt has been on the rise but unfortunately it is not the exception across the world an average of 332 Christians are killed each month in 214 churches and properties destroyed Christians are the most persecuted group in the world St. John the Evangelist Church here in Toronto experienced an act of arson on the morning of Easter Sunday persecution occurs everywhere I want to raise awareness of these hostilities because few people recognize the reality of Christian persecution the ongoing persecution of Christians in the Middle East has already forced thousands of men women and children to flee for their lives it is no exaggeration to call this targeting of a faith-based group a modern attempt at genocide we must remain vigilant and condemn hostilities based on religious affiliation wherever they occur no one in the 21st century should face violence and the threat of death because of their faith it is too easy to believe that such violence could never happen here in Ontario but if we ignore persecution in other countries individuals can bring it here also thank you thank you mr. Speaker I'm honoured to rise legislature and share some personal thoughts on the late Ron Moser the former city councillor who passed away earlier this month I first met Ron 1988 we were actually elected on the same day November 14th at that time there are many new phases on Scarborough council including my colleagues from the Bass Bucke soon Shreene Shaw, Fran Johnson, Paul Maschinski and myself in fact six of the 14 new councillors on Scarborough city council were new rookies we were sworn in together on December 1st of that year and to this day I remember the infectious smile that he always had on his face didn't take long for us to become close friends Ron was always on his mobile phone and when he when I asked him why he spent so much time on his device he was simply explained to me I needed to stay in touch with my constituents he became known and famous for holding appointments with constituents every day that began at 7 a.m. usually with us city staff in tow he was the first advocate for the creation of the Scarborough park and leaves behind an incredible legacy in his community my thoughts and prayers go out to his wife Heather there are three incredible children Tammy Cindy and Selena grandchildren Colin Brooke and Logan and sudden-laws Mark and Jeff I'm proud to consider Ron a dear friend and I'll miss him dearly thank you speaker thank you for the number of statements the number from for you thank you mr. Speaker last Monday we celebrate the play out order here at the legislative assembly of Ontario and I would like to say that we had many recipients of this order a gate in Gervais Madeleine Mayor mrs. Mayor Marcel Gibro Sylvie Landry Gérard Malor and I nominated Thierry Lassure and Thierry it's been 15 years 25 years rather that he served the association world in education culture and francophony and I would like to explain that mr. Lassure is one of the ambassadors for the francophone community and received his honor for his work and his engagement in serving the french-speaking public within the metropolitan police of Toronto also at the police forces college and many other organizations I would like to say too that he explained to me that anglophones are francophiles and francophones of culture and it's true thank you mr. Speaker I thank all members for their statements just before we move on to the next section of routine


I'm Adrian Schröter from SUSE in Nürnberg. And I want to speak again about the OpenSorg Build Service. But this time, I wanted to focus a bit about our ideas, our current possibilities and our future ideas to package, to create packages which build for different distributions. Not only SUSE-limited, also Mendriva, Fedora, Debian, Ubuntu. There are problems, obviously. And I wanted to focus in this area of the Build Service. But I'm flexible. Who knows what the OpenSorg Build Service is? OK, who has used it? OK, some. Good. So very brief part. What is the OpenSorg Build Service? In first place, it was suddenly needed when SUSE decided to make the OpenSorg Distribution really a community distribution. Until then, for 10 years, SUSE was developed in-house. So if you wanted to join the SUSE distribution development, it would mean you need a local NIST account inside of the SUSE network and other limitations. We had quite automated build system at that point of time, but this obviously wouldn't work out with an open-source development. The good thing is we had 10 years of experience, and we learned a lot of mistakes we did during the 10 years. So when we started from scratch, we were able to avoid these mistakes. But we don't want to limit us to develop only OpenSUSE. We wanted to make it really a platform also interested for people who just want to offer packages, because our idea is if you can get the software authors to come to us to build packages there, then we get automatically also the better distribution because the authors work already at our system and are connected best with our system. So we want to offer them something that you don't get elsewhere. And this is building also for Fedora, for instance. So the idea is to have all sources, all stuff in one place, change it, and you get packages for all distributions. And of course, to connect with existing infrastructure so you can, in extreme case, with each SVN commit, you can get a new package. See that your package, your commit, now broke something, for instance. The build service, for this reason, had very many phases. The users are seeing it. Then there are packages seeing it, only interesting in their single package. Then there are people like our release manager seeing it, when it's also building the entire distribution. So EZO images, FTP trees, and so on. ISVs are using it for creating add-on stuff. Live systems, so really, really pretty much different use cases for it. We use it at Build OpenSuserOrg, visually. This is a place where the OpenSuser distribution gets developed, but where everybody can go also create an account and create packages for any distributions. So Build OpenSuserOrg is also supporting Fedora, Ubuntu, and so on. Then we have at Novel an internal build service, which is building the enterprise products. So the same software is used just installed a second time. Novel plans to offer an ISV build service. So a build service hosted at Novel, but where every ISV can come and build packages for the enterprise platforms. Then there are plenty examples where people simply use the build service at their site. For instance, there's one guy currently trying to port the OpenSuser to a Spark architecture. So he is able to reinstall the build service in the same way that we have in our site, and just recompile it for Spark and fix the Spark-specific things. Other companies are creating an entire distribution as well with it. For instance, there's Intel is creating Moblin with it. Kray is creating some kind of distributions. I do not know the details, actually. And many small ISVs like OpenExchange or so is providing a group bare support here. They use a buildOpenSuzorg, actually, for publishing their open source product and have a build service in-house again for the commercial product. It's possible because really everything in build service is designed to be as open as possible, as open as we can. License itself is under GPL, the code itself. The API is very simple. It's a REST-based API. So if you can operate it with just HTTP operations, that means that you can easily integrate it into any tool chain you have. You can either call it from command line with a curl option. You can integrate it with your Java stack easily because it's just HTTP, and HTTP is supported everywhere. And the build service itself is not limited to SUSE-based and not limited to package formats. Besides RPM, it supports also Debian or, for instance, Kiwi. The image descriptions are also handled like a package format. So when you place a Kiwi file there, for the build service, it's just another package. And OK, the result is an EZO image. One thing, one concept we have is a project model inside. And this project model gives very much power and very much flexibility. I just have one example here. I'm not saying something. So a project organized a space in the build service. It defines which people have right access there, can submit packages there, they can organize themselves. You put the sources inside there, and you add the description how you want to build them. For instance, for open SUSE, for Fedora, whatever, Mindriva. You can reuse different sources. For instance, you say, OK, I want a SUSE kernel, but I want to kick out this patch, which is fine for an Oracle database, but it's bad for my multimedia stuff. So you can easily follow an existing source with a different patch set.  And the result in the end is always a repository with all the packages. And yeah, people can just add it to their tool and install the packages from the repositories. This is just one example how you could use it in real life. So there was, at the time, the KDE4 project. It consisted from multiple packages. They were compiled for different targets. Simple thing. The good thing is that you can reuse it. So the Amarok people wanted to build also in current Amarok at that time, but they had the problem that the KDE4 was not part of any of the distributions. So they were not able to compile just the Amarok against open SUSE 10.0, for instance. But what they can do, they can compile it against the KDE4 project which compiles against the open SUSE 10.2. So you can easily reuse existing sources and collaborate with them. OK, that's the generic part. Now, the specific part, if you create packages which should compile on different distributions, you have problems. One part of the problem is actually not that it's the age of the distribution. That means an older distribution has a complete different API set, usually, because the old version of GLIPC is packaged. The old version of QT is packaged. So you don't have the API interfaces you may need. Also, the GCC is changing over time. And the newer versions suddenly complain about programming errors, which were always there. But in the former times, they were just not detected. And now, suddenly, it aborts. Or each distribution may have any QA scripts to check that the package is not doing something evil. Or require, for instance, something. Also, the policies of the distributions developing over time, and that happens changes. Then there are distribution-specific things. When Riva, for instance, has the LIP64 rule, that all library packages have to start with LIP64. And this shouldn't happen on other distributions. So you have really a number of problems. And you can, of course, solve them or just ignore them. There are some generic solutions. So the LSB is a nice idea. So it standardizes the base set of libraries up to GTK QT. But one of the problems is it's a runtime standard. It's not for standardizing the build time. So you have to deal with the build problems also. Yeah, the package name problems, for instance, there are packages which have the same content, but different name on each platform.  You want to have a specialty for Fedora or for Zuzo to support something specific only existing on this platform. So we have some methods to support this. There's an example, the Kranalypse package, for instance. It's really named differently on really every distribution. And that would mean you need a spec file saying, build requires differently on each distribution. And that's a pain for a package. The point is, when we know such things, we can have substitute rules. They are stored inside of the projects. And the base distributions like Zuzo, Fedora, and Viva are also projects in the build service. So for instance, when we could add a substitute rule in the Fedora project that says Kranalypse with capital C. And the package just submits this package, build requires, for instance, in the way Zuzo is writing it, and it gets mapped automatically on Fedora. The nice thing is, you get also another source RPM, which differs to the source RPM from Zuzo, which works on a Fedora, actually. Other common problems are macros. For instance, just example for the run level scripts for starting services. Zuzo has a standard. And Viva has a different standard. Fedora, another one, they actually don't use macros at all for some reason. Of course, you could now do specific versions for each distribution again, but we define some default macros in the build service. But we have the hope that we can push them upstream to RPM at some point of time, so that's really a standard inside of RPM. Right now, they are only defined in the build service. But that means when you submit this backfile using these macros in the build service, again, you get the right, expansion the right macros for each distribution again. You don't need to handle this manually on your own in your spec file anymore. Then, there are the exceptions. For instance, you want to do something special when you build again through the version older than 10.1. You can construct such things. This writing, it's even working if you can use this backfile on any other system where through the version is not known. So it looks a bit ugly, but it works pretty well in the end. For instance, when you want to follow the main driver policy, you can rename your spec file completely. So the resulting package is completely different via this writing. But of course, all this is too complicated. This is nice that you can to interact. It is nice that you have the power to do specialties and to use these special things. But I mean, most authors, frankly, don't want to package. Most authors of software just want, well, I do all the day hacking my cc++ code. I don't want to learn how to write spec files. And I don't want to learn how to write Debian files. So there are many approaches to generate these spec files and so on automatically. There are several generic approaches. So one guy thinking he can rule the world and automatically just trade spec files for any kind of packages. And I was also one of these guys, but we all failed basically because we don't have the insight of each software stack in the Linux environment. So then some people said, OK, no problem. We asked the user, create a wizard. And then another problem appeared. And suddenly the wizard is so complicated that it's easier to write the spec file. Didn't work out. Then there are people who tried with Scrap and guessing from the source code maybe how it could be and how it could like. But the success rate that you get a working package of that is very low. Autospec was something from Matthias Kettner, which I took over. It was nice to read when you want to learn Bash and what you can do with Bash. It tried to compile a table with generated spec files multiple times. And it learned about the failures and re-twited. It worked also not out in the end. What works out, actually, are specific approaches. So for Cpons there is already a spec file generator. Jam has one. And this means the autos there, these software stacks, contain all the information you need to generate a spec file, a Debian description. So the information is there, and it is a standard upstream. So the autos really take care about this. And then you have a very high success rate to automatically generate working package descriptions. Autos, unfortunately, very often ignores this because they use their CMake. They use their Autoconf. They use their QMake, whatever. And they make it in this way that they can run the application. They use their IDE. They click on the button. And there is some result, some star ball. That means, on the other hand, that most of the information we need to know to build a package is inside of this build environment. Because in the build environment are informations like I link against the Mesa library, for instance. So when we know that there is a link against the Mesa library, we can find out, OK, the Mesa library. For this, usually, you need the Mesa-Devil package. So we can map this. We can, of course, also do some guessing. But the point here is really that we have a specific generator for this specific build environment, which is maybe CMake, QMake, whatever. And the point is that these generators, if they are for this specific language, they can be written in this language. And they should be maintainable by the people who are working with this language, not by some single guy who has no clue about the software stack, actually. So what we designed and where we have a prototype working at the moment is the QMake example. I picked QMake because it was a very, very complete, very, there are no dependencies to outside. And they generate applications, not only for Linux, but also for Windows and Mac OS and so on. So at QMake, you have a profile. And it defines the files to install. Very important for the file list. The version, of course, and the libraries to link. And my generator reads this profile, asks the library mapper, OK, I see links against QT, then which package is it. And it generates backfiles and not yet DB and DSC files. But it is straightforward to generate this as well. The good thing is it's not much work to provide such a generator, actually, because there is something which reads profiles. That's QMake. So what I did is just I used the QMake, which is there. I added some lines of patches and a small rubber script, and I was done. That was done within an hour. And I had a working generator just for the specific approach. And the good thing is when QMake is evolving, I can easily follow because it's just a patch against QMake. Except that they want to drop QMake now. But bad luck. But just to visualize it, it should work also with any other system. So these plugins are designed in a way that they are packaged in itself in the end. That's a good thing is that we can support it on the server side, but it works in the same way also on your workstation. So you can develop it on your workstation. You can run it on your workstation. It's not limited to the build service. It's really a generic approach. Duncan yesterday saw this slide, for instance, and he said, oh, well, why do you vise is not yet integrated? And he just made a plugin based on the gem generator. There's a gem generator based on gem. He generates spec files. And now, within an hour, we had already a support for Rails. So that's the reason why I hope it will work out in this way. I want to show it to you. I have this is a build service web interface. There's also a command line interface and so on. But this is a web interface. And then a technical guy, me, implemented a web wizard. This is the reason why it looks so ugly. And it's not ready for end users. So this is an instance actually running on my notebook. It's a build service I brought to here. It's not online yet. So for instance, I can say I want photo wall. It's a QMAKE application. I just say, oh, well, photo is my package. I need to paste the URL. And at the moment, you need to save which generator you use. I hope we can skip this into the future. Well, yeah, it needs to know some descriptions, whatever. And it's done. And if so most, this means in this way we can package most of the simple applications, I'm quite happy in future. What it actually have done is writing a service file. So it's pretty generic. Again, it's just saying use two services. One is a download URL plug-in, just downloading the file in the end. And there could be some verification plug-ins which don't exist yet. And in this case, a QMAKE generator. Just use it. The result is the table, of course, and the spec file. What you see here are missing implementations. You see it knows about specialties in the distributions. For instance, Fedora has no dependency to C++, even when you install libqt-devil. OK, but we can handle it here. Then, yeah, Fedora has a different way to call QMAKEs. And Zuzer has OK, but it's handled. Zuzer has some special macro to support translations and desktop files. OK, handled. And we have a number of files which get installed, which is documented in the profile. So everything is there. And we get actually a running build. The build is already running because build service always starts the build when the source is changing or when depending packages are changing. We could watch it here. Yeah, it sets up the build environment. So for each package, the build service is trading in. And for M in the end, a complete new system to avoid that older builds influence the build. And the build is really repeatable. So I think we don't wait until it's finished, but I promise you that this particular example really compiles successful for Zuzer and Fedora, at least. Any questions to this generic, to this spec file generation? Otherwise, I would just tell you where we are with the build service in general and where we want to hit. Sorry. That's all I'm not about the deserability, rather the possibility to generate multi-distribution package. Distributing package is not just putting a file to download somewhere. It's also to provide a final user some kind of guarantee that it will work on the target environment. When I create and maintain package, I do it from on the river. I imagine, and I already had some remarks about Zuzer, that do you wonderful package work under my own environment? I have no way to test. And even if I had a way to do, I won't make any effort for it. So my point is, what's the advantage of providing package for distribution? You don't have any way or any deserability to charge a work. I mean, you mean it would be nicer to have one package, which works, one RPM, which works on all distributions? My point is, I don't care if I work as an environment. I'm targeting myself. Absolutely. But if you're an upstream developer, your goal should be to make it easier for distribution to package your software, not to distribute it yourself. Yeah, I think when we get the software authors to use this, they will see bugs in their build environment and fix it there, hopefully. And so we don't need a patch in the package anymore. That would be the best way, of course. And yeah, what we also want to have in future is the QA system, so that we can test more and show also more problems. But on the other hand, we want, of course, to have a fast success for the people. So there should be a package, how broken it would be. I mean, there are examples where they're enforced to install to user locally, ignoring everything else. If I may also add to the audience's answer, the interfaces and the results of the build service are open. So for example, notification system when packages are built. So we're talking to people like CMake and Ctest, so they could automatically download the packages, install them, run their test suites, run a UI testing tool like Squish to check that the software actually runs and installs and performs correctly. In practice, the open-source build service won't be of that much interest to other distributions themselves, but rather for developers to test them on these distributions. So there are people rebuilding Fedora and Ubuntu with the build service to adapt them for their own needs. So they're in my mode on the build service. OK. So if you are on distribution, you can get a pretty simple service to host your building or? Theoretically, yeah. Theoretically, yeah. And usually, they install their own instance. Yeah, yeah, yeah. But we could also do it at open-source.org. Yeah, because for some, it might be a lack of resources in terms of hardware bandwidth or even, I mean, also different architectures. I don't know how to support more than just two normal ones. Yeah, so the instance at open-source.org is only offering the normal ones, 64-bit and 32-bit. But it works, of course, for all other architectures as well. So the version internal, it's also for S390, itanium. OK, yeah, but do you offer those in the build service? That's also in the build service. I mean, in another build service instance, yes. OK, so you can actually build for multiple architectures on the system build service. Yeah, oh, cool. And there's a guy, for instance, supporting the open-source distribution to Spark at some moment just by installing it at some place and just reusing the remote connection of the build service because you can interconnect them on this side. So he automatically gets all the factory updates and rebuilds it on Spark hardware at this place. Maybe we should move our dead Spark port there. May I just? My ad, his question was, you can build for other distributions, but you have no way to test them. So how can you guarantee if it works? But for me, a big advantage is I can build packages of my applications for other distributions and have users test them. I have users using other distributions who would not want to do packaging, but who would just give it a try and test them for me, tell me if the package runs so I can put it on my download page. I mean, when it compiles, it can't be that broken, actually. Frankly, of course, it can be a runtime issue, of course, and you can integrate QA tests automatically, but what we don't offer is a life instance where you can connect to something we just don't offer. I mean, there are other offers. I think SourceForge is offering this and we simply see no point in offering remote lock-in shells for people. It's not in our focus, basically. That's a resource question because we want to use the same hardware better for building more packages. One more question. Might be a bit what, I know this service works on Linux. Is there a possibility to make it work with other canals like OpenSolaris or VSDs? Well, we have currently supported for packaging formats, build descriptions format, OpenSolaris is not yet supported, but you need basically to adapt two places to add another format. So if someone is spending time in supporting or implementing the parser for the OpenSolaris format, it could be easily extended. It's not necessarily about the packaging format, but rather the hosting. You know, the kernel that runs the build. You mean at our place at OpenSolaris or Huston? Well, in the first? In the instance, yeah, that should, well, it's Perl and Ruby on Rails. So it's, I don't see a reason why you shouldn't be able to run it there. Okay, and how about building the packages themselves? For example, Debian packages for OpenSolaris. That's the tricky part. Well, Debian is supported. The question is how much would this system differ to Debian? I mean, the different kernel shouldn't matter. At least if you don't use any virtualization at build time. The point is that we do, we really rebuild inside of Xen or KVM for security reasons, but you can also use just change route. And for in this instance, it would be simpler to use just change route. And as long as you have all your libraries and stuff as Debian package already somewhere, then you can, it should work out of the box. Okay, I would just inform you what we plan with the build service in general, besides these features. Yeah, right now, everybody can come to build OpenSolaris. To the main driver for Debian Ubuntu is there and it's building. You can install your own build service. We offer this release on Tuesday also appliances now. It makes it much easier to install because the build service is, I think, about 20 or 25 processes running in parallel. You need to set up Rails and Perl. It's, there are packages, but it's not automatically happening. So the appliance is really easy to start a build service on your own. What we work on at the moment is to improving the developer collaboration parts. We have started a review system. So it makes it more transparent, especially for our OpenSolar factory distribution, what is happening until a check in a new package or a change to a package gets accepted for it. So they are basically a legal and a source review and this should become transparent in the system. Also, we want to add the maintenance support so that the patch RPMs and the external needed metafiles, which are needed to do official maintenance updates for our official products get generated by it. And a very big point is to redo the web interface. There's the OpenSolar Booster team at the moment, which is unhappy with the web interface as it's right now because it just show a very limited feature set of the build service actually and it could be much better. So the next version will be a complete new web interface, basically. Then we have an attribute system, very flexible system to store any kind of extra information to package this project and so on. It's used to add information and to integrate it with external systems. And the automatic source processing is what I was speaking about here. What we also want to do this year, maybe or not, is really to enable the trust system. There was a diploma thesis, which was successful, but it's not really accessible yet. The trust system about their projects and people get some rating and based on the changes on the package, you know how much you can personally trust these packages because everybody can build a package so also every evil guy can come to the build service and you need to know about it. The LSP conform builds as another target. Would be really nice to have some pointers that it's really hard to work for the package to create a successful build against this target. But it should be there. Then we wanted to separate the QA tests which are inside as a separate framework so that the difference if the package is failing because of a compile error or because of a QA failure so that you see it differently. And there's also ideas of people who want to non-Linux platform support. Windows and MacOS are visually the most biggest targets. That depends if you find people who have time for this. The plan is there since we started the build service but it's so far not, no one really made a serious approach for that. Yesterday KDE on Windows people approached me and asked. Oh. It actually might even happen now. Okay, yeah. I talked to them before but we should talk again maybe. Yeah. In general if you want anything to know about the developments we have a concept page, we have the feature tracker. You can also request own features there but given the limited resources of our site it's better you implement it to yourself. And we have of course a mailing list, the instance and the IRC channel where people get help for getting into the stuff. Okay, any last questions? Yeah, the software itself is complete GPL and this is everybody, you just need to create an account. No money, nothing, it's just create an account and submit your packages and you, fine. Yes, there's Jan Simon-Möller running around here, not in this room. He worked on adding ARM support and of course ARM is working when you natively compile on ARM hardware but it's not what you want because ARM hardware is most likely to slow but he extended our build script and so on that you actually, it's a very clever trick in the end. It uses QA mode to emulate an ARM but the compiler backend is running natively. So you don't, you have only 10% speed reduction and you can very fast compile ARM packages and you don't need to adapt your packages because it looks like a native build. So you don't need to deal with all the broken build environments of all kind of packages where just are not designed to work a cost build. So he had pretty much success with that. Any last question? Okay, if you have any personal question or want to see something, I'm at the ZuzoBoost most of the time. So thank you very much.