Our next caller is Jeffrey from Maryland Jeffrey. What's up, man? How can we help you? Hey guys, how y'all doing today? Good. How are you? All right, I appreciate you taking the call So my question is um, and I'll give you a little bit of my background. Um So I'm currently on maps and a bollock I've done. I'm on my third time on that So recently I got an injury on my back. I'm recovered from it But I feel like now For whatever reason every time I go do like squats or something like deadlifts I feel like I get really sore the next day and I'm not sure if if it's because I'm pushing myself too much And the prior I was doing a lot of running I stopped doing that because I felt like my knees started hurting from all that too much And my next question is so I'm trying to re-enlist in the military I'm still currently I'm way more than what I used to but I think it's more of a muscle that I've gained not not body fat I still fit my same clothes but For for to join the military you have to weigh a certain weight for your height and weight So my question is how do you? How do you lose weight and still gain muscle while having to meet the military's requirements? All right, let's start with the first one. I need to ask you when you say you get really sore Do you mean just your muscles get sore or the back injury starts to hurt again? so at first I Was going I did lighter weights Because my back was still hurting but now it doesn't hurt. I just feel very sore Okay, it just you might be going too hard and too too heavy or maybe too much volume It also could be he's been this is a third time around on maps on a ball too Like his body might be screaming for something like mass performance and some mobility work Yeah, actually that maps performance would be perfect for you I think that would be the perfect routine for you and then as far as your The the fat loss muscle gain type of stuff. That's gonna be diet I mean you have you're gonna have the good training if you follow maps performance And by the way, if you don't have that we'll send that to you but that's great That's gonna be diet dude and then to pass the military test. You need to practice the actual test There's nothing's gonna get you nothing's gonna make you more capable of passing the test like getting good at the actual test itself And are you are you concerned with your ability to pass test or is it just more the weight thing? Do you feel pretty confident you'll pass the physical? No, so I've already been in the military my concern is just the weight The weight because for my height they require certain weight, but I've gained more weight So that would mean I would have to drop at least 15 more pounds in order to meet their requirements And they do a lot of running so I feel like that's another issue When it comes to like lifting weights as well This is another reason why I'm glad Adam mentioned performance because it's gonna be a lot more protective of the joints and that repetitive stress Is gonna add up obviously. Yeah, like losing weights gonna help You know, it's gonna help you feel like lighter in your feet like less, you know stress on the joints But to then reinforce that and go through those mobility sessions, especially but like keep up, you know Your strength cycles is gonna be you know a great compliment to what you're doing Yeah, how long do we have until to lose that weight? So we have about 15 to 20 pounds We need to go down. How long do we have? There's time but I would say it probably like three months. Oh, okay. Yeah, you got that. Oh, yeah, bro That's yeah. Yeah. Yeah. Yeah, that's good.  Like what do you have any any issues with like soda or sweets or processed foods or you know, what are your worst foods? My worst foods has to be sweets probably. Okay. I'm pretty good at controlling myself But there are there's days that it could get pretty bad. What does that mean? Like what does that look like? Candy, what is it? Well usually so I usually meal prep and I have everything ready So as long as I eat I'm good But then let's say I'll go out with some friends on a weekend and I'll have some cookies and One would turn into ten. Yeah, and but for the most part, especially I don't I don't always do that And I do meal prep every meal so I'm pretty good on that You know what it sounds like you know, it sounds like Jeffrey it sounds like and I've seen this is very common Monday through Friday, you're on point Saturday and Sunday you go off a little bit and so from a calorie perspective What that tends to look like is let's say somebody wants to I don't know Let's say they want to lose a pound of body fat a week So that's roughly and this is loose right 3,500 calories of deficit a week So what they do is they go, okay, I'm gonna be a 500 calorie deficit Every day because that equals, you know, 2,500 calories. So Monday through Friday, they're good, right? So that's 2,500 calorie deficit so far then Saturday and Sunday They go over by I don't know a thousand calories each day, which is easy to do. It's very easy to do I mean 10 cookies could easily turn into 700 or a thousand calories. Well now your calorie deficit for the week is 500 So now it would take you weeks to notice one pound of fat loss So those two days can make a big difference in how, you know, you start to lose body fat overall If Sal's right and that is something that you struggle with is on weekends I gave a tip to somebody else on one of these live questions a while back that I think And I had a lot of response from people that said, oh my god, I started doing that That was a huge game changer for me and that was if that's the case like you struggle with Keeping your calories in check on the weekends Sunday becomes the most important day of training and dieting It's like a crazy hack that I figured out personally because I sugar and sweets are my thing weekends Going over my also my thing also if I were to take a day off of lifting or two It would be saturday or sunday. And so if I build my routine around Okay, sunday is the day I cannot miss and that is the day that i'm going to be dialed in the most It's crazy how the rest of the week kind of just falls in in order Where if I don't do that on sunday and I start off and I have a bad sunday eating and then I go into monday It's harder to get me out of that on monday tuesday wednesday Okay And as far as uh The performance uh mass performance Would would you say include that with anabolic or just do no no it's a new program. It's a whole new program Just follow performance And it's got no more anabolics. Yeah, no more no more anabolic Leave that leave that or you mean anabolic like steroids Maybe that's why you're 200 pounds now You're on that you're on that d-ball. No. Yeah. No maps performance is its own program So you're gonna once we send that to you you could scrap it maps anabolic and do maps performance I think it'll be better for what your goals are Okay, sounds great. All right, man. Thanks for calling in. All right. Thank you. Have a great day guys. Thank you How many times did you guys have that with clients where they're really good monday through friday saturday and sunday they According to them they go off a little bit and but they don't realize like how much damage those going off That's why I just I mean that was a big thing for me I remember I shared a long time ago. I shared on the podcast the the introduction to the body bug Yeah Before that we didn't have a good tool to be able to kind of get a good Estimation of your metabolism, right or what you're burning on a regular basis And it and I was so dialed monday through friday. Like I ate perfect. I trained hard I was moving all day training 10 to 12 clients like Super active burned a tremendous amount of calories 5 000 plus calories a day. I was that back then And then saturday and sunday there was times where I could drop all the way to 25 Half you're just sitting on your ass and that's also the day I'd say hey, it's saturday at sunday I'm gonna have some pizza and watch football or I'm gonna you know I'll have a beer or two like I would go off the diet I would possibly not train and I would be burning like 50 percent the calories So not much room for air I could I could easily go over and that the little bit I was going over on saturday sunday it was enough to cancel All the work I was doing the week and that was what that's how the sunday can't take it off thing happened for me I said, okay. Well, I'm just gonna make myself Dialed sunday is gonna become my best day. It's no longer gonna be my worst day It'll become my best day And what ended up happening was if I set the tone on sunday the rest of the week I ended up having a great week Yeah, no, it makes a huge difference that when you said that I know we got messages from people who are like And it's the psychological piece of it. Totally. Yeah, totally


coming to the general functional group update. My name is Sid, and I'm going to try to share my screen. I'm at some place else today than my office. So forgive me if there's any technical difficulties. I want to clarify one thing. Sometimes I talk about our top priorities and .com availability and the number of leads we generate. And I stress that it's those are like the two top things in the company that have to improve that I'm focused on. And some people took that as meaning the people that are working on that are doing a bad job. That is not the case.  Like in a fast growing company, you continually have things that are kind of the throttle on the rest of the company. We could grow faster if. And whatever is after that, if you have more leads, if .com is more available, that will be a thing I focus on. That will be a thing I call out. And that is going to be something that we have to improve. So those are the areas where we can have the biggest impact. It doesn't necessarily mean that the quality there is bad or that the people are not doing a good job or there's no good plan in place. Generally, you might have great people working with a great plan. And still it's a problem on our growth. And still it will get called out. Number two, a decision we made at the executive offside is that we'll stop the early adopter program for ultimate as soon as possible. As soon as possible and we'll make guest users free in the ultimate addition. By making guest users free, we take away one of the things that our customers said is that they don't want to pay for someone that's only just commenting on things. I can't see my chat at the same time. So I want to ask if there's any questions at this point. Don't see anything yet. If we could speak up. Another thing I wanted to highlight, because it's obvious to me, but I learned to, I'm trying to repeat things that are obvious to me, but not might not be for everyone else, is that we're very well positioned to win in this market. We're the only ones kind of crazy enough maybe to make a single product for the whole DevOps lifecycle. And that's very, very ambitious. I don't think any other companies even dare to do that. And the only reason we're able to do it is because there's a lot of open source software out there. So instead of us trying to make everything, we're leveraging open source. We're leveraging Prometheus and technologies like Yeager and Elasticsearch and all the other great things and Kubernetes to build something. And it's kind of turning the disadvantage in this market on its head. When we started GitHub, lots of investors said, yeah, DevOps tooling, yeah, it's a really bad market because everything is open source. We're turning that on its head. It's a really great market because everything is open source. So we can just take all the components, leverage that open source. And then the problem is integrating all of that open source. You need at least 10 different components for a DevOps lifecycle if you're not using GitHub. And that means 24 different integrations. With GitHub, we don't do those integrations. We don't make the components as much as we focus on making them well integrated with our UX team with a single database. And that's unique. No one else is doing it. And it's an amazing value for customers because every customer you talk to is like, yeah, maintaining our tool chain, it's really hard. And everyone in the company has it organized differently and it's hurting us. A fourth thing, starting to a potential customer yesterday and look, they're not buying GitHub. They don't want another tool. They don't want LDAP sync or things like that. They want what we sell has to do with job. And it has to get them to a 200% faster DevOps cycle. And we say, if you buy GitHub, your DevOps cycle is three times as fast. That's what they're buying. And we should even, I made a proposal today. And if you look at our Slack channels, I won't name it, but there's a Slack channel that we can maybe even change our pricing so that we get paid when their DevOps cycle gets faster. And I think that's an amazing opportunity because I think if we go into a company and we look at the DevOps cycle of the different projects, I'm sure that the more of GitHub you adopt, the faster your DevOps cycle can be with the integrated security testing, with the review apps, et cetera. So if we can show that there's a correlation there, we can help the customer improve their DevOps cycle just by having more teams adopt all of GitHub. And maybe in the future, we get even paid by that. We get paid if we make it faster, not so much for seats or for licenses but just helping with a business outcome. The fifth thing is about multi-threading. There was a trend on Hacker News about GitT and it's an alternative to GitLab that's written in Go. It's amazingly fast, it's multi-threaded and it doesn't use a lot of memory. And GitLab does. And right now it's using four gigabytes. Some people even say GitLab's using eight gigabytes. A lot of that is from our application server that has multiple processes. Now that that's no longer the latest in Ruby on Rails land, like Puma and multi-threading was introduced years ago. We tried it, it didn't work at that time. But I think we should have another stab at it and try to make GitLab multi-threaded. The first thing to implement would be the Rubikop rules for preventing common mistakes that can cause problems in multi-threaded apps like global variables. And I think we should work towards that. I don't think we'll get GitLab down to half a gigabyte but a lot of people have instances on sites like DigitalOcean and most cloud providers, they charge for memory. So the more memory we use, the more expensive it will be to run GitLab. The last thing I'd love to talk about more is go beyond SaaS apps. Right now with GitLab, we assume you develop a SaaS app. There's some great, great sites out there, like bodybuild and lots of others that make it easier to develop for mobile. Visual Studio, for example, is also having some great features for that. There's people working on data and they have different requirements. They have something similar to a DevOps lifecycle with them for data engineering. And then there's machine learning. Not Jupiter, but TensorFlow and technologies like that. And there's a lifecycle to that too. Yesterday, we talked to someone from Google who was working on Kubeflow. And Kubeflow is making it easier to kind of do machine learning through the machine learning lifecycle. And I think it's really important that we make GitLab work, not just for run-of-the-mill Ruby on Rails applications but also for these scenarios. One of the projects we have is BizOps. It's for data engineering, making it easier to ingest data and to clean it up and to analyze it. The other big thing is what Dimitri is working on, our co-founder CTO, he's working on making it very easy to deploy Jupiter Hub from GitLab to make sure that when you deploy JupiterLab, it ties back to GitLab. And Jupiter comes up not just in data but also in machine learning. It's becoming the lengua franca of how to do analysis. And if you don't know Jupiter, it's based on iPython notebooks. It's similar to Mathematica or Maple. And if you don't know any of those, it's kind of an interactive Word document. So you have a document, you make a calculation, you press enter and it gets executed. Brandon, here's to the crazy ones. Yeah, that might be an Apple commercial. So thanks for that. Michael asked, is there any place in the handbook that goes over the other open source tools that GitLab is leveraging within GitLab? I don't think there is. But if you're interested in the BizOps section of our handbook, there is, it's front and center of what other technologies we're leveraging. And I'm sharing my screen so I can even show you quickly. So BizOps is leveraging Singer, DBT, Postgres, GitLab, CI and more DBT, Jupiter Hub and possibly D3 or SuperSat. That's Slack channel. Yeah, I guess that people could see my tab anyway. Our normal pricing is charging $99 per user per month. And you can't go out and do this tomorrow because I'm still arguing, arguing, having a constructive conversation with Chad in the Slack channel. You could imagine a pricing channel where we say, oh, it's half the price. And if every percentage points we make your DevOps life cycle faster, we charge a quarter. And if we improve it 200%, you end up paying the same. We make it even faster, we get more money. James says it might start up slower. I'm not aware of that, that might be, I don't think people care too much about our startup time. What happened when we tried Puma before is that we just had a lot of quote that wasn't multi-treaded in libraries in our own code everywhere. And we just got horrible errors the whole time. But that was around GitLab, like 4.05.0. So long, long time ago. So I think we should revisit that. Yeah, I was just saying, it might be that turning on multi-threading makes it the memory consumption worse to start with. And I think it was something to do with because each process accessing the memory, but I think there are workarounds. So yeah, setting the vision, I think we can get there. Yeah, we also got probably some horrible memory leaks. So that might even lead to everything getting worse. I think we have to buy to it. Patrick asks, is it possible that the requirements are too different for S&B and enterprise? Might be possible, but I think we can just go down a lot more. And there's always going to be some people that want to run it on 100 megabytes. Well, they should probably download, they should use GitWeb, the thing all based on. It comes with Git. And you can run a small web server to look at your GitWeb posts. But the further we can lower the requirements, the entry requirements, the less space there is below us for a competitive solution to develop. And there's this theory. It's called the innovators dilemma. And it kind of says most of the times you get displaced not by someone that makes something that's better. You get displaced by someone that makes something that's worse but more affordable or lower requirements. So we're not gonna lose to GitHub in the last week. We have a better product, we have better pricing. It doesn't, we're gonna win. However, very far in the future, 2030, we're gonna get displaced from something that looked like a toy that was doing a worse job but it was more affordable. And right now, that thing is looking like it's those things in that Hacker News article. So we should make sure that there's as little space below us as we can. So yeah, we can make everyone happy but we can probably reduce our memory requirements from four to eight gigabytes to one or two. So we should do that. Yeah, Chad says, yeah, faster DevOps cycle makes a lot of sense. It's not on our homepage. Yeah, I agree. So maybe it's on our homepage instead of saying concurrent DevOps, which nobody knows yet, we should call out a 200% faster DevOps cycle. And that would link you to a page like, hey, we can make it faster. How do we do that? We do that with concurrent DevOps. So if a sheesh is on the call, she might be an experiment worthy to run and Cortland plus wants that. Andrew, you wanna talk about Gitterly and removing the rocket code? Sure, it was on your point of going to multi-threaded Ruby. And so this is like a really wasteful thing that is the way it is at the moment because obviously we've been trying to build Gitterly and keep the application going. And so we've got a lot of struts that we've put, imagine we're building a bridge over a highway and we didn't wanna stop the highway. One of those struts is that we vendor code from the main application into Gitterly Ruby. And so when the GitLab application runs, we have the same code running in two places. And only once we get to Gitterly v 1.1, what would be able to remove that strut? And at the moment, obviously the Gitterly team are, many of them are working on other things. So this has been deep prioritized and will be a big win for memory consumption. I just wanted to make that point. Cool, yeah. I think everyone's looking forward to Gitterly 1.0 where we can turn off NFS and then Gitterly 1.1 where we can get rid of the rugged code in memory. So, but thanks for calling that out. I forgot that. I forgot to mention that on Hacker News on Sunday. Thanks, Jayce, for the Jupyter Hub link. And yeah, if you haven't watched the video about Jupyter or something like that already and you don't understand what it is, I encourage you to look at it. It is the way that data science and machine learning is being done. Ralph plus one's chance point about calling out our benefit to the customer instead of concurrent DevOps. William is in the call. William, feel free to speak up. John may ask about conversational development. So John, we're remaining a renaming conversational development to their DevOps score. And the DevOps score is going to be based on how much of GitLab you've adopted. So are you just using the version control or also the CI? Are you doing CD? Are you using the monitoring, et cetera? The more you use the higher your DevOps score. What we want for every customer is a graph. On one axis is the DevOps score of the different projects in the company. The other axis is their cycle time. And now what we hope is that there will be a line like this and I'm probably drawing the graph in the mirror image or something. But the more of GitLab you adopt on in general, the lower your cycle time. That's what we're hoping for. And we're going to build that into the product. So not only we can see it, but all the users are using that instance on GitLab 11. All those statistics should move out of the admin area and into an area where all the users can see it. Now we can have a conversation around that like, hey, you're seeing this trend. So would you like a 200% faster DevOps cycle? Yes, okay. Well, the way to get there is obvious. You can see it here, adopt more of GitLab. So how can we help your teams adopt more of GitLab? I want to ask, ending the early adopter program. I think so as she's just coordinating this, I think we'll have a cutoff date for like, this is the last date. If you're not in touch with us before this date, you cannot take advantage of the early adopter program, say end of next week with a ceaseless on it. So I'm not sure what the date will be, but they'll determine that. And then you have to actually order from us, for example, end of this quarter. I'm copying Chad's comments. Cool. I don't see anything else actionable. And I got to be on my way.


Hello, Java developers. My name is Matt Raebel. And today I'd like to show you how to build a secure rest API, and native image using Heladon. Let's get it up. I created a demo script for this, you can find it in octadev native Java examples, and the demo dash heladon dot adoc file. And like I said, we're going to create a Java REST API, secure it with OAuth2, and then we'll pass a JWT to it to authenticate our user. And then I'll do some comparisons with other frameworks that allow you to build Java REST APIs like Micronaut, Quarkus, and Spring Boot. And so for the demo script, for the repo, for a related blog post, check out the description on this video, I put links all over in there, and you'll be able to find all this information. The first thing you'll need is SDK man, I already have it installed. And if you need to get it, you can get it from SDK man dot IO, and then HTTP IE. And you can get that from HTTP by e.org, I believe. And then CLI dot octa.com is where you get the octa CLI, I already have that installed as well. At the end of some of the steps, you'll find IntelliJ live templates that I use. So they're just little brackets, and I store those in idea live templates on GitHub. So if you want to import them and use them, you certainly could but there's just a couple and you could copy and paste the code just as easily. So with SDK man, you can install Java 17. I already have installed. And so if I did Java version, you would see it there. If you want to see all the Java or all VM versions available, you can SDK list Java, and then grep for girl there. And then the first thing I want to do is generate an OAuth 2 access token. So with the octa CLI that makes it pretty easy. If you don't have an octa account, you can do octa register, or octa login if you do. And then I'll do octa apps create spot. And this we're going to use OIDC debugger for this. That's a website that allows you to easily create an access token. And the post logout redirect UI should match there. And then you'll see we got that client ID and issuer. So if we were to go to the site, it does remember my information from last time.  And, you know, everything else is okay, the defaults with code, you might need to check pkce because I don't believe that's a default. And then make sure and tack on v1 token there. And then click send request. And it comes back and does the pixie dance, and gets me that access token. So now I can set that right here. And back to our instructions. And we'll build a Java REST API with held on. So using their Maven archetype. We'll see the into downloads here, and run it. And this is using the hell it on quick start micro profile there. And then we can open that up in IntelliJ. There's also a held on CLI you can use, and run held on a knit for that. The first thing you'll need to do is add micro profile JWT support in the palm dot XML so just right at the top there should be fine. And then add a low resource. Looks like I got a type of there. And the source main Java here. And we'll put it in the controller package. And then we got a shortcut. Tell J live template. And this, you know, is just at the available at the path of slash hello. And it does a get request. I don't believe we actually need that one in there. That one should work fine. And then, you know, returns the user's information from the principle. So then we can also add a hello application to register that class. And this is that each app for my shortcut. No. Alright, we'll just copy and paste it then. And re import to get that JWT import. And then you can see we just register the class there, application scoped, it's just part of micro profile. And then we'll add our octa endpoints into source main resources meta and micro profile config dot properties. So this is our octa domain, which we have back here, replace that. There is no command to just start up a heledon app if you use heledon CLI there is. But I've just been doing MVM package and Java dash jar with the generated, you know, jar there. And what do we have here, we have a test failure. Uh oh, we better go. Oh, we need to delete these two because well, we don't need them. And then I think it generates a test as well. So that main test looks like it goes to greet Joe. And yeah, we'll just delete it. Who needs tests anyway, right? And then we'll go ahead and run it again. And then it doesn't like that we forgot to put jar on there, which makes perfect sense. I don't blame it. So it starts up. And now we can go ahead and hit that endpoint with our token. Make sure and reset it there. invalid URL. Let's see. Maybe I just did the command wrong. Yep, looks like it. I did it in the wrong order. So I got some cleanup to do on my instructions. If you go to the demo script after this, I make I'll make sure it's all up to date. But you can see, you know, it's logging in, it's got my information there. And it's all working. So let's go ahead and build a native heledon app. So I want to make sure it's not running in the background. And then make sure you're in the project. You can see that took just over a minute to run there a minute 20 seconds, according to my calculations. And now we can go ahead and start it up with target heledon. You'll see it's kind of buried in here, but it gives the time it started there 54 milliseconds. So let's try it again. 31 milliseconds. And 31. So that seems to be pretty consistent there. That's all working nicely. If we did a startup time comparison here with the other frameworks, what I did was I cloned them all or I created apps just like I showed you how to do here. And then I started them all three times. And then I started them five times and took the average of that. So you can see, you know, milliseconds to start here for heledon is 42. This is on an M1. So it's much faster here with 30 milliseconds. This was on Intel that I originally recorded these numbers. So with Micronaut, it's 27 milliseconds. With Quarkus, wicked fast 19 milliseconds. And then Spring Boot, a little bit slower than heledon there. And then the memory usage. This is a command I used to figure out memory usage with heledon. It starts up before any request 42 megs used, which is awesome for a job application, right? And after five requests, it has 62. And then you can see the comparison with the others there. And then what about the MacBook Pro M1, which I'm using to record this? You know, the milliseconds to start is 23. So faster than when I'm recording this with Camtasia.  Not sure why that is. But my basic synopsis is it builds twice as fast, which is very nice for a developer experience. It starts twice as fast, which is again very nice. But it does use a bit more memory. And so what we did with the Octa CLI is we made it easy to create a heledon app that integrates with Octa. So if I were to, you know, exit out of here and cancel this one and go up a level and create a new directory, clear this so you can see it easier. Octa start heledon.  So, you know, use get ignore to check that in or to ignore that file with if it has client secrets in it, which it doesn't right now, or use environment variables. And you can find this example's code in that native Java examples repo and the heledon directory. And of course, the blog post, build rest APIs and native Java apps with heledon. So I hope you've enjoyed this screencast. If you want to find me, I'm on Twitter at mrable. You can find my team at octadev and subscribe to our YouTube channel so you can get notifications when we publish more cool content like this. Thanks for watching. Have a great day.