Continuous integration service used to build and test software projects hosted at GitHub
POPULARITY
We often talk about promotions and growth, but the moment the conversation shifts towards paths to staff or executive positions, the advice goes blank. There is very little actionable information out there that can tell you how you can get to the highest echelons of leadership. To get a clearer picture on this topic, I sat down with Lena Reinhard, a seasoned executive with an extensive track record at CircleCI, Travis CI, and more. Lena shares her insights on the best ways to accelerate career growth in the tech space, answer thorny questions, such as “Why are executives hired from the outside?” and provide some candid takes on why taking things slow sometimes can pay off in the end.
Adnan Khan, Lead Security Engineer at Praetorian, joins Corey on Screaming in the Cloud to discuss software bill of materials and supply chain attacks. Adnan describes how simple pull requests can lead to major security breaches, and how to best avoid those vulnerabilities. Adnan and Corey also discuss the rapid innovation at Github Actions, and the pros and cons of having new features added so quickly when it comes to security. Adnan also discusses his view on the state of AI and its impact on cloud security. About AdnanAdnan is a Lead Security Engineer at Praetorian. He is responsible for executing on Red-Team Engagements as well as developing novel attack tooling in order to meet and exceed engagement objectives and provide maximum value for clients.His past experience as a software engineer gives him a deep understanding of where developers are likely to make mistakes, and has applied this knowledge to become an expert in attacks on organization's CI/CD systems.Links Referenced: Praetorian: https://www.praetorian.com/ Twitter: https://twitter.com/adnanthekhan Praetorian blog posts: https://www.praetorian.com/author/adnan-khan/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Are you navigating the complex web of API management, microservices, and Kubernetes in your organization? Solo.io is here to be your guide to connectivity in the cloud-native universe!Solo.io, the powerhouse behind Istio, is revolutionizing cloud-native application networking. They brought you Gloo Gateway, the lightweight and ultra-fast gateway built for modern API management, and Gloo Mesh Core, a necessary step to secure, support, and operate your Istio environment.Why struggle with the nuts and bolts of infrastructure when you can focus on what truly matters - your application. Solo.io's got your back with networking for applications, not infrastructure. Embrace zero trust security, GitOps automation, and seamless multi-cloud networking, all with Solo.io.And here's the real game-changer: a common interface for every connection, in every direction, all with one API. It's the future of connectivity, and it's called Gloo by Solo.io.DevOps and Platform Engineers, your journey to a seamless cloud-native experience starts here. Visit solo.io/screaminginthecloud today and level up your networking game.Corey: As hybrid cloud computing becomes more pervasive, IT organizations need an automation platform that spans networks, clouds, and services—while helping deliver on key business objectives. Red Hat Ansible Automation Platform provides smart, scalable, sharable automation that can take you from zero to automation in minutes. Find it in the AWS Marketplace.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I've been studiously ignoring a number of buzzword, hype-y topics, and it's probably time that I addressed some of them. One that I've been largely ignoring, mostly because of its prevalence at Expo Hall booths at RSA and other places, has been software bill of materials and supply chain attacks. Finally, I figured I would indulge the topic. Today I'm speaking with Adnan Khan, lead security engineer at Praetorian. Adnan, thank you for joining me.Adnan: Thank you so much for having me.Corey: So, I'm trying to understand, on some level, where the idea of these SBOM or bill-of-material attacks have—where they start and where they stop. I've seen it as far as upstream dependencies have a vulnerability. Great. I've seen misconfigurations in how companies wind up configuring their open-source presences. There have been a bunch of different, it feels almost like orthogonal concepts to my mind, lumped together as this is a big scary thing because if we have a big single scary thing we can point at, that unlocks budget. Am I being overly cynical on this or is there more to it?Adnan: I'd say there's a lot more to it. And there's a couple of components here. So first, you have the SBOM-type approach to security where organizations are looking at which packages are incorporated into their builds. And vulnerabilities can come out in a number of ways. So, you could have software actually have bugs or you could have malicious actors actually insert backdoors into software.I want to talk more about that second point. How do malicious actors actually insert backdoors? Sometimes it's compromising a developer. Sometimes it's compromising credentials to push packages to a repository, but other times, it could be as simple as just making a pull request on GitHub. And that's somewhere where I've spent a bit of time doing research, building off of techniques that other people have documented, and also trying out some attacks for myself against two Microsoft repositories and several others that have reported over the last few months that would have been able to allow an attacker to slip a backdoor into code and expand the number of projects that they are able to attack beyond that.Corey: I think one of the areas that we've seen a lot of this coming from has been the GitHub Action space. And I'll confess that I wasn't aware of a few edge-case behaviors around this. Most of my experience with client-side Git configuration in the .git repository—pre-commit hooks being a great example—intentionally and by design from a security perspective, do not convey when you check that code in and push it somewhere, or grab someone else's, which is probably for the best because otherwise, it's, “Oh yeah, just go ahead and copy your password hash file and email that to something else via a series of arcane shell script stuff.” The vector is there. I was unpleasantly surprised somewhat recently to discover that when I cloned a public project and started running it locally and then adding it to my own fork, that it would attempt to invoke a whole bunch of GitHub Actions flows that I'd never, you know, allowed it to do. That was… let's say, eye-opening.Adnan: [laugh]. Yeah. So, on the particular topic of GitHub Actions, the pull request as an attack vector, like, there's a lot of different forms that an attack can take. So, one of the more common ones—and this is something that's been around for just about as long as GitHub Actions has been around—and this is a certain trigger called ‘pull request target.' What this means is that when someone makes a pull request against the base repository, maybe a branch within the base repository such as main, that will be the workflow trigger.And from a security's perspective, when it runs on that trigger, it does not require approval at all. And that's something that a lot of people don't really realize when they're configuring their workflows. Because normally, when you have a pull request trigger, the maintainer can check a box that says, “Oh, require approval for all external pull requests.” And they think, “Great, everything needs to be approved.” If someone tries to add malicious code to run that's on the pull request target trigger, then they can look at the code before it runs and they're fine.But in a pull request target trigger, there is no approval and there's no way to require an approval, except for configuring the workflow securely. So, in this case, what happens is, and in one particular case against the Microsoft repository, this was a Microsoft reusable GitHub Action called GPT Review. It was vulnerable because it checked out code from my branch—so if I made a pull request, it checked out code from my branch, and you could find this by looking at the workflow—and then it ran tests on my branch, so it's running my code. So, by modifying the entry points, I could run code that runs in the context of that base branch and steal secrets from it, and use those to perform malicious Actions.Corey: Got you. It feels like historically, one of the big threat models around things like this is al—[and when 00:06:02] you have any sort of CI/CD exploit—is either falls down one of two branches: it's either the getting secret access so you can leverage those credentials to pivot into other things—I've seen a lot of that in the AWS space—or more boringly, and more commonly in many cases, it seems to be oh, how do I get it to run this crypto miner nonsense thing, with the somewhat large-scale collapse of crypto across the board, it's been convenient to see that be less prevalent, but still there. Just because you're not making as much money means that you'll still just have to do more of it when it's all in someone else's account. So, I guess it's easier to see and detect a lot of the exploits that require a whole bunch of compute power. The, oh by the way, we stole your secrets and now we're going to use that to lateral into an organization seem like it's something far more… I guess, dangerous and also sneaky.Adnan: Yeah, absolutely. And you hit the nail on the head there with sneaky because when I first demonstrated this, I made a test account, I created a PR, I made a couple of Actions such as I modified the name of the release for the repository, I just put a little tag on it, and didn't do any other changes. And then I also created a feature branch in one of Microsoft's repositories. I don't have permission to do that. That just sat there for about almost two weeks and then someone else exploited it and then they responded to it.So, sneaky is exactly the word you could describe something like this. And another reason why it's concerning is, beyond the secret disclosure for—and in this case, the repository only had an OpenAI API key, so… okay, you can talk to ChatGPT for free. But this was itself a Github Action and it was used by another Microsoft machine-learning project that had a lot more users, called SynapseML, I believe was the name of the other project. So, what someone could do is backdoor this Action by creating a commit in a feature branch, which they can do by stealing the built-in GitHub token—and this is something that all Github Action runs have; the permissions for it vary, but in this case, it had the right permissions—attacker could create a new branch, modify code in that branch, and then modify the tag, which in Git, tags are mutable, so you can just change the commit the tag points to, and now, every time that other Microsoft repository runs GPT Review to review a pull request, it's running attacker-controlled code, and then that could potentially backdoor that other repository, steal secrets from that repository.So that's, you know, one of the scary parts of, in particular backdooring a Github Action. And I believe there was a very informative Blackhat talk this year, that someone from—I'm forgetting the name of the author, but it was a very good watch about how Actions vulnerabilities can be vulnerable, and this is kind of an example of—it just happened to be that this was an Action as well.Corey: That feels like this is an area of exploit that is becoming increasingly common. I tie it almost directly to the rise of GitHub Actions as the default CI/CD system that a lot of folks have been using. For the longest time, it seemed like a poorly configured Jenkins box hanging out somewhere in your environment that was the exception to the Infrastructure as Code rule because everyone has access to it, configures it by hand, and invariably it has access to production was the way that people would exploit things. For a while, you had CircleCI and Travis-CI, before Travis imploded and Circle did a bunch of layoffs. Who knows where they're at these days?But it does seem that the common point now has been GitHub Actions, and a .github folder within that Git repo with a workflows YAML file effectively means that a whole bunch of stuff can happen that you might not be fully aware of when you're cloning or following along with someone's tutorial somewhere. That has caught me out in a couple of strange ways, but nothing disastrous because I do believe in realistic security boundaries. I just worry how much of this is the emerging factor of having a de facto standard around this versus something that Microsoft has actively gotten wrong. What's your take on it?Adnan: Yeah. So, my take here is that Github could absolutely be doing a lot more to help prevent users from shooting themselves in the foot. Because their documentation is very clear and quite frankly, very good, but people aren't warned when they make certain configuration settings in their workflows. I mean, GitHub will happily take the settings and, you know, they hit commit, and now the workflow could be vulnerable. There's no automatic linting of workflows, or a little suggestion box popping up like, “Hey, are you sure you want to configure it this way?”The technology to detect that is there. There's a lot of third-party utilities that will lint Actions workflows. Heck, for looking for a lot of these pull request target-type vulnerabilities, I use a Github code search query. It's just a regular expression. So, having something that at least nudges users to not make that mistake would go really far in helping people not make these mista—you know, adding vulnerabilities to their projects.Corey: It seems like there's also been issues around the GitHub Actions integration approach where OICD has not been scoped correctly a bunch of times. I've seen a number of articles come across my desk in that context and fortunately, when I wound up passing out the ability for one of my workflows to deploy to my AWS account, I got it right because I had no idea what I was doing and carefully followed the instructions. But I can totally see overlooking that one additional parameter that leaves things just wide open for disaster.Adnan: Yeah, absolutely. That's one where I haven't spent too much time actually looking for that myself, but I've definitely read those articles that you mentioned, and yeah, it's very easy for someone to make that mistake, just like, it's easy for someone to just misconfigure their Action in general. Because in some of the cases where I found vulnerabilities, there would actually be a commit saying, “Hey, I'm making this change because the Action needs access to these certain secrets. And oh, by the way, I need to update the checkout steps so it actually checks out the PR head so that it's [testing 00:12:14] that PR code.” Like, people are actively making a decision to make it vulnerable because they don't realize the implication of what they've just done.And in the second Microsoft repository that I found the bug in, was called Microsoft Confidential Sidecar Containers. That repository, the developer a week prior to me identifying the bug made a commit saying that we're making a change and it's okay because it requires approval. Well, it doesn't because it's a pull request target.Corey: Part of me wonders how much of this is endemic to open-source as envisioned through enterprises versus my world of open-source, which is just eh, I've got this weird side project in my spare time, and it seemed like it might be useful to someone else, so I'll go ahead and throw it up there. I understand that there's been an awful lot of commercialization of open-source in recent years; I'm not blind to that fact, but it also seems like there's a lot of companies playing very fast and loose with things that they probably shouldn't be since they, you know, have more of a security apparatus than any random contributors standing up a clone of something somewhere will.Adnan: Yeah, we're definitely seeing this a lot in the machine-learning space because of companies that are trying to move so quickly with trying to build things because OpenAI AI has blown up quite a bit recently, everyone's trying to get a piece of that machine learning pie, so to speak. And another thing of what you're seeing is, people are deploying self-hosted runners with Nvidia, what is it, the A100, or—it's some graphics card that's, like, $40,000 apiece attached to runners for running integration tests on machine-learning workflows. And someone could, via a pull request, also just run code on those and mine crypto.Corey: I kind of miss the days when exploiting computers is basically just a way for people to prove how clever they were or once in a blue moon come up with something innovative. Now, it's like, well, we've gone all around the mulberry bush just so we can basically make computers solve a sudoku form, and in return, turn that into money down the road. It's frustrating, to put it gently.Adnan: [laugh].Corey: When you take a look across the board at what companies are doing and how they're embracing the emerging capabilities inherent to these technologies, how do you avoid becoming a cautionary tale in the space?Adnan: So, on the flip side of companies having vulnerable workflows, I've also seen a lot of very elegant ways of writing secure workflows. And some of the repositories are using deployment environments—which is the GitHub Actions feature—to enforce approval checks. So, workflows that do need to run on pull request target because of the need to access secrets for pull requests will have a step that requires a deployment environment to complete, and that deployment environment is just an approval and it doesn't do anything. So essentially, someone who has permissions to the repository will go in, approve that environment check, and only then will the workflow continue. So, that adds mandatory approvals to pull requests where otherwise they would just run without approval.And this is on, particularly, the pull request target trigger. Another approach is making it so the trigger is only running on the label event and then having a maintainer add a label so the tests can run and then remove the label. So, that's another approach where companies are figuring out ways to write secure workflows and not leave their repositories vulnerable.Corey: It feels like every time I turn around, Github Actions has gotten more capable. And I'm not trying to disparage the product; it's kind of the idea of what we want. But it also means that there's certainly not an awareness in the larger community of how these things can go awry that has kept up with the pace of feature innovation. How do you balance this without becoming the Department of No?Adnan: [laugh]. Yeah, so it's a complex issue. I think GitHub has evolved a lot over the years. Actions, it's—despite some of the security issues that happen because people don't configure them properly—is a very powerful product. For a CI/CD system to work at the scale it does and allow so many repositories to work and integrate with everything else, it's really easy to use. So, it's definitely something you don't want to take away or have an organization move away from something like that because they are worried about the security risks.When you have features coming in so quickly, I think it's important to have a base, kind of like, a mandatory reading. Like, if you're a developer that writes and maintains an open-source software, go read through this document so you can understand the do's and don'ts instead of it being a patchwork where some people, they take a good security approach and write secure workflows and some people just kind of stumble through Stack Overflow, find what works, messes around with it until their deployment is working and their CI/CD is working and they get the green checkmark, and then they move on to their never-ending list of tasks that—because they're always working on a deadline.Corey: Reminds me of a project I saw a few years ago when it came out that Volkswagen had been lying to regulators. It was a framework someone built called ‘Volkswagen' that would detect if it was running inside of a CI/CD environment, and if so, it would automatically make all the tests pass. I have a certain affinity for projects like that. Another one was a tool that would intentionally degrade the performance of a network connection so you could simulate having a latent or stuttering connection with packet loss, and they call that ‘Comcast.' Same story. I just thought that it's fun seeing people get clever on things like that.Adnan: Yeah, absolutely.Corey: When you take a look now at the larger stories that are emerging in the space right now, I see an awful lot of discussion coming up that ties to SBOMs and understanding where all of the components of your software come from. But I chased some stuff down for fun once, and I gave up after 12 dependency leaps from just random open-source frameworks. I mean, I see the Dependabot problem that this causes as well, where whenever I put something on GitHub and then don't touch it for a couple of months—because that's how I roll—I come back and there's a whole bunch of terrifyingly critical updates that it's warning me about, but given the nature of how these things get used, it's never going to impact anything that I'm currently running. So, I've learned to tune it out and just ignore it when it comes in, which is probably the worst of all possible approaches. Now, if I worked at a bank, I should probably take a different perspective on this, but I don't.Adnan: Mm-hm. Yeah. And that's kind of a problem you see, not just with SBOMs. It's just security alerting in general, where anytime you have some sort of signal and people who are supposed to respond to it are getting too much of it, you just start to tune all of it out. It's like that human element that applies to so much in cybersecurity.And I think for the particular SBOM problem, where, yeah, you're correct, like, a lot of it… you don't have reachability because you're using a library for one particular function and that's it. And this is somewhere where I'm not that much of an expert in where doing more static source analysis and reachability testing, but I'm certain there are products and tools that offer that feature to actually prioritize SBOM-based alerts based on actual reachability versus just having an as a dependency or not.[midroll 00:20:00]Corey: I feel like, on some level, wanting people to be more cautious about what they're doing is almost shouting into the void because I'm one of the only folks I found that has made the assertion that oh yeah, companies don't actually care about security. Yes, they email you all the time after they failed to protect your security, telling you how much they care about security, but when you look at where they invest, feature velocity always seems to outpace investment in security approaches. And take a look right now at the hype we're seeing across the board when it comes to generative AI. People are excited about the capabilities and security is a distant afterthought around an awful lot of these things. I don't know how you drive a broader awareness of this in a way that sticks, but clearly, we haven't collectively found it yet.Adnan: Yeah, it's definitely a concern. When you see things on—like for example, you can look at Github's roadmap, and there's, like, a feature there that's, oh, automatic AI-based pull request handling. Okay, so does that mean one day, you'll have a GitHub-powered LLM just approve PRs based on whether it determines that it's a good improvement or not? Like, obviously, that's not something that's the case now, but looking forward to maybe five, six years in the future, in the pursuit of that ever-increasing velocity, could you ever have a situation where actual code contributions are reviewed fully by AI and then approved and merged? Like yeah, that's scary because now you have a threat actor that could potentially specifically tailor contributions to trick the AI into thinking they're great, but then it could turn around and be a backdoor that's being added to the code.Obviously, that's very far in the future and I'm sure a lot of things will happen before that, but it starts to make you wonder, like, if things are heading that way. Or will people realize that you need to look at security at every step of the way instead of just thinking that these newer AI systems can just handle everything?Corey: Let's pivot a little bit and talk about your day job. You're a lead security engineer at what I believe to be a security-focused consultancy. Or—Adnan: Yeah.Corey: If you're not a SaaS product. Everything seems to become a SaaS product in the fullness of time. What's your day job look like?Adnan: Yeah, so I'm a security engineer on Praetorian's red team. And my day-to-day, I'll kind of switch between application security and red-teaming. And that kind of gives me the opportunity to, kind of, test out newer things out in the field, but then also go and do more traditional application security assessments and code reviews, and reverse engineering to kind of break up the pace of work. Because red-teaming can be very fast and fast-paced and exciting, but sometimes, you know, that can lead to some pretty late nights. But that's just the nature of being on a red team [laugh].Corey: It feels like as soon as I get into the security space and start talking to cloud companies, they get a lot more defensive than when I'm making fun of, you know, bad service naming or APIs that don't make a whole lot of sense. It feels like companies have a certain sensitivity around the security space that applies to almost nothing else. Do you find, as a result, that a lot of the times when you're having conversations with companies and they figure out that, oh, you're a red team for a security researcher, oh, suddenly, we're not going to talk to you the way we otherwise might. We thought you were a customer, but nope, you can just go away now.Adnan: [laugh]. I personally haven't had that experience with cloud companies. I don't know if I've really tried to buy a lot. You know, I'm… if I ever buy some infrastructure from cloud companies as an individual, I just kind of sign up and put in my credit card. And, you know, they just, like, oh—you know, they just take my money. So, I don't really think I haven't really, personally run into anything like that yet [laugh].Corey: Yeah, I'm curious to know how that winds up playing out in some of these, I guess, more strategic, larger company environments. I don't get to see that because I'm basically a tiny company that dabbles in security whenever I stumble across something, but it's not my primary function. I just worry on some level one of these days, I'm going to wind up accidentally dropping a zero-day on Twitter or something like that, and suddenly, everyone's going to come after me with the knives. I feel like [laugh] at some point, it's just going to be a matter of time.Adnan: Yeah. I think when it comes to disclosing things and talking about techniques, the key thing here is that a lot of the things that I'm talking about, a lot of the things that I'll be talking about in some blog posts that have coming out, this is stuff that these companies are seeing themselves. Like, they recognize that these are security issues that people are introducing into code. They encourage people to not make these mistakes, but when it's buried in four links deep of documentation and developers are tight on time and aren't digging through their security documentation, they're just looking at what works, getting it to work and moving on, that's where the issue is. So, you know, from a perspective of raising awareness, I don't feel bad if I'm talking about something that the company itself agrees is a problem. It's just a lot of the times, their own engineers don't follow their own recommendations.Corey: Yeah, I have opinions on these things and unfortunately, it feels like I tend to learn them in some of the more unfortunate ways of, oh, yeah, I really shouldn't care about this thing, but I only learned what the norm is after I've already done something. This is, I think, the problem inherent to being small and independent the way that I tend to be. We don't have enough people here for there to be a dedicated red team and research environment, for example. Like, I tend to bleed over a little bit into a whole bunch of different things. We'll find out. So far, I've managed to avoid getting it too terribly wrong, but I'm sure it's just a matter of time.So, one area that I think seems to be a way that people try to avoid cloud issues is oh, I read about that in the last in-flight magazine that I had in front of me, and the cloud is super insecure, so we're going to get around all that by running our own infrastructure ourselves, from either a CI/CD perspective or something else. Does that work when it comes to this sort of problem?Adnan: Yeah, glad you asked about that. So, we've also seen open-s—companies that have large open-source presence on GitHub just opt to have self-hosted Github Actions runners, and that opens up a whole different Pandora's box of attacks that an attacker could take advantage of, and it's only there because they're using that kind of runner. So, the default GitHub Actions runner, it's just an agent that runs on a machine, it checks in with GitHub Actions, it pulls down builds, runs them, and then it waits for another build. So, these are—the default state is a non-ephemeral runner with the ability to fork off tasks that can run in the background. So, when you have a public repository that has a self-hosted runner attached to it, it could be at the organization level or it could be at the repository level.What an attacker can just do is create a pull request, modify the pull request to run on a self-hosted runner, write whatever they want in the pull request workflow, create a pull request, and now as long as they were a previous contributor, meaning you fixed a typo, you… that could be a such a, you know, a single character typo change could even cause that, or made a small contribution, now they create the pull request. The arbitrary job that they wrote is now picked up by that self-hosted runner. They can fork off it, process it to run in the background, and then that just continues to run, the job finishes, their pull request, they'll just—they close it. Business as usual, but now they've got an implant on the self-hosted runner. And if the runners are non-ephemeral, it's very hard to completely lock that down.And that's something that I've seen, there's quite a bit of that on GitHub where—and you can identify it just by looking at the run logs. And that's kind of comes from people saying, “Oh, let's just self-host our runners,” but they also don't configure that properly. And that opens them up to not only tampering with their repositories, stealing secrets, but now depending on where your runner is, now you potentially could be giving an attacker a foothold in your cloud environment.Corey: Yeah, that seems like it's generally a bad thing. I found that cloud tends to be more secure than running it yourself in almost every case, with the exception that once someone finds a way to break into it, there's suddenly a lot more eggs in a very large, albeit more secure, basket. So, it feels like it's a consistent trade-off. But as time goes on, it feels like it is less and less defensible, I think, to wind up picking out an on-prem strategy from a pure security point of view. I mean, there are reasons to do it. I'm just not sure.Adnan: Yeah. And I think that distinction to be made there, in particular with CI/CD runners is there's cloud, meaning you let your—there's, like, full cloud meaning you let your CI/CD provider host your infrastructure as well; there's kind of that hybrid approach you mentioned, where you're using a CI/CD provider, but then you're bringing your own cloud infrastructure that you think you could secure better; or you have your runners sitting in vCenter in your own data center. And all of those could end up being—both having a runner in your cloud and in your data center could be equally vulnerable if you're not segmenting builds properly. And that's the core issue that happens when you have a self-hosted runner is if they're not ephemeral, it's very hard to cut off all attack paths. There's always something an attacker can do to tamper with another build that'll have some kind of security impact. You need to just completely isolate your builds and that's essentially what you see in a lot of these newer guidances like the [unintelligible 00:30:04] framework, that's kind of the core recommendation of it is, like, one build, one clean runner.Corey: Yeah, that seems to be the common wisdom. I've been doing a lot of work with my own self-hosted runners that run inside of Lambda. Definitionally those are, of course, ephemeral. And there's a state machine that winds up handling that and screams bloody murder if there's a problem with it. So far, crossing fingers hoping it works out well.And I have a bounded to a very limited series of role permissions, and of course, its own account of constraint blast radius. But there's still—there are no guarantees in this. The reason I build it the way I do is that, all right, worst case someone can get access to this. The only thing they're going to have the ability to do is, frankly, run up my AWS bill, which is an area I have some small amount of experience with.Adnan: [laugh]. Yeah, yeah, that's always kind of the core thing where if you get into someone's cloud, like, well, just sit there and use their compute resources [laugh].Corey: Exactly. I kind of miss when that was the worst failure mode you had for these things.Adnan: [laugh].Corey: I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?Adnan: I do have a Twitter account. Well, I guess you can call it Twitter anymore, but, uh—Corey: Watch me. Sure I can.Adnan: [laugh]. Yeah, so I'm on Twitter, and it's @adnanthekhan. So, it's like my first name with ‘the' and then K-H-A-N because, you know, my full name probably got taken up, like, years before I ever made a Twitter account. So, occasionally I tweet about GitHub Actions there.And on Praetorian's website, I've got a couple of blog posts. I have one—the one that really goes in-depth talking about the two Microsoft repository pull request attacks, and a couple other ones that are disclosed, will hopefully drop on the twenty—what is that, Tuesday? That's going to be the… that's the 26th. So, it should be airing on the Praetorian blog then. So, if you—Corey: Excellent. It should be out by the time this is published, so we will, of course, put a link to that in the [show notes 00:32:01]. Thank you so much for taking the time to speak with me today. I appreciate it.Adnan: Likewise. Thank you so much, Corey.Corey: Adnan Khan, lead security engineer at Praetorian. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that's probably going to be because your podcast platform of choice is somehow GitHub Actions.Adnan: [laugh].Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
About JeremyJeremy is the Director of DevRel & Community at CircleCI, formerly at Solace, Auth0, and XDA. He is active in the DevRel Community, and is a co-creator of DevOpsPartyGames.com. A lover of all things coffee, community, open source, and tech, he is also house-broken, and (generally) plays well with others.Links Referenced: CircleCI: https://circleci.com/ DevOps Party Games: https://devopspartygames.com/ Twitter: Iamjerdog LinkedIn: https://www.linkedin.com/in/jeremymeiss/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I generally try to have people that I know in the ecosystem on this show from time to time, but somehow today's guest has never made it onto the show. And honestly, I have no excuse other than that, I guess I just like being contrary about it. Jeremy Meiss is the Director of DevRel and Community at CircleCI. Jeremy, thank you for finally getting on the show.Jeremy: Hey, you know what? I woke up months and months ago hoping I would be able to join and never have, so I appreciate you finally, you know, getting that celestial kick in the ass.Corey: I love the fact that this is what you lie awake at night worrying about. As all people should. So, let's get into it. You have been at CircleCI in their DevRel org—heading their DevRel org—for approximately 20 years, but in real-time and non-tech company timeframes, three years. But it feels like 20. How's that been? It's been an interesting three years, I'll say that much with the plague o'er the land.Jeremy: Yes, absolutely. No, it was definitely a time to join. I joined two weeks before the world went to shit, or shittier than it already was. And yeah, it's been a ride. Definitely see how everything's changed, but it's also been one that I couldn't be happier where I'm at and seeing the company grow.Corey: I've got to level with you. For the longest time, I kept encountering CircleCI in the same timeframes and context, as I did Travis CI. They both have CI in the name and I sort of got stuck on that. And telling one of the companies apart from the other was super tricky at the time. Now, it's way easier because Travis CI got acquired and then promptly imploded.Security issues that they tried to hide left and right, everyone I knew there long since vanished, and at this point, it is borderline negligence from my point of view to wind up using them in production. So oh, yeah, CircleCI, that's the one that's not trash. I don't know that you necessarily want to put that on a billboard somewhere, but that's my mental shortcut for it.Jeremy: You know, I'm not going to disagree with that. I think, you know, it had its place, I think there's probably only one or two companies nowadays actually propping it up as a business, and I think even they are actively trying to get out of it. So yeah, not going to argue there.Corey: I have been on record previously as talking about CI/CD—Continuous Integration slash Continuous Deployment—or for those who have not gone tumbling down that rabbit hole, the idea that when you push a commit to a particular branch on Git—or those who have not gotten to that point, push the button, suddenly code winds up deploying to different environments, occasionally production, sometimes staging, sometimes development, sometimes by accident—and there are a bunch of options in that space. AWS has a bunch of services under their CodeStar suite: CodeBuild, CodeDeploy, CodePipeline, and that's basically there as a marketing exercise by CI/CD companies that are effective because after having attempted to set those things up with the native offerings, you go scrambling to something else, anything else. GitHub Actions has also been heavily in that space because it's low friction to integrate, it's already there in GitHub, and that's awesome in some ways, terrible in others. But CircleCI has persistently been something that I see in a lot of different environments, both the open-source world, as well as among my clients, where they are using you folks to go from developer laptops to production safely and sanely.Jeremy: Absolutely, yeah. And I think that's one thing for us is, there's a niche of—you know, you can start if you're into AWS or you're into Google, or you're in—any of those big ecosystems, you can certainly use what they have, but those are always, like, add-on things, they're always like an afterthought of, “Oh, we're going to go add this,” or, “We're going to go add that.” And so, I think you adequately described it of, you know, once you start hitting scale, you're eventually going to start to want to use something, and I think that's where we generally fit in that space of, you know, you can start, but now you're going to eventually end up here and use best-in-class. I spent years Auth0 in the identity space, and it was the same kind of boat is that, you know, sure you can start with hopefully not rolling your own, but eventually you're going to end up wanting to use something best-in-class that does everything that you want it to do and does it right.Corey: The thing that just completely blows my mind is how much for all these companies, no matter who they are and how I talk to them, everyone talks about their CI/CD flow with almost a sense of embarrassment. And back in the days when I was running production environments, we use Jenkins as sort of a go-to answer for this. And that was always a giant screaming exemption to the infrastructure-as-code approach because you could configure it via the dashboard and the web interface and it would write that out as XML files. So, you wound up with bespoke thing lots of folks could interact with in different ways, and oh, by the way, it has access into development, staging, and production. Surely, there will be no disasters that happened as a result of this.And that felt terrible. And now we've gotten into a place where most folks are not doing that anymore, at least with the folks that I talk to, but I'm still amazed by how few best practices around a lot of this stuff has really emerged. Every time I see a CI/CD pipeline, it feels like it is a reimplementation locally of solving a global problem. You're the director of DevRel and have been for a few years now. Why haven't you fixed this yet?Jeremy: Primarily because I'm still stuck on the fact you mentioned, pushing a button and getting to XML. That just kind of stuck me there and sent me back that I can't come up with a solution at this point.Corey: Yeah, it's the way that you solve the gap—the schism as it were—between JSON and YAML. “Cool, we're going to use XML.” And everyone's like, “Oh, God, not that.” It's like, “Cool, now you're going to settle your differences or I'm going to implement other things, too.”Jeremy: That's right, yeah. I mean, then we're going to go use some bespoke company's own way of doing IAC. No, I think there's an element here where—I mean, it goes back to still using best-in-class. I think Hudson, which eventually became Jenkins, after you know, Cisco—was it Cisco? No, it was Sun—after Sun, you know, got their hands all over it, it was the thing. It's kind of, well, we're just going to spin this up and do it ourselves.But as the industry changes, we do more and more things on the cloud and we do it primarily because we're relocating the things that we don't want to have to manage ourselves with all of the overhead and all of the other stuff. We're going to go spit it over to the cloud for that. And so, I think there's been this shift in the industry that they still do, like you said, look at their pipelines with a little bit of embarrassment [laugh], I think, yeah. I chuckle when I think about that, but there is a piece where more and more people are recognizing that there is a better way and that you can—you don't have to look at your pipelines as this thing you hate and you can start to look at what better options there are than something you have to host yourself.Corey: What I'm wondering about now, though, because you've been fairly active in the space for a long time, which is a polite way of saying you have opinions—and you should hear the capital O and ‘Opinions' when I say it that way—let's fight about DevRel. What does DevRel mean to you? Or as I refer to it, ‘devrelopers?'Jeremy: Uh, devrelopers. Yes. You know, not to take from the standard DevOps answer, but I think it depends.Corey: That's the standard lawyer answer to anything up to and including, is it legal for me to murder someone? And it's also the senior consultant answer, to anything, too, because it turns out the world is baked and nuanced and doesn't lend itself to being resolved in 280 characters or less. That's what threads are for.Jeremy: Right [laugh]. Trademark. That is ultimately the answer, I think, with DevRel. For me, it is depending on what your company is trying to do. You ultimately want to start with building relationships with your developers because they're the ones using your product, and if you can get them excited about what they're doing with your product—or get excited about your product with what they're doing—then you have something to stand on.But you also have to have a product fit. You have to actually know what the hell your product is doing and is it going to integrate with whatever your developers want. And so, DevRel kind of stands in that gap that says, “Okay, here's what the community wants,” and advocates for the community, and then you have—it's going to advocate for the company back to the community. And hopefully, at the end of the day, they all shake hands. But also I've been around enough to recognize that there comes that point where you either a have to say, “Hey, our product for that thing is probably not the best thing for what you're trying to do. Here, you should maybe start at this other point.”And also understanding to take that even, to the next step to finish up the answer, like, my biggest piece now is all the fights that we have constantly around DevRel in the space of what is it and what is it not, DevRel is marketing. DevRel is sales. DevRel is product. And each of those, if you're not doing those things as a member of the company, you're not doing your job. Everybody in the company is the product. Everybody in the company is sales. Everybody in the company is marketing.Corey: Not everyone in the company realizes this, but I agree—Jeremy: Yes.Corey: Wholeheartedly.Jeremy: Yes. And so, that's where it's like yes, DevRel is marketing. Yes, it is sales. Because if you're not out there, spreading whatever the news is about your product and you're not actually, you know, showing people how to use it and making things easier for people, you're not going to have a job. And too often, these companies that—or too often I think a lot of DevRel teams find themselves in places where they're the first that get dropped when the company goes through things because sometimes it is just the fact that the company has not figured out what they really want, but also, sometimes it's the team hasn't really figured out how to position themselves inside the business.Corey: One of the biggest, I'll call it challenges that I see in the DevRel space comes down to defining what it is, first and foremost. I think that it is collectively a mistake for an awful lot of practitioners of developer relations, to wind up saying first and foremost that we're not marketing. Well, what is it that you believe that marketing is? In fact, I'll take it a step beyond that. I think that marketing is inherently the only place in most companies where we know that doing these things leads to good results, but it's very difficult to attribute or define that value, so how do we make sure that we're not first up on the chopping block?That has been marketing's entire existence. It's, you know that doing a whole bunch of things in marketing will go well for you, but as the old chestnut says, half your marketing budget is wasted and you'll go broke figuring out which half it is.Jeremy: Yeah. And whenever you have to make cuts, generally, they always, you know, always come to the marketing teams because hey, they're the ones spending, you know, millions of dollars a quarter on ads, or whatever it is. And so yeah, marketing has, in many ways figured this out. They're also the team that spends the most money in a company. So, I don't really know where to go with that isn't completely off the rails, but it is the reality. Like, that's where things happen, and they are the most in touch with what the direction of the company is going to ultimately be received as, and how it's going to be spoken about. And DevRel has great opportunities there.Corey: I find that when people are particularly militant about not liking sales or marketing or any other business function out there, one of the ways to get through them is to ask, “Great. In your own words, describe to me what you believe that department does. What is that?” And people will talk about marketing in a bunch of tropes—or sales in a bunch of tropes—where it is the worst examples of that.It's, “Terrific, great. Do you want me to wind up describing what you do as an engineer—in many cases—in the most toxic stereotype of Uber and 2015-style engineer I can come up with?” I think, in most cases if we're having a conversation and I haven't ended it by now, you would be horrified by that descriptor. Yeah. Not every salesperson is the skeezy used car salesman trying to trick you into something awful. Actual selling comes down to how do we wind up taking your pain away. One of my lines is, “I'm a consultant. You have problems and money. I will take both.”Jeremy: That's right [laugh]. Yeah, that's right.Corey: If you don't have a painful problem, I have nothing to sell you and all I'm doing is wasting my breath trying.Jeremy: Yeah, exactly. And that's where—I'll say it two ways—the difference between good marketing teams are, is understanding that pain point of the people that they're trying to sell to. And it's also a difference between, like, good and bad, even, DevRel teams is understanding what are the challenges that your users are having you're trying to express to, you're trying to fix? Figure that out because if you can't figure that out, then you or your marketing team are probably soon to be on the block and they're going to bring someone else in.Corey: I'm going to fight you a little bit, I suspect, in that a line I've heard is that, “Oh, DevRel is part of product because we are the voice of the community back into the development cycle of what product is building.” And the reason that I question that is I think that it glosses over an awful lot of what makes product competent as a department and not just a function done by other people. It's, “Oh, you're part of the product. Well, great. How much formal training have you had as part of your job on conducting user research and interviews with users and the rest?”And the answer invariably rounds to zero and, okay, in other words, you're just giving feedback in a drive-by fashion that not structured in any way and your product people are polite enough not to call you out on it. And that's when the fighting and slapping begins.Jeremy: Yeah. I don't think we're going to disagree too much there. I think one of the challenges, though, is for the very reason you just mentioned, that the product teams tend to hear your product sucks. And we've heard all the people telling us that, like, people in the community say that, they hear that so much and they've been so conditioned to it that it just rolls off their back, like, “Okay, whatever.” So, for DevRel teams, even if you're in product, which we can come back to that, regardless of where you're at, like, bringing any type of feedback you bring should have a person, a name associated with it with, like, Corey at Duckbill Group hates this product.Corey: Uh-oh [laugh]. Whenever my name is tied to feedback, it never goes well for me, but that will teach me eventually, ideally, to keep my mouth shut.Jeremy: Yeah. Well, how's that working for you?Corey: I'll let you know if it ever happens.Jeremy: Good. But once you start making the feedback like an actual person, it changes the conversation. Because now it's like, oh, it's not this nebulous, like, thing I can not listen to. It's now oh, it's actually a person at a specific company. So, that's one of the challenges in working with product that you have to overcome.When I think about DevRel in product, while I don't think that's a great spot for it, I think DevRel is an extension of product. That's part of where that, like, the big developer experience craze comes from, and why it is a valuable place for DevRel to be able to have input into is because you tend to be the closest to the people actually using the product. So, you have a lot of opportunities and a big surface area to have some impact.Corey: This episode is sponsored in part by our friends at Strata. Are you struggling to keep up with the demands of managing and securing identity in your distributed enterprise IT environment? You're not alone, but you shouldn't let that hold you back. With Strata's Identity Orchestration Platform, you can secure all your apps on any cloud with any IDP, so your IT teams will never have to refactor for identity again. Imagine modernizing app identity in minutes instead of months, deploying passwordless on any tricky old app, and achieving business resilience with always-on identity, all from one lightweight and flexible platform.Want to see it in action? Share your identity challenge with them on a discovery call and they'll hook you up with a complimentary pair of AirPods Pro. Don't miss out, visit Strata.io/ScreamingCloud. That's Strata dot io slash ScreamingCloud.Corey: I think that that is a deceptively nuanced statement. One of the things I learned from an earlier episode I had with Dr. Christina Maslach, is contributors to occupational burnout, so much of it really distills down—using [unintelligible 00:16:35] crappy layman's terms—to a lack of, I guess what I'm going to call relevance or a lack—a feeling like you are not significant to what the company is actually doing in any meaningful way. And I will confess to having had a number of those challenges in my career when I was working in production environments because, yeah, I kept the servers up and the applications up, but if you really think about it, one of the benefits of working in the system space—or the production engineers base, or DevOps, or platform engineering, or don't even start with me these days—is that what you do conveys almost seamlessly from company to company. Like, the same reason that I can do what I do now, I don't care what your company does, necessarily, I just know that the AWS bill is a bounded problem space and I can reason about it almost regardless of what you do.And if I'm keeping the site up, okay, it doesn't matter if we're streaming movies or selling widgets or doing anything, just so long as I don't find that it contradicts my own values. And that's great, but it also is isolating because you feel like you're not really relevant to the direction of what the company actually does. It's, “Okay, so what does this company do?” “We make rubber bands,” and well, I'm not really a rubber band connoisseur, but I could make sure that the website stays up. But it just feels like there's a disconnect element happening.Jeremy: That is real. It is very real. And one of the ways that I tried to kind of combat that, and I help my team kind of really try and keep this in mind, is we try to meet as much as possible with the people that are actually doing the direction, whether it be product marketing, or whether it's in product managers, or it's even, you know, in engineering is have some regular conversations with what we do as a company. How are we going to fit with that in what we do and what we say and all of our objectives, and making sure that everything we do ties to something that helps other teams and that fits within the business and where it's going so that we grow our understanding of what the company is trying to do so that we don't kind of feel like a ship that's without a sail and just floating wherever things go.Corey: On some level, I am curious as to what you're seeing as we navigate this—I don't know if it's a recession,' I don't know if it's a correction; I'm not sure what to call it—but my gut tells me that a lot of things that were aimed at, let's call it developer quality of life, they were something of a necessity in the unprecedented bull market that we've seen for the last decade at some point because most companies cannot afford to compete with the giant tech company compensation packages, so you have to instead talk about quality of life and what work-life balance looks like, and here's why all of the tools and processes here won't drive you to madness. And now it feels like, “Oh, we don't actually have to invest in a lot of those things, just because oh yeah, like, the benefits here are you're still going to be employed next week. So, how about that?” And I don't think that's a particularly healthy way to interact with people—it's certainly not how I do—but it does seem that worrying about keeping developers absolutely thrilled with every aspect of their jobs has taken something of a backseat during the downturn.Jeremy: I don't know. I feel like developer satisfaction is still an important piece, even though, you know, we have a changing market. And as you described, if you're not happy with the tool you're using, you're not going to be as productive than using the tool or using—you know, whether it's an actual developer productivity tool, or it's even just the fact that you might need two monitors, you're not going to be as productive if you're not enjoying what you're doing. So, there is a piece of it, I think, the companies are recognizing that there are some tools that do ultimately benefit and there's some things that they can say, we're not going to invest in that area right now. We're good with where we're at.Corey: On some level, being able to say, “No, we're not going to invest in that right now,” is the right decision. It is challenging, in some cases, to wind up talking to some team members in some orgs, who do not have the context that is required to understand why that decision is being made. Because without context, it looks like, “Mmm, no. I'm just canceling Christmas for you personally this year. Sorry, doesn't it suck to be you? [singing] Dut, dut.” And that is very rarely how executives make decisions, except apparently if they're Elon Musk.Jeremy: Right. Well, the [Muskrat 00:21:23] can, you know, sink any company—Corey: [laugh].Jeremy: — and get away with it. And that's one thing I've really been happy with where I'm at now, is you have a leadership team that says, “Hey, here's where things are, and here's what it looks like. And here's how we're all contributing to where we're going, and here's the decisions we're going to make, and here's how—” they're very open with what's going on. And it's not a surprise to anybody that the economic time means that we maybe can't go to 65 events next year. Like, that's just reality.But at the end of the day, we still have to go and do a job and help grow the company. So, how can we do that more efficiently? Which means that we—it leaves it better to try and figure that out than to be so nebulous, with like, “Yep, nope. You can't go do that.” That's where true leadership comes to is, like, laying it out there, and just, you know, getting people alongside with you.Corey: How do you see DevRel evolving? Because I think we had a giant evolution over the past few years. Because suddenly, the old vision of DevRel—at least in some quarters, which I admit I fell a little too deeply into—was, I'm going to go to all the conferences and give all of the talks, even though most of them are not related to the core of what I do. And maybe that's a viable strategy; maybe it's not. I think it depends on what your business does.And I don't disagree with the assertion that going and doing something in public can have excellent downstream effects, even if the connection is not obvious. But suddenly, we weren't able to do that, and people were forced to almost reinvent how a lot of that works. Now, that the world is, for better or worse, starting to open up again, how do you see it evolving? Are we going right back to a different DevOps days in a different city every week?Jeremy: I think it's a lot more strategic now. I think generally, there is less mountains of money that you can pull from to go and do whatever the hell you want. You have to be more strategic. I said that a few times. Like, there's looking at it and making sure, like, yeah, it would be great to go and, you know, get in front of 50,000 people this quarter or this year, whatever you want to do, but is that really going to move the bottom line for us? Is that really going to help the business, or is that just helping your Delta miles?What is really the best bang for the buck? So, I think DevRel as it evolves, in the next few years, has to come to a good recognition moment of we need to be a little bit more prescriptive in how we do things within our company and not so willy-nilly return to you know, what we generally used to get away with. That means you're going to see a lot more people have to be held to account within their companies of, is what you're doing actually match up to our business goal here? How does that fit? And having to explain more of that, and that's, I think, for some people will be easy. Some people are going to have to stretch that muscle, and others are going to be in a real tough pickle.Corey: One last topic I want to get into with you is devopspartygames.com, an online more or less DevOps, quote-unquote, “Personality” assortment of folks who wind up playing online games. I was invited once and promptly never invited back ever again. So first, was it something I said—obviously—and two what is that and how—is that still going in this post-pandemic-ish era?Jeremy: I like how you answered your own question first; that way I don't have to answer it. The second one, the way it came about was just, you know, Matty and I had started missing that interaction that we would tend to have in person. And so, one of the ways we started realizing is we play these, you know, Jackbox games, and why can't we just do this with DevOps tech prompts? So, that's kind of how it kicked off. We started playing around doing it for fun and then I was like, “You know, we should—we could do this as a big, big deal for foreseeable future.”Where's that now is, we actually have not done one online for—what is it? So probably, like, eight, nine months, primarily because it's harder and harder to do so as everybody [laugh]—we're now doing a little bit more travel, and it's hard to do those—as you know, doing podcasts, it takes a lot of work. It's not an easy kind of thing. And so, we've kind of put that on pause. But we actually did our first in-person DevOps Party Games at DevOpsDays Chicago recently, and that was a big hit, I think, and opportunity to kind of take what we're doing virtually, and the fun and excitement that we generally would have—relatively half-drunk—to actually doing it actually in-person at an event. And in the different—like, just as giving talks in person was a different level of interaction with the crowd, the same thing is doing it in person. So, it was just kind of a fun thing and an opportunity maybe to continue to do it in person.Corey: I think we all got a hell of a lot better very quickly at speaking to cameras instead of audiences and the rest. It also forced us to be more focused because the camera gives you nothing in a way that the audience absolutely does.Jeremy: They say make love to the camera, but it doesn't work anyways.Corey: I really want to thank you for spending as much time as you have talking to me. If people want to learn more about who you are and what you're up to, where should they go?Jeremy: Well, for the foreseeable future, or at least what we can guess, you can find me on the Twitters at @Iamjerdog. You can find me there or you can find me at, you know, LinkedIn, at jeremymeiss, LinkedIn. And you know, probably come into your local DevOpsDays or other conference as well.Corey: Of course. And we will, of course, put links to that in the show notes.Jeremy: Excellent.Corey: Thank you so much for being so generous with your time. It is always appreciated. And I do love talking with you.Jeremy: And I appreciate it, Corey. It was great beyond, finally. I won't hold it against you anymore.Corey: Jeremy Meiss, Director of DevRel at CircleCI. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, irritated comment talking about how CI/CD is nonsense and the correct way to deploy to production is via the tried-and-true method of copying and pasting.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
https://fellow.app/supermanagers/lena-reinhard-hypergrowth-in-engineering-organizations-how-to-hire-grow-and-support-the-atomic-unit-of-a-team/ Maintaining a high performance culture during a period of hypergrowth is hard. Performance management is neglected, hiring standards decrease… In episode #129, Lena Reinhard shares her tactical approach to building the habit of strategic thinking and maintaining a high standard. Lena has over 13 years of experience supporting engineering leaders and building high-performing, globally distributed engineering organizations in hypergrowth. She was the former VP of Engineering at CircleCI and Travis CI. Lena shares her playbook for growth, what being a strategic leader means, and the STABB framework. Tune in to hear all about Lena's leadership journey and the lessons learned along the way! . . . Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review and share the podcast with your colleagues.
Cloud Posse holds public "Office Hours" every Wednesday at 11:30am PST to answer questions on all things related to DevOps, Terraform, Kubernetes, CICD. Basically, it's like an interactive "Lunch & Learn" session where we get together for about an hour and talk shop. These are totally free and just an opportunity to ask us (or our community of experts) any questions you may have. You can register here: https://cloudposse.com/office-hoursJoin the conversation: https://slack.cloudposse.com/Find out how we can help your company:https://cloudposse.com/quizhttps://cloudposse.com/accelerate/Learn more about Cloud Posse:https://cloudposse.comhttps://github.com/cloudpossehttps://sweetops.com/https://newsletter.cloudposse.comhttps://podcast.cloudposse.com/[00:00:00] Intro[00:01:29] Many GitHub “Projects” Improvementshttps://github.blog/2022-11-15-the-journey-of-your-work-has-never-been-clearer/[00:03:41] Spacelift Announces “Spaces” Featurehttps://spacelift.io/blog/spaces-by-spacelift[00:05:07] GitHub Actions can now require approval for workflows from private forkshttps://github.blog/changelog/2022-11-14-github-actions-require-approval-for-running-workflows-from-private-forks/[00:05:39] GitHub Actions Importer can import from Azure DevOps, CircleCI, GitLab, Jenkins, and Travis CI.https://docs.github.com/en/actions/migrating-to-github-actions/automating-migration-with-github-actions-importer[00:09:06] GitHub Action for Atlantis Drift Detectionhttps://github.com/cresta/atlantis-drift-detection[00:10:13] Terraform Provider for Reading Environment Variableshttp://terraform-provider-environment[00:14:39] How We Use Terraform At Slackhttps://slack.engineering/how-we-use-terraform-at-slack/[00:15:09] New Atmos Documentation Live!https://atmos.tools/[00:41:35] Careers at Cloud Possehttps://cloudposse.com/careers/[00:43:26] When can we expect Cloud Posse for Google? [00:48:52] Confidence in using Atmos in 3-5 year lifespan?[00:58:11] Outro#officehours,#cloudposse,#sweetops,#devops,#sre,#terraform,#kubernetes,#awsSupport the show
Cet épisode marathon sera découpé en deux morceaux pour éviter à vos oreilles une écoute marathon. Cette deuxième partie couvre des sujets d'architecture et de loi société et organisation ainsi que les conférences à venir. Logging, Migration Java 8 vers 11, Xerox Park, (manque de) sécurité, courbes elliptiques, sondage développeurs. Enregistré le 8 juillet 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–282.mp3 News Architecture Pour ou contre le logging Contre puis pour tous les langages et plateformes utilisent les logs debugging, tracing, journaling, monitoring, and printing errors impact sur les performances (allocation supérieure sur un log que sur le code métier log = mémoire, CPU (GC), I/O risque de securité (dépendances et fonctionnalités sans besoin) format des log: pour lecture humaine main volume impose traitement automatique log level la bonne abstraction (souvent trop et pas ce que l'on veut à la fois debugging -> utiliser un debugger ; journaling -> event sourcing ou solution dédiée ; tracing > open tracing ; monitoring -> monitoring solution via metrics et health check bons usages de logging: en dev (println), fin de jobs automatiques, erreurs non récupérables ou innatendues, pas les erreurs utilisateur (logger les erreurs qui cachent un bug), dans les container, Sébastien utilise System.out et System.err vu que les logs sont gérés par la plateforme la réponse pour maintenant les logs peuvent etre structurés performance, on peut éviter les concatenations de String (parameterized logging), memory allocation est bien meilleure depuis 2012 (e.g. Shenandoah), vu des problèmes dans des cas plus rare de genre MDC.getCopyOfContextMap disk I/O: ok mais disque cape a 200 MiB/s donc bon…: si c;est le cas, sépare I/O log du reste (disque vs network par exemple) gros fan de logs structures via JSON ; log line sur console et JSON en fichier log plus de manière conditionelle tracing théoriquement bon mais limite dans son contexte métier et peu d'infos passables system.out problème de scalabilité d'usage, etc et appel blocant println (async usage n'est pas bon) LinkedIn et sa migration de Java 8 à 11 1000 apps sur 320k hosts Migration Java 8 vers 11 avec en vue G1 regardé depuis 2018 Jetty, Hadoop, Play, Samza: focalisé sur Jetty Mettre a jour le système de build, 2. Faire des tests de performance 3. Automatiser la migration mise. a jour vers gradle 5 G1 80% des applis CMS 20% pris 20 apps representatives focalisé sur les applications avec les tailles de piles les plus grosses de équipera jusquà 200% plus de latence et throughput: zones G1, Shenandoah et ZGC automatisé la migration du reste et tourné les builds de tests qui ont identifié les problèmes de migration quelques problèmes: suppression de certaines classes Java EE, changement du type de classloader par défaut, casting de classe plus stricte ils ont utilisé -release 8 et ont limité les usages des features Java 11 les options de CLI de la JVM ont beaucoup changé LinkedIn fait du microsercices ce qui veut dire que beaucoup de repositories sont liés à d'autre par un graphe de dépendance: euh c'est pas le principe des microservices d'éviter ça??? mise a jour de 500 librairies 3/4 de l'année Quelques challenges vus La JVM respecte groups et donc moins de thread GC sont crées aussi ils pouvaient piquer des cycles CPUs avant et plus maintenant Java 11 a un usage de mémoire hors pile plus important reduction de latence p99 par 10% et le throughput par 20% sans changer le type de GC C'est un bon retour qui sent le type de développement de la vrai vie Méthodologies Un article sur Xerox park et comment ils ont inventé le futur article de 1985 Xerox achète un constructeur de mainframe, et ils ont crée un lab de recherche pour aider les usages Macintosh et la souris et les fenêtres, les cartes météos colorées, imprimante laser, réseaux d'ordinateurs, lasers semi-conducteurs qui lisent les disques optiques, langages de programmation structurés developer l'architecture de l'information project proposes et faite en bottom up PARC construisait ses propres hardware ce qui a créer des inventions et qui devaient etre construits pour 100 utilisateurs (scale) recherche en construisant concrètement, pas en papier théorique académique bit map, distributed computing, email, frame buffer, LAN, object oriented programming Cree Alto un ordinateur « personnel » qui a permis aux chercheurs de tester leurs idées, beaucoup en avaient un. donc ils ont du inventer le LAN et Ethernet (packet) via une personne avec passe de radio amateur (medium partagé et non reliable premier projet distribué. (Un protocole d'impression) antialiasing : ils amélioraient en testant pour de vrai un gars a construit un proto de souris pour prouver que les curseurs étaient plus efficace: tests avec des dans la rue et IO a perdu :D concept de modal (insert, delete) vers comportement non modal, plus simple pour l'utilisateur small talk: un langage si simple qu'un enfant peut l'utiliser (simulation based programming) overlapping windows ont été développées en small talk autre groupe strong type system Xerox ne savait pas convertir ces recherches en produits et les amener sur le marcher (sauf l'imprimante laser) Sécurité Travis CI fuit encore des mots de passe permet d'accéder au compte privé des développeurs open source qui ont mis en place travisCI c'est la quatrième fois token offre accès lecture et écriture aux repos risque d'attaque de supply chain tokens github, AWS ou DockerHub apr exemple mais aussi les bases de données utilisées dans la CI via l'API TravisCI HDMI peut-être un vecteur d'attaque et d'infection de vos ordinateurs Un hack d'un adaptateur HDMI peut potentiellement infecter un video-projecteur, et qui à son tour pourra réinfecter les prochains ordinateurs qui s'y connecteront Cet article propose de construire une sorte de connecteur qui sert de firewall HDMI pour éviter ce genre d'infection il y a des préservatifs USB aussi qui ne laissent passer que la puissance et pas les données Un guide pour protéger son macOS Une suite de conseils comme de faire une installation toute fraiche, de mettre les mises à jour logicielle automatiques, n'autoriser que les applications signées, appliquer le chiffrement du disque… Mais aussi utiliser par exemple un gestionnaire de mot de passe, éviter les extensions de navigateur, faire tourner un firewall Et des liens vers des guides de sécurités plus avancés un truc que je n'ai pas fait mais qui me tente c'est un outbound firewall comme little snitch ou lulu Comment choisir un algorithme de courbes elliptiques un article qui détaille le pour et le contre de certaines courbes elliptiques cas d'usage, notamment gouvernemental faiblesses (timing attaques etc) pour les curieux mais la première courbe citée est celle la plus utilisée en ce moment Loi, société et organisation Stackoverflow sort son sondage sur les développeurs 70% apprennent a coder en ligne (les plus de 45 ans dans les bouquins) stackoverflow derrière la doc technique puis les blogs ; video 60% des gens ; podcast 7,21% damn! presque 60% ont moins de 10 ans d'expérience ; si t'es pas VP ou CxO a 17 ans d'expérience, tu as raté ta vie 9% cloud infra engineers 22% ont neuro atypiques Docker passe dans la catégorie outil fondamental (69% d'usage) les frameworks 3D genre Unity 3D ou Unreal Engine sont des outils que des non développeurs pro apprennent Rust technologie la plus aimée, Rust et Python en plus demandées Java 6eme position mais 4ème pour ceux qui apprenent Angular.is en framework le plus redouté / react.is le plus demandé Docker et Kube sont les plus aimés et demandé indépendants on augmenté de 5% et 4% pour les temples pleins 85% des dev sont dans une orga partiellement distancié le 62% des devs pro cherchent des réponses pendant plus de 30 minutes par jour, 25% 11h Azure prend la deuxième place des cloud, OVH 3,7% Spring framework le plus populaire de Java VSCode 74%, IntelliJ 28%, vim 23%, Eclipse 12%, EMacs 4,5% pleins d'outils asynchrone (tickets etc) que je ne connais pas salaires ont augmenté de 23% en median JavaScript change de licence open source toujours la licence Ecma international license, assez restrictive qui interdit le fork, mais avec certaines provisions pour l'intégration et la reproduction mais aussi une nouvelle licence dérivée de la W3C Document & Software License, un peu plus ouverte, qui permet d'intégrer et s'intégrer plus facilement avec les autres standards du Web Conférences de la part de Youen Cette année Codeurs en Seine, c'est le 17 novembre et le cfp est ouvert N'hésitez pas à amener un peu de JVM dans l'appel à orateur. (ca commence à se faire rare). Pour rappel : codeurs en seine c'est 1000 personnes autour des métiers du développement dans une des plus grande salle de Rouen, le kindarena. Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/
Do you want to scale your automation and have your development teams become more productive and ship code more frequently? Are you making some common performance mistakes? And do you use Travis CI? If so, you might be at risk. Find out the answers to these and all other and full pipeline DevOps automation testing performance testing and security testing in 10 minutes or less in this episode of the TestGuild new show for the week of June 19th, so grab your favorite cup of coffee, tea and let's do this. Time News Title Rocket Link 0:27 Create a FREE Applitools Account https://rcl.ink/xroZw 0:59 Dev Tools AI https://links.testguild.com/RhPZe 1:46 Esalesforce Playwright https://links.testguild.com/16C2A 2:49 Provar Test Manager https://links.testguild.com/x8C4x 3:34 IBM Virtual Dev and Test for z/OS https://links.testguild.com/96Rsg 4:18 Test At Scale LambdaTest https://links.testguild.com/TYxeM 5:39 Applitools Front-End Test Fest https://links.testguild.com/Y382Q 6:22 testRigor and Twilio https://links.testguild.com/9lyGz 6:54 Oracle Test Automation Event https://links.testguild.com/8GCkU 7:40 Performance Mistakes https://links.testguild.com/UCNAa 8:15 Open source incident response tool OnCall https://links.testguild.com/mmtAt 8:45 Unpatched Travis CI API Bug https://links.testguild.com/JjrOQ
In this week's review:The rise of BlackCat (ALPHV) ransomwareMicrosoft Analysis of BlackCatAdvIntel Analysis of BlackCatRansomware Group Debuts Searchable Victim DataLockBit 2.0: How This RaaS Operates and How to Protect Against ItTranslating Saitama's DNS tunneling messages - SANS Internet Storm CenterPublic Travis CI Logs (Still) Expose Users to Cyber AttacksBlog: https://offsec.blog/Youtube: https://www.youtube.com/channel/UCCWmudG_CTNAFBaV48vIcfwTwitter: https://twitter.com/cyberthreatpovWork with Us: https://securit360.com
Follina's Tuesday Patch, Hertzbleed Attack, Mighty Bot, and more.A daily look at the relevant information security news from overnight - 15 June, 2022Episode 245 - 15 June 2022Follina's Tuesday PAtch- https://www.zdnet.com/article/microsoft-june-2022-patch-tuesday-55-fixes-remote-code-execution-in-abundance/Hertzbleed Attack - https://www.securityweek.com/new-hertzbleed-remote-side-channel-attack-affects-intel-amd-processorsTravis Exposed Tokens- https://www.bleepingcomputer.com/news/security/thousands-of-github-aws-docker-tokens-exposed-in-travis-ci-logs/Citrix ADM Error - https://www.securityweek.com/attackers-can-exploit-critical-citrix-adm-vulnerability-reset-admin-passwordsLinux Panchan Bot - https://www.bleepingcomputer.com/news/security/new-go-botnet-panchan-spreading-rapidly-in-education-networks/Mighty Bot - https://www.zdnet.com/article/a-tiny-botnet-launched-the-largest-ddos-attack-on-record/Hi, I'm Paul Torgersen. It's Wednesday June 15th, 2022, and this is a look at the information security news from overnight. From ZDNet.comJune Patch Tuesday is a popular one with everyone from Siemens to Schneider to Adobe to SAP rolling out updates. In fact, 141 updates just from those four. The one I am going to call out is Microsoft. Redmond rolled out 55 fixes, That's down from 74 last month, and only three of which are critical, but one of those is a fix for the Follina zero-day. At long last. Get your patch on kids. From SecurityWeek.com:Researchers have identified a new side-channel attack that can allow hackers to remotely extract sensitive information from a targeted system through a CPU timing attack they are calling Hertzbleed. This impacts devices powered by Intel and AMD and possibly others. Details on the article. From BleepingComputer.com:The Travis CI platform, which is used for software development and testing, has exposed user data containing tens of thousands of authentication tokens for GitHub, AWS, and Docker Hub. Aqua Security, who discovered the flaw, shared their findings with Travis hoping for a fix, but they were told that the issue was “by design” and left the data exposed. From SecurityWeek.com:Citrix has warned of a critical vulnerability in their Citrix Application Delivery Management that could essentially allow an attacker to trigger an administrator password reset at the next reboot. The vulnerabilities impact all supported versions of Citrix ADM server and Citrix ADM agent. Customers will need to update the server as well as all associated agents. The company says it has already taken care of the ADM cloud service and no additional action is required there. From BleepingComputer.comA new peer-to-peer botnet named Panchan has popped up targeting Linux servers in the education sector to mine crypto. It is empowered with SSH worm functions to move laterally within the compromised network, and has powerful detection avoidance capabilities, such as using memory-mapped miners and dynamically detecting process monitoring to pause the mining module. And last today, from ZDNet.comSpeaking of botnets, Cloudflare says it mitigated a DDoS attack that peaked at 26 million requests per second, and was caused by a botnet of only just over 5,000 devices. Rather than being based in IoT devices, this botnet was hiding in cloud service providers. For this particular attack, each device was averaging 5,200 requests per second, which is about 4,000 times more than a typical IoT botnet can generate. Details on the article. That's all for me today. Have a great rest of your day. Like and subscribe, and until tomorrow, be safe out there.
Security researchers found leaked developer credentials from Travis CI, Google places an AI engineer on leave after expressing concerns that it’s LaMDA language model is sentient, and the Netherlands accepts Apple’s changes it its App Store payment rules. MP3 Please SUBSCRIBE HERE. You can get an ad-free feed of Daily Tech Headlines for $3 aContinue reading "Security Researchers Find Leaked Trove of Developer Credentials – DTH"
Bu hafta Kerem Kocaer ve Murat Lostar, hacker platformu #RaidFrums'un kapatılmasını ve #Heroku ve #Travis CI'dan çalınan OAuth token'ları yorumluyor. Dünyanın en büyük hacker platformlarından biri olan ve RaidForums, Europol tarafından çökertildi. 2015 yılından beri aktif olan sitenin kurucusu 21 yaşındaki Portekiz vatandaşı, İngiltere'de yakalandı. Geçtiğimiz yıllarda, dark web'te yer alan #SilkRoad ve #AlphaBay isimli illegal sitelerde aynı şekilde kapatılmıştı. Yakın zaman önce Microsoft'un satın aldığı, yazılım geliştirme ve kaynak kodları saklama platformu Github, Heroku ve Travis-CI'ın Github'daki özel repo'larından bazı kaynak kodları alınmış olduğunu fark ederek Heroku ve Travis CI'ı bilgilendiriyor. 15 Nisan'da Heroku web sitesinde durumu yayımlıyor ve etkilendiğini düşündüğü müşterilerine mesaj göndererek #OAuth token'larını kapatmaya başlıyor. Görüntülü yayına https://www.youtube.com/siberingunlugu üzerinden ulaşabilirsiniz. Keyifli dinlemeler
Passend zu unserer letzten Twitter-Umfrage gibt es Neues aus dem KI-Bereich. OpenAI stellt DALL-E 2 vor: Ein neue künstliche Intelligenz, die es schafft, realistische Bilder aus Texteingaben zu erzeugen. Die Möglichkeiten sind fast grenzenlos und am eindrücklichsten wird es, wenn ihr euch ein paar Beispielbilder anseht.Quarkus kommt in der Version 2.8. Wenn ihr noch nicht wisst, was Quarkus ist, könnt ihr euch schon jetzt auf unsere "Java in der Cloud"-Folge in zwei Wochen freuen!Es gab ein Sicherheitsproblem bei GitHub, das dazu geführt hat, dass Travis CI und Heroku aktuell nicht auf GitHub zugreifen können. Hier die Links zum Secret Scanning und TruffleHog.Fabi greift unser Quanten-Game auf und stellt euch ein neues Spiel von Google vor. Passend dazu gibt es von OpenSSH eine neue Version, die den Schlüsselaustausch sicher gegen Attacken von Quantencomputern machen soll. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTube
About AidanAidan is an AWS enthusiast, due in no small part to sharing initials with the cloud. He's been writing software for over 20 years and getting paid to do it for the last 10. He's still not sure what he wants to be when he grows up.Links: Stedi: https://www.stedi.com/ GitHub: https://github.com/aidansteele Blog posts: https://awsteele.com/ Ipv6-ghost-ship: https://github.com/aidansteele/ipv6-ghost-ship Twitter: https://twitter.com/__steele TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by someone who is honestly, feels like they're after my own heart. Aidan Steele by day is a serverless engineer at Stedi, but by night, he is an absolute treasure and a delight because not only does he write awesome third-party tooling and blog posts and whatnot around the AWS ecosystem, but he turns them into the most glorious, intricate, and technical shit posts that I think I've ever seen. Aidan, thank you for joining me.Aidan: Hi, Corey, thanks for having me. It's an honor to be here. Hopefully, we get to talk some AWS, and maybe also talk some nonsense as well.Corey: I would argue that in many ways, those things are one in the same. And one of the things I always appreciated about how you approach things is, you definitely seem to share that particular ethos with me. And there's been a lot of interesting content coming out from you in recent days. The thing that really wound up showing up on my radar in a big way was back at the start of January—2022, for those listening to this in the glorious future—about using IPv6 to use multi-factor auth, which it is so… I don't even have the adjectives to throw at this because, first it is ridiculous, two, it is effective, and three, it is just who thinks like that? What is this and what did you—what monstrosity have you built?Aidan: So, what did I end up calling it? I think it was ipv6-ghost-ship. And I think I called it that because I'd recently watched, oh, what was that series that was recently on Apple TV? Uh, the Isaac Asimov—Corey: If it's not Paw Patrol, I have no idea what it is because I have a four-year-old who is very insistent about these things. It is not so much a TV show as it is a way of life. My life is terrible. Please put me out of my misery.Aidan: Well, at least it's not Bluey. That's the one I usually hear about. That's Australia's greatest export. But it was one of the plot devices was a ship that would teleport around the place, and you could never predict where it was next. And so no one could access it. And I thought, “Oh, what about if I use the IPv6 address space?”Corey: Oh, Foundation?Aidan: That's the one. Foundation. That's how the name came about. The idea, honestly, it was because I saw—when was it?—sometime last year, AWS added support for those IP address prefixes. IPv4 prefixes were small; very useful and important, but IPv6 with more than 2 trillion IP addresses, per instance, I thought there's got to be fun to be had there.Corey: 281 trillion, I believe is the—Aidan: 281 trillion.Corey: Yeah. It is sarcastically large space. And that also has effectively, I would say in InfoSec sense, killed port scanning, the idea I'm going to scan the IP range and see what's there, just because that takes such a tremendous amount of time. Now here, in reality, you also wind up with people using compromised resources, and yeah, it turns out, I can absolutely scan trillions upon trillions of IP addresses as long as I'm using your AWS account and associated credit card in which to do it. But here in the real world, it is not an easily discoverable problem space.Aidan: Yeah. I made it as a novelty, really. I was looking for a reason to learn more about IPv6 and subnetting because it's the term I'd heard, a thing I didn't really understand, and the way I learn things is by trying to build them, realizing I have no idea what I'm doing, googling the error messages, reluctantly looking at the documentation, and then repeating until I've built something. And yeah, and then I built it, published it, and seemed to be pretty popular. It struck a chord. People retweeted it. It tickled your fancy. I think it spoke something in all of us who are trying not to take our jobs too seriously, you know, know we can have a little fun with this ludicrous tech that we get to play with.Corey: The idea being, you take the multi-factor auth code that your thing generates, and that is the last series of octets for the IP address you wind up going towards and that is such a large problem space that you're not going to find it in time, so whatever it is automatically connect to that particular IP address because that's the only one that's going to be listening for a 30 to 60-second span for the connection to be established. It is a great idea because SSH doesn't support this stuff natively. There's no good two-factor auth approach for this. And I love it. I'd be scared to death to run this in production for something that actually matters.And we also start caring a lot more about how accurate are the clocks on those instances, all of a sudden. But, oh, I just love the concept so much because it hits on the ethos of—I think—what so much of the cloud does were these really are fundamental building blocks that we can use to build incredible, awe-inspiring things that are globe-spanning, and also ridiculousness. And there's so much value of being able to do the same thing, sometimes at the same time.Aidan: Yeah, it's interesting, you mentioned, like, never using in prod, and I guess when I was building it, I thought, you know, that would be apparent. Like, “Yes, this is very neat, but surely no one's going to use it.” And I did see someone raised an issue on the GitHub project which was talking about clock skew. And I mentioned—Corey: Here at the bank where I'm running this in production, we're—Aidan: [laugh].Corey: —having some trouble with the clock. Yeah, it's—Aidan: You know, I mentioned that the underlying 2FA library did account for clock scheme 30 seconds either way, but it made me realize, I might need to put a disclaimer on the project. While the code is probably reasonably sound, I personally wouldn't run it in production, and it was more meant to be a piece of performance art or something to tickle one's fancy and to move on, not to roll it out. But I don't know, different strokes for different folks.Corey: I have gotten a lot better about calling out my ridiculous shitpost things when I do them. And the thing that really drove that home for me was talking about using DNS TXT records to store information about what server a virtual machine lives on—or container or whatnot—thus using Route 53 is a database. And that was a great gag, and then someone did a Reddit post of “This seems like a really good idea, so I'm going to start doing it, and I'm having these questions.”And at that point is like, “Okay, I've got a break character at that point.” And is, yeah, “Hi. That's my joke. Don't do it because X, Y, and Z are your failure modes, there are better tools for it. So yeah, there are ways you can do this with DNS, but it's not generally a great idea, and there are some risk factors to it. And okay, A, B, and C are the things you don't want to do, so let's instead do it in a halfway intelligent way because it's only funny if everyone's laughing. Otherwise, we fall into this trap of people take you seriously and they feel bad as a result when it doesn't work in production. So, calling it out as this is a joke tends to put a lot of that aside. It also keeps people from feeling left out.Aidan: Yeah. I realized that because the next novelty project I did a few days later—not sure if you caught it—it was a Rick Roll over ICMPv6 packets, where if you had run ping six to a certain IP range, it would return the lyrics to music's greatest treasure. So, I think that was hopefully a bit more self-evident that this should never be taken seriously. Who knows, I'm sure someone will find a use for it in prod.Corey: And I was looking through this, this is great. I love some of the stuff that you're doing because it's just fantastic. And I started digging a bit more to things you had done. And at that point, it was whoa, whoa, whoa, wait a minute. Back in 2020, you found an example of an issue with AWS's security model where CloudTrail would just start—if asked nicely—spewing other people's credential sets and CloudTrail events and whatnot into your account.And, A, that's kind of a problem. B, it was something that didn't make that big of a splash when it came out—I don't even think I linked to it at the time—and, C, it was examples of after the recent revelations around CloudFormation and Glue that the fine folks at Orca Security found out. That wasn't a one-off because you'd done this a year beforehand. We have now an established track record of cross-account data sharing and, potentially, exploits, and I'm looking at this and I got to level with you I felt incredibly naive because I had assumed that since we hadn't heard of this stuff in any real big sense that it simply didn't happen.So, when we heard about Azure; obviously, it's because Azure is complete clown shoes and the excellent people that AWS would never make these sorts of mistakes. Except we now have evidence that they absolutely did and didn't talk about it publicly. And I've got a level with you. I feel more than a little bit foolish, betrayed, naive for all this. What's your take on it?Aidan: Yeah, so just to clarify, it wasn't actually in your account. It was the new AWS custom resource execution model was you would upload a Lambda function that would run in an Amazon-managed account. And so that immediately set off my spidey sense because executing code in someone else's account seems fraught with peril. And so—Corey: Yeah, you can do all kinds of horrifying things there, like, use it to run containers.Aidan: Yeah. [laugh]. Thankfully, I didn't do anything that egregious. I stayed inside the Lambda function, but I look—I poked around at what credentials have had, and it would use CloudWatch to reinvoke itself and CloudWatch kept recording CloudTrail. And I won't go into all the details, but it ended up being that you could see credentials being recorded in CloudTrail in that account, and I could, sort of, funnel them out of there.When I found this, I was a little scared, and I don't think I'd reported an issue to AWS before, so I didn't want to go too far and do anything that could be considered malicious. So, I didn't actively seek out other people's credentials.Corey: Yeah, as a general rule, it's best once you discover things like that to do the right thing and report it, not proceed to, you know, inadvertently commit felonies.Aidan: Yeah. Especially because it was my first time. I felt better safe than sorry. So, I didn't see other credentials, but I had no reason to believe that, I wouldn't see it if I kept looking. I reported it to Amazon. Their security team was incredibly professional, made me feel very comfortable reporting it, and let me know when, you know, they'd remediated it, which was a matter of days later.But afterwards, it left me feeling a little surprised because I was able to publish about it, and a few people responded, you know, the sorts of people who pay close attention to the industry, but Amazon didn't publish anything as far as I was aware. And it changed the way I felt about AWS security, because like you, I sort of felt that AWS, more or less had a pretty perfect track record. They would have advisories about possible [Zen 00:12:04] exploits, and so on. But they'd never published anything about potential for compromise. And it makes me wonder how many of the things might have been reported in the past where either the third-party researcher either didn't end up publishing, or they published and it just disappeared into the blogosphere, and I hadn't seen it.Corey: They have a big earn trust principle over there, and I think that they always focus on the trust portion of it, but I think what got overlooked is the earn. When people are giving you trust that you haven't earned, on some level, the right thing to do is to call it out and be transparent around these things. Yes, I know, Wall Street's going to be annoyed and headlines, et cetera, et cetera, but I had always had the impression that had there been a cross-account vulnerability or a breach of some sort, they would communicate this and they would have their executives go on a speaking tour about it to explain how defense-in-depth mitigated some of it, and/or lessons learned, and/or what else we can learn. But it turns out that wasn't was happening at all. And I feel like they have been given trust that was unearned and now I am not happy with it.I suddenly have a lot more of a, I guess, skeptical position toward them as a result, and I have very little tolerance left for what has previously been a staple of the AWS security discussions, which is an executive getting on stage for a while and droning on about the shared responsibility model with the very strong implication that “Oh, yeah, we're fine. It's all on your side of the fence that things are going to break.” Yeah, turns out, that's not so true. Just you know, about the things on your side of the fence in a way that you don't about the things that are on theirs.Aidan: Yeah, it's an interesting one. Like, I think about it and I think, “Well, they never made an explicit promise that they would publish these things,” so, on one hand, I say to myself, “Oh, maybe that's on me for making that assumption.” But, I don't know, I feel like the way we felt was justified. Maybe naive in hindsight, but then, you know, I guess… I'm still not sure how to feel because of, like, I think about recent issues and how a couple of AWS Distinguished Engineers jumped on Twitter, and to their credit were extremely proactive in engaging with the community.But is that enough? It might be enough for say, to set my mind at ease or your mind at ease because we are, [laugh] to put it mildly, highly engaged, perhaps a little too engaged in the AWS space, but Twitter's very ephemeral. Very few of AWS's customers—Corey: Yeah, I can't link to tweets by distinguished engineers to present to an executive leadership team as an official statement from Amazon. I just can't.Aidan: Yeah. Yeah.Corey: And so the lesson we can take from this is okay, so “Well, we never actually said this.” “So, let me get this straight. You're content to basically let people assume whatever they want until they ask you an explicit question around these things. Really? Is that the lesson you want me to take from this? Because I have a whole bunch of very explicit questions that I will be asking you going forward, if that is in fact, your position. And you are not going to like the fact that I'm asking these questions.”Even if the answer is a hard no, people who did not have this context are going to wonder why are people asking those questions? It's a massive footgun here for them if that is the position that they intend to have. I want to be clear as well; this is also a messaging problem. It is not in any way, a condemnation of their excellent folks working on the security implementation themselves. This stuff is hard and those people are all-stars. I want to be very clear on this. It is purely around the messaging and positioning of the security posture.Aidan: Yeah, yeah. That's a good clarification because like you, my understanding that the service teams are doing a really stellar, above-average job, industry-wide, and the AWS Security Response Teams, I have absolute faith in them. It is a matter of messaging. And I guess what particularly brings it to front-of-mind is, it was earlier this month, or maybe it was last month, I received an email from a company called Sourcegraph. They do code search.I'm not even a customer of theirs yet, you know? I'm on a free trial, and I got an email that—I'm paraphrasing here—was something to the effect of, we discovered that it was possible for your code to appear in other customers' code search results. It was discovered by one of our own engineers. We found that the circumstances hadn't cropped up, but we wanted to tell you that it was possible. It didn't happen, and we're working on making sure it won't happen again.And I think about how radically different that is where they didn't have a third-party researcher forcing their hand; they could have very easily swept under the rug, but they were so proactive that, honestly, that's probably what's going to tipped me over to the edge into me becoming a customer. I mean, other than them having a great product. But yeah, it's a big contrast. It's how I like to see other companies work, especially Amazon.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: The two companies that I can think of that have had security problems have been CircleCI and Travis CI. Circle had an incredibly transparent early-on blog post, they engaged with customers on the forums, and they did super well. Travis basically denied, stonewalled for ages, and now the only people who use Travis are there because they haven't found a good way to get off of it yet. It is effectively DOA. And I don't think those two things are unrelated.Aidan: Yeah. No, that's a great point. Because you know, I've been in this industry long enough. You have to know that humans write code and humans make mistakes—I know I've made more than my fair share—and I'm not going to write off the company for making a mistake. It's entirely in their response. And yeah, you're right. That's why Circle is still a trustworthy business that should earn people's business and why Travis—why I recommend everyone move away from.Corey: Yeah, I like Orca Security as a company and as a product, but at the moment, I am not their customer. I am AWS's customer. So, why the hell am I hearing it from Orca and not AWS when this happens?Aidan: Yeah, yeah. It's… not great. On one hand, I'm glad I'm not in charge of finding a solution to this because I don't have the skills or the expertise to manage that communication. Because like I think you said in the past, there's a lot of different audiences that they have to communicate with. They have to communicate with the stock market, they have to communicate with execs, they have to communicate with developers, and each of those audiences demands a different level of detail, a different focus. And it's tricky. And how do you manage that? But, I don't know, I feel like you have an obligation to when people place that level of trust in you.Corey: It's just a matter of doing right by your customers, on some level.Aidan: Yeah.Corey: How long have you been working on an AWS-side environments? Clearly, this is not like, “Well, it's year two,” because if so I'm going to feel remarkably behind.Aidan: [laugh]. So, I've been writing code in some capacity or another for 20 years. It took about five years to get anyone to pay me to do so. But yeah, I guess the start of my professional career—and by ‘professional,' I want to use it in strictest term, means getting paid for money; not that I [laugh] am necessarily a professional—coincided with the launch of AWS. So, I don't hadn't experienced with the before times of data centers, never had to think about direct connect, but it means I have been using AWS since sometime in 2008.I was just looking at my bill earlier, I saw that my first bill was for $70. It was—I was using a C1xLarge, which was 80 cents an hour, and it had eight-core CPUs. And to put that in context at the time—Corey: Eight vCPUs, technically I believe.Aidan: An it basically is—Corey: —or were they using [eCPU 00:20:31] model back then?Aidan: Yeah, no, that was vCPUs. But to me, that was extraordinary. You know, I was somewhere just after high school. It was—the Netflix Prize was around. If you're not sure what that was, it was Netflix had this open competition where they said anyone who could improve upon their movie recommendation algorithm could win a million dollars.And obviously being a teenager, I had a massive ego and [laugh] no self-doubt, so I thought I could win this, but I just don't have enough CPUs or RAM on my laptop. And so when EC2 launched, and I could pay 80 cents an hour, rather than signing up for a 12-month contract with a colocation company, it was just a dream come true. I was able to run my terrible algorithms, but I could run them eight times faster. Unfortunately and obviously, I didn't win because it turns out, I'm not a world-class statistician. But—Corey: Common mistake. I make that mistake myself all the time.Aidan: [laugh]. Yeah. I mean, you know, I think I was probably 19 at the time, so I had—my ego did make me think I was one, but it turned out not to be so. But I think that was what really blew my mind was that me, a nobody, could create an account with Amazon and get access to these incredibly powerful machines for less than the dollar. And so I was hooked.Since then, I've worked at companies that are AWS customers since then. I've worked at places that have zero EC2 service, worked at places that have had thousands, and places in between. And it's got to a point, actually, where, I guess, my career is so entwined with AWS that one, my initials are actually AWS, but also—and this might sound ridiculous, and it's probably just a sign of my privilege—that I wouldn't consider working somewhere that used another cloud. Not—Corey: No, I think that's absolutely the right approach.Aidan: Yeah.Corey: I had a Twitter thread on this somewhat recently, and I'm going to turn it into a blog post because I got some pushback. If I were looking at doing something and I would come into the industry right now, my first choice would be Google Cloud because its developer experience is excellent. But I'm not coming to this without any experience. I have spent a decade or so learning not just how it was works, but also how it breaks, understanding the failure mode and what that's going to look like and what it's good at and what it's not. That's the valuable stuff for running things in a serious way.Aidan: Yeah. It's an interesting one. And I mean, for better or worse, AWS is big. I'm sure you will know much better than I do the exact numbers, but if a junior developer came to me and said, “Which cloud should I learn, or should I learn all of them?” I mean, you're right, Google Cloud does have a better developer experience, especially for new developers, but when I think about the sheer number of jobs that are available for developers, I feel like I would be doing them a disservice by not suggesting AWS, at least in Australia. It seems they've got such a huge footprint that you'll always be able to find a job working as an AWS-familiar engineer. It seems like that would be less the case with Google Cloud or Azure.Corey: Again, I am not sitting here, suggesting that anyone should, “Oh, clouds are insecure. We're going to run our own stuff in our own data centers.” That is ridiculous in this era. They are still going to do a better job of security than any of us will individually, let's be clear here. And it empowers and unlocks an awful lot of stuff.But with their privileged position as these hyperscale providers that are the default choice for building things, I think comes with a significant level of responsibility that I am displeased to discover that they've been abdicating. And I don't love that.Aidan: Yeah, it's an interesting one, right, because, like you're saying, they have access and the expertise that people doing it themselves will never match. So, you know, I'm never going to hesitate to recommend people use AWS on account security because your company's security posture will almost always be better for using AWS and following their guidelines, and so on. But yeah, like you say, with great power comes significant responsibility to earn trust and retain that trust by admitting and publicizing when mistakes are made.Corey: One last topic I want to get into with you is one that you and I have talked about very briefly elsewhere, that I feel like you and I are both relatively up-to-date on AWS intricacies. I think that we are both better than the average bear working with the platform. But I know that I feel this way, and I suspect you do too that VPCs have gotten confusing as hell. Is that just me? Am I a secret moron that no one bothered to ever tell me this, and I should update my own self-awareness?Aidan: [laugh]. Yeah, it's… I mean, that's been the story of my career with AWS. When I started, VPCs didn't exist. It was EC2 Classic—well, I guess at the time, it was just EC2—and it was simple. You launched an instance and you had an IP address.And then along came VPCs, and I think at the time, I thought something to the effect of “This seems like needless complexity. I'm not going to bother learning this. It will never be relevant.” In the end that wasn't true. I worked in much large deployments when VPCs made fantastic sense made a lot of things possible, but I still didn't go into the weeds.Since then, AWS has announced that EC2 Classic will be retired; an end of an era. I'm not personally still running anything in EC2 Classic, and I think they've done an incredible job of maintain support for this long, but VPC complexity has certainly been growing year-on-year since then. I recently was using the AWS console—like we all do and no one ever admits to—to edit a VPC subnet route table. And I clicked the drop-down box for a target, and I was overwhelmed by the number of options. There were NAT gateways, internet gateways, carrier gateways, I think there was a thing called a wavelength gateway, ENI, and… I [laugh] I think I was surprised because I just scroll through the list, and I thought, “Wow, that is a lot of different options. Why is that?”Especially because it's not so relevant to me. But I realized a big thing of what AWS has been doing lately is trying to make themselves available to people who haven't used the cloud yet. And they have these complicated networking needs, and it seems like they're trying to—reasonably successfully—make anything possible. But with that comes, you know, additional complexity.Corey: I appreciate that the capacity is there, but there has to be an abstraction model for getting rid of some of this complexity because otherwise, the failure mode is you wind up with this amazingly capable thing that can build marvels, but you also need to basically have a PhD in some of these things to wind up tying it all together. And if you bring someone else in to do it, then you have no idea how to run the thing. You're effectively a golden retriever trying to fly a space shuttle.Aidan: Yeah. It's interesting, like, clearly, they must be acutely aware of this because they have default VPCs, and for many use cases, that's all people should need. But as soon as you want, say a private subnet, then you need to either modify that default VPC or create a new one, and it's sort of going from 0 to 100 complexity extremely quickly because, you know, you need to create route tables to everyone's favorite net gateways, and it feels like the on-ramp needs to be not so steep. Not sure what the solution is, I hope they find one.Corey: As do I. I really want to thank you for taking the time to speak with me about so many of these things. If people want to learn more about what you're up to, where's the best place to find you?Aidan: Twitter's the best place. On Twitter, my username is @__Steele, which is S-T-E-E-L-E. From there, that's where I'll either—I'll at least speculate on the latest releases or link to some of the silly things I put on GitHub. Sometimes they're not so silly things. But yeah, that's where I can be found. And I'd love to chat to anyone about AWS. It's something I can geek out about all day, every day.Corey: And we will certainly include links to that in the [show notes 00:29:50]. Thank you so much for taking the time to speak with me today. I really appreciate it.Aidan: Well, thank you so much for having me. It's been an absolute delight.Corey: Aidan Steele, serverless engineer at Stedi, and shit poster extraordinaire. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an immediate request to correct the record about what I'm not fully understanding about AWS's piss-weak security communications.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Kommentare und Themenvorschläge gerne an @opensourcecouch bei allen sozialen Netzwerken. Jubiläen 50 Jahre Diskette https://www.heise.de/news/Donnerstag-50-Jahre-Diskette-WD-vor-Milliardenfusion-illegales-Bitcoin-Mining-6174643.html https://www.heise.de/hintergrund/Zahlen-bitte-3-75-Megabyte-Speicher-auf-der-ersten-Festplatte-der-Welt-6188203.html Der ewige Optimist https://www.golem.de/news/zum-tod-von-sir-clive-sinclair-der-ewige-optimist-2109-145862.html Themen Nightscout - Open Source Diabetes Monitoring http://www.nightscout.info/ Getting GPL compliance from a Chinese company - in person https://www.youtube.com/watch?v=Vj04MKykmnQ https://www.reddit.com/r/linux/comments/p8gnno/getting_gplv2_compliance_from_a_chinese_company/ Münster: Prozess um Betrug mit Kryptowährung https://www1.wdr.de/nachrichten/westfalen-lippe/prozess-kryptowaehrung-onecoin-104.html Leverage Article 17 to build a public repository of Public Domain and openly licensed works https://www.communia-association.org/2021/09/21/a-proposal-to-leverage-article-17-to-build-a-public-repository-of-public-domain-and-openly-licensed-works/ OMIGOD: Microsoft lässt Azure-Admins mit Linux-Lücke allein https://www.heise.de/news/OMIGOD-Microsoft-laesst-Azure-Admins-mit-Linux-Luecke-allein-6194618.html Travis-CI könnte Secrets Tausender Projekte geleakt haben https://www.golem.de/news/security-travis-ci-koennte-secrets-tausender-projekte-geleakt-haben-2109-159610.html Mehr NFT-Unfug: Smiley wird versteigert https://www.heise.de/news/Bitte-laecheln-Das-erste-Smiley-wird-versteigert-6189717.html --- Send in a voice message: https://anchor.fm/opensourcecouch/message
Links: WTF? Microsoft makes fixing deadly OMIGOD flaws on Azure your job: https://www.theregister.com/2021/09/17/microsoft_manual_omigod_fixes/ Travis CI flaw exposed secrets of thousands of open source projects: https://arstechnica.com/information-technology/2021/09/travis-ci-flaw-exposed-secrets-for-thousands-of-open-source-projects/ How to Build Strong Security Guardrails in the AWS Cloud With Minimal Effort: https://markn.ca/2021/how-to-build-strong-security-guardrails-in-the-aws-cloud-with-minimal-effort/ Introduction to OWASP Top 10 2021: https://owasp.org/Top10/ AWS SIGv4 and SIGv4A: https://shufflesharding.com/posts/aws-sigv4-and-sigv4a Inside Figma: getting out of the (secure) shell: https://www.figma.com/blog/inside-figma-getting-out-of-the-secure-shell/ AWS Firewall Manager now supports AWS WAF rate-based rules: https://aws.amazon.com/about-aws/whats-new/2021/09/aws-firewall-manager-waf-rate-based-rules/ How to automate incident response to security events with AWS Systems Manager Incident Manager: https://aws.amazon.com/blogs/security/how-to-automate-incident-response-to-security-events-with-aws-systems-manager-incident-manager/ New Standard Contractual Clauses now part of the AWS GDPR Data Processing Addendum for customers: https://aws.amazon.com/blogs/security/new-standard-contractual-clauses-now-part-of-the-aws-gdpr-data-processing-addendum-for-customers/ Protect your remote workforce by using a managed DNS firewall and network firewall: https://aws.amazon.com/blogs/security/protect-your-remote-workforce-by-using-a-managed-dns-firewall-and-network-firewall/ AWS Security Hub Automated Response and Remediation: https://github.com/awslabs/aws-security-hub-automated-response-and-remediation Checkov: https://github.com/bridgecrewio/checkov TranscriptCorey: This is the AWS Morning Brief: Security Edition. AWS is fond of saying security is job zero. That means it's nobody in particular's job, which means it falls to the rest of us. Just the news you need to know, none of the fluff.Corey: This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain, so bear with me. I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything else like that that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example, and the only thing that these things do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out. But wait, there's more because they also have an enterprise option that you should be very much aware of: canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead you're likely to find out that you've gotten breached the very hard way. So, check it out. It's one of those few things that I look at and say, “Wow, that is an amazing idea. I am so glad I found them. I love it.” Again, those URLs are canarytokens.org and canary.tools. And the first one is free because of course it is. The second one is enterprise-y. You'll know which one of those you fall into. Take a look. I'm a big fan. More to come from Thinkst Canary weeks ahead.Corey: Oh, for th—this is the third episode of the Last Week in AWS slash AMB: Security Edition, and instead of buying a sponsorship like a reasonable company, Microsoft Azure is once again forcing me to talk about their cloud instead, via completely blowing it when it comes to security. Again. Not only did they silently install an agent onto virtual machines in Azure that add a handful of trivially exploitable vulnerabilities, it's also apparently your job to fix it for them. I have to confess, I take Azure a lot less seriously than I did a month ago.Now, let's dive in here. Speaking of terrible things, it's honestly difficult for me to imagine a company screwing the pooch harder than TravisCI did this month. They had a bug that started leaking private credentials into public build logs; this is bad. They fixed it; this is good. And then only begrudgingly disclosed it in a buried release with remarkably little public messaging; this is unfathomable. At this point, if you're using TravisCI, get the hell off of it. Mistakes happen to every vendor. The ones that try to hide their mistakes are absolutely not companies you can trust.If you put up a slide deck and accompanying notes entitled How to Build Strong Security Guardrails in the AWS Cloud With Minimal Effort, I'm probably going to take a look at it because strong guardrails are important and minimal effort is critical if you expect it to actually get done. If you're also my longtime friend Mark Nunnikhoven, then I'm going to default to treating it as gospel because Mark frankly does not miss when it comes to AWS concepts explained in an easily approachable way. Security has got to be aligned with the way engineers work within your environment. Remember, it's not that hard to spin up a new AWS account on someone's corporate credit card; you absolutely do not want to incentivize that behavior.Corey: I periodically say the OWASP Top 10, which is a list of the most critical security risks for applications on the web, has not meaningfully changed in ten years. Well, apparently it just did. It's worth reviewing the changes; broken configurations top the list. The Open Web Application Security Project—OWASP—is a foundation that's remained surprisingly free of capture by security vendors. It's a good starting point to frame your risk exposure and what to think about.AWS VP and Distinguished Engineer Colm MacCárthaigh has an article on AWS's new signing protocol, along with the differences between AWS SIGv4 and SIGv4A. As a quick primer, all requests to AWS are signed for authentication reasons. The new SIGv4A isn't region-locked—and the recent release of the S3 Multi-Region Access Points is why it makes it a bit of a problem—there's no key exchange, and it's more computationally expensive. You don't really need to know the details as a practitioner, but you should be aware that AWS very much does put stupendous thought into this, and they sweat the details something fierce. This is why we trust cloud providers like AWS, and Google Cloud, and absolutely not Azure.Figma has a great post up, talking about how they stopped using SSH via bastion host and started using Systems Manager Session Manager instead. Bad name, wonderful service. More to the point, what I like about this post isn't just the, “Here's how the technology works,” parts, but also dives into the nuts and bolts of how they handled the migration without stopping work for folks. Communicating changes like this is tricky; don't lose sight of that.Now, from the mouth of AWS horse itself, let's dive in. AWS Firewall Manager now supports AWS WAF rate-based rules. This is pretty awesome if for no other reason than it's aware both of multiple regions as well as multiple accounts.An awful lot of security services that are both first and third-party alike tend to go for addressing only one of those at best. Anything that lets you manage things centrally in a holistic way when it comes to security is generally going to be a win, but you also don't want a giant single point of failure. It's a bit of a balancing act, but that's why our field needs us. It's why they pay us.How to automate incident response to security events with AWS Systems Manager Incident Manager. And I'm genuinely torn on this. I like automation, but it strikes me as a way to end up automating the responses to fairly common things rather than addressing the actual cause so you get fewer false alarms. You really don't want the security pager going off frequently, if for no other reason than you'll be training the people carrying it to ignore it.Announcer: Have you implemented industry best practices for securely accessing SSH servers, databases, or Kubernetes? It takes time and expertise to set up. Teleport makes it easy. It is an identity-aware access proxy that brings automatically expiring credentials for everything you need, including role-based access controls, access requests, and the audit log. It helps prevent data exfiltration and helps implement PCI and FedRAMP compliance. And best of all, Teleport is open-source and a pleasure to use. Download Teleport at goteleport.com. That's goteleport.com.Corey: AWS is harping about its New Standard Contractual Clauses now part of the AWS GDPR Data Processing Addendum for customers, blah, blah, blah—look, if you have compliance obligations, here's what you do. Check the documents in AWS Artifact, reach out to your account manager for additional resources, and whatever you do, do not attempt to YOLO it yourself from first principles. AWS has piles and piles of documents ready and waiting to satisfy regulators and auditors alike. I tried to do it myself once, and a financial institution attempted to set up a tour of us-east-one. Trust me when I say you don't want to go down that path.Protect your remote workforce by using a managed DNS firewall and network firewall. Look, the post can safely be discarded; it's chock full of complexity lurking deep in the weeds, but I bring it up instead so that you think for a moment about the threat model of a remote workforce, read as most of them these days. Does having a DNS firewall protect against threats that they're likely to encounter? Does a network firewall make sense in a zero-trust world? Consider those things in the context of your environment rather than in the context of a company that has things it needs to sell you. Good decisions are rarely sourced from vendors.A couple of tools as well. Automating response and remediation is one of those delicate balances. The unimaginatively named AWS Security Hub Automated Response and Remediation GitHub repo has ways to handle this but it's going to be super easy to automate away things that really shouldn't be automated. You are definitely going to want to think through edge and corner cases.And lastly, I tripped over checkov last week. It analyzes your Terraform slash CloudFormation slash whatever configurations for various misconfigurations. It caught a couple of things that I've been ignoring for a while, and while it missed another couple of problems in my environment, it's definitely going to be something I integrate into my deployment pipelines in the future, once I have deployment pipelines. That's checkov—C-H-E-C-K-O-V—open-source projects. Take a look. I'm a fan.And that's what happened to the world of AWS security last week. Enjoy not having to care about the rest of it.Corey: I have been your host, Corey Quinn, and if you remember nothing else, it's that when you don't get what you want, you get experience instead. Let my experience guide you with the things you need to know in the AWS security world, so you can get back to doing your actual job. Thank you for listening to the AWS Morning Brief: Security Editionwith the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcasts, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.
This week in the AppSec News, Mike and John talk: RCE in Azure OMI, punching a hole in iMessage BlastDoor, Travis CI exposes sensitive environment variables, keeping code ownership accurate, deploying security as a product, IoT Device Criteria (aka nutrition labels), & more! Show Notes: https://securityweekly.com/asw166 Visit https://www.securityweekly.com/asw for all the latest episodes!
This week in the AppSec News, Mike and John talk: RCE in Azure OMI, punching a hole in iMessage BlastDoor, Travis CI exposes sensitive environment variables, keeping code ownership accurate, deploying security as a product, IoT Device Criteria (aka nutrition labels), & more! Show Notes: https://securityweekly.com/asw166 Visit https://www.securityweekly.com/aswfor all the latest episodes!
This week, we welcome Jeff Williams, Co-Founder and Chief Technology Officer at Contrast Security, to discuss Transforming Modern Software Development with Developer-first Application Security! Modern software development demands a different approach to application security. Contrast's developer-first Application Security Platform empowers developers to accelerate the release of secure code with highly accurate results that include context-aware, how-to-fix vulnerability remediation guidance. In the AppSec News, Mike and John talk: RCE in Azure OMI, punching a hole in iMessage BlastDoor, Travis CI exposes sensitive environment variables, keeping code ownership accurate, deploying security as a product, IoT Device Criteria (aka nutrition labels), & more! Show Notes: https://securityweekly.com/asw166 Segment Resources: 2021 Application Security Observability Report: https://view-su2.highspot.com/viewer/612ff3a8c6485f4687834782 White Paper: Pipeline-native Scanning for Modern Application Development https://view-su2.highspot.com/viewer/612ff3e4cc0bb2392d968b25 DevSecOps Requires a Platform Approach to Application Security https://view-su2.highspot.com/viewer/612ff42ecb2d1b6cd60f3f65 Visit https://securityweekly.com/contrast to learn more about them! Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly
This week, we welcome Jeff Williams, Co-Founder and Chief Technology Officer at Contrast Security, to discuss Transforming Modern Software Development with Developer-first Application Security! Modern software development demands a different approach to application security. Contrast's developer-first Application Security Platform empowers developers to accelerate the release of secure code with highly accurate results that include context-aware, how-to-fix vulnerability remediation guidance. In the AppSec News, Mike and John talk: RCE in Azure OMI, punching a hole in iMessage BlastDoor, Travis CI exposes sensitive environment variables, keeping code ownership accurate, deploying security as a product, IoT Device Criteria (aka nutrition labels), & more! Show Notes: https://securityweekly.com/asw166 Segment Resources: 2021 Application Security Observability Report: https://view-su2.highspot.com/viewer/612ff3a8c6485f4687834782 White Paper: Pipeline-native Scanning for Modern Application Development https://view-su2.highspot.com/viewer/612ff3e4cc0bb2392d968b25 DevSecOps Requires a Platform Approach to Application Security https://view-su2.highspot.com/viewer/612ff42ecb2d1b6cd60f3f65 Visit https://securityweekly.com/contrast to learn more about them! Visit https://www.securityweekly.com/asw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly
In today's podcast we cover four crucial cyber and technology topics, including: 1. Software Travis CI potentially exposed sensitive user data 2. Pakistani sentenced for role in phone unlocking fraud ring 3. Banco De Venezuela dealing with 5th day of outage after cyberattack 4. Biden considering crypto exchanges involved in ransomware payments I'd love feedback, feel free to send your comments and feedback to | cyberandtechwithmike@gmail.com
Josh and Kurt talk about an unusual number of really bad security updates. We even recorded this before the Azure OMIGOD vulnerability was disclosed. It's certainly been a wild week with Apple and Chrome 0days, and a Travis CI secret leak. Maybe this is the new normal. Show Notes Matrix 4 trailer Travis CI issue Apple 0day patches Chrome 0day patches CGP Grey Where is the European Union
This week Emile Vauge, founder & CEO of Traefik, joins Gerhard to share a story that started as a solution to a 2000 microservices challenge, the real-world implications of shipping many times a day for years, and the difficulties of sustaining an inclusive and healthy open-source community while building a product company. Working every day on keeping the open-source community in sync with the core team was an important lesson. The second learning was around big changes between major versions. The journey from Travis CI to Circle CI, then to Semaphore CI and eventually GitHub Actions is an interesting one. The automation tools inspired by the Mymirca ant colony is a fascinating idea, executed well. There is more to discover in the episode.
This week Emile Vauge, founder & CEO of Traefik, joins Gerhard to share a story that started as a solution to a 2000 microservices challenge, the real-world implications of shipping many times a day for years, and the difficulties of sustaining an inclusive and healthy open-source community while building a product company. Working every day on keeping the open-source community in sync with the core team was an important lesson. The second learning was around big changes between major versions. The journey from Travis CI to Circle CI, then to Semaphore CI and eventually GitHub Actions is an interesting one. The automation tools inspired by the Mymirca ant colony is a fascinating idea, executed well. There is more to discover in the episode.
Travis CI security vulnerability is bad news for open source Ransomware accounts for a quarter of cyber insurance claims Microsoft goes passwordless Thanks to our episode sponsor, Sonrai Sonrai is changing Public Cloud Security by focusing on protecting data from over-privileged human and non-human identities. Sonrai provides a single pane of glass built on an analytic platform that protects organizations by leveraging CSPM, CIEM, and cloud DLP at the confidence level required by your environment. Learn more about Sonrai Cloud Security at www.sonrai.com
My guest today is Leo Farias. Leo is the creator of the wildly popular FVM open-source tool. He is the CEO and co-founder of Concepta Inc and CTO and co-founder of FanHero.FVM stands for Flutter Version Management. FVM is a simple CLI tool to manage different versions of the Flutter SDK: "FVM helps with the need for consistent app builds by allowing to reference Flutter SDK version used on a per-project basis. It also allows you to have multiple Flutter versions installed to quickly validate and test upcoming Flutter releases with your apps, without waiting for Flutter installation every time."In my opinion, FVM is an essential tool for every Flutter developer. It facilitates switching Flutter versions quickly, as well as pinning the Flutter version that should be used for a project which is especially helpful when working on teams. We talked about what motivated Leo to build FVM, FVM's functionalities, and the differences between the various installation options for FVM.Leo also worked on Sidekick, a beautiful desktop app (of course written in Flutter) for managing Flutter versions (you can think of it as a graphical user interface over FVM's core functionalities), explore releases, view popular packages, and more. Sidekick is available on Mac, Windows, and Linux.At the end of the podcast, we talked about what is next for Leo and what else is he working on.Guest: Leo FariasTwitter @leoafariasGitHub @leoafariasLinkedIn @leofariasFanHero: A white label, all-in-one live streaming and OTT solutionConcepta: Orlando Mobile App and Web Development Companyfvm.app: Flutter Version ManagementHost: Vince VargaTwitter @vincevargadevGitHub @vincevargadevLinkedIn @vincevargadevWeb vincevarga.devMost relevant past episodes from Flutter 101Dart in the Cloud, Backend, Command Line, and Shelf with Kevin Moore (Episode 14): Kevin Moore is a Product Manager at Google working on Dart and Flutter. Dart in the cloud, on the backend, and on the command line. Functions Framework for Dart, Google Cloud Run, Docker and Dart, Shelf, and many many other useful packages.Dart on AWS Lambda and Serverless Computing with Sebastian Döll (Episode 6): We talked to Sebastian Döll (GitHub Microsoft, previously Solutions Architect at AWS) about serverless computing, the state of serverless Dart, and how he implemented a custom AWS Lambda Runtime for Dart.Mentioned packagespub.dev/packages/fvm: A simple CLI to manage Flutter SDK versions per project. Support channels, releases, and local cache for fast switching between versions.pub.dev/packages/cli_pkg: A set of Grinder tasks that make it easy to release a Dart command-line application on many different release channels, to Dart users and non-Dart users alike. It also integrates with Travis CI to make it easy to automatically deploy packages.pub.dev/packages/pub_api_client: An API Client for pub.dev to interact with public package information.pub.dev/packages/mix: An expressive way to effortlessly build design systems in Flutter. Mix offers primitive building blocks to help developers and designers create beautiful and consistent UI.Other resourcesGitHub OCTO | Flat DataDart Sass: Dart Sass is the primary implementation of Sass, which means it gets new features before any other implementation.github.com/leoafarias/sidekick: Sidekick is an app that provides a simple desktop interface to tools that enhance Flutter development experience to make it even more delightful.github.com/leoafarias/flutter_flat_data: Flutter & Dart Unofficial Flat Data APIgithub.com/leoafarias/homebrew-fvm: Homebrew formula for fvm
On our first episode of Whiskey Web and Whatnot we have Sagamore Spirits Rye as our whiskey, discuss Travis CI's latest problems and how GitHub Actions has filled the space, as well as talk about Nintendo / PC games we've been interested in recently.
Sponsored by Linode! pythonbytes.fm/linode Special guest: Ogi Moore Watch the live stream on YouTube. Michael #1: diskcache via Ian Maurer Python disk-backed cache (Django-compatible). Faster than Redis and Memcached. Pure-Python. The cloud-based computing of 2020 puts a premium on memory. Gigabytes of empty space is left on disks as processes vie for memory. Among these processes is Memcached (and sometimes Redis) which is used as a cache. Wouldn't it be nice to leverage empty disk space for caching? Features: Pure-Python Fully Documented Benchmark comparisons (alternatives, Django cache backends) 100% test coverage Hours of stress testing Performance matters Django compatible API Thread-safe and process-safe Supports multiple eviction policies (LRU and LFU included) Keys support "tag" metadata and eviction Developed on Python 3.8 Tested on CPython 3.5, 3.6, 3.7, 3.8 Tested on Linux, Mac OS X, and Windows Tested using Travis CI and AppVeyor CI Brian #2: TOML is 1.0.0 now. What does that mean for Python? Hopefully, some kind of toml parser will make it into Python core. Any Python access to 1.0.0? Mixed Implementations and TOML version support page lists: pytomlpp supports 1.0.0-rc.3, which is a wrapper around C++ tomlplusplus, which does support 1.0.0. Confusing tomlkit supports 1.0.0-rc.1, so that’s promising toml supports 0.5.0, great name. It’d be cool if it would support 1.0.0 What’s different between 0.5.0 and 1.0.0? Unless I’m mistaken, not much: CHANGELOG 1.0.0-rc1 Leading zeroes in exponent parts of floats are permitted. Allow raw tab characters in basic strings and multi-line basic strings. Allow heterogenous values in arrays. Other than that, lots of “Clarify …”, which I’m not sure how those all affect implementation. I’d love to hear more from people who know more about this Ogi #3: pyqtgraph pyqtgraph - plotting library, for when you need fast/interactive plots Uses qt5 (and soon qt6) bindings to generate plots within Qt applications Fills a niche role, want easy mouse interactivity, running locally on a machine Often used in engineering/scientific applications when looking at a lot of data, and wanting interactivity Michael #4: Parler + Python = Insurrection in public via Jim Kring and Mark Little According to Wikipedia: Parler (/ˈpɑːrlər/) is an American alt-tech microblogging and social networking service. Parler has a significant user base of Donald Trump supporters, conservatives, conspiracy theorists, and right-wing extremists. ArsTechnica article send in by Mark Little Ars: Parler’s amateur coding could come back to haunt Capitol Hill rioters Coding mess A key reason for her success: Parler’s site was a mess. Its public API used no authentication. When users deleted their posts, the site failed to remove the content and instead only added a delete flag to it. Oh, and each post carried a numerical ID that was incremented from the ID of the most recently published one. Another amateur mistake was Parler’s failure to scrub geolocations from images and videos posted online. Some 80 terabytes of posts, 1M videos, many already deleted, preserved for posterity. Catalog and Python pointed out by Shaun King. See the catalog (maybe, it’s the ugly side of people). The gist: https://gist.github.com/kylemcdonald/d8884da1a82ef50754ee49e0b6561071 Partially back online with Russian hosting service? Brian #5: Best-of Web Development with Python Suggested by Douglas Nichols Cool list with nice icons Covers Frameworks, HTTP Clients, Servers Auth tools, HTML Processing, URL utilities OpenAPI, GraphQL, Websocket RPC, Serverless, Content Management Web Testing, Web Forms, Markdown Third-party APIs Email, Web Scraping & Crawling, Monitoring Admin UI API Proxies Flask/FastAPI/Pyramid/Django Utilities Nice to see lots of FastAPI projects: fastapi-sqlalchemy - Adds simple SQLAlchemy support to FastAPI. fastapi-plugins - FastAPI framework plugins. fastapi_contrib - Opinionated set of utilities on top of FastAPI. starlette_exporter - Prometheus exporter for Starlette and FastAPI. fastapi-utils - Reusable utilities for FastAPI. fastapi-code-generator - This code generator creates FastAPI app from an.. slowapi - A rate limiter for Starlette and FastAPI. fastapi-versioning - api versioning for fastapi web applications. fastapi-react - Cookiecutter Template for FastAPI + React Projects. Using.. fastapi_cache - FastAPI simple cache. Ogi #6: Assorted Pyjion - https://github.com/tonybaloney/Pyjion a JIT extension for CPython that compiles python code using .NET 5 CLR CuPy - NumPy compatible multi-dimensional array on CUDA, uses _``*array_function_* (enabled with numpy 1.17) code using numpy to operate directly on CuPy arrays see NEP-18 and CuPy docs compatible with other libraries as well Extras: Michael: Trying Firefox + Brave + VPN Python Web Conf 2021 call for talks, due Jan 29, I’ll be speaking! PyCon US 2021 launched call for proposals: December 22, 2020 — Call for proposals opened February 12, 2021 — Proposals are due March 16, 2021 — Notifications will be sent to presenters March 23, 2021 — Deadline for speakers to confirm participation March 30, 2021 — Schedule is publicly released April 28, 2021 — Deadline to submit pre-recorded presentation (tutorials will be live) May 12-13, 2021 — Tutorial days May 15-16, 2021 — Conference days Apple launching Racial Equity and Justice Initiatives with partners across a broad range of industries and backgrounds — from students to teachers, developers to entrepreneurs, and community organizers to justice advocates Brian: PyCascades 2021 schedule https://2021.pycascades.com/program/schedule/ Ogi: Anthony Explains Video Series Learn X in Y minutes Reading Working in Public by Nadia Eghbal - provides some sanity checks for existing maintainers, might be a fantastic perspective for new contributors to open source Joke Tech Support, 2x Working at the help desk? Get the theme song: Here to help song And help by chat: "Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights." - Byrne Hobart
With the increasing attack surface of web applications, it's become even more important to identify and understand the most common attack surfaces and how easily problems in your own web application can develop. Growing complexity and the dependence on unknown libraries, assets and larger development teams means the attack surface has never been larger. But following smarter development practises like Devsecops and maintaining better cybersecurity culture and frequent scanning makes it possible to keep your web applications secure. Popular problems with your attack surface Some of the most popular attack surface problems are often the most overlooked, yet easily seen. And while some are inherited by your web application (like complexity and unknown assets), some are created by misconfiguring services and not following cybersecurity practises. Let's look at some of the most common problems you might find with your attack surface. Complexity With modern applications getting more complex because of the way they're developed and deployed, the attack surface has gotten larger on all fronts. For example, most web applications include multiple add-on libraries, which are often developed by third-party developers. This introduces possible vulnerabilities if those libraries aren't scanned, kept secure and up-to-date. Similarly, deploying web applications is done by leveraging modern containerization tools like Docker, LXC or LXD. Using each of these introduces another layer of complexity with the possibility of vulnerabilities present. When developing web applications, CI, CD tools like Jenkins, Travis CI, and others are frequently used, which poses another security threat. If your CI, CD tool has a vulnerability and the attacker is able to insert code into your web application, this weakness could be integrated, processed and deployed all over your infrastructure, all being automated. The above examples demonstrate that when our complexity of development and deployment increases, our attack surface increases dramatically as well. Unknown assets Often, modern web applications leverage third-party party libraries to handle various tasks. For example, web applications often use third-party party libraries to handle invoicing, billing via payment gateways, user authentication, and more. If these libraries contain vulnerabilities and, or are untested before putting them into production, using them runs the risk of growing your attack surface. Stay on the safe side regarding unknown or unfamiliar assets like libraries, plugins and themes, all of which should only be used when fully scanned and determined to be safe. Unknown vulnerabilities Scanning and checking for vulnerabilities is frequently overlooked, yet the most important step when trying to reduce your attack surface. Simply put, it's only when a user scans their web application that they find out vulnerabilities exist. These could be in the web server, in programming language being used to develop the web application, or simply in the web application itself. Therefore, frequent scanning is necessary for reducing your web application's attack surface. Misconfigured services Misconfigured services are a frequent source of entry for attackers. These include running services as a privileged user, often seen on Linux based systems with users running services as "root"—which, when combined with other vulnerabilities in the software running on the system, can lead to a massive increase in your attack surface. For example, if the script which takes user input does not sanitize or filter input from users, running a web server as root which executes commands input from users on the OS level can lead to destructive or dangerous commands being executed anywhere on the operating system (since the web server was running as root). Similarly, configuring your software, services with incorrect memory limits can cause system crashes and DoS-like attacks as ...
Toutes les notes sont disponibles sur https://www.clever-cloud.com/fr/podcast/episode21 Avec par ordre d'apparition : @waxzce @geal @kerupse @judu le nouveau pricing Travis CI https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing NAT splitstreaming https://twitter.com/samykamkar/status/1322671073893126144?s=19 https://samy.pl/slipstream/ À relire : https://www.clever-cloud.com/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/ Le Kernel 5.9 : https://kernelnewbies.org/LinuxChanges Zstd compression for kernel and initramfs https://github.com/systemd/zram-generator Fanotify: notifs accès FS, utile pour antivirus and co https://github.com/Keruspe/facron Le chat FaaS de Clever Cloud à tester http://fcb827f6-0119-403c-be89-904cef646bbd.par0-faas-n0.clvrcld.net/ Amazon bottle rocket https://aws.amazon.com/fr/blogs/opensource/announcing-the-general-availability-of-bottlerocket-an-open-source-linux-distribution-purpose-built-to-run-containers/ Le nouveau raspberry Pi est Cute https://www.raspberrypi.org/blog/raspberry-pi-400-the-70-desktop-pc/ Node.js 15 https://nodejs.medium.com/node-js-v15-0-0-is-here-deb00750f278 Les logos de google https://techcrunch.com/2020/10/06/googles-new-logos-are-bad/ Conf de Sebastien Prunier https://www.youtube.com/watch?v=hROZNfBCoz0 https://twitter.com/desmfr/status/1317012109037895680 La musique de Geal - https://www.youtube.com/watch?v=6BjUclqeC4s
Mathias Meyer is an engineer turned founder, a former CEO at Travis CI and CTO at Reaction Commerce. In this episode, we discuss how a simple process, architectural decision records, created the space for his team to make and document decisions; what it means to debug an organization; how to approach OKRs via an evolutionary approach—from not tracking anything to tracking something; the engineering metrics he ended up tracking and more.
00:29 Scala 3 Macro tutorial 05:45 Scalambda 09:07 What project loom is by Daniel Spiewak 09:08 Project Loom? Better Futures? What’s next for JVM concurrent programming by Adam Warski 14:34 auto publish sbt plugin from Travis CI by Eugene Yokota 16:28 Scala String Interpolation by Pradeep Mishra 16:45 String Interpolation by Josh Suereth 18:28 Dobbie by Rob Norris 19:57 Kaleidoscope by Jon Pretty 21:16 Cats Concurrency basics with Ref and Deferred by Krzysztof Grajek
Ana Rosas nos acompaña para hablar sobre su experiencia convirtiéndose en Engineering Manager. Ana tiene muchos años de experiencia en el área de tecnología, y su currículum incluye empresas como Travis CI y más recientemente Canonical. Enlaces del episodio:A Las Chicas de Verdad Nos Gusta el Pollo Frito (Oda al Pollo)Taylor Lorenz on TwitterAnother 1-liner npm package broke the JS ecosystemERR_INVALID_PACKAGE_TARGET · Issue #13 · then/is-promisemaximum clee on TwitterNVIDIA RTX Voice: Setup GuideHow to use your Nvidia graphics card to improve the quality of your callsLinux Containers - LXD - IntroductionCareers | CanonicalSi te gusta El Podcast DEV, has aprendido algo con nosotros, o simplemente te caemos bien, ¡ahora nos puedes apoyar en Patreon! Al hacerlo, cada semana recibirás un episodio extra de El Podcast DEV, tendrás acceso a una comunidad privada, y nos ayudarás a poder dedicarle más tiempo a la producción del podcast — todos ganamos.
In this episode of React Native Radio Josh Justice interviews Yassir Hartani. Yassir writes a blog about all he learns while programming with React Native. They begin by discussing his article about React Native Navigation. Yassir explains why he prefers React Native Navigation and walks Josh through the article. They move on to share tips for getting into React Native development. Yassir shares the differences between React Native development and developing on the web. He explains the difference in base components, syntax, and naming. For those used to developing on the web he recommends using styled-components. Next, the discuss best practices for upgrading and explain why upgrading in React Native can be painful. They discuss tips for improving user experience including, keyboards, clickable buttons, native feedback, and safe area view. Developer experience tips are next. Yassir recommends building for both iOS and Android, test for both platforms as well. They also recommend testing on a physical device. The panel shares other testing tips and gives error tracking recommendations. Panelists Josh Justice Guest Yassir Hartani Sponsors G2i Infinite Red CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links An Introduction to React-Native-Navigation Styled Components for React Native React Native Upgrade Helper React Native CLI “upgrade” command KeyboardAvoidingView TouchableNativeFeedback React-native-platform-touchable SafeAreaView https://facebook.github.io/react-native/docs/improvingux Sentry Bugsnag Android keystores Fastlane CircleCI App Center CodePush Detox Travis CI https://www.facebook.com/ReactNativeRadio/ https://twitter.com/R_N_Radio Picks Josh Justice: Big Nerd Ranch Guides PouchDB `pouchdb-react-native` Yassir Hartani: Deep Work 4-Hour Workweek
In this episode of React Native Radio Josh Justice interviews Yassir Hartani. Yassir writes a blog about all he learns while programming with React Native. They begin by discussing his article about React Native Navigation. Yassir explains why he prefers React Native Navigation and walks Josh through the article. They move on to share tips for getting into React Native development. Yassir shares the differences between React Native development and developing on the web. He explains the difference in base components, syntax, and naming. For those used to developing on the web he recommends using styled-components. Next, the discuss best practices for upgrading and explain why upgrading in React Native can be painful. They discuss tips for improving user experience including, keyboards, clickable buttons, native feedback, and safe area view. Developer experience tips are next. Yassir recommends building for both iOS and Android, test for both platforms as well. They also recommend testing on a physical device. The panel shares other testing tips and gives error tracking recommendations. Panelists Josh Justice Guest Yassir Hartani Sponsors G2i Infinite Red CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links An Introduction to React-Native-Navigation Styled Components for React Native React Native Upgrade Helper React Native CLI “upgrade” command KeyboardAvoidingView TouchableNativeFeedback React-native-platform-touchable SafeAreaView https://facebook.github.io/react-native/docs/improvingux Sentry Bugsnag Android keystores Fastlane CircleCI App Center CodePush Detox Travis CI https://www.facebook.com/ReactNativeRadio/ https://twitter.com/R_N_Radio Picks Josh Justice: Big Nerd Ranch Guides PouchDB `pouchdb-react-native` Yassir Hartani: Deep Work 4-Hour Workweek
En este episodio hablamos de los generadores de sitios web estáticos que ya son una solución realista en el mercado para crear sitios rápidos y escalables. Además explicamos cuáles son sus principales beneficios (páginas generadas corren muy rápido) y sus inconvenientes (las funciones dinámicas como comentarios o formularios son más complejas de implementar) o por qué separar el origen de datos del resultado final en sitios pequeños donde no se genere mucho contenido puede ser un buen aliado. En el segundo bloque compartimos de las bases de un modelo de desarrollo con JAMStack orientadas hacia el cliente y no hacia el servidor y ahondamos en la diferencia competitiva de los Headless CMS frente al CMS tradicional.Enlaces recomendados:- VuePress es un generador de sitios web estáticos con Vue.js: https://vuepress.vuejs.org/- Una lista de los generadores de sitios web estáticos más conocidos del mercado con opción para filtrar por estrellas en el repositorio (popularidad) o seguidores en twitter: https://www.staticgen.com/- Stackbit te permite elegir la plantilla, el generador de sitios web estáticos, el CMS y donde lo quieres desplegar: https://www.stackbit.com- Webflow: https://webflow.com- Una lista de CMSs para sitios con un stack que se basa en JavaScript, API y Markup: https://headlesscms.org/- Generador de sitios web estáticos con Vue a partir de cualquier Headless CMSs o CMSs como WordPress, Contentful o Drupal: https://gridsome.org- Netlify: https://www.netlify.com- Cómo funciona un generador de sitios web estáticos: https://css-tricks.com/really-makes-static-site-generator/- Jekyll es un generador de sitios web estáticos, usa markdown, ruby y liquid para generar sitios html: https://jekyllrb.com- Una solución interesante de Headless CMS sin la necesidad de montar una infraestructura completa (no es que sea barato): https://www.contentful.com- Pelican es un generador de sitios estáticos que permite crear web de forma fácil, estas pueden almacenarse en GitHub Pages. Si quieres automatizar el proceso de actualizaciones puede utilizarse un servidor de integración continúa como Travis-CI: https://blog.getpelican.com/- ReadMe - documentación interactiva: https://readme.com- Una referencia de contenido en el mundo de frontend: https://www.smashingmagazine.com/- Open source Node.js Headless CMS to easily build customisable APIs: https://strapi.io- Hay un episodio de fenómeno mutante donde Óscar y Daniel radian cómo migran una web desde WordPress a Hugo: https://www.fenomenomutante.com/53-hugo-a-cascoporro/https://www.fenomenomutante.com/53-hugo-a-cascoporro/La mejor forma para comunicarte con nosotros es vía Twitter:Danny Prol: https://twitter.com/DannyProlClaudio Cossio: https://twitter.com/ccossio
פרק מספר 61 של באמפרס (377 למניין רברס עם פלטפורמה) - רן, אלון, ודותן מתאוששים מהבחירות (שוב) עם סקירה של טכנלוגיות ודברים מעניינים בשוק התוכנה הלוהט מהזמן האחרון, לפחות עד שיפורסמו התוצאות הרשמיות (ממשלת אחדות של React ו-Rust?! שמעתם את זה לראשונה כאן)רן - בלוג-פוסט מעניין שמגיע מ - Palo Alto Networks (שאחד ממייסדיה ישראלי) - השוואה של Security Features עבור Containers שונים - An Overview of Sandboxed Container Technologiesצעד אחורה לפני הצלילה - דוגמא נפוצה ל - Containers Technology זו Docker: טכנולוגיה שנחשבת פחות בטוחה מוירטואליזציה מלאה כיוון שכל ה- Containers משתמשים באותו Kernel, ואעפ”י שננקטים הרבה צעדים על מנת לבודד בין ה - Containers השונים, הבידוד אף פעם לא מוחלט ותמיד יש חשש מזליגה של מידע או השפעה מאחד לשני - בעיה קיימת, שרירה וידועה בעולם ה - Containers נכון להיום, וכל הזמן מחפשים עבורה פתרונות שונים.הבלוג-פוסט המדובר מציג את מה שנחשב כ - state of the art נכון להיום: מה הן ה -Containers Technologies הקיימות היום ואיזו רמה של בידוד נלקחת על מנת לספק רמה גבוהה יותר של Securityה - trade-off הקלאסי הוא Performance vs. Security.יש כאן תיאור של Use-cases שונים וגם תיאור הנדסי של איך כל טכנולוגיה עובדת, וזה מאוד מעניין.סקירה קצרה של מה שמתואר (אמ;לק) - לא טכנולוגית Containers (בתור התחלה . . . ) אבל נותנת מענה ל Use Case דומה - UniKernel: מעיין מערכת הפעלה שיש בה תוכנית אחת, למעשה - מערכת הפעלה שלמה שכל מה שהיא עושה זה להריץ את התוכנית שלכם (אם Zaphod Beeblebrox היה מתכנת וכו’); כיוון שכך - היא מאוד מוקשחת (כוללת רק את מה שהתוכנית שלכם צריכה - ולא יותר). כאמור - לא באמת Container אבל Use Case דומה - עם startup time מאוד קצר, מבנה מינימליסטי וכו’.מ-IBM מגיעה Container Technology בשם IBM Nabla - גם אם לא שמעתם על זה קודם (כאילו יש משהו של IBM שהוא לא AS400, Mainframe או משהו מהשכבה הגיאולוגית הזו כן שמעתם עליו), זה קיים - וברשימה.טכנולוגיה של Google בשם gVisor - טכנולוגיה שמשמשת את Google פנימית (וגם עבור App Engine לפני הרבה זמן), היום היא כבר מופיעה כקוד פתוח, ומהווה ברירת מחדל או משהו בסגנון עבור Kubernetes; מה שמעניין כאן הוא השימוש ב User-level Kernel - יש Kernel אבל ב - User level, כך שהוא לא משותף - אלא הרבה Kernels קטנים.יש את Amazon Firecracker - שעליו כבר דיברנו כמה פעמים (וגם כאן וכאן).וגם את OpenStack Kata - שגם עליו לא שמענו קודם (זאת אומרת - על OpenStack כן, Kata פחות - המושג עצמו מוסבר יפה ב - Phoenix Project).בסופו של דבר - סקירה מאוד יפה ומעמיקה מומלץ.אז בכל זאת TL;DR לאמ;לק? חלק מהטכנולוגיות ברמת בשלות גבוהה וחלק פחות; וכל אחת מהן לוקחת איזשהו Trade-off בין Performance ל - Security, וכל אחד צריך למצוא את המקום הנכון בשבילו - אין פתרון קסם אחד.יש גם טבלת סיכום בסוף המאמר, עם Features שונים כמו הפעלה דומה ל - Docker, האם הקוד פתוח (כן, כולם), וכו’ - יכול לעזור לבחור.בשורה התחתונה - אנחנו יודעים ש - Docker הכי פופלארי אם אתם בעניין של מיינסטרים (אפילו לא מופיע בסקירה . . . ), אבל גם סביר להניח שהוא הכי פחות בטוח (Secured), אז אם חשוב לכם Security כי למשל את מריצים workloads מגורמים שהם Un-trusted ואתם חייבים לשים לב; אם כל ה - workload שלכם פנימית אז הסכנה אולי פחות גדולה ועדיין מומלץ לשים לב ולמנוע מבעייה באחד ה - Containers לזלוג לאחרים.שורה תחתונה, שוב: ה - trade-off הקלאסי של Performance vs. Security, עם רמות בשלות שונות של הפלטפורמות השונות: gVisor ו - Firecracker ברמת בשלות גבוהה יחסית והשתיים האחרות פחות, אבל אף אחת לא פופלארית ברמה של Docker למשל.צריך לקחת בחשבון שלפעמים בענייני Security הדברים הכי פופלאריים הם גם הכי מסוכנים - אם מישהו מנסה Brut-force ויודע שרוב הסיכויים הם לנחות על Docker אז אולי ישקיע בזה יותר וזה סיכון.מצד אחד - אולי ככל שהפלטרפרומה יותר פופלארית כך היא תהווה מטרה יותר גדולה ל Hackers, ומצד שני - יותר עיניים יסתכלו עליה כך שיותר באגים ימצאו ואולי כך היא תהפוך ליותר קשיחה. מאזן אימה . . .הבוטים באים! AWS Chatbot: ChatOps for AWSאיפה נועםר?אז AWS פרסמו פלטרפורמה בשם AWS Chatbot, שיכולה להוות נדבך משמעותי ב - Chat-Ops על AWS.רגע - ChatOps?מדובר ביכולת לנהל סביבת Production דרך צ’אט - אם זה Deployment או Provisioning למכונות, Scale up או Scale down, ניטור (Monitoring) . . . הכל דרך צ’אט.שיטה מקובלת בכל מיני חברות, אחת המפורסמות היא GitHub.יתרונות - שקיפות: אף פעם לא עושים SSH לאיזשהו Server, הכל דרך צ’אט אז כולם רואים מה קורה, וגם יכולים ללמוד איך לעשות את זה בפעם הבאה לבד.ובחזרה לאייטם - AWS Chatbot, מאפשרת לממש ChatOps על AWS.רן השתמש (בקטנה) לצרכי עבודה - פונקציות Lambda שמדווחות על Events ב-AWS, או כאלה ש”מאזינות לצ’אט” ועושות פעולות על AWS, ויש גם דברים אחרים.זו פלטפורמה קצת יותר הוליסטית, שיכולה להוות נקודת התחלה די טובה, בהנחה שאתם עובדים תחת AWS ורוצים ChatOps.אז עכשיו רק חסר להוסיף את זה עם פקודות קוליות ל Alexa . . . רק לחבר לשירות Text to Speech שלהם (Polly) וזהו?תכל’ס - מה הסיכוי שזה כבר קיים? כל ה-Echo Devices גם ככה מקשיבים כל הזמן, אז אפשר להתחיל להרים מכונות כבר כשמתמעורר הדיון בפינת הקפה, ואז כשסוף כל סוף מגיעה הפקודה זה מוכן ממש מהר. נשאר רק לממש Delay קטן כדי למנוע חשדות ולהפחית Creepiness . . . אין על SkyNet.האם אפשר לשדר את כל הפקודות הקוליות בתדר שרק מכונות “שומעות”, ואז לעשות Hacking לכולם? בטח גם זה כבר קיים . . . מסביר מלא דברים.וברצינות (יחסית) - זה עובד רק על AWS או שניתן לבצע אינטגרציה עם מערכות אחרות?מה שהם מממשים עובד רק על AWS, עם ה - Backend של AWS - למשל EC2, ELB ,S3 וכאלה, אבל אפשר לקחת Design דומה, וקונספטואלית לעשות משהו דומה עבור פלטפורמה אחרת - וזה גם קיים -אחד הראשונים היה HUBOT של GitHub, והוא עדיין די פופלארי (על אף הרבה re-writes, במקור זה היה ב CoffeeScript, אבל יש מצב שיש כיום בעולם יותר מפתחי Cobol מ-CoffeeScript…)יש גם פלטפורמה חדשה שנכתבה ב-Go, עם השם הקליט joe…טרנד אחר שמתכתב עם זה הוא GitOps, אבל זה אולי לפעם אחרת.הכרזה של AWS על POP חדש בישראל - AWS CloudFront launches a POP in Israelלא פופ כזה . . . Point Of Presence - למעשה מדובר ב”קצה של ה-CDN” שנמצא בישראלגרם להתרגשות גדולה בקרב קהילת המפתחים בישראל (אלון בהדגמה חיה, פחות עובר בטקסט, דמיינו התרגשות).בסופו של דבר זה בסך הכל POP, ויכול קצת לזרז את הגישה ל-CDN של AWS, ואולי גם חישוביות במובן של Lambda@Edge, אבל כנראה שלא יותר מזה (חישוביות מוגבלת).ב-POP סטנדרטי של AWS יש CloudFront ו - Lambda@Edge (לא בכולם, כאן נראה שכן) - ודי זהו בגדול.מה הסיכוי שזה מתואם עם ההשקה של Amazon.com בישראל? אולי, אבל יש מצב שיותר קשור למכרזים ממשלתיים ש-AWS מתעניינת בהם (מול GCP ו-Azure בעיקר), ושכוללים בין השאר דרישה לתשתיות פיזיות בארץ, כך שאולי זה קשור כהכנה או משהו.אבל זה רק POP . . . פקידי הממשלה - שלא יעבדו עליכם! שוב . . . זה לא Storage וזה לא Compute - זו עדיין לא נוכחות “אמיתית”, אבל לפחות אנחנו על המפה ואנחנו נשארים במפה. הנה.בתיאוריה - יש את Lambda@Edge, אז ברמה התיאורטית אפשר “לעשות הכל” . . . זאת אומרת - רק דברים ש Lambda@Edge יכולה לעשות. יש מגבלות לעומת Lambda רגילה - שלחו גלויה אם אתם יודעים מה הן בדיוק (או בדקו ב Stack Overflow). בין הפותרים נכונה יוגרל פותר שלא ענה נכונה. או גלויה נוספת.ואם ב-AWS עסקינן - עוד הכרזה קטנה על Improved VPC networking for AWS Lambda functionsלמי שהתעסק על Functions ו-VPC יודע שהייתה בעיה בחיבור של Lambda עם VPC - כשה-Cold start עולה משמעותית יותר לאט (עד כדי 8-10 שניות, לעומת סדר גודל של עד שנייה אחת).יש לזה הרבה “תירוצים” של חיבורים ותשתיות וכו’עכשיו - נפתרה הבעיה, ובחיבור של Lambda עם VPC לא אמור להיות שינוי משמעותי ב-Cold start, שזה די מגניב כי זה הפריע לשימוש ב-Lambda במקרים מסויימים, למשל אם היה צריך להתחבר ל-Database שמאחורי VPC.האייטם הבא - GitHub: בהמשך להכרזה מלפני לא מעט זמן על GitHub Actions, אז GitHub Actions now supports CI/CD, free for public repositoriesהכרזה על Workflows, שזה בעצם CI/CD - בחינם עבור פרויקטים פומביים (Public).למעשה ניתן להשתמש עכשיו ב GitHub Actions על מנת להריץ CI, באותו אופן שבו יכולתם להריץ למשל CircleCI או Travis-CI וכו’.בכל מקרה - עכשיו זה מובנה בתוך GitHub וזה די נחמדרן כבר השתמש בזה בפרויקט (טיזר להמשך . . . )ה-Feature כולו עדיין ב-Beta, אבל אתם יכולים להגיש בקשה להתקבל ל-Beta (רן התקבל, רק אומרים).אז
Can you explain Cloud Native? What are the key OpenSource frameworks you need to know? How about all these OpenSource Licensing models? Why do they exist? Which one to use? What are the monetization models and why to watch closely how Big IT & Cloud companies are impacting this space?Carmen Andoh (@carmatrocity), Program Manager at Google and former Infrastructure Engineer at Travis CI, helps us understand how to navigate the Cloud Native & OpenSource world and gives answer to all the questions above. The IT world is changing but its up to us to shape the future by inventing it. If you want to learn more after listening check out the CNCF Trailmap and follow up with Carmen on social media to get access to her material around that topic!Trailmaphttps://github.com/cncf/trailmap
Can you explain Cloud Native? What are the key OpenSource frameworks you need to know? How about all these OpenSource Licensing models? Why do they exist? Which one to use? What are the monetization models and why to watch closely how Big IT & Cloud companies are impacting this space?Carmen Andoh (@carmatrocity), Program Manager at Google and former Infrastructure Engineer at Travis CI, helps us understand how to navigate the Cloud Native & OpenSource world and gives answer to all the questions above. The IT world is changing but its up to us to shape the future by inventing it. If you want to learn more after listening check out the CNCF Trailmap and follow up with Carmen on social media to get access to her material around that topic!Trailmaphttps://github.com/cncf/trailmap
Chris Arceneaux (@chris_arceneaux) continues our Python For DevOps series and discusses how to use the CI/CD platforms Travis CI & Gitlab Resources: https://www.arsano.ninja/ https://github.com/carceneaux/travis-ci-python-demo https://github.com/carceneaux/gitlab-ci-python-demo *About vBrownBag* SUBSCRIBE! http://bit.ly/vBBYoutube Socials: Twitter: https://twitter.com/vBrownBag Facebook: https://facebook.com/vBrownBag iTunes: http://bit.ly/vbrownbagitunes Google+: google.com/+vBrownBag https://vBrownBag.com is a community of people who believe in helping other people. Specifically we work in IT infrastructure and we help other people in the IT industry to better their carreers by educating. Most frequent activity is producing the vBrownBag podcast. vBrownBag also attends global conferences to produce TechTalks and theater sessions. *About vBrownBag Podcasts* The vBrownBag crew host podcasts where community members present on topics that will help others in the community. Some podcast series are aimed at helping people achieve certifications. Other podcasts help community members learn an entirely new subject area. We also cover areas like storage or automation. The podcast has been running weekly since 2010. *vBrownBag TechTalks* The vBrownBag crew love IT conferences, the only place where we actually see each other, the awesome people who are our presenters and the community members who follow the podcast. The conferences are also a great place to generate some more community learning content. More about vBrownBag: https://vbrownbag.com/brownbags/what-is-vbrownbag/
La mejora continua en desarrollo de software se basa en optimizar y mejorar la calidad de un producto o servicio a través de un proceso evolutivo. En este episodio hablamos sobre las diferencias entre integración continua, entrega continua y despliegue continuo, el proceso de implementación de pruebas automatizadas para que las mejoras continuas funcionen, el ciclo de vida de DevOps o por qué mejora continua no envuelve solo actualizar una funcionalidad. Te recomendamos: DevOps llevado a la práctica mediante integración, entrega continua y sus herramientas disponibles en el mercado. Por Álvaro Vargas Quezada, Ingeniero de Software en Alvax Informática: https://youtu.be/PSBMfqFbvmE Técnicas de desarrollo en paralelo, integración continua/entrega continua y despliegue continuo, explicadas y comparadas por Oscar Faura: https://devopsti.wordpress.com/2014/09/26/integracion-continua-ci-entrega-continua-cd-y-despliegue-continuo-cd/ Travis CI: https://travis-ci.org CircleCI: https://circleci.com GitLab: https://about.gitlab.com Docker: https://www.docker.com
The gents look back with some hindsight on the debates around private equity, VC vs. bootstrapping Honeybadger, and how funding decisions may have affected recent layoffs at NPM and Travis CI. Our recent Twitter ad performance for FounderQuest is also discussed as well as Nintendo graphics and food trucks. Join us!
stdout.fm 18번째 로그에서는 .dev 도메인, 랭킹 시각화, 개발자 설문 조사에 대해서 이야기를 나눴습니다. 참가자: @seapy, @raccoonyy, @nacyo_t Blue - Yeti TX650 디지털 보이스 레코더 TX 시리즈 | ICD-TX650 | Sony KR Blue - Yeti Nano 개발자라면 탐나는 .dev 최상위 도메인 등록 시작 | 44bits.io .DEV 도메인 이름 | .DEV 도메인 등록 - GoDaddy KR .com - 위키백과, 우리 모두의 백과사전 .io - 위키백과, 우리 모두의 백과사전 Google Registry - .dev Jon Postel - Wikipedia The TLD map with Jon Postel Wikimedia Commons ICANN - Internet Corporation for Assigned Names and Numbers Top 15 Best Global Brands Ranking (2000-2018) - YouTube Best Global Brands - Interbrand Top 10 Country GDP Ranking History (1960-2017) - YouTube Hans Rosling: 한스 로슬링이 이제껏 보지 못했던 최고의 통계를 보여준다. | TED Talk 주요 연예기획사 시가총액 순위 변화 Carmen Hernández Andoh on Twitter: “A bunch of talented, amazing people from Travis will be looking for jobs soon. … /1” IDERA | SQL Server, Database Management, and IT Performance Tools Idera acquires Travis CI | TechCrunch It looks like Ibera is gutting Travis CI just a few weeks after acquiring it : devops The Travis CI Blog: Travis CI joins the Idera family Bitrise - Mobile Continuous Integration and Delivery Continuous Integration and Delivery - CircleCI GitLab Continuous Integration & Delivery | GitLab 프로그래머스 2019 개발자 설문조사 리포트 | 프로그래머스 Python Developers Survey 2018 Results Download IntelliJ IDEA: The Java IDE for Professional Developers by JetBrains For Students: Free Professional Developer Tools by JetBrains TextMate: Text editor for macOS Bash, Zsh에서 여러줄의 명령어를 에디터로 편집하고 실행하기 | 44bits.io 셸에서 여러줄의 명령어를 에디터로 편집하고 실행하기 /w VSCode - YouTube 데이터 베이스 관리 시스템 | MySQL | Amazon Web Services Host, run, and code Python in the cloud: PythonAnywhere
Hiro Asari is a software developer at Travis CI and has spoken at many conferences across the globe. Hiro guested on to the show to discuss dpl, a continuous deployment tool he maintains at TravisCI.
Hiro Asari is a software developer at Travis CI and has spoken at many conferences across the globe. Hiro guested on to the show to discuss dpl, a continuous deployment tool he maintains at TravisCI.
Episode 8 – Now With Insane Magic This week we talk about TLS support for NLB, AWS Worklink, Kubernetes Metering and retailers pushing back on AWS. Plus the lightning round and cool tools with Jonathan. #thecloudpod Thanks to our Sponsors: Foghorn Consulting: fogops.io/thecloudpod Audible: audibletrial.com/thecloudpod News Microsoft Earnings – http://fortune.com/2019/01/30/microsoft-stock-down-slowdown-azure-cloud/ Idera acquires Travis CI – https://techcrunch.com/2019/01/23/idera-acquires-travis-ci/ Google Gives Wikipedia Millions – https://www.wired.com/story/google-wikipedia-machine-learning-glow-languages/ NLB now supports TLS Termination – https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers Microsoft Acquires Citus Data – https://blogs.microsoft.com/blog/2019/01/24/microsoft-acquires-citus-data-re-affirming-its-commitment-to-open-source-and-accelerating-azure-postgresql-performance-and-scale/ AWS Worklink secures on premise website and apps – https://aws.amazon.com/blogs/aws/amazon-worklink-secure-one-click-mobile-access-to-internal-websites-and-applications/ GKE Usage Metering https://cloud.google.com/blog/products/containers-kubernetes/gke-usage-metering-whose-line-item-is-it-anyway Albertsons picks Azure to run cloud workloads due to Amazon being a competitor – https://www.fool.com/investing/2019/01/28/amazon-fear-is-driving-retailers-to-microsofts-clo.aspx Lightning Round Python Shell for AWS Glue – https://aws.amazon.com/about-aws/whats-new/2019/01/introducing-python-shell-jobs-in-aws-
Show: 383 Description: Aaron and Brian talk with Paul D. Johnston (@PaulDJohnston, Co-Founder ServerlessDays (creator of “Jeff”), CXO Serverless Consultant) about the current state of Serverless, Serverless vs. FaaS, how to economically think about functions of code, and areas where Serverless needs to improve. Show Sponsor Links:Datadog Homepage - Modern Monitoring and AnalyticsTry Datadog yourself by starting a free, 14-day trial today. Listeners of this podcast will also receive a free Datadog T-shirtLiquid Technology - IT Value RecoveryTry CloudLast Service, get a free t-shirt and chance at Amazon Gift CardCloud News of the WeekIBM signs deal with Vodafone - https://newsroom.ibm.com/2019-01-17-IBM-Vodafone-Business-Join-Forces-to-Drive-Innovation-in-Rapidly-Changing-WorldIBM signs deal with Juniper - https://www.ibm.com/blogs/cloud-computing/2019/01/18/ibm-juniper-cloud-agreement/Travis CI acquired by Idera - https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-incConfluent, creators of Kafka, raised $125M in VC funding in a Round D, at a $2.5B valuation - https://www.forbes.com/sites/alexkonrad/2019/01/23/open-source-unicorn-confluent-reaches-25-billion-valuation-three-years-after-hiring-its-first-sales-rep/#67d93c3315e2Microsoft buys Citus Data (open source Postgres SQL) - http://zd.net/2FQfF2vShow Interview Links:Paul’s Blog - https://medium.com/@PaulDJohnstonThe ServerlessCast #6 - Event-Driven Thinking with Paul Johnson - http://www.thecloudcast.net/2017/05/the-serverlesscast-6-events-vs-functions.htmlServerlessDays - https://serverlessdays.io/Show Notes:Topic 1 - Happy New Year, hope you’re having a good 2019. It’s been a while since you were last on the show. As the creator of Jeff, what have you been up to lately?Topic 2 - Let’s talk about a basic thing that seems to confuse people. What’s the new definition, or the actual difference (if there is any), between “Serverless” and “Functions as a Service”. Topic 3 - I’ve seen you mention several times on Twitter that, “Few people really understand how powerful serverless can be. They focus on the wrong things.” Help us get focused on the important parts. Topic 4 - I’ve also seen you say that “with serverless, infrastructure is a rounding error.” Walk us through the economics of your experiences with serverless, and how you think about “profitable software”.Topic 5 - Why do you think it seems like so many of the other cloud offerings are so far behind AWS Lambda? Topic 6 - At a high level, what is working well in serverless, and what is still complicated or missing? What’s your wishlist for 2019?Feedback?Email: show at thecloudcast dot netTwitter: @thecloudcastnet and
Coté has a late night, mental breakdown about scorecards. Can Brandon save him? Also, kafka, Travis CI, and snow. Relevant to your interests Atlassian surpassed $1B in calendar-year revenue in 2018 (https://www.zdnet.com/article/atlassian-surpassed-1b-in-calendar-year-revenue-in-2018/) Google remains the top open-source contributor to CNCF projects (https://techcrunch.com/2019/01/17/google-remains-the-top-open-source-contributor-to-cncf-projects/) Oracle exec: Open-source vendors locking down licences proves 'they were never really open (https://www.theregister.co.uk/2019/01/17/oracle_exec_opensource_vendors_locking_down_licenses_proves_they_were_never_really_open/)’ Morgan Stanley Downgrades Oracle Stock on Dim Growth Prospects (https://www.barrons.com/articles/oracle-stock-morgan-stanley-downgrades-51547572633) Vodafone signs $550m deal with IBM to offload cloud biz (https://www.theregister.co.uk/2019/01/18/vodafone_signs_550m_deal_with_ibm_to_offload_cloud_biz/) Insiders say that Google's new cloud boss is likely to make some very large acquisitions (https://www.businessinsider.com/new-google-cloud-ceo-thomas-kurian-acquisitions-2019-1) 'The goal is to automate us': welcome to the age of surveillance capitalism (https://www.theguardian.com/technology/2019/jan/20/shoshana-zuboff-age-of-surveillance-capitalism-google-facebook) Just forget what Gartner said about AI in June 'cos CIOs are all over it now apparently (http://go.theregister.com/feed/www.theregister.co.uk/2019/01/21/gartner_ai_cio_research/) Open-Source Unicorn: Confluent Reaches $2.5 Billion Valuation Three Years After Hiring Its First Sales Rep (https://www.forbes.com/sites/alexkonrad/2019/01/23/open-source-unicorn-confluent-reaches-25-billion-valuation-three-years-after-hiring-its-first-sales-rep/) Travis CI joins the Idera family (https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc) IBM Boasts Another Big Win, Touts Hybrid Cloud Prowess (https://www.sdxcentral.com/articles/news/ibm-boasts-another-big-win-touts-hybrid-cloud-prowess/2019/01/?utm_source=feedblitz&utm_medium=FeedBlitzRss&utm_campaign=sdxcentral) Microsoft wins cloud business from Albertsons as fear of Amazon grows among retailers (https://www.cnbc.com/2019/01/23/microsoft-signs-cloud-deal-with-albertsons.html) Non Sense Oreo Competitor Makes Federal Case Out of ‘Cutthroat’ Cookie Rivalry (https://www.wsj.com/articles/food-fight-in-the-cookie-aislehydrox-vs-oreo-turns-cutthroat-11547740235) ROAD TRIP! Buc-ee's opens 1st location outside of Texas (https://abc13.com/business/road-trip-buc-ees-opens-1st-location-outside-of-texas/5099836/) Sponsors Solarwinds To learn more or try the company’s DevOps products for free, visit https://solarwinds.com/devops. Arrested DevOps Subscribe to the Arrested DevOps podcast by visiting https://www.arresteddevops.com/ Conferences, et. al. ALERT! DevOpsDays Discount - DevOpsDays MSP (https://www.devopsdays.org/events/2019-minneapolis/welcome/), August 6th to 7th, $50 off with the code SDT2019 (https://www.eventbrite.com/e/devopsdays-minneapolis-2019-tickets-51444848928?discount=SDT2019). 2019, a city near you: The 2019 SpringTours are posted (http://springonetour.io/). Coté will be speaking at many of these, hopefully all the ones in EMEA. They’re free and all about programming and DevOps things. Free lunch and stickers! Jan 28th to 29th, 2019 - SpringOne Tour Charlotte (https://springonetour.io/2019/charlotte), $50 off with the code S1Tour2019_100. Feb 12th to 13th, 2019 - SpringOne Tour St. Louis (https://springonetour.io/2019/st-louis). $50 off the code S1Tour2019_100. Mar 7th to 8th, 2019 - Incontro DevOps in Bologna (https://2019.incontrodevops.it/), Coté speaking. Mar 13th, 2019 - Coté speaking at (platform as a product) (https://www.meetup.com/Continuous-Delivery-Amsterdam/events/258120367/) - Continuous Delivery, Amsterdam. Mar 18th to 19th, 2019 - SpringOne Tour London (https://springonetour.io/2019/london). Get £50 off ticket price of £150 with the code S1Tour2019_100. Mar 21st to 2nd, 2019 (https://springonetour.io/2019/amsterdam) - SpringOne Tour Amsterdam. Get €50 off ticket price of €150 with the code S1Tour2019_100. Get a Free SDT T-Shirt Write an iTunes review of SDT and get a free SDT T-Shirt. Write an iTunes Review on the SDT iTunes Page. (https://itunes.apple.com/us/podcast/software-defined-talk/id893738521?mt=2) Send an email to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and include the following: T-Shirt Size (Only Large or X-Large remain), Preferred Color (Gray, Black) and Postal address. First come, first serve. while supplies last! Can only ship T-Shirts within the United State SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Follow us on Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/) or LinkedIn (https://www.linkedin.com/company/software-defined-talk/) Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you a sticker. Listen to the Software Defined Interviews Podcast (https://www.softwaredefinedinterviews.com/). Check out the back catalog (http://cote.coffee/howtotech/). Brandon built the Quick Concall iPhone App (https://itunes.apple.com/us/app/quick-concall/id1399948033?mt=8) and he wants you to buy it for $0.99. Recommendations Brandon: (https://www.audible.com/pd/Billion-Dollar-Whale-Audiobook/1478948000?qid=1548351044&sr=1-1&ref=a_search_c3_lProduct_1_1&pf_rd_p=e81b7c27-6880-467a-b5a7-13cef5d729fe&pf_rd_r=D3A67G0APYVG06H98NGK&)Billion Dollar Whale (https://www.audible.com/pd/Billion-Dollar-Whale-Audiobook/1478948000?qid=1548351044&sr=1-1&ref=a_search_c3_lProduct_1_1&pf_rd_p=e81b7c27-6880-467a-b5a7-13cef5d729fe&pf_rd_r=D3A67G0APYVG06H98NGK&), Malaysia Wants Goldman’s Money Back (https://www.bloomberg.com/opinion/articles/2019-01-18/malaysia-wants-goldman-s-money-back). Coté: UNIQLO HEATTECH (https://www.uniqlo.com/uk/en/men/featured/heattech), as soft as a fancy conference t-shirt. Herbarium (https://www.ceskatelevize.cz/telexport/programmes?kategorie=24&porad=770), dubbed in English - “that’s Jim’s spatula!” Outro: "'93 'til Infinity." (https://genius.com/Souls-of-mischief-93-til-infinity-lyrics)
Byproducts of reading OpenBSD’s netcat code, learnings from porting your own projects to FreeBSD, OpenBSD’s unveil(), NetBSD’s Virtual Machine Monitor, what 'dependency' means in Unix init systems, jailing bhyve, and more. ##Headlines ###The byproducts of reading OpenBSD netcat code When I took part in a training last year, I heard about netcat for the first time. During that class, the tutor showed some hacks and tricks of using netcat which appealed to me and motivated me to learn the guts of it. Fortunately, in the past 2 months, I was not so busy that I can spend my spare time to dive into OpenBSD‘s netcat source code, and got abundant byproducts during this process. (1) Brush up socket programming. I wrote my first network application more than 10 years ago, and always think the socket APIs are marvelous. Just ~10 functions (socket, bind, listen, accept…) with some IO multiplexing buddies (select, poll, epoll…) connect the whole world, wonderful! From that time, I developed a habit that is when touching a new programming language, network programming is an essential exercise. Even though I don’t write socket related code now, reading netcat socket code indeed refresh my knowledge and teach me new stuff. (2) Write a tutorial about netcat. I am mediocre programmer and will forget things when I don’t use it for a long time. So I just take notes of what I think is useful. IMHO, this “tutorial” doesn’t really mean teach others something, but just a journal which I can refer when I need in the future. (3) Submit patches to netcat. During reading code, I also found bugs and some enhancements. Though trivial contributions to OpenBSD, I am still happy and enjoy it. (4) Implement a C++ encapsulation of libtls. OpenBSD‘s netcat supports tls/ssl connection, but it needs you take full care of resource management (memory, socket, etc), otherwise a small mistake can lead to resource leak which is fatal for long-live applications (In fact, the two bugs I reported to OpenBSD are all related resource leak). Therefore I develop a simple C++ library which wraps the libtls and hope it can free developer from this troublesome problem and put more energy in application logic part. Long story to short, reading classical source code is a rewarding process, and you can consider to try it yourself. ###What I learned from porting my projects to FreeBSD Introduction I set up a local FreeBSD VirtualBox VM to test something, and it seems to work very well. Due to the novelty factor, I decided to get my software projects to build and pass the tests there. The Projects https://github.com/shlomif/shlomif-computer-settings/ (my dotfiles). https://web-cpan.shlomifish.org/latemp/ https://fc-solve.shlomifish.org/ https://www.shlomifish.org/open-source/projects/black-hole-solitaire-solver/ https://better-scm.shlomifish.org/source/ http://perl-begin.org/source/ https://www.shlomifish.org/meta/site-source/ Written using a mix of C, Perl 5, Python, Ruby, GNU Bash, XML, CMake, XSLT, XHTML5, XHTML1.1, Website META Language, JavaScript and more. Work fine on several Linux distributions and have https://en.wikipedia.org/wiki/TravisCI using Ubuntu 14.04 hosts Some pass builds and tests on AppVeyor/Win64 What I Learned: FreeBSD on VBox has become very reliable Some executables on FreeBSD are in /usr/local/bin instead of /usr/bin make on FreeBSD is not GNU make m4 on FreeBSD is not compatible with GNU m4 Some CPAN Modules fail to install using local-lib there DocBook/XSL Does Not Live Under /usr/share/sgml FreeBSD’s grep does not have a “-P” flag by default FreeBSD has no “nproc” command Conclusion: It is easier to port a shell than a shell script. — Larry Wall I ran into some cases where my scriptology was lacking and suboptimal, even for my own personal use, and fixed them. ##News Roundup ###OpenBSD’s unveil() One of the key aspects of hardening the user-space side of an operating system is to provide mechanisms for restricting which parts of the filesystem hierarchy a given process can access. Linux has a number of mechanisms of varying capability and complexity for this purpose, but other kernels have taken a different approach. Over the last few months, OpenBSD has inaugurated a new system call named unveil() for this type of hardening that differs significantly from the mechanisms found in Linux. The value of restricting access to the filesystem, from a security point of view, is fairly obvious. A compromised process cannot exfiltrate data that it cannot read, and it cannot corrupt files that it cannot write. Preventing unwanted access is, of course, the purpose of the permissions bits attached to every file, but permissions fall short in an important way: just because a particular user has access to a given file does not necessarily imply that every program run by that user should also have access to that file. There is no reason why your PDF viewer should be able to read your SSH keys, for example. Relying on just the permission bits makes it easy for a compromised process to access files that have nothing to do with that process’s actual job. In a Linux system, there are many ways of trying to restrict that access; that is one of the purposes behind the Linux security module (LSM) architecture, for example. The SELinux LSM uses a complex matrix of labels and roles to make access-control decisions. The AppArmor LSM, instead, uses a relatively simple table of permissible pathnames associated with each application; that approach was highly controversial when AppArmor was first merged, and is still looked down upon by some security developers. Mount namespaces can be used to create a special view of the filesystem hierarchy for a set of processes, rendering much of that hierarchy invisible and, thus, inaccessible. The seccomp mechanism can be used to make decisions on attempts by a process to access files, but that approach is complex and error-prone. Yet another approach can be seen in the Qubes OS distribution, which runs applications in virtual machines to strictly control what they can access. Compared to many of the options found in Linux, unveil() is an exercise in simplicity. This system call, introduced in July, has this prototype: int unveil(const char *path, const char *permissions); A process that has never called unveil() has full access to the filesystem hierarchy, modulo the usual file permissions and any restrictions that may have been applied by calling pledge(). Calling unveil() for the first time will “drop a veil” across the entire filesystem, rendering the whole thing invisible to the process, with one exception: the file or directory hierarchy starting at path will be accessible with the given permissions. The permissions string can contain any of “r” for read access, “w” for write, “x” for execute, and “c” for the ability to create or remove the path. Subsequent calls to unveil() will make other parts of the filesystem hierarchy accessible; the unveil() system call itself still has access to the entire hierarchy, so there is no problem with unveiling distinct subtrees that are, until the call is made, invisible to the process. If one unveil() call applies to a subtree of a hierarchy unveiled by another call, the permissions associated with the more specific call apply. Calling unveil() with both arguments as null will block any further calls, setting the current view of the filesystem in stone. Calls to unveil() can also be blocked using pledge(). Either way, once the view of the filesystem has been set up appropriately, it is possible to lock it so that the process cannot expand its access in the future should it be taken over and turn hostile. unveil() thus looks a bit like AppArmor, in that it is a path-based mechanism for restricting access to files. In either case, one must first study the program in question to gain a solid understanding of which files it needs to access before closing things down, or the program is likely to break. One significant difference (beyond the other sorts of behavior that AppArmor can control) is that AppArmor’s permissions are stored in an external policy file, while unveil() calls are made by the application itself. That approach keeps the access rules tightly tied to the application and easy for the developers to modify, but it also makes it harder for system administrators to change them without having to rebuild the application from source. One can certainly aim a number of criticisms at unveil() — all of the complaints that have been leveled at path-based access control and more. But the simplicity of unveil() brings a certain kind of utility, as can be seen in the large number of OpenBSD applications that are being modified to use it. OpenBSD is gaining a base level of protection against unintended program behavior; while it is arguably possible to protect a Linux system to a much greater extent, the complexity of the mechanisms involved keeps that from happening in a lot of real-world deployments. There is a certain kind of virtue to simplicity in security mechanisms. ###NetBSD Virtual Machine Monitor (NVVM) NetBSD Virtual Machine Monitor The NVMM driver provides hardware-accelerated virtualization support on NetBSD. It is made of an ~MI frontend, to which MD backends can be plugged. A virtualization API is provided in libnvmm, that allows to easily create and manage virtual machines via NVMM. Two additional components are shipped as demonstrators, toyvirt and smallkern: the former is a toy virtualizer, that executes in a VM the 64bit ELF binary given as argument, the latter is an example of such binary. Download The source code of NVMM, plus the associated tools, can be downloaded here. Technical details NVMM can support up to 128 virtual machines, each having a maximum of 256 VCPUs and 4GB of RAM. Each virtual machine is granted access to most of the CPU registers: the GPRs (obviously), the Segment Registers, the Control Registers, the Debug Registers, the FPU (x87 and SSE), and several MSRs. Events can be injected in the virtual machines, to emulate device interrupts. A delay mechanism is used, and allows VMM software to schedule the interrupt right when the VCPU can receive it. NMIs can be injected as well, and use a similar mechanism. The host must always be x8664, but the guest has no constraint on the mode, so it can be x8632, PAE, real mode, and so on. The TSC of each VCPU is always re-based on the host CPU it is executing on, and is therefore guaranteed to increase regardless of the host CPU. However, it may not increase monotonically, because it is not possible to fully hide the host effects on the guest during #VMEXITs. When there are more VCPUs than the host TLB can deal with, NVMM uses a shared ASID, and flushes the shared-ASID VCPUs on each VM switch. The different intercepts are configured in such a way that they cover everything that needs to be emulated. In particular, the LAPIC can be emulated by VMM software, by intercepting reads/writes to the LAPIC page in memory, and monitoring changes to CR8 in the exit state. ###What ‘dependency’ means in Unix init systems is underspecified (utoronto.ca) I was reading Davin McCall’s On the vagaries of init systems (via) when I ran across the following, about the relationship between various daemons (services, etc): I do not see any compelling reason for having ordering relationships without actual dependency, as both Nosh and Systemd provide for. In comparison, Dinit’s dependencies also imply an ordering, which obviates the need to list a dependency twice in the service description. Well, this may be an easy one but it depends on what an init system means by ‘dependency’. Let’s consider ®syslog and the SSH daemon. I want the syslog daemon to be started before the SSH daemon is started, so that the SSH daemon can log things to it from the beginning. However, I very much do not want the SSH daemon to not be started (or to be shut down) if the syslog daemon fails to start or later fails. If syslog fails, I still want the SSH daemon to be there so that I can perhaps SSH in to the machine and fix the problem. This is generally true of almost all daemons; I want them to start after syslog, so that they can syslog things, but I almost never want them to not be running if syslog failed. (And if for some reason syslog is not configured to start, I want enabling and starting, say, SSH, to also enable and start the syslog daemon.) In general, there are three different relationships between services that I tend to encounter: a hard requirement, where service B is useless or dangerous without service A. For instance, many NFS v2 and NFS v3 daemons basically don’t function without the RPC portmapper alive and active. On any number of systems, firewall rules being in place are a hard requirement to start most network services; you would rather your network services not start at all than that they start without your defenses in place. a want, where service B wants service A to be running before B starts up, and service A should be started even if it wouldn’t otherwise be, but the failure of A still leaves B functional. Many daemons want the syslog daemon to be started before they start but will run without it, and often you want them to do so so that at least some of the system works even if there is, say, a corrupt syslog configuration file that causes the daemon to error out on start. (But some environments want to hard-fail if they can’t collect security related logging information, so they might make rsyslogd a requirement instead of a want.) an ordering, where if service A is going to be started, B wants to start after it (or before it), but B isn’t otherwise calling for A to be started. We have some of these in our systems, where we need NFS mounts done before cron starts and runs people’s @reboot jobs but neither cron nor NFS mounts exactly or explicitly want each other. (The system as a whole wants both, but that’s a different thing.) Given these different relationships and the implications for what the init system should do in different situations, talking about ‘dependency’ in it systems is kind of underspecified. What sort of dependency? What happens if one service doesn’t start or fails later? My impression is that generally people pick a want relationship as the default meaning for init system ‘dependency’. Usually this is fine; most services aren’t actively dangerous if one of their declared dependencies fails to start, and it’s generally harmless on any particular system to force a want instead of an ordering relationship because you’re going to be starting everything anyway. (In my example, you might as well say that cron on the systems in question wants NFS mounts. There is no difference in practice; we already always want to do NFS mounts and start cron.) ###Jailing The bhyve Hypervisor As FreeBSD nears the final 12.0-RELEASE release engineering cycles, I’d like to take a moment to document a cool new feature coming in 12: jailed bhyve. You may notice that I use HardenedBSD instead of FreeBSD in this article. There is no functional difference in bhyve on HardenedBSD versus bhyve on FreeBSD. The only difference between HardenedBSD and FreeBSD is the aditional security offered by HardenedBSD. The steps I outline here work for both FreeBSD and HardenedBSD. These are the bare minimum steps, no extra work needed for either FreeBSD or HardenedBSD. A Gentle History Lesson At work in my spare time, I’m helping develop a malware lab. Due to the nature of the beast, we would like to use bhyve on HardenedBSD. Starting with HardenedBSD 12, non-Cross-DSO CFI, SafeStack, Capsicum, ASLR, and strict W^X are all applied to bhyve, making it an extremely hardened hypervisor. So, the work to support jailed bhyve is sponsored by both HardenedBSD and my employer. We’ve also jointly worked on other bhyve hardening features, like protecting the VM’s address space using guard pages (mmap(…, MAPGUARD, …)). Further work is being done in a project called “malhyve.” Only those modifications to bhyve/malhyve that make sense to upstream will be upstreamed. Initial Setup We will not go through the process of creating the jail’s filesystem. That process is documented in the FreeBSD Handbook. For UEFI guests, you will need to install the uefi-edk2-bhyve package inside the jail. I network these jails with traditional jail networking. I have tested vnet jails with this setup, and that works fine, too. However, there is no real need to hook the jail up to any network so long as bhyve can access the tap device. In some cases, the VM might not need networking, in which case you can use a network-less VM in a network-less jail. By default, access to the kernel side of bhyve is disabled within jails. We need to set allow.vmm in our jail.conf entry for the bhyve jail. We will use the following in our jail, so we will need to set up devfs(8) rules for them: A ZFS volume A null-modem device (nmdm(4)) UEFI GOP (no devfs rule, but IP assigned to the jail) A tap device Conclusion The bhyve hypervisor works great within a jail. When combined with HardenedBSD, bhyve is extremely hardened: PaX ASLR is fully applied due to compilation as a Position-Independent Executable (HardenedBSD enhancement) PaX NOEXEC is fully applied (strict W^X) (HardenedBSD enhancement) Non-Cross-DSO CFI is fully applied (HardenedBSD enhancement) Full RELRO (RELRO + BINDNOW) is fully applied (HardenedBSD enhancement) SafeStack is applied to the application (HardenedBSD enhancement) Jailed (FreeBSD feature written by HardenedBSD) Virtual memory protected with guard pages (FreeBSD feature written by HardenedBSD) Capsicum is fully applied (FreeBSD feature) Bad guys are going to have a hard time breaking out of the userland components of bhyve on HardenedBSD. :) ##Beastie Bits GhostBSD 18.10 has been released Project Trident RC3 has been released The OpenBSD Foundation receives the first Silver contribution from a single individual Monitoring pf logs gource NetBSD on the RISC-V is alive The X hole Announcing the pkgsrc-2018Q3 release (2018-10-05) NAT performance on EdgeRouter X and Lite with EdgeOS, OpenBSD, and OpenWRT UNIX (as we know it) might not have existed without Mrs. Thompson Free Pizza for your dev events Portland BSD Pizza Night: Nov 29th 7pm ##Feedback/Questions Dennis - Core developers leaving illumOS? Ben - Jumping from snapshot to snapshot Ias - Question about ZFS snapshots Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
Brant Burnett is continuously integrating and deploying microservices. This episode is sponsored by Smartsheet. Show Notes: Previous microservice episodes: Chase Aucoin on the Microservices Manifesto Richard Rodger on Microservices SOA (Service Oriented Architectures), first defined in a Gartner paper from 1996: "Service Oriented" Architectures, Part 1 CI tools mentioned: Jenkins TeamCity Travis CI AppVeyor DEB and RPM files were mentioned. DEB - Video: Anatomy of a Debian Package RPM - rpm.org Chocolatey is a similar offering for Windows s3 is a cloud storage service from AWS (Amazon) Spinnaker Blue/Green Deployment and Red/Black Deployment Canary Release Monitoring tools mentioned: Prometheus and Data Dog Linq2Couchbase is a Linq provider for Couchbase (NoSQL database). For more about Linq, check out this video featuring Ander Hejlsberg State of DevOps Report 2018 by Puppet (and Splunk) Book: Accelerate : The Science of Lean Software and DevOps by Nicole Forsgren, Jez Humble, Gene Kim LaunchDarkly Brant Burnett is on Twitter. Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Music is by Joe Ferg, check out more music on JoeFerg.com!
Recording from Script'18 A typical interaction with a device or interface involves touching it. Either you're pressing buttons on a controller, swiping on a touchscreen or clicking on your laptop's trackpad. But what if you could control things without the use of your hands? What if you could use... your thoughts? I have been tinkering with a brain sensor and developed an open source JavaScript framework for it to allow me (or anyone else) to control interfaces or robots using facial expressions and mental commands. ScriptConf is powered by: - Dynatrace (https://dynatrace.com) - Fredmansky (https://fredmansky.at) - Karriere.at (https://karriere.at) - epunkt (https://www.epunkt.com) - Microsoft (https://microsoft.com) - Studio Mitte (https://studiomitte.com) - Presono (https://presono.com) - Travis CI (https://travis-ci.com)
A recording from Script'18 (https://scriptconf.org) Next wave infrastructure - do far more with much less - Phil Hawksworth(https://twitter.com/philhawksworth) Recent years have seen a shift in technical architectures. Building complex services for the web used to be just that – complex. Projects might have demanded a broad range of specialist skills which could stretch even the fullest of full-stack developers. These days we have a growing number of options for how we design, build and maintain the systems which keep our web sites and applications alive. This talk will look at ways to make use of emerging tools and services which can deliver surprisingly rich features and capabilities without maintaining expensive and complex infrastructure. We’ll talk about the benefits in keeping your stack simple, in using the expertise of others, and we'll examine the performance and security benefits of JAMstack and microservices. ScriptConf is powered by: - Dynatrace (https://dynatrace.com) - Fredmansky (https://fredmansky.at) - Karriere.at (https://karriere.at) - epunkt (https://www.epunkt.com) - Microsoft (https://microsoft.com) - Studio Mitte (https://studiomitte.com) - Presono (https://presono.com) - Travis CI (https://travis-ci.com) Photo by bebraw: https://www.flickr.com/photos/bebraw/sets/72157669068490399
Panel: Divya Sasidharan Erik Hanchett Joe Eames Chris Fritz In this episode, the panel talks about code automation, generators, and other topics. They talk about the pros and cons of what generators can and cannot do. Later they discuss different codes, such as Prettier and Eslint codes, and also talk about their pros and cons. Check-out today’s episode to get the full details on these topics and much more! Show Topics: 1:03 – Panel has different views on what code automation is and or is not. 2:53 – One of the panelists started his career with Rails. 3:58 – Let’s jump into one thing that I think Rails did really well, and that is generators! Generators aren’t really popular in the JavaScript community. What are generators? 4:43 – Generators is to help build your tooling. 4:57 – What is an example of a generator, and how can it resolve the issue-at-hand? 5:04 – To generate a component, for example. 5:20 – The panel go back and forth and discuss the different definitions of what a generator means to them, and the purpose of a generator. 8:29 – For beginners, if you are brand new to JavaScript then these generators could be confusing. 9:10 – People at first did not like Java’s generators. 10:04 – How much do you guys use generators in your workday? 10:07 – Angular CLI. 12:06 – To organize in a consistent way for a larger team, generators can help. 12:37 – It also standardizes things, too. If you have something in place, then basically the machine makes the decision for you already, which can save some headaches. 13:09 – Tooling to review code. As long as you can agree on a style then these tools can format your code the way you want it. 13:49 – Let’s talk about Prettier and Eslint code. Let’s take a poll. The panel goes back-and-forth and discusses the pros and cons of both codes, Prettier and Eslint. Some panelists have very strong views on one or the other, and they’ve had much experience with these codes, which they have given it much thought over the years. 22:36 – Bottom line: we all figure out things as we go along. 22:52 – New topic: Apart of the automated code review is to have Eslint and Prettier and other codes have all of these things run-on a pre-commit hook, only on the files that are staged. 25:06 – Who uses pre-commit hooks? A lot of people will run different tools to compress their images, and there is a tool that can help with that. 26:32 – Smart - anything to save time. 27:40 – New topic: Continuation integration. After a pre-commit hook in editor, then when you take a poll request then sometimes there are these services, Travis CI or CircleCI that will go through and run some tests to make sure that your project builds correctly, and deploy your site. I like to use tools like this. It integrates with others like GitHub among others. 29:54 – Digital Ocean’s Advertisement! 30:58 – If you want to see an example please got to this timestamp to hear the panelist’s suggestion! 32:03 – Once an application has been developed for a while it might take 4-5 minutes for it to finish – if I think it is fine, I don’t want to waste time. It doesn’t seem like a good use of my time. 36:23 – “Throwing out data is like gardening!” – This is Divya’s motto. 37:40 – One panelist likes to use the squash and merging option. 38:14 – Divya: “Do you have any control over what gets squashed?” 38:28 – Everything gets squashed 39:49 – Auto-completion. 40:27 – The panel talks about plugins and such. 41:10 – Back to continuation integration (CI). Biggest concern people have is it builds failing when nothing is wrong. 42:00 – “Time Zones” – that’s one scenario for Divya. 42:32 – Another panelist voices another concern. 45:31 – Another topic: Running Eslint and Prettier – how do we actually run those things? How do we run tests? 46:24 – The panel talks about what was and is popular within this field. 50:29 – Question asked. 50:41 – Proxies is very common. 54:46 – Another common web pack customization is when you have to use environmental variables. 55:55 – Anyone have anything else to talk about? No, so let’s talk about PICKS! Links: JavaScript Ruby on Rails Angular CLI Prettier and Eslint code Article on Travis Cl or CircleCI GitHub Kendo UI Digital Ocean Code Badge Sponsors: Kendo UI Digital Ocean Code Badge Picks: Divya Sci-Fi Book: Lewis’ Out of the Silent Planet N.K. Jemisin – author ToDoIst App Chris VR in Hand-Tracking & Beat Saber Joe Framework Summit Notion.so WorkFlowy Erik Program
Panel: Divya Sasidharan Erik Hanchett Joe Eames Chris Fritz In this episode, the panel talks about code automation, generators, and other topics. They talk about the pros and cons of what generators can and cannot do. Later they discuss different codes, such as Prettier and Eslint codes, and also talk about their pros and cons. Check-out today’s episode to get the full details on these topics and much more! Show Topics: 1:03 – Panel has different views on what code automation is and or is not. 2:53 – One of the panelists started his career with Rails. 3:58 – Let’s jump into one thing that I think Rails did really well, and that is generators! Generators aren’t really popular in the JavaScript community. What are generators? 4:43 – Generators is to help build your tooling. 4:57 – What is an example of a generator, and how can it resolve the issue-at-hand? 5:04 – To generate a component, for example. 5:20 – The panel go back and forth and discuss the different definitions of what a generator means to them, and the purpose of a generator. 8:29 – For beginners, if you are brand new to JavaScript then these generators could be confusing. 9:10 – People at first did not like Java’s generators. 10:04 – How much do you guys use generators in your workday? 10:07 – Angular CLI. 12:06 – To organize in a consistent way for a larger team, generators can help. 12:37 – It also standardizes things, too. If you have something in place, then basically the machine makes the decision for you already, which can save some headaches. 13:09 – Tooling to review code. As long as you can agree on a style then these tools can format your code the way you want it. 13:49 – Let’s talk about Prettier and Eslint code. Let’s take a poll. The panel goes back-and-forth and discusses the pros and cons of both codes, Prettier and Eslint. Some panelists have very strong views on one or the other, and they’ve had much experience with these codes, which they have given it much thought over the years. 22:36 – Bottom line: we all figure out things as we go along. 22:52 – New topic: Apart of the automated code review is to have Eslint and Prettier and other codes have all of these things run-on a pre-commit hook, only on the files that are staged. 25:06 – Who uses pre-commit hooks? A lot of people will run different tools to compress their images, and there is a tool that can help with that. 26:32 – Smart - anything to save time. 27:40 – New topic: Continuation integration. After a pre-commit hook in editor, then when you take a poll request then sometimes there are these services, Travis CI or CircleCI that will go through and run some tests to make sure that your project builds correctly, and deploy your site. I like to use tools like this. It integrates with others like GitHub among others. 29:54 – Digital Ocean’s Advertisement! 30:58 – If you want to see an example please got to this timestamp to hear the panelist’s suggestion! 32:03 – Once an application has been developed for a while it might take 4-5 minutes for it to finish – if I think it is fine, I don’t want to waste time. It doesn’t seem like a good use of my time. 36:23 – “Throwing out data is like gardening!” – This is Divya’s motto. 37:40 – One panelist likes to use the squash and merging option. 38:14 – Divya: “Do you have any control over what gets squashed?” 38:28 – Everything gets squashed 39:49 – Auto-completion. 40:27 – The panel talks about plugins and such. 41:10 – Back to continuation integration (CI). Biggest concern people have is it builds failing when nothing is wrong. 42:00 – “Time Zones” – that’s one scenario for Divya. 42:32 – Another panelist voices another concern. 45:31 – Another topic: Running Eslint and Prettier – how do we actually run those things? How do we run tests? 46:24 – The panel talks about what was and is popular within this field. 50:29 – Question asked. 50:41 – Proxies is very common. 54:46 – Another common web pack customization is when you have to use environmental variables. 55:55 – Anyone have anything else to talk about? No, so let’s talk about PICKS! Links: JavaScript Ruby on Rails Angular CLI Prettier and Eslint code Article on Travis Cl or CircleCI GitHub Kendo UI Digital Ocean Code Badge Sponsors: Kendo UI Digital Ocean Code Badge Picks: Divya Sci-Fi Book: Lewis’ Out of the Silent Planet N.K. Jemisin – author ToDoIst App Chris VR in Hand-Tracking & Beat Saber Joe Framework Summit Notion.so WorkFlowy Erik Program
A recording from Script'18 (https://scriptconf.org) Cycle.js on pen and paper - Andre Staltz (https://twitter.com/andrestaltz) Let's learn the Cycle.js framework from paper sketches and diagrams that make it look easy and obvious. Then, let's see how you can use it in the real world. ScriptConf is powered by: - Dynatrace (https://dynatrace.com) - Fredmansky (https://fredmansky.at) - Karriere.at (https://karriere.at) - epunkt (https://www.epunkt.com) - Microsoft (https://microsoft.com) - Studio Mitte (https://studiomitte.com) - Presono (https://presono.com) - Travis CI (https://travis-ci.com)
A recording from Script'18 (https://scriptconf.org) Creating Augmented Reality Apps with Web Technology - Michaela Lehr (https://twitter.com/fischaelameer) If 2017 was the year of Virtual Reality, 2018 may become the year of Augmented Reality. With Apple's ARKit for iOS and Google's ARCore for Android, we should not forget that actually the open web and Augmented Reality are the perfect couple. But how do we create AR apps with web technology? In my talk you will learn how to write your own AR app that runs in the browser. You will see how Augmented Reality works, what markers are for, and how to create them. And you'll get an overview about the devices you can use to test your AR projects. We are just at the beginning of the rise of Augmented Reality. This is why lots of UX design questions are still unanswered. But there are patterns and best practises, and you will learn how to use them to get a great user experience in your AR application. ScriptConf is powered by: - Dynatrace (https://dynatrace.com) - Fredmansky (https://fredmansky.at) - Karriere.at (https://karriere.at) - epunkt (https://www.epunkt.com) - Microsoft (https://microsoft.com) - Studio Mitte (https://studiomitte.com) - Presono (https://presono.com) - Travis CI (https://travis-ci.com)
A recording from Script'18 (https://scriptconf.org) Hop on the serverless adventure with Node.js - Simona Cotin (https://twitter.com/simona_cotin) Serverless is the new black - I can deploy my application to the cloud without ever worrying about infrastructure. We all remember the days when we had to spend hours and hours configuring and debugging web servers when all we wanted was to just code and test our app. Those days are long gone and it’s time for us to unlearn how to provision and manage infrastructure while focusing on building and scaling applications. ScriptConf is powered by: - Dynatrace (https://dynatrace.com) - Fredmansky (https://fredmansky.at) - Karriere.at (https://karriere.at) - epunkt (https://www.epunkt.com) - Microsoft (https://microsoft.com) - Studio Mitte (https://studiomitte.com) - Presono (https://presono.com) - Travis CI (https://travis-ci.com) Photo by bebraw: https://www.flickr.com/photos/bebraw/sets/72157669068490399
In this weeks episode we start off discussion around testing in a Continuous Integration pipeline, and setting up a personal Bamboo CI system. We then move on to separating domain logic from the delivery, and how a Package-Bridge-Delivery split works. After a small mouse related intermission, we touch upon experiences building custom Babel plugins and testing using Jest, Travis CI and Docker. Finally, we highlight creating small CLI applications with Go, Serverless Offline and Logic-Gates/8-bit computers.
A recording from Script'18 (https://scriptconf.org) The Journey to Full Time Open Source Working on open source has changed my life. I am self-employed and work on open source full-time. I don't have a boss. I only work on projects that I enjoy working on, and I can work whenever and wherever I want. I also let people use all the code I write for free. This is all made possible thanks to the amazing support from the community made up of the users of my open source projects. I think I'm incredibly lucky to be in this position today. Yet there are still many open source maintainers struggling on the verge of burnout while their software is being used by millions. So in this talk I will share with you my journey of open source - in particular how I made it my full-time job - in the hope of shedding some insights on open source sustainability. ScriptConf is powered by: - Dynatrace (https://dynatrace.com) - Fredmansky (https://fredmansky.at) - Karriere.at (https://karriere.at) - epunkt (https://www.epunkt.com) - Microsoft (https://microsoft.com) - Studio Mitte (https://studiomitte.com) - Presono (https://presono.com) - Travis CI (https://travis-ci.com)
After helping found Travis CI and grow into the CEO role over six years, Mathias recently left Travis and starting helping other companies with their growth challenges. We talked about the difficulty of leaving and moving on after six years and the tactics that have helped him work through it. We also talk about the operational side of growth. While we all want revenue to grow, sometimes, we fail to think about how that growth affects operations and requires significant attention to the operational side of the business. We also touch on how bootstrapping lends itself to slower and steady growth with a little less stress. We discuss how Travis CI's support of open source projects started out simply as support for the open source community but had the wonderful side effect of great marketing. However, in the case of Travis, scaling to support so many free projects early on wasn't without its own challenges. And we cover some of the challenges of being a german business and doing business internationally while also having a remote team working asynchronously across time zones with nine hours of difference. Special Guest: Mathias Meyer.
In episode #173 we discuss continuous integration with Nate Dentzau. www.talkingdrupal.com/173 Topics What is CI Benefits Deployment vs Delivery Common CI Tools Getting started with CI Resources Oomph Drupal Scaffold https://github.com/oomphinc/drupal-scaffold Travis-CI integrations: https://docs.travis-ci.com/user/code-climate/ Github Integrations: https://github.com/marketplace Hosts Stephen Cross - www.ParallaxInfoTech.com @stephencross John Picozzi - www.oomphinc.com @johnpicozzi Nic Laflin - www.nLighteneddevelopment.com @nicxvan Nate Dentzau - @NathanDentzau
Introduction Yannick et Benjamin reçoivent à nouveau Xavier Gouchet pour parler de testing et plus particulièrement de mutation testing. Téléchargement direct Show notes 1:49″ – Test unitaire : https://fr.wikipedia.org/wiki/Test_unitaire 2:10″ – Test d’intégration : https://fr.wikipedia.org/wiki/Test_d%27intégration 2:25″ – Test fonctionnel : https://www.developpez.net/forums/d1286493/general-developpement/alm/methodes/gestion-projet/test/tests-fonctionnels/ 2:38″ – Espresso : https://developer.android.com/training/testing/espresso/index.html 6:47″ – Jenkins : https://jenkins.io/ 6:48″ – Travis CI : https://travis-ci.org/ 7:28″ – Pull […]
Getting started or getting ahead in IT is a moving target, so we’ve crowd sourced some of the best tips and advice to help. Plus a tricky use of zero-width characters to catch a leaker, a breakdown of the new BranchScope attack, and a full post-mortem of the recent Travis CI outage.
Rob and Jason are joined by Richel Bilderbeek to talk about the benefits of using Travis CI for C++ developers and the role of C++ in theoretical biology. Richel Bilderbeek is a C++ developer for 17 years. He is mostly interested in what the literature has to say about good C++ practices, then teaching children and to adults, additionally writing articles, blog posts and tutorials. In his professional life, he is a PhD in theoretical biology. News Writing a Really, Really Fast JSON Parser C++ Online Compilers Looking for Proofreaders for my new Book: Concurrency with Modern C++ Richel Bilderbeek @rjcbilderbeek Richel Bilderbeek's GitHub Richel Bilderbeek's homepage Links Travis CI Travis CI Tutorial Science and Hi-Tech Day (Dutch) Sponsors Conan.io Hosts @robwirving @lefticus Better C++/Chicago
Get to know Mohamed Said in his first ever interview where we discuss how he got into programming, being Laravel's first ever employee, what it's like working with Taylor Otwell.
This episode, Jake and Michael speak about working with UUIDs in Laravel, Wordpress, and testing mindsets.
Eine Einführung in die kontinuierliche Integration – Continuous Integration – gibt es in der zweiundneunzigsten Episode des Anwendungsentwickler-Podcasts. Inhalt Voraussetzungen Völlig unabhängig von Programmiersprache oder Plattform. Theoretisch auch ohne separate Software umsetzbar, aber einfacher mit etablierten Lösungen wie Jenkins, Team Foundation Server, Travis CI, Teamcity oder CruiseControl. Alle Artefakte (Code, Oberflächen, Konfiguration usw.) müssen in... Der Beitrag Einführung in Continuous Integration – Anwendungsentwickler-Podcast #92 erschien zuerst auf IT-Berufe-Podcast.
In this episode I am joined by Ivan Nemytchenko from the open source company, GitLab. Here we take some time to explain what continuous integration and deployment is and how to get started with it in your development process. GitLab offers a free CI / CD solution called GitLab CI, but there are other solutions such as Jenkins and Travis CI as well. A writeup to this episode can be found via https://www.thepolyglotdeveloper.com/2016/11/tpdp-episode-11-continuous-integration-deployment-polyglot-developer/ If you have questions that you'd like answered in the next episode, visit https://www.thepolyglotdeveloper.com/podcast-questions and fill out the form.
This week on the show, we'll be talking to Petra about the NetBSD foundation, about how they operate and assist NetBSD behind the scenes. That plus lots of news This episode was brought to you by Headlines What is new on EC2 for FreeBSD 11.0-RELEASE (http://www.daemonology.net/blog/2016-10-03-FreeBSD-EC2-11-0-RELEASE.html) “FreeBSD 11.0-RELEASE is just around the corner, and it will be bringing a long list of new features and improvements — far too many for me to list here. I think there are some improvements in FreeBSD 11.0 which are particularly noteworthy for EC2 users.” “First, the EC2 Console Screenshot functionality now works with FreeBSD. This provides a "VGA" output as opposed to the traditional "serial port" which EC2 has exposed as "console output" for the past decade, and is useful largely because the "VGA" output becomes available immediately whereas the "serial port" output can lag by several minutes. This improvement is a simple configuration change — older releases didn't waste time writing to a non-serial console because it didn't go anywhere until Amazon added support on their side — and can be enabled on older FreeBSD releases by changing the line console="comconsole" to boot_multicons="YES" in /boot/loader.conf.” “The second notable change is support for EC2 "Enhanced Networking" using Intel 82599 hardware; on the C3, C4, R3, I2, D2, and M4 (excluding m4.16xlarge) families, this provides increased network throughput and reduced latency and jitter, since it allows FreeBSD to talk directly to the networking hardware rather than via a Xen paravirtual interface. Getting this working took much longer than I had hoped, but the final problem turned out not to be in FreeBSD at all — we were tickling an interrupt-routing bug in a version of Xen used in EC2. Unfortunately FreeBSD does not yet have support for the new "Elastic Network Adapter" enhanced networking used in P2 and X1 instance families and the m4.16xlarge instance type; I'm hoping that we'll have a driver for that before FreeBSD 11.1 arrives.” “The third notable change is an improvement in EC2 disk throughput. This comes thanks to enabling indirect segment I/Os in FreeBSD's blkfront driver; while the support was present in 10.3, I had it turned off by default due to performance anomalies on some EC2 instances. (Those EC2 performance problems have been resolved, and disk I/O performance in EC2 on FreeBSD 10.3 can now be safely improved by removing the line hw.xbd.xbdenableindirect="0" from /boot/loader.conf.)” “Finally, FreeBSD now supports all 128 CPUs in the x1.32xlarge instance type. This improvement comes thanks to two changes: The FreeBSD default kernel was modified in 2014 to support up to 256 CPUs (up from 64), but that resulted in a (fixed-size) section of preallocated memory being exhausted early in the boot process on systems with 92 or more CPUs; a few months ago I changed that value to tune automatically so that FreeBSD can now boot and not immediately panic with an out-of-the-box setup on such large systems.” “I think FreeBSD/EC2 users will be very happy with FreeBSD 11.0-RELEASE; but I'd like to end with an important reminder: No matter what you might see on FTP servers, in EC2, or available via freebsd-update, the new release has not been released until you see a GPG-signed email from the release engineer. This is not just a theoretical point: In my time as a FreeBSD developer I've seen multiple instances of last-minute release re-rolls happening due to problems being discovered very late, so the fact that you can see bits doesn't necessarily mean that they are ready to be downloaded. I hope you're looking forward to 11.0-RELEASE, but please be patient.” *** Upgrading Amazon EC2 instance from 10.3 to 11.0-PRERELEASE results in hang at boot (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213196) As if to underscore that last point, a last minute bug was found on sunday night A user reported that they used freebsd-update to upgrade an EC2 instance from 10.3 to 11.0 and it started hanging during boot After some quick investigation by Colin, the problem was reproduced Since I had done a lot of work in the loader recently, I helped Colin build a version of the loader with a lot of the debugging enabled, and some more added to try to isolate where in the loader the freeze was happening Colin and I worked late into the night, but eventually found the read from disk that was causing the hang Unlike most of the other reads, that were going into the heap, this read was into a very low memory address, right near the 640kb border. This initially distracted us from the real cause of the problem With more debugging added, it was determined that the problem was in the GELIBoot code, when reading the last sector of each partition to determine if it is encrypted. In cases where the partition is not 4k aligned, and butts up against the end of the disk, the formula used could result in a read past the end of the disk The formula rounds the last sector byte address down to the nearest factor of 4096, then reads 4096 bytes. Then that buffer is examined to determine if the partition is encrypted. If it is a 512b sector drive, the metadata will be in the last 512 bytes of that 4096 byte buffer. However, if the partition is not 4k aligned, the rounding will produce a value that is less than 4096 bytes from the end of the disk, and attempting to read 4096 bytes, will read past the end of the disk Normally this isn't that big of a problem, the BIOS will just return an error. The loader will retry up to three times, then give up and move on, continuing to boot normally. Some BIOSes are buggy, and will initiate their own retries, and the combination might result in a stall of up to 30 seconds for each attempt to read past the end of the disk But it seems that Amazon EC2 instances, (and possibly other virtual instances), will just hang in this case. This bug has existed for 6 months, but was not caught because almost all installations are 4k aligned thanks to changes made to the installer over the last few years, and most hardware continues to boot with no sign of a problem Even the EC2 snapshot images of 11.0 do not have the problem, as they use a newer disk layout that is 4k aligned by default now. The problem only seems to happen when older disk images are upgraded The fix has been committed and will be merged the the branches over the next few days An Errata notice will be issues, and the fix will be available via freebsd-update It is recommended that EC2 users, and anyone who wants to be especially cautious, wait until this errata notice goes out before attempting to upgrade from FreeBSD 10.3 to 11.0 You can determine if your partitions are 4k aligned by running ‘gpart show'. If there is free space after your last partition, you won't have any issues. *** OpenBSD 6.0 Limited Edition CD set (signed by developers) (http://undeadly.org/cgi?action=article&sid=20160929230557&mode=expanded) The first one went for .$4,200.00 (http://www.ebay.com/itm/-/331985953783) + Looking for your piece of OpenBSD history? At the recent g2k16 hackathon in Cambridge UK, 40 OpenBSD developers put pen to paper and signed 5 copies of the new 6.0 release. + Each of these will be auctioned off on ebay, with the proceeds to benefit the OpenBSD foundation. + The first auction has already ended, and CD set went for a whopping $4200! + The next set only has 2 days left, and currently stands at $3000! (http://www.ebay.com/itm/-/331990536246) + Get your bids in soon, these are VERY unique, the odds of getting the same 40 developers in a room together and signing a new .0 release may make this a once-in-a-lifetime opportunity. + Additionally, if you are just starting your OpenBSD collection, here's a nice image to make you envious: A nice collection of OpenBSD CD Sets (http://i.imgur.com/OrE0Gsa.png) [What typing ^D really does on Unix ](https://utcc.utoronto.ca/~cks/space/blog/unix/TypingEOFEffects) + How often have you used a ^D to generate an EOF? Do you really know what that does? + Chris Siebenmann has posted a look at this on his blog, which might not be what you think “Typing ^D causes the tty driver to immediately finish a read().” He continues on: Normally doing a read() from a terminal is line-buffered inside the tty driver; your program only wakes up when the tty driver sees the newline, at which point you get back the full line. (Note that this buffering is distinct from anything that your language's IO system may be doing.) Typing ^D causes the tty driver to stop waiting for a newline and immediately return from the read() with however much of the line has been accumulated to date. If you haven't typed anything on the line yet, there is nothing accumulated and the read() will return 0 bytes, which is conveniently the signal for end of file. If you have typed something the program will get it; because it doesn't have a trailing newline, the program's own line-buffering may take over and keep read()ing to get the rest of the line. (Other programs will immediately process the partial line with no buffering; cat is one example of this.) Once you've typed ^D on a partial line, that portion of the line is immutable because it's already been given to the program. Most Unixes won't let you backspace over such partial lines; effectively they become output, not input. (Note that modern shells are not good examples of this, because they don't do line-buffered input; to support command line editing, they switch terminal input into an uninterpreted mode. So they get the raw ^D and can do whatever they want with it, and they can let you edit as much of the pending line as they want.) Fascinating stuff, and interesting to see behind the curtain at exactly what's going on with your programs buffering and tty driver interaction. Interview - Petra Zeidler - spz@netbsd.org (mailto:spz@netbsd.org) NetBSD Foundation *** News Roundup Running FreeBSD in Travis-CI Thanks to KQEmu (http://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html) Travis-CI is the most popular testing framework on Github, but it doesn't support any of the BSDs This didn't discourage Even Rouault, who managed to run FreeBSD in KQEMU on the Linux instances provided by Travis-CI “Travis-CI has a free offer for software having public repository at GitHub. Travis-CI provides cloud instances running Linux or Mac OS X. To increase portability tests of GDAL, I wondered if it was somehow possible to run another operating system with Travis-CI, for example FreeBSD. A search lead me to this question (https://github.com/travis-ci/travis-ci/issues/1818) in their bug tracker but the outcome seems to be that it is not possible, nor in their medium or long term plans.” “One idea that came quickly to mind was to use the QEMU machine emulator that can simulate full machines, of several hardware architectures.” They found an existing image of FreeBSD 9.2 and configured the Travis job to download it and fire it up in QEMU. “Here we go: ./configure && make ! That works, but 50 minutes later (the maximum length of a Travis-CI job), our job is killed with perhaps only 10% of the GDAL code base being compiled. The reason is that we used the pure software emulation mode of QEMU that involves on-the-fly disassembling of the code to be run and re-assembling.” Travis-CI runs in Google Compute Engine, which does not allow nested virtualization, so hardware virtualization is not an option to speed up QEMU “Here comes the time for good old memories and a bit of software archeology. QEMU was started by Fabrice Bellard. If you didn't know his name yet, F. Bellard created FFMPEG and QEMU, holds a world record for the number of decimals of Pi computed on a COTS PC, has ported QEMU in JavaScript to run the Linux kernel in your browser, devised BPG, a new compression based on HEVC, etc....” “At the time where his interest was focused on QEMU, he created KQemu, a kernel module (for Linux, Windows, FreeBSD hosts), that could significantly enhance QEMU performance when the guest and hosts are x86/x86_64 and does not require (nor use) hardware virtualization instructions.” “Running it on Travis-CI was successful too, with the compilation being done in 20 minutes, so probably half of the speed of bare metal, which is good enough.” “I could also have potentially tried VirtualBox because, as mentioned above, it supports software virtualization with acceleration. But that is only for 32 bit guests (and I didn't find a ready-made FreeBSD 32bit image that you can directly ssh into). For 64 bit guests, VirtualBox require hardware virtualization to be available in the host. To the best of my knowledge, KQemu is (was) the only solution to enable acceleration of 64 bit guests without hardware requirements.” It will be interesting to see if enough people do this hack, maybe Travis-CI will consider properly supporting FreeBSD *** OpenBSD EuroBSDcon 2016 Papers are online (https://www.openbsd.org/events.html) Slides from the OpenBSD talks at EuroBSDCon are online now Landry Breuil, Building packages on exotic architectures (https://rhaalovely.net/~landry/eurobsdcon2016/) Peter Hessler, Bidirectional Forwarding Detection (BFD) implementation and support in OpenBSD (https://www.openbsd.org/papers/eurobsdcon2016-bfd.pdf) Ingo Schwarze, Why and how you ought to keep multibyte character support simple (https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf) (roff/mm/gpresent source code (https://www.openbsd.org/papers/eurobsdcon2016-utf8.roff)) Stefan Sperling, OpenBSD meets 802.11n (https://www.openbsd.org/papers/eurobsdcon2016-openbsd-11n.pdf) Antoine Jacoutot, OpenBSD rc.d(8) (https://www.bsdfrog.org/pub/events/openbsd-rcd-EuroBSDcon2016.pdf) Marc Espie, Retrofitting privsep into dpb and pkg_add (https://www.openbsd.org/papers/eurobsdcon2016-privsep.pdf) Martin Pieuchot, Embracing the BSD routing table (https://www.openbsd.org/papers/eurobsdcon2016-embracingbsdrt.pdf) I am working to build a similar website for the FreeBSD project, but there is still a lot of work to do I also managed to find the slides from the keynotes: Opening Keynote: George Neville-Neil: Looking Backwards: The coming decades of BSD (https://papers.freebsd.org/2016/EuroBSDCon/LookingBackwards.pdf) Closing Keynote: Gert Döring: Internet Attacks, Self-Governance, and the Consequences (http://www.monobsd.com/files/16_ddos_and_consequences.pptx) *** VirtualBox Shared Folders on FreeBSD: progress report (https://kernelnomicon.org/?p=650) In the past month or so, VirtualBox in the FreeBSD ports tree got bumped to version 5, which while bringing new features, did cause a regression in Shared Folders. FreeBSD developer gonzo@ (Oleksandr Tymoshenko) has been tackling this issue in recent days and provides us with a look behind the curtain at the challenges involved. Specifically he started by implementing the various needed VOPs: “lookup, access, readdir, read, getattr, readlink, remove, rmdir, symlink, close, create, open, write.” He then continues with details about how complete this is: ““Kind of implemented” means that I was able to mount directory, traverse it, read file, calculate md5 sums and compare with host's md5sum, create/remove directories, unzip zip file, etc but I doubt it would survive stress-test. Locking is all wrong at the moment and read/write VOPs allocate buffers for every operation.” The bigger issue faced is with the rename VOP though: I hit a roadblock with rename VOP: it involves some non-trivial locking logic and also there is a problem with cached paths. VBox hypervisor operates on full paths so we cache them in vboxfs nodes, but if one of parent directories is renamed, all cached names should be modified accordingly. I am going to tackle these two problems once I have long enough stretch of time time sit and concentrate on task. + We wish him luck in getting those issues solved. I know quite a few of our users rely on shared folders as well. FreeBSD News Issue #1 (http://support.rossw.net/FreeBSD-Issue1.pdf) Issue #1 of FreeBSD News, from summer of 1997 Contains an article by Yahoo! co-founder David Filo about their early use of FreeBSD, on 100mhz Pentium machines with 64MB of ram Java Development Kit 1.0.2 ported to FreeBSD What is FreeBSD? Running the world's busiest FTP site (cdrom.com) on FreeBSD Xi Graphics announces the release of CDE Business Desktop, the first and only integrated desktop for FreeBSD, on AcceleratedX, a fully supported commercial grade X display server Get FreeBSD 2.2.2 Today! *** Beastie Bits Call for testing: newly MPSAFE nvme(4) (http://mail-index.netbsd.org/current-users/2016/09/21/msg030183.html) Thinking about starting a BUG in Indianapolis, IN USA (http://lists.dragonflybsd.org/pipermail/users/2016-September/313061.html) The cost of forsaking C: Why students still need to learn C (https://medium.com/bradfield-cs/the-cost-of-forsaking-c-113986438784#.o2m5gv8y7) OpenBSD (U)EFI bootloader howto (https://blog.jasper.la/openbsd-uefi-bootloader-howto/) Michael Lucas sets his eyes on OpenBSD's web stack for his next book (http://blather.michaelwlucas.com/archives/2780) LibreSSL 2.5.0 released (http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.5.0-relnotes.txt) OPNsense 16.7.5 released (https://opnsense.org/opnsense-16-7-5-released/) Feedback/Questions Jonas - ZFS on DO (http://pastebin.com/XeJhK0AJ) Ricardo - OpenBSD Encrypted Disk (http://pastebin.com/Z9JRjcvb) WiskerTickle - Storage Benchmark (http://pastebin.com/XAD0UevP) Phil - Thanks (http://pastebin.com/N52JhYru) Luis - Misc Questions (http://pastebin.com/57qS0wrx) ***
Jake and Michael discuss starting a PHP meetup and becoming a speaker, the GitHub Universe, and GitLab's Master Plan.
In today's episode we're joined by Mathias Meyer to talk about Travis CI
Mathias Meyer, CEO of Travis CI, discusses with your cohosts Francesc and Mark what are Continuous Integration and Deployment, and how Travis CI makes them easy and accessible to all. Did you know Travis CI ran on Google Cloud Platform? About Mathias Mathias Meyer is the CEO and core member of the team running Travis CI, a hosted continuous integration and deployment platform, and the author of the Riak Handbook. His interests include coffee, photography, studies of human error and distributed systems. Cool thing of the week GitHub Making open source data more available blog post GitHub on BigQuery: Analyze all the code blog post All the open source code in GitHub now shared within BigQuery: Analyze all the code! medium Analyzing Go code with BigQuery medium Interview Travis CI homepage Continuous Integration wikipedia Extreme Programming: A Gentle Introduction page Free Travis CI for Open Source travis-ci.org Google Compute Engine to run builds docs Google Cloud Storage to cache images docs Travis the Tractor, from Bob the Builder. Question of the week Where do I go if I want to get involved with specific parts of the Kubernetes community? Kubernetes Special Interest Groups Correction Francesc will be in GopherCon next week, not this one. Clearly he doesn't know how calendars work.
This is a small episode. I'm changing the name from the "Python Test Podcast" to "Test & Code". I just want to discuss the reasons behind this change, and take a peek at what's coming up in the future for this podcast. Links The Waterfall Model and "Managing the Development of Large Software Systems" (http://testandcode.com/7) Josh Kalderimis from Travis CI (http://tesatandcode.com/14)
Check out and sign up for iOS Remote Conf! April 13-15th, 2016. 01:22 - Dominic Jodoin Introduction Twitter GitHub Blog 01:46 - Emma Trimble Introduction Twitter 02:03 - Travis CI Background and Origin @travisci Continuous Integration (CI) 06:27 - Travis CI vs Other CI Solutions CircleCI Jenkins 10:44 - Travis and Open Source Getting Set Up YAML 14:47 - iOS and Travis CI fastlane 16:04 - Testing and The Backend 21:17 - CocoaPods 22:41 - Support Swift 24:53 - Pricing and Cost 27:33 - GitHub Integration 29:27 - Setup and Tool Support Mercurial Picks Smoked Gouda Cheese (Jaim) Smooch (Dominic) Making voice calls in Slack (Emma) The Most Important Object In Computer Graphics History Is This Teapot (Andrew) Big John's Cajun Cheese (Andrew) 2016 Chocolate and Cheese Festival @ The Natural History Museum of Utah (Andrew)
Check out and sign up for iOS Remote Conf! April 13-15th, 2016. 01:22 - Dominic Jodoin Introduction Twitter GitHub Blog 01:46 - Emma Trimble Introduction Twitter 02:03 - Travis CI Background and Origin @travisci Continuous Integration (CI) 06:27 - Travis CI vs Other CI Solutions CircleCI Jenkins 10:44 - Travis and Open Source Getting Set Up YAML 14:47 - iOS and Travis CI fastlane 16:04 - Testing and The Backend 21:17 - CocoaPods 22:41 - Support Swift 24:53 - Pricing and Cost 27:33 - GitHub Integration 29:27 - Setup and Tool Support Mercurial Picks Smoked Gouda Cheese (Jaim) Smooch (Dominic) Making voice calls in Slack (Emma) The Most Important Object In Computer Graphics History Is This Teapot (Andrew) Big John's Cajun Cheese (Andrew) 2016 Chocolate and Cheese Festival @ The Natural History Museum of Utah (Andrew)
Interview with Josh Kalderimis from Travis CI. Josh is a co-founder and Chief Post-It Officer at Travis CI. Topics What is Continuous Integration, CI What is Travis CI Some history of the company travis-ci.org vs travis-ci.com and merging the two Enterprise and the importance of security Feature questions Travis vs Jenkins Travis notification through Slack Reporting history of Travis results Dealing with pytest results status other than pass/fail Capturing std out and stderr logging from tests Build artifacts Tox and Travis Using Selenium What does a Chief Post-It Officer do Differentiation between Travis and other CI options Using Slack to keep remote teams communicating well Travis team Funding open source projects Travis Foundation Rails Girls Summer of Code Open source grants Mustaches and beards Shite shirts New Zealand What does Team Periwinkle do Links Jeff Knupp's Open Sourcing a Python Project the Right Way (https://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/) Sven's blog post when Travis started (http://svenfuchs.com/2011/2/5/travis-a-distributed-build-server-tool-for-the-ruby-community) Sven's mustache and Josh's beard (https://travis-ci.com/about) Travis CI for open source (http://travis-ci.org) Travis CI for private repositories and enterprise (http://travis-ci.com) Slack (https://slack.com/) Travis Foundation (http://foundation.travis-ci.org/) Rails Girls Summer of Code (http://railsgirlssummerofcode.org/) Talk Python to Me Podcast (https://talkpython.fm/episodes/show/45/the-python-testing-column-now-a-thing)
01:02 - Felix Krause Twitter GitHub Blog 01:17 - Fastlane 01:37 - The Background and Motivation of Fastlane 03:19 - Fastlane as a Collection of Tools 04:06 - Plugin Architecture 05:08 - Language = Ruby 06:29 - Nomad 08:32 - What do these tools help with? snapshot deliver 12:23 - Using Fastlane for Continuous Integration Jenkins CI Travis CI CircleCI Bitrise scan Xcode Server 14:17 - Fastlane Growth and Community 17:14 - Contribution 20:29 - Integrating and Using Tools in Workflows 26:10 - Keeping Up with Changes 27:00 - Twitter + Fastlane 29:34 - Support and Community (Cont’d) 32:12 - Getting Started Felix Krause: iOS Continuous Delivery with Fastlane @ CocoaHeads Stockholm 33:10 - Difficulties and Gotchas Code Signing sigh 34:23 - Naming Tools Picks Swift Sandbox (Andrew) Chris McVeigh (Andrew) Brine your turkey (Jaim) Tower (Felix) what-terminal-is-felix-using (Felix) Google Flights (Felix)
01:02 - Felix Krause Twitter GitHub Blog 01:17 - Fastlane 01:37 - The Background and Motivation of Fastlane 03:19 - Fastlane as a Collection of Tools 04:06 - Plugin Architecture 05:08 - Language = Ruby 06:29 - Nomad 08:32 - What do these tools help with? snapshot deliver 12:23 - Using Fastlane for Continuous Integration Jenkins CI Travis CI CircleCI Bitrise scan Xcode Server 14:17 - Fastlane Growth and Community 17:14 - Contribution 20:29 - Integrating and Using Tools in Workflows 26:10 - Keeping Up with Changes 27:00 - Twitter + Fastlane 29:34 - Support and Community (Cont’d) 32:12 - Getting Started Felix Krause: iOS Continuous Delivery with Fastlane @ CocoaHeads Stockholm 33:10 - Difficulties and Gotchas Code Signing sigh 34:23 - Naming Tools Picks Swift Sandbox (Andrew) Chris McVeigh (Andrew) Brine your turkey (Jaim) Tower (Felix) what-terminal-is-felix-using (Felix) Google Flights (Felix)
01:12 - MIKMIDI The iPhreaks Show Episode #57: MIDI 02:17 - Adding Features or Changing the Way a Library Works in an Open Source Projects 04:49 - Deprecation 07:23 - Deprecation vs Replacing 09:37 - Semantic Versioning 15:14 - What is a breaking change? 17:51 - Choosing Issues and Bugs to Tackle; How long should it take? 24:31 - Maintainer Responsibility 26:33 - Being a Good Contributor; Documentation & Examples Contributor Covenant 31:01 - Using Badges 32:12 - How Travis CI Integrates with an Open Source Project ClangFormat 35:22 - Hosting for Open Source Projects GitHub Bitbucket Kiln 36:37 - Generated Documentation CocoaPods CocoaDocs Dash 39:07 - Licensing The MIT License The Apache License GPL License AGPL License 40:56 - What’s changed in MIKMIDI? (Since Episode #57) Picks The Big Star Story (Jaim) Searching for Sugar Man (Andrew) Erica Sadun: A handful of Swift style rules #swiftlang (Andrew) appledoc (Andrew) jazzy (Andrew) Toastmasters (Chuck)
01:12 - MIKMIDI The iPhreaks Show Episode #57: MIDI 02:17 - Adding Features or Changing the Way a Library Works in an Open Source Projects 04:49 - Deprecation 07:23 - Deprecation vs Replacing 09:37 - Semantic Versioning 15:14 - What is a breaking change? 17:51 - Choosing Issues and Bugs to Tackle; How long should it take? 24:31 - Maintainer Responsibility 26:33 - Being a Good Contributor; Documentation & Examples Contributor Covenant 31:01 - Using Badges 32:12 - How Travis CI Integrates with an Open Source Project ClangFormat 35:22 - Hosting for Open Source Projects GitHub Bitbucket Kiln 36:37 - Generated Documentation CocoaPods CocoaDocs Dash 39:07 - Licensing The MIT License The Apache License GPL License AGPL License 40:56 - What’s changed in MIKMIDI? (Since Episode #57) Picks The Big Star Story (Jaim) Searching for Sugar Man (Andrew) Erica Sadun: A handful of Swift style rules #swiftlang (Andrew) appledoc (Andrew) jazzy (Andrew) Toastmasters (Chuck)
Спонсор выпуска — Vexor CI – облачный continuous integration сервис для ruby разработчиков с поминутной оплатой. С учетом поминутной оплаты, Vexor очень выгоден для маленьких проектов и эффективен для больших. Каждому новому пользователю предоставляется $10 на счет для экспериментов. Попробовать Vexor CI Расшифровки Коллекция рецептов для быстрого руби от Эрика. Интервью с Эриком Кир Первый раз в Москве? Эрик Ага, да. Кир И как тебе Москва, что думаешь о городе? Эрик Очень красивый город. Первый раз тут, и мне все очень нравится. Погода хорошая; вчера гуляли, были в музее космонавтики и в музее холодной войны — было здорово. Кир Круто. Эрик Ага. Кир Так вот. Ты работаешь в SoundCloud, в Берлине? Эрик Да! Кир Можешь рассказать об архитектуре SoundCloud? Эрик Так, в SoundCloud мы используем архитектуру микросервисов. Я работаю в команде, которая занимается платформой, проще говоря — серверным API. Публичный API — который используется, если использовать SoundCloud API — там запросы обрабатываются Rails приложением. Но вот как мы работаем.. Как только у нас появляются новые сервисы, и есть смысл их как-то отделить от основного, сделать их отдельным сервисом — мы так и делаем. В общем, мы используем Ruby, Rails, еще довольно много используем Scala, Clojure; все наши утилиты командной строки написаны на Go. Да, у нас даже сервисы на Julia есть. Все зависит от того, что лучше подойдет для задачи, которую мы пытаемся решить. Кир Интересно. То есть, как я понимаю, вы мигрировали с монолитного Rails приложения, да? Эрик Да! Думаю, многие компании, когда они развиваются и начинают масштабироваться, переходят с такой монолитной архитектуры приложения на архитектуру микросервисов. И да, мы довольно далеко в этом деле продвинулись. Кир Ясно. Давай поговорим про open source, над которым ты работал — какой проект твой любимый? Эрик Ох, их много — сложно выбрать. Не знаю, некоторые обертки над API, над которыми я работал — таких было несколько.. Я сделал octokit, обертку над API GitHub; еще обертку над API RubyGems.org, чтобы можно было доставать метаданные о gem'ах. Ну и, наверное, самая популярная обертка, которую я сделал — gem twitter. Да и gem soundcloud, я его сейчас поддерживаю, но автором был не я. Да, думаю, решать проблемы такого рода, причем несколько раз для разных сервисов, стало таким неплохим шаблоном, так что я горжусь теми gem'ами. Думаю, приемы работы над кодом, которые я использовал там, приводят к коду довольно чистому, хорошо покрытому тестами, и все такое. И, знаешь, наверное самый популярный мой gem — это rails_admin, там код и близко не такой чистый, так что для меня над ним не так приятно работать по этой причине. Каждый раз, когда с ним работаю, всегда нахожу какие-то вещи, которые стоит зарефакторить; но раз уж столько людей его используют, просто приятно было сделать что-то такое — люди постоянно ко мне подходят, благодарят. Так что им приятно заниматься по другой причине — не из-за красоты кода, а из-за пользы, которую он дает. Кир Понятно. А что вообще помогает тебе работать над новыми open source проектами? Эрик Ну, думаю, как и у всех — главная причина, наверное, в том, что когда я использую какой-то проект и нахожу баг, я вкладываюсь в проект просто чтобы пофиксить этот самый баг, или просто в какой-то степени этот проект улучшить. Иногда я начинаю проекты только затем, чтобы чему-то научиться — попробовать в деле новый фреймворк или новый язык; да, в общем, получается такое игрушечное приложение или игрушечная библиотека, и тогда нет причин не выпустить этот код как open source, чтобы другие люди могли учиться так же, как учился я, или научиться чему-то на моих ошибках. Да я и сам учусь на своих ошибках, потому что когда ты выпускаешь что-то как open source, другие люди видят твою работу, присылают пулл-реквесты, чтобы ее улучшить, и каждый раз, когда это происходит — это возможность мне чему-то научиться; другие же люди это увидят и тоже сделают какие-то выводы для себя. Кир Точняк. Ты упомянул, что в SoundCloud используется много разных языков, так вот, есть у тебя какой-то open source не на Ruby? Эрик Да, у нас есть. Кир Scala, Clojure? Эрик Да-да. Посмотри на https://github.com/soundcloud, думаю, у нас там больше сотни публичных репозиториев. И да, там есть проекты на Ruby, наш самый популярный — Large Hadron Migrator, LAM (https://github.com/soundcloud/lhm). Там идея в том, что если у тебя есть действительно здоровенная база данных (MySQL — прим. пер.), и тебе нужно сделать миграцию, с помощью этого проекта можно это сделать без даунтайма. Если на пальцах, он работает вот так: копирует таблицу, прогоняет миграцию на копии, потом на копию переносит все данные, которые скопились с момента начала миграции. Довольно эффективный способ делать миграции в БД. Нам этот проект был реально нужен, у нас были очень большие таблицы в MySQL, на которых нужно было делать миграции, а если мы делали обычные миграции, мы могли попасть на несколько часов даунтайма. Так что мы сделали такой вот инструмент. Другие компании, у которых тоже было много строк в таблицах их баз данных, большие таблицы, и нужно было делать миграции над ними, тоже оценили наше решение. Кир На каком это языке? Эрик На Ruby. Так что да, это в основном для миграций с Rails. Но у нас.. Если посмотреть на https://github.com/soundcloud, у нас есть репозитории почти на всех языках, что можно представить — Ruby, Clojure, Scala, Go.. Как я уже говорил, у нас есть код на Julia, думаю, мы его тоже выложили. Да, ну и на других языках. В SoundCloud мы гордимся тем, что всегда используем лучший инструмент для каждой конкретной задачи, а инженеры принимают решения основываясь на том, что по их мнению лучше всего использовать. Так что если давать инженерам автономию для принятия решений, последуют лучшие решения, чем если в компании просто есть правила — «использовать один язык для всего», или «использовать этот фреймворк для всего». И даже внутри нашей организации, мы иногда используем Rails, иногда Sinatra или другие фреймворки. Это действительно зависит только от характера проблемы, которую мы пытаемся решить. Кир Какое будущее у Ruby, по твоему мнению? Эрик Хм. Хороший вопрос. Надеюсь, что будущее будет таким же, как и прошлое — за последнее время каждый год выходит новая версия Ruby, и каждый раз она быстрее и лучше предыдущей. Так что да, надеюсь, такое продолжится в будущих версиях. Что я действительно хотел бы видеть (я упомянул об этом в своем докладе), так это JIT компилятор в MRI (CRuby). Кажется, над этим уже работают, так что я настроен оптимистично — думаю, скоро мы это увидим. Так же, как и AOT компилятор. Я еще работаю над парой интерфейсов для командной строки; Ruby не очень хорош для работы с командной строкой, потому что время запуска может быть большим, а вот если был бы компилятор, который бы предварительно парсил весь Ruby код в бинарник, было бы круто — особенно для штук вроде CLI (Command-Line Interface — прим. пер.). Так что вот, JIT и AOT компиляторы. И еще получше примитивы для параллелизма. Матц говорил, что он сожалеет о решении использовать Thread как главный примитив для параллелизма в Ruby, так что он вместе с Core Team думает над использованием actors, и может каких-то еще примитивов. Чтобы они появились в core библиотеках языка. Так что я этого очень жду, думаю, будет круто. Кир Да, я заметил тренд с переписыванием инструментов командной строки на Go. Эрик Да, точно. Кир Вот Heroku так делает. Эрик Да, это хороший пример. Их CLI для выполнения разных команд, раньше был на Ruby, но, вообще, думаю, он намного лучше стал на Go, по ряду причин. Во-первых, у Go весь runtime включен в бинарник, так что нет такой зависимости, как Ruby — не надо сначала устанавливать Ruby, а потом уже CLI. Можно просто установить бинарник, в котором все уже есть. Ну и то еще, что можно кросс-компилировать сразу на несколько разных платформ, делает разработку инструментов для командной строки намного проще. И вообще тот факт, что Go — язык компилируемый, означает, что никакой подготовки кода во время запуска нет, как в Ruby. Так что если есть, скажем, 30 библиотек, от которых зависит инструмент, то в Ruby даже для самой простой операции сначала нужно пропарсить все эти библиотеки, а это может занять много времени, особенно если нужно выполнить какую-то простую команду — такую, как help, version или что-то такое, и во многих CLI на Ruby это работает куда медленнее, чем должно бы. Так что AOT компилятор существенно этому поможет, Ruby сможет составить конкуренцию языкам вроде Go в борьбе за CLI. Кир Давай поговорим о Берлине. Эрик Ага. Кир Что ты думаешь о стартап-культуре, об атмосфере? Эрик Очень хорошая. Я переехал в Берлин из Сан-Франциско, где я до этого прожил 8 лет. И в Сан-Франциско чувствуется такое отношение, словно это единственное место в мире, где можно сделать стартап, и что если тебе нужно сделать стартап, то нужно переехать в Сан-Франциско, если хочешь добиться успеха. Это сработало для многих компаний, но в SoundCloud нам этого делать не пришлось. Есть много преимуществ работы в Берлине. Главное преимущество — мы можем нанимать талантливых людей со всей Европы, да и со всего мира, вообще говоря. У нас отличный офис, где есть разработчики из.. кажется, 35 разных стран, или вроде того. Думаю, эмиграционные законы США делают такое куда более сложным. У меня был такой скепсис, когда я переезжал из Сан-Франциско, но.. Мои коллеги — невероятно талантливые люди, я каждый день у них чему-то учусь. Да, Берлин — отличное место для работы. И стартап сцена — не только SoundCloud, у нас куча других стартапов! От самых маленьких, где пара человек работают над какой-то идеей, до людей, которые уже подняли венчурный капитал и теперь быстро растут. Да и просто классное сообщество и отношение. Митапы каждую неделю, наверное, даже каждый день — можно ходить на разные технарские митапы в Берлине. И вот что еще круто в Берлине: классное сообщество для тех, кто хочет учиться. То есть, если вы хотите научиться программированию, или если вы пока юниор, и вы ищете возможность подкачаться, Берлин — отличное для этого место. Вот Rails Girls начинались не в Берлине, но благодаря Travis CI, да, там много классных людей — Свен (Sven Fuchs — прим. пер.), Аника (Anika Lindtner — прим. пер.), да и вся команда — Джош (Josh Kalderimis — прим. пер.), Константин (Konstantin Haase — прим. пер.)… Такое комьюнити они создали! Меня пригласили выступить на Eurucamp пару лет назад — тогда я в первый раз оказался в Берлине, еще до того, как я туда переехал. Перед конференцией я побыл коучем на Rails Girls, и это был первый раз, когда я помогал на Rails Girls, и было круто. Но, думаю, Rails Girls проводятся в Берлине уже очень давно, теперь и Summer of Code проводится оттуда. Есть целые четыре разные команды Summer of Code, которые расположены в Берлине. Так что вот, это отличное место для того, чтобы научиться программированию и прокачаться. Кир Все, спасибо большое! Эрик Да, конечно. Спасибо за вопросы! Интервью с Божидаром Ярослав Привет, Божидар! Как тебе Москва? Божидар Все здорово. Фантастический город, счастлив, что я здесь и что меня пригласили. Это мой первый визит в Россию, для меня все в новинку и очень увлекательно. У вас прекрасный город, прекрасная страна. Ярослав Первый вопрос будет про Rubocop. Многие из наших ребят знают о gem parser нашей местной знаменитости, Петра (Зотова — прим. пер), который, кстати, выступал в прошлом году на этой самой конференции. Можешь рассказать немного о том, как parser и Rubocop работают вместе? Божидар Да, конечно. Когда я начал работать над Rubocop, я использовал Ripper, внутренний парсер MRI, у которого есть две фундаментальные проблемы: во-первых, он работает только с MRI, что сделало бы Rubocop несовместимым с JRuby и Rubinius. Во-вторых, он генерит ужасный AST. Я пытался отправить несколько багфиксов в Ripper, но стало понятно, что это ни к чему не приведет. В одном из сообщений об ошибке, которое я открыл на официальном багтрекере Ruby, кто-то упомянул, что мне лучше бы не использовать Ripper вообще, потому что есть новая библиотека под названием parser от Петра. Я ее посмотрел, она работала замечательно, выдавала отличный формат AST, в общем, делала ровно то, что нужно. Была переносимой, правда очень глючной, но я намеревался работать с ней, несмотря на это. В основном из-за Петра, отличного мейнтейнера. Я зарепортил, наверное, около 50 багов, или вроде того. И он обычно отвечал в течение пары часов. После того, как вышла первая версия Rubycop с использованием parser, обнаружилось еще больше багов — пользователи умудрялись писать такой Ruby код, что мы даже не знали о том, что так можно написать. Но в течение следующих релизов Петр все исправил, и я уверен, что это лучшая библиотека из тех, что существуют. Производительность отличная, почти так же быстро, как и с Ripper, но выдаются структуры данных намного проще, с этим намного приятнее работать. Если мне бы пришлось работать с Ripper, я бы, наверное, забросил Rubocop. Ярослав Мы говорим о Ripper, но ведь еще есть gem.. как его.. Божидар ruby_parser? Ярослав Да, ruby_parser. Божидар Да, проблема с ruby_parser была в том, что его не мейнтейнили особенно. Думаю, Петр изначально хотел улучшить ruby_parser (так и было — прим. пер.); он был совместим с Ruby 1.8, но не обновлялся для 1.9. Я видел от него несколько пулл-реквестов, но ребята, которые мейнтейнили ruby_parser, сказали, что изменения слишком сложные, или что-то в этом духе, и что они не будут их применять. Думаю, это и было мотивацией для Петра сделать новый gem. И еще дело было в том, что ruby_parser не был так производителен, как parser, так что при работе с огромными проектами это могло стать проблемой — можно было ждать целый час, пока идет анализ кода. Ярослав Ага. Следующий вопрос про твою самую известную работу — Ruby Guide. Можешь рассказать о процессе, о том как ты работаешь над ним? У тебя просто появился набор каких-то правил, ты сделал первый коммит и потом ты начал их обновлять? Как ты итерируешь, как обновляешь эти правила? Думаешь ли ты, что многие из них обязательные, или какие-то нет? В общем, твой Ruby Style Guide и Rails Style Guide не высечены в камне, они обновляются, так что хочется послушать про процесс. Например, как ты их валидируешь. Божидар Ну, обычно я делаю что-то, что называю проверкой толпой (Crowd Validation). Я добавляю правила иногда, когда натыкаюсь на хорошие идиомы в книгах, докладах; встречаю что-то, чего я раньше не замечал. Если я делаю правки и они не вызывают существенной негативной реакции в сообществе, значит, это и правда хорошая рекомендация. Если я что-то добавляю и все начинают на это жаловаться, значит, я сделал ошибку. Если мнения разделяются, мы начинаем вдаваться в детали. Например, мы делаем поиск по ruby-исходникам на GitHub, и если мы видим, что недавно добавленное или предложенное правило имеет смысл, если большинство отобранных проектов используют это правило, иначе мы его убираем, или правим существующее правило. Это уже много раз случалось. Но, в конце концов, кто-то должен проталкивать эти правила — обычно это не только я; можно видеть, что довольно много людей предлагают новые правила. Но я всегда стараюсь делать проверку, чтобы быть уверенным, что мы не предлагаем что-то, что нарушает сложившиеся практики. Так что если что-то звучит как хорошая идея, но никто ее не придерживается, мы не будем ее рекомендовать. Мы не хотим заставлять кого-то следовать стилю, который не принимается, не является естественным для Ruby сообщества. Ярослав Ясно. А ты начал с своего собственного набора правил, или ты использовал другие источники для вдохновления? Божидар Я начал с правил, которые я собрал из моих любимых книг по Ruby. В основном.. Моя любимая книга по Ruby — это, наверное, “The Ruby Programming Language”.. Ярослав Pickaxe? Божидар Не-не. Это “Programming Ruby”. Ярослав А, другая. Божидар Да. Так вот, я начал с советов из «Библии», то есть, единственной книжки, написанной самим Матцем, по крайней мере, частично. Я детально сверил стиль, который он использует, со стилем, который используется в Pickaxe. Были некоторые различия в верстке кода, например, Матц не использовал столько пустого места, отбивок, как использовал Дейв Томас, а я люблю читаемый код. Так что я взял у Дейва стиль для таких случаев. После этого, я начал добавлять вещи из “Eloquent Ruby”, “The Ruby Way” — книг, которые я считаю каноническими для сообщества. Так что начинал я оттуда, а после первого публичного релиза гайда, я получил массу отзывов — часто с приложенным анализом использования из поиска по GitHub, о котором я уже говорил. Например, все книги утверждали, что стоит избегать использования тернарного оператора, а использовать вместо него if/then/else в одну строку, но оказалось, что ни в одном Ruby проекте такого нет, наоборот, все используют тернарный оператор. Да, так что если люди хотят писать код так, кто я такой, чтобы им запрещать. Так что мы изменили это правило, да и другие правила тоже подверглись изменениям с изначальной версии. Мы обновляем правила все время. Например, когда все начиналось, еще не было Ruby 2.0 и 2.1, так что не было правил о аргументах-ключсловах (keyword arguments), использованию private на той же строке, что и определение метода, потому что это не имело смысла. Но гайд постоянно развивается, и, думаю, чем больше проходит времени, тем больше мы приближаемся к настоящей душе Ruby-стиля. Ярослав Я спрашивал, потому что еще до того, как я увидел твой гайд, был гайд от Кристиана, автора Rack (https://github.com/chneukirchen/styleguide — прим. пер.). Видел его? Божидар Да, видел. Ярослав Я его использовал неоднократно для обучения внутри команды, и только потом увидел твой гайд, который намного больше и подробнее. Божидар Да, я проводил поиски по гайдам. Я видел этот, видел веб-страницу, не помню URL, что-то от zenspider, наверное. Я видел три ресурса, но во всех отсутствовали примеры. Были правила, но без объяснений о том, почему это вообще хорошая идея. Некоторые правила были явно в противоречии с устоявшимися практиками. Это все были попытки, предпринятые одним человеком, больше похожие на личный набор правил. Вместо чего-то, что могло бы использоваться всеми, что и было моей целью. Потому что изначально я занимался документом по заказу компании. И мой проект случайно стал популярным. Ярослав Еще что хочу спросить о твоих гайдах. В каком-то смысле использование гайда по стилю — это как принятие методологии разработки ПО, методологии гибкой разработки ПО, например. Это много как можно сделать — кто-то делает все в точности по правилам, по книге, кто-то начинает использовать некоторые вещи и модифицирует их потом, и получается его собственная методология, и все такое. То есть, одни люди пишут книги, а другие люди просто используют их, как им заблагорассудится. Так как ты думаешь, как лучше всего применять твой гайд, или, может быть, как ты сам его применяешь на своих проектах, когда работаешь консультантом? Ты заставляешь людей ему следовать, или это процесс, шаг за шагом? Божидар Ну, обычно на моих проектах, Ruby Style Guide в его чистой форме дается как правило. Но это правило лишь до какой-то степени; некоторые правила абсолютны — например, не нужно мешать метод и его алиас в проекте, нужно выбрать одно название и использовать его везде. Правила про отступы тоже абсолютны, но, с другой стороны, у нас есть вещи вроде правил по метрикам: короткие методы, короткие классы, и вот они иногда довольно субъективны, нужно идти на нарушение правил: как ни старайся, иногда нельзя раздробить какую-то задачу на больше частей, чем ты уже сделал. Есть точка, после которой попытки упростить что-то просто вредны: больше это не оптимизация, ты уже делаешь код сложнее. Так что.. Есть другие такие правила, которые не следует применять вслепую.. Нужно думать. Я всегда говорю людям: это не десять заповедей, ниспосланные нам свыше. Многие из них — крайне разумные практики, и ничего плохого от их применения не случится, но нужно знать, когда их нарушать, и нужно знать, почему они были хорошей идеей изначально. Не нужно их нарушать, если нет четкой причины это делать. Ярослав Еще вопрос. Посмотрел на твой профиль на GitHub, и оказывается, что ты интересуешься Clojure. Божидар Да-а-а. Ярослав И у тебя даже гайд по стилю для Clojure есть. Не знал раньше. Так вот, в Ruby сообществе много разговоров идет.. В общем, на каждой Ruby конференции по крайней мере в России есть много людей, которым вообще не интересно разговаривать про Ruby, они хотят говорить про Clojure, Scala, функциональные языки, Elixir тоже популярная тема. Так вот, почему именно Clojure? Божидар Ну.. По той же причине, по которой я изначально выбрал Ruby. Я был очарован простотой и мощью языков из семейства Lisp. Когда я был начинающим программистом, я немного писал на Common Lisp. И потом я наткнулся на Ruby, и, хотя он не был Lisp'ом, очевидно, но в нем было много наследия Lisp. И это был язык, для работы на котором я хотя бы нашел людей, готовых мне заплатить. Rails был на волне, все хотели разрабатывать на Rails, веб. Это был хороший компромисс. Но сейчас есть Clojure, настоящий Lisp, со всей мощью, без ограничений Ruby. Все говорят о проблемах с производительностью Ruby, но, думаю, что есть ряд проблем, для которых объектно-ориентированный подход становится «бутылочным горлышком» в архитектуре. Ты сказал об Elixir, еще одном не-ООП языке, который недавно стал набирать популярность. Люди делают на нем классные вещи. Haskell становится популярным после того, как существовал уже 20 лет. Ярослав Да, но есть много людей, которые называют его академическим языком — в противовес Erlang и Clojure. Божидар Ну да, но нельзя отрицать и то, что количество open source проектов, использующих Haskell, выросло в 4 раза за последние пару лет. Не думаю, что люди занимаются на Haskell только исследованиями. Люди используют его для реальной, полезной работы. Есть известные веб-фреймворки для Haskell, его точно используют для решения реальных проблем, а не вычисления чисел Фибоначчи. Так что думаю, что с тем, как мультиядерность становятся нормой, языки, которые могут масштабироваться, языки, на которых можно строить распределенные системы, будут становиться все более и более популярными. А Ruby придется развиваться быстрее, или он потеряет в популярности. То, о чем ты говоришь — что люди на Ruby-конференциях здесь не хотят говорить о Ruby — это не случайность. Если посмотреть на Ruby-конференции в Штатах, например — всегда есть доклады об альтернативных языках. На последней конференции был доклад по Elixir, перед этим Рич Хики собственной персоной докладывался по Clojure на RubyConf (думаю, речь идет о RailsConf'2012 — прим. пер.), а это что-нибудь да значит. И еще нам нужно иметь в виду, что многие известные рубисты забросили Ruby и стали работать на других языках. Например, Аарон говорил о Хосе Валиме.. Ярослав С которого и начался Elixir, ага. Божидар Да. Я почти уверен, что ему Ruby уже не интересен — да, его компания известна среди рубистов, он все еще мейнтейнер Rails и сопутствующих проектов, что нужно для клиентов, но его настоящая страсть — Elixir. Он об этом сам несколько раз говорил. Был еще известный рубист, Фил Хагельберг (@technomancy — прим. пер.), сейчас он один из самых известных кложуристов. Ярослав Да, но он всегда был поклонником Emacs, и поклонником Lisp. Он был главным источником всего, что в Emacs было связано с Ruby. Все люди, которые начинали с Lisp в университете или школе, которые хакали на Emacs долгое время.. У них теперь время возмездия. Божидар Да, но думаю, что Ruby-программистов привлекает мощь всех этих новых альтернативных языков. Думаю, некоторые из хороших идей этих функциональных языков рано или поздно окажутся в Ruby. Я говорил об идее сделать строки иммутабельными, не уверен, как это можно сделать, учитывая что весь код, который зависит от строк, мутабелен, но люди говорят о персистентных структурах данных в Ruby. Матц говорил, что главная фича в Ruby 3.0 — фреймворк для параллелизма, видимо, похожий на actors. Весь мир ПО движется в этом направлении; нельзя отрицать и то, что нельзя бесконечно делать веб-приложения. Ландшафт рынка веб-приложений существенно изменился. Rails стал популярным, когда все веб-сайты были довольно стандартными. Была довольно статичная прослойка для представления, довольно простые модели. И сейчас все дошло до клиентских приложений, когда весь твой фронтенд — это отдельное приложение, а твое Rails-приложение — просто JSON-сервер. И ты начинаешь спрашивать себя — а нужен ли мне Rails только для JSON сервера? Почему бы мне не сделать приложение на чем-то высокопроизводительном — Java, Erlang? Потому что если избавиться от тесной интеграции представлений-моделей в Rails, его ценность резко уменьшается. Думаю, что мир ПО изменяется очень быстро, и сообщество Ruby и Rails должно реагировать мгновенно, или сгинет в геенне огненной. Как и много других классных технологий. Ярослав Депрессивно, но справедливо. Еще вопрос, чтобы не очень долго тебя задерживать. Очевидно, написание правильного Ruby — очень важная тема в эти дни. Ruby вырос, люди должны перестать делать отстойные приложения, чтобы их было проще поддерживать. Один из докладчиков на этой конференции — удаленный докладчик, правда — Сэнди Метц, она тоже рассказывает о способе писать на Ruby правильно, но она делает это с помощью книги. Вот. А у тебя есть гайд, с пятью тысячами вотчеров, кажется, на GitHub, огромное число, я точно не помню, но это все-таки open source проект, у него есть URL, надо ему поставить звездочку. Так вот, есть планы написать книгу? Божидар Да, я об этом говорил на докладе. Я запланировал написать книгу, но потом я стал мейнтейнером Cider, это IDE для Clojure, очень популярная. Пришлось много с этим работать, и это выкачало из меня все силы, которые я откладывал на Rubocop, Ruby Style Guide, Rails Style Guide, и вообще на все связанные с Ruby проекты, потому что очень уж я вдохновлен Clojure. Но моя работа с Cider сейчас в таком состоянии, что я ей более или менее доволен, так что я думаю, что продолжу там, где я остановился. И сделаю маленькую книгу, очень маленькую книгу. Но, думаю, будет здорово, если у всех правил будут описания побольше, примеры подлиннее. В Styleguide я этого сделать не могу — это как README длиной в 50 страниц, это было бы странно. Но, думаю, небольшая книга будет полезна многим. Ярослав Ну что же, удачи в написании книги. Спасибо, что зашел! Божидар Вам спасибо. Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.
With everyone returning from Midwest.JS and Steel City Ruby, we reminisce about the conferences, complain about the post office, and debate what Devops is. Midwest.JS 0:15 Steel City Ruby 2:09 Dev>Input 3:50 Stamps.com 4:13 CodeClimate 4:43 Seth Vargo's talks 8:08 Jessica Kerr: Property-based testing: what is it? 8:37 Rantly 9:38 Generatron 10:03 DevOps 10:18 Chef 15:00 Why You Shouldn’t Use Vagrant: Real talk from a Vagrant burn-out 16:30 Test-Kitchen 19:10 Travis CI 20:26 Heroku 22:55 OpenShift 22:55 Continuously deploying your (free) OpenShift site with Travis CI 26:03 What Exactly is DevOps? 29:09
Ende 2008 wurde der Grundstein für die Software MapProxy gelegt. Im März 2010 wurde MapProxy dann von den Entwicklern im Rahmen der FOSSGIS-Konferenz in Osnabrück als Open-Source-Software veröffentlicht. Der Vortrag beleuchtet die kleine Erfolgsgeschichte der Open-Source-Geo-Komponente MapProxy: Was war Ausgangspunkt und Grundidee hinter dem MapProxy und welchen Funktionsumfang hat MapProxy mittlerweile erreicht? In kleinen Beispielen wird auf wiederkehrende Probleme eingegangen die mit MapProxy gelöst werden können. Dabei wird auch auf die neuen und erweiterteren MapProxy Hilfswerkzeuge eingegangen. Diese bieten dem Benutzer die Möglichkeit MapProxy noch schneller und einfacher zu konfigurieren. Zusätzlich zum Funktionsumfang zeigt der Vortrag auch einen kleinen Blick hinter die Kulissen vom MapProxy Projekt. Neben dem eigentlichen Quellcode der Software gehört noch mehr zu einer Infrastruktur (z.B. Travis-CI) um eine Software erfolgreich ausliefern zu können. Abschließend wirft der Vortragende noch einen Blick auf die nahe und ferne Zukunft des MapProxy Projektes. Ein Highlight ist hierbei der neue Hintergrunddienst der für MapProxy entwickelt und auch als Open-Source-Software veröffentlicht wurde.
Bienvenue dans le cent-dix-huitième épisode de CacaoCast! Dans cet épisode, Philippe Casgrain et Philippe Guitard discutent des sujets suivants: TN2318 - Enfin un technote sur les erreurs de signature GitHub - Astuce pour les développeurs qui travaillent en binôme Cosmic Sans Neue - Une police pour programmeur app.io - Pour présenter votre application sur le web travis ci - Maintenant avec Xcode 5 et iOS 7 pre-app-release-checklist - Si vous aimez les listes détaillées Ecoutez cet épisode
本期由Terry Tai和Dingding共同主持,邀请了 neo 的美女软件工程师鲁葳,和她一起聊聊软件咨询公司是如何工作的。让大家了解更多的优秀软件咨询公司的细节和内幕。 关于鲁葳: Twitter Blog 访谈笔记 neo Pivotal Labs thoughtbot PivotalTracker University of Waterloo rocketfuel Jim Weirich Pair programming TDD Continuous integration Sublime Text RubyMine Vim Emacs tmux Travis CI Jenkins CI Yehuda Katz Eric Ries Lean UX Rails Girls Remote Pair Programing Blog Customer.io Effective JavaScript Special Guest: 鲁葳.
Adam and Andrew talk with Justine Arreche a Designer at Travis CI and Sebastian Gräßl a Freelance Developer. Together, they’re the creators of Open Karma, a tool to help bridge the gap between developers and designers in open source (they’re bringing some design love to OSS).
Adam and Andrew talk with Justine Arreche a Designer at Travis CI and Sebastian Gräßl a Freelance Developer. Together, they’re the creators of Open Karma, a tool to help bridge the gap between developers and designers in open source (they’re bringing some design love to OSS).
伊藤直也さん, 宮下剛輔さんをゲストに迎えて、Docker, chef, serverspec, Travis CI, Vagrant, サーバプロビジョニング、テスト などについて話しました。 Show Notes Docker LXC Linux Containers aufs Inside Sqale backend Heroku Cedar Stack Dokku Heroku Buildpacks Dockerfile miyagawa/docker-plenv-vanilla Vagrant serverspec Food fight show Test-Driven infrastrcture with Chef Test Kitchen ansible sunzi CloudFoundry lleval autodoc WEB+DB PRESS Vol.75
Kenta Murataさん, Ryo Nakamuraさんをゲストに迎えて、RailsConf, Ruby 2.0, Rails 4, Chanko 2.0, RubyKaigi, YAPC などについて話しました。 Show Notes RailsConf Blind Reviews at RailsConf 2013 RubyKaigi 2013 DHH keynote at RailsConf 2013 Not sure if I should be offended by the Kansas barbs DHH RailsConf 2012 Keynote gist.github.com launched with Rails 4 What's new in Rails 4.0 Cookpad の本番環境で使用している Ruby が 2.0.0-p0 になりました Ruby 1.8.7 and REE End of Life Ruby 1.8.7 EOL expected this June What a hard work to make the recipe sharing service available on Ruby 1.9.3! MIME encoding bug of NKF.nkf Rails 3.2.13 default_scope breaks chained scopes rails/strong_parameters Turbolinks Compatibility Android Is The New IE 6 Chanko: Rapidly & Safely prototyping your rails application プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました Use Erubis when available for faster startup Travis CI Coveralls Code Climate rubygems travis Coveralls + Perl YAPC::Asia クックパッド採用情報 第4回 開発コンテスト24
本期由 Daniel 主持,参与嘉宾有 SaitoWu, Dingding Ye。武鑫(Saito) 是著名自托管 Git 项目仓库开源项目 GitLab 的核心开发者之一,也是 RubyConfChina 2012 的讲师。本期 SaitoWu 同学继续第六期的话题,跟我们聊聊 Gitlab 的故事,包括 Gitlab 的项目领导人 Randx 其人,武鑫如何成为 Gitlab 的核心开发者之一,Gitlab 这个开源项目对武鑫产生的影响可以给我们带来什么样的启发,以及对 Gitlab 将来发展的展望。在节目的最后,武鑫回答了大家关心的问题。 Gitlab 专题问题收集帖 How Gitlab Works How Gitlab Works PPT Randx Gitlab core team members Gitlab.com Randx join Gitlab.com as a co-founder IRC Gitlab Googlegroup grit_ext Skyrim 上古卷轴5:天际 Github Enterprise 打造Facebook 王淮 Smart HTTP Support Scott Chacon Gitosis Gitolite grack Git Transfer Protocols GitLab 5.0 Gitlab Shell Github Hooks Gitlab Hooks Project Management Tools Gitlab-CI Travis-CI Jenkins-CI Gitolite Mirror Gitlab-grit Gitlab-recipes gitlab-vagrant-vm Feedly gitlab_meta Special Guest: saitowu.
Сегодня обсуждаем исключительно гиковские темы. Много времени уделяем Continuous Integration и организации бизнес-процессов в команде. В выпуске: - Зачем и когда нужен Continuous Integration. CI-сервера: TeamCity, Travis CI, Jenkins. - Фильтрация строковых идентификаторов в Sphinx. - "Правильный" бизнес-процесс создания ПО. Голоса подкаста: Антон Сергеев (hackPNZ) Слава Федотов (fe.off) Антон Копылов Podsafe: J.1.0 - Frozen Paradise
Unsupported Operation 67JavaOracle pulls support for JavaFX ScriptJava 7u4b15 developer preview availableMiscDataStax has quietly made their Cassandra documentation available in PDFExcelTestNG - interesting - webdriver/selenium testing driven by Excel spreadsheets, and TestNG.Practical Unit Testing with Mockito and TestNG is nearing publication - now has an ISBN!LogBack 1.0.1Hibernate 4.1Hazelcast 2.0 released - release notes.AIDE - IDE for Android, ON AndroidTerminal-IDE is similar, but gives you a vi based environment.SmartGIT 3.0.1 available - changes - GUI Git client in Java. now supports mercurial and svn since I last checked it out.Gerrit 2.3rc0 availableAtlassian buys an IRC/IM client/server company - closes a 7 year ticket “won’t fix”Web StuffNettoSphere - A WebSocket and HTTP server based on Atmosphere and Netty.vert.x - node.js like asynchronous web server/platform - lets you write applications in js, ruby, and java. comes with distributed event bus, websocket support, tcp/ssl, pre made modules for mailer, authentication, work queuesThymeleaf 2.0 - XML/HTML specific template engine.GateIN 3.2.0 Final - people still use portal servers?JRebel 4.6 released, JRebel for Vaadin announcedApache / Maven / RelatedShavenmaven - super-lightweight dependency management - NO XML - just URLsGrails 2.0.1 now uses RichardStyle composites, and hopefully will make its way to “Apache Maven Central” soon.Apache Jena 0.9.0 - Java framework for building Semantic WebCommons Math 3.0Apache Camel 2.9.1Apache Hama 0.4 - incubating - metrics on HadoopApache Rave 0.8 - incubating - social mashupApache Tomcat Native 1.1.23Apache Ant 1.8.3Directory studio 2.0.M3ApacheDS 2.0.0-M6Apache Directory LDAP 1.0.0-M11Apache Commons Daemon 1.0.10Apache ACE has become a top level projectApache OFBiz 09.04.02 (2nd TLD in a month - DeltaCloud was the other)Apache MyFaces extension for CDI 1.0.4JetbrainsIntelliJ IDEA 11.1 to support JavaScript.next with Traceur compiler.AppCode 1.5 RCGroovyFirst official GroovyFX releaseScalaAkka moved to a new Akka Organisation on GithubAkka 2.0 also released!New Scala proposal for value typesClojureClojure 1.4 beta 4First Github got hacked, then node.js’s NPM, Clojars takes precautions:Hello folks!In light of the recent break-in to the Node.js package hosting site (https://gist.github.com/2001456), I’ve decided to bump the priority of increasing the security on Clojars. I’ve deployed a fix that uses bcrypt (http://codahale.com/how-to-safely-store-a-password/) for password hashing. The first time you log in, it will re-hash your password using bcrypt and wipe the old weak hash.Note that Clojars has NOT had a security breach at this time. This is a preventative measure to protect your password in the event of a future breach. We are also looking into allowing signed jars (and possibly requiring them for releases). If you’re interested in helping out with this effort, (design or code) please join the clojars-maintainers mailing list: http://groups.google.com/group/clojars-maintainersBecause we can’t ensure that everyone will log in to re-hash their password, at some point in the future (probably 2–3 weeks out) we will WIPE all the old password hashes. Otherwise users who have stopped using Clojars or missed the announcement could have their passwords exposed in the event of a future break-in. I will be sure to send out a few more warnings before this happens, but even if your password has been wiped it’s easy to reset it via the “forgot password” functionality.If you have any applications storing passwords hashed with SHA1 (even if you use a salt) I highly recommend you take the same steps; refer to http://codahale.com/how-to-safely-store-a-password/ for details.please log into Clojars to re-hash your password.Thanks for your attention.-PhilRelated news - Bouncy Castle 1.46 releasedStatic code analyzer for Clojure - kibit 0.0.2 now releasedMarginalia v0.7.0 - documentation generator for clojurelein 2.0 preview releases are out, and now preview2 is supported by Travis-CIlein-navem is a lein plugin that converts a maven pom.xml into lein project.cljDatomic is a new database service from Rich Hickey. And dayam it looks nice. Some really nice ideas in here.
Wynn caught up with Josh Kalderimis and Mathias Meyer from Travis CI to talk about hosted CI in the sky, scaling apps, and a little Riak.
Wynn caught up with Josh Kalderimis and Mathias Meyer from Travis CI to talk about hosted CI in the sky, scaling apps, and a little Riak.
Новости Вышел Draper 1.1 Factory Girl 2.4 Вышла Juvia - открытый Disqus Travis CI собирает пожертвования Mechanize 2.1.1 Для начинающих и конченных программеров шпаргалочка о том, как не надо делать, подкаст Ruby Rogues 7 февраля вышел Sidekiq — библиотека для обработки фоновых событий 12 февраля вышел Split 0.3.2 библиотека для A/B тестирования Обсуждение Ruboto Rails or Sinatra Heroku Пока мы писались, коммитов у Алексея Вахова стало 37, прямо как количество сигналов у одной известной компании
Mit guten Podcasts ist es wie mit gutem Wein: Was lange reift, ploppt am Ende doppelt so gut. Daher hoffen wir, dass sich das Warten auf diese Episode gelohnt hat - wir haben uns Mathias Meyer (http://twitter.com/roidrage) eingeladen und löchern ihn zu Infrastruktur und weiteren DevOps-Themen. Shownotes - Travis-CI https://travis-ci.org - Release It http://pragprog.com/book/mnee/release-it - Post-Mortem http://about.travis-ci.org/blog/2012-09-24-post-mortem-pull-request-unavailability - Chaos-Monkey - New Relic - Dev Ops Game Day https://github.com/cloudworkshop/devopsgameday/wiki - metriks https://github.com/eric/metriks - Ganglia http://ganglia.sourceforge.net - Graphite http://graphite.wikidot.com - Librato Metrics https://metrics.librato.com - Papertrail https://papertrailapp.com - Graylog2 http://graylog2.org - rsyslogd - Chef http://www.opscode.com/chef - Puppet http://puppetlabs.com/solutions/devops - Deploying Rails http://pragprog.com/book/cbdepra/deploying-rails - Scalability Rules http://www.amazon.de/Scalability-Rules-Principles-Scaling-Sites/dp/0321753887 - Scalable Internet Architectures http://www.amazon.de/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X - Web Operations http://www.amazon.de/Web-Operations-Keeping-Data-Time/dp/1449377440 - Architecture of Open Source Applications - http://www.amazon.de/The-Architecture-Open-Source-Applications/dp/1257638017 - http://www.amazon.de/Architecture-Open-Source-Applications-Volume/dp/11055 Picks Mathias - OnePiece Onesies http://onepiece.com Dennis - Startups for the Rest of Us Podcast http://www.startupsfortherestofus.com - xScope http://xscopeapp.com/ - Highlight.js https://github.com/isagalaev/highlight.js Jan - iA Writer http://www.iawriter.com - “The Breakpoint” mit Paul Irish und Addy Osmani http://addyosmani.com/blog/the-breakpoint-episode1 Peter - http://www.smore.com/clippy-js - http://www.railsplugins.org - http://www.amazon.de/Silver-Hawk-Ladeger%C3%A4t-Batterien-Akkus/dp/B004FPMY5U
Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: I think every platform kind of has this tipping point where you start to see like, hey, this feature, this product is getting a lot of traction, and people building on any platform should realize they are doing R&D for the primary platform at all times. Every feature you release, every experience you have is an opportunity for the original platform to be like, hey, that’s a great idea. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for deep work on iPad and Mac. But this podcast isn’t about me use the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Adam Wulf. 00:00:43 - Speaker 2: Hey, everyone. And joined today by Joe Watkin. 00:00:47 - Speaker 1: Hey folks, great to be here. 00:00:49 - Speaker 2: And Joe, you have an interesting background with creative tools including GitHub and Abstract, you’ve had your own startup doing calendar slackbots and other calendaring things, but before we talk about all that, I’m very interested in your side project ballot share. Can you tell us about that? 00:01:06 - Speaker 1: Oh yeah, yeah. Ballot share is a is a labor of love. It’s much less of a business than a fun project, and it really just centers around helping people get more information when they’re about to vote. And so, People usually want to vote for one or two things when they hit a ballot, but it’s all of the minutia stuff that people don’t really have a really good sense of what to vote for or who to vote for on really local issues, but those are the stuff that really, you know, impacts them. And so Ballot share is just a site where you can see who’s endorsed things all the way down the ballot to like your local city ballot initiatives. And you can also create your own endorsement around things that you think are important and share that with friends. So the most common use case we see is people say, oh, like I have a friend who’s really plugged into education, so maybe I could ask them who to vote for for the school board president. And so they send you their endorsement and you kind of see it in a grid where you can kind of compare all of the endorsements that you want to compare. It was built for the last election cycle and we’re hoping to revive it again for the midterms. 00:02:14 - Speaker 2: I really like that idea of a sort of using your trust network if that’s the right way to put it. Maybe we get some of this implicitly, you know, there’s people I follow usually like substack where they do political analysis and to some extent I’m sort of trusting if I’ve come to trust that their analysis is good in some cases it’s that I’m reading their analysis and better understanding the issue, but in some cases it’s that I go, OK, this person. Seems to be pro this thing and I basically trust them, so therefore, I’m gonna kind of outsource that decision a little bit, especially for, as you said, all these finer details and local things that maybe you can’t deeply research each and every item. So it feels like it’s naturally what people do anyways. So as a tool to help you kind of reach that. 00:02:59 - Speaker 1: Yeah, yeah. A lot of people end up making like Excel sheets and then sending them around. And it’s actually kind of funny, we noticed that it’s not just wanting to know who endorsed it, it’s who is against certain things. So when you see like, hey, this group is against it, you’re like, that’s surprising, why? And sometimes it takes like, hey, of the 10 ballot initiatives, 6 seem like everyone is in agreement, but then like maybe 3 are kind of like up in the air. And so you, those are the ones that you personally investigate. So it kind of just puts more time to the ones that you think are actually worth the the decision to make sure you get it right. 00:03:36 - Speaker 2: And tell us a little bit about your background. 00:03:39 - Speaker 1: Yeah, so I’ve done a lot of work in the tech space, but it’s not always specifically on the tech side. So my background is I came into tech via sales actually. So I was hired at GitHub as one of the first technical minded sales people, and GitHub was a very weird beast where there were no managers and you kind of like had to understand how to do a pull request to like even do anything in the company. So, I originally did Git Up sales, focused on the enterprise clients, but switched over to BD at GitHub, maybe my 2nd or 3rd year, as just a hugely undervalued piece of the business. 00:04:16 - Speaker 2: And I’ll briefly unpack that BD stands for business development, which I think itself is probably not a super well, in my experience, it’s not even a super well understood title slash function, so maybe you want to briefly describe what that is. 00:04:31 - Speaker 1: Yeah, absolutely. BD means so many different things. It’s kind of funny. I think a lot of startups tend to use BD as just another name for sales directly, like generating revenue and talking to customers. At GitHub, it was a little bit of a catch-all, so I was running sales partnerships where we partner with companies like Ubico and get more people using two-factor keys, but it was also partnering on the technical side. So working with companies to maybe build a plug-in, and specifically my charge was everyone who’s using the API helping them do their job better. And at the time it was mostly just like a ragtag group of maybe a couple 100 people using the GitHub API. They had a very open, very public permissionless API at the time, so people just, a lot of researchers, a lot of students, but then like a handful of companies who are trying to build a business. So my job was a little bit more. Focused on getting that group of people to be more successful, and the sales partnerships happened, they were just much less of a focus, and it was a small team, we maybe had 6 people max, so we kind of did a lot with a little. 00:05:40 - Speaker 2: And you had the same title at Abstract, if I’m not mistaken. Tell us about that experience. 00:05:44 - Speaker 1: Indeed, yeah, Abstract is a funny company. They do version control for design files, and BD at that company was much more around product partnerships and mergers and acquisitions work, M&A work. And so we didn’t do any kind of like sales partnerships. We specifically focused on anything that would help the product be a little bit better, and then kind of fielding the requests and inbound we were getting from interested parties around M&A work. And so that ended up being a lot of work when we got acquired by Adobe, but it was a pretty fun ride as well. 00:06:19 - Speaker 2: And it seems to me version control is by definition part of a tool chain, part of a stack, so those partnerships and integrations are crucial because that is the whole sort of reason for existence for the tool, and I assume there’s the technical integration, but then making those business partnerships where you’re doing something together, maybe that’s co-marketing, but maybe it’s also you’re trying to serve the same set of customers together even though you’re two different companies making two different products just from the outside it seems to me like that would be a crucial function. 00:06:49 - Speaker 1: Yeah, it’s definitely an important one. In both GitHub and the, you know, abstract case, these are part of a stack like you mentioned. People are considering entire tool chains, and so we’ve got to work nice with everyone and also try to help the group itself be better cause I think there is this constant struggle in the sass world of, you see companies who want to go single suite and company offer everything under the sun, like an Atlassian or Salesforce is another one of those. 00:07:16 - Speaker 2: Microsoft is the absolute king of this, right? You sign one contract, and you get a whole suite of mostly mediocre products, but it’s OK because they fit together and, you know, you could kind of buy one time and everything you need in the software world is kind of taken care of. 00:07:34 - Speaker 1: 100%. And then you see the opposite swing where it’s all best to breed, where it’s, hey, I really care about getting the best tool for this, even if it costs more. And we see companies swing between the two quite often. So whether it’s cost related or maybe it’s, you know, new leadership, it’s like, hey, we really care about developers, let’s break out of this like low cost tooling and now give them like stuff that they want to use. So in both cases in Abstract and GitHub we were kind of managing in the breast of breed world where we were working with partners who are, you know, all trying to serve similar and shared customers. 00:08:08 - Speaker 3: And an abstracts case, if I understand right, the design files are mostly probably opaque binary to some degree, and so they would not fit very well in a git style version control, and so that’s where the abstract steps in for that really special case of potentially very large, very binary. Difficult to diff files, is that right? 00:08:31 - Speaker 1: Oh yeah, absolutely. I love talking about this cause it’s like real deep and kind of amazing that as you exactly said the Git is more suited for plain text files and You know, there are things like LFS and Git that, you know, have pointers and allow big binary files to be version controlled, but it’s really hard. And so this is exactly what Abstract it, is that they saw Sketch was market leader, but they couldn’t solve this one piece around versioning because of these big binary blobs, and so they created an ingenious solution that actually did use Git on the back end and stored this enormous corpus of design information. And was able to kind of parse through the binary and pick up changes. So, at the time it was revolutionary, you know, there was literally nothing else that did this. And so they built a very strong business on that kind of like breakthrough in being able to take a workflow that worked with developers and apply it in the design world and give designers just like a huge amount of new workflow capability. You know, they could do branches, they could do merger requests, a lot of the same things that developers have used. 00:09:40 - Speaker 3: Yeah, that opens up so much more freedom. I’ve worked with designers running up against this exact same problem, probably, well, long time ago now, over 15 years ago, but it was, it was exactly this problem of there’s one blessed Photoshop file and if that gets messed up or there’s the classic version 1 version 2, version 2 final. Nightmare. 00:10:06 - Speaker 1: Final final, yeah, absolutely. I mean this is now obviated by all the web tools like a figma that, you know, are building versioning, just like a Google doc, you know, saving every stroke, but at the time when everything is desktop based, like, these are intractable problems, so it’s kind of interesting to see how The world moves into a different medium that solves it, but then introduces other problems, like now you’ve got multi-user collaboration real time, and that’s like, you know, a big headache, but also like a huge opportunity, so there’s always something fun to be worked on. 00:10:37 - Speaker 2: I believe that the developer workflow that is Encoded through Git and GitHub, which is a more asynchronous and the merger quest as a bundle and being able to look at diss. Obviously that whole thing is way out of reach for the vast majority of people in the world. But I do think a version of that probably can and should be part of almost every kind of creative tool, certainly for design tools, again, as you say, we do see that in the real time collab and the figmas and sketches of the world. I think you see this, one reason why Google Docs is really popular with writers is they have a really good versioning system or good versioning relative to the writing tools still. Pretty basic compared to what developers are used to, but where you can see new changes when you come to a document, you can look at a history, and critically, you can choose which changes to merge or reject, or have a comment this thread that is based on a change, right? That’s one of the biggest, I think, powerful abstractions in the mental model for something like Git, which is based ultimately on patches, which is you can talk about a diff as its own thing separate from the resulting code. And so that results in poll requests and then essentially code reviews and discussions around that. And I think probably most creative tools and fields could benefit from that, but the way those tools work for developers, it’s just way too heavyweight and complicated for most people. So, stay tuned. I can switch actually has some research tracks going on this, so I hope you’ll see some essays on the topic soon. And then I think you heard that time zones are one of the easiest and most fun things to do in programming, which is why you’ve worked on several calendar products as your own startups. Tell us a bit about that. 00:12:19 - Speaker 1: Oh yeah, my latest venture was called Eventbot, and it was a Slackbot that provided a calendar, basically behind every single Slack channel. And this is my 4th real calendar startup, and I’m just a glutton for punishment here. I think that In general, I like the calendar space because I think it’s interesting to build tools around how we use our time. Like I think if you can make that slightly optimized for people, it has a huge ripple effect. But I do think it is a brutal industry that where businesses are, you know, sitting in a large graveyard of failed to ups, so I’m not ignorant of how crazy that world is, but it was a fun project. I think we saw slack growing at a tremendous rate, you know, I’ve seen a lot of different approaches in the calendar world and me and my co-founder really saw like, hey, we could build this. tool that provides a really important niche within Slack, and, you know, maybe it can grow bigger than we think and we can, you know, put it into other areas, but we just sunset eventbot after 5 years of growth. It’s been a fun ride, but I do think that the business itself wasn’t able to sustain the amount of work required to keep it going. Like as you said, time zones are crazy. Little known fact, there are thousands of time zones, not even just the familiar ones. There are many Cities that choose not to obey daylight savings times, laws that are passed on a monthly basis that change how you have to calendar. So that part of the business is super boring and extremely frustrating for developers who have to try to keep up and make sure that they’re current. 00:13:58 - Speaker 3: I think calendaring is really interesting because there’s a built-in moat for any new business, and if you can swim across the moat and build a business, then to some extent you’re safe, but it’s so easy to just drown in the middle of the moat with all of the complexity of time zones and recurrence rules and invitations and It’s just a nightmare of Minutia that just drags you down by the heels. 00:14:33 - Speaker 2: That’s right. Well, I forgot you spent 5 years of your life working on Fantastic Cal. I did pretty successful kind of gooey calendar, so you’re very familiar with the pain there. 00:14:42 - Speaker 3: Yeah, my first startup was also a web calendar back pre-G Google calendar days, and I’ve made some pretty fantastic slash horrible decisions in learning that, just kind of walking in naively into the problem space and making choices that I instantly regret. Lots of bullet wounds and scars in that space. 00:15:06 - Speaker 1: Oh yeah, there’s lots of strange edge cases in the calendar world, you know, being able to even have a consensus of what is now, what time is today, like, these are things that when you’re talking to users across the globe that the internet affords us, have just so many edge cases that we have to deal with, but Yeah, I do agree that I think building on another person’s platform has a ton of benefits, and we used a lot of them when we were building a bot, you know, primarily distribution was huge. We were early on in this slack marketplace, and so when we were building, we were finding users coming to us, which, you know, as a business that solves a major, major problem, just getting people to care or even know you exist. And in previous startups, you know, you have sales motions, you’ve got marketing efforts, and here you kind of at least, if you can solve that piece, you can focus more of the efforts on product, on delivering unique interesting value to customers. But like you said, there’s lots of kind of catch-22s in that bargain. But in the beginning days for us, we found it to be extremely valuable. We started with a free product that was truly broken. Like, I was super surprised when people had used eventbot to begin with. We had a calendar product where you could create a start date and time for a meeting, but you couldn’t create an end date and time. We launched it without that feature because we were not even sure what we were building, and we got some really, really gracious folks who were like, oh, I wanted a calendar built for Slack. You should build this. And we use, you know, the community who was adopting a free broken product to help us improve it and actually put an end time, and then subsequently actually really improved the product, but it was a blessing to kind of get user traction, even at the early days. 00:16:54 - Speaker 2: And I was sorry to see it shutting down because I’d been a user earlier on, but I was impressed by your, I guess it was an email or Slack message. I can’t remember where I basically described, hey, you know, we’re sunsetting this product. Sorry about that. Here’s exactly what customers can expect, and I think how to gracefully. Set of product which you know guess what does happen in the technology industry and there’s lots of ways to do it that I think are not very conscientious of the needs and even feelings of those end users and customers and there’s ways to do it that are more graceful seems like seems like you manage the latter. 00:17:29 - Speaker 1: Yeah, no, I appreciate that. I think I’m probably like you all have been on the other end of that, where you get an email saying like, hey, this service is shutting down, and you’re kind of like, uh, like the world is worse off, and we at least wanted to make that pain a little bit less, so, you know, we started making all the features free, so people can kind of export data. We gave customers months and months of notice so that they kind of knew, but in the end, You know, we realize that we’re stewards of other people’s data, right? And so if we’re going to be cutting our service, then we don’t want people to feel like, hey, I made this investment and now I don’t have my information anymore. 00:18:04 - Speaker 2: And on top of everything we talked about, somehow you managed to be a teacher inside of all of this. I don’t know where you find the time. 00:18:12 - Speaker 1: Yeah, neither do I, actually, it’s kind of funny. Teaching is something I stumbled into 2012. Actually, while I was building a different calendar startup called Calico, way back in the day, I ran out of money, and I started to, you know, think about what I could teach, and I just graduated Berkeley’s grad school, so I was like, well, you know, let me go back and Try to teach something I know, which was, I just learned how to code, so I taught an intro to code course. And, you know, at the time, intro to coding and boot camps were like all the rage, so it was a pretty well received course. So I’ve now taught two courses at Berkeley for 10 years. I’ve taught an intro to code course for non-technical people. Which is really like a primer into how not to sound stupid in front of developers. 00:19:02 - Speaker 2: I think that’s the, that’s the primary reason I think people take my course, that is to say, people that want to, they work with technical people adjacent to them, maybe similar to like a sales role, for example, and they want to be able to speak the language and interact and kind of reason better about that, not necessarily get a career as a software developer themselves. 00:19:20 - Speaker 1: 100%, yeah. I think the largest percentage of people who take the course are people who want to transition into product management, and they’re working, you know, day to day with engineers and they want to understand real life expectations, like, how does this code work and what are the restraints and constraints that I have on my job. It’s a super useful course that we’ve got fine tuned to make it be very practical, which is not often the case for courses in academic institutions, but, you know, we we try pretty hard. And then the second course I teach is sales for startups, where, you know, I believe that sales is just an incredibly powerful skill, whether you are, you know, at the startup phase and a founder trying to sell people on the company, on the vision, and, you know, the funding, or you’re selling to customers and trying to get them to make a purchase, so. The two courses I teach are really intended for folks to have an ability to do something in the startup world. You’re either building something or you are selling something. But if you wanted to join a startup, I’m hoping that, you know, you take some of these courses and you feel like, hey, I can join this world of startups, I don’t need to necessarily go to a big company and try to like find a niche. So yeah, it’s been fun. I definitely enjoy it. There’s a long story of like how I feel teaching, especially these past few years where it’s been, you know, much harder, remote. I think every semester we’ve had a fire, an active shooter, smoke, virus pandemic, like, it’s been a crazy past 5 years, but in general it it gives me a lot of joy. I think something that I don’t think I can replace anymore in my life. It’s a really fun thing I get to do. 00:21:00 - Speaker 3: I think those are really interesting courses because you’re teaching kind of each side of the company about the other side of the company. You’re teaching the non-technical folk. Here’s kind of the problems and the struggles that they have, and here’s how that side of the technical people function, and then also helping teach the technical people. By the way, this is what sales looks like. This is why the other side of the company is a lot harder than just Sitting behind a desk and telling you what to do with a product sheet and timeline. 00:21:27 - Speaker 1: Yeah, I agree. I think it gives the other side a little bit more respect for these roles and what they do and what they bring to the companies. It’s also a lot of fun to teach. 00:21:36 - Speaker 3: Building that empathy within a team, I think is so important when you have an extremely small team in a startup, so that everyone knows the importance of everyone else’s role and responsibility, and you end up, I think, just so much more efficient than a brilliant engineer who doesn’t understand sales and customer needs, or someone who’s really in touch with the customer, but has no idea how long it takes to build particular features. 00:22:03 - Speaker 1: Yeah, I think it creates better entrepreneurs as well. Once you start to realize, like, hey, if I have to look at this idea through the sales lens before I start, like, is this a good idea? Does this have legs, you know, on the technical side, on the business side, channel, marketing, like all of those things are really great to think through early on. So hopefully I catch people while they’re still, you know, in school and kind of incubating things. And I’ve gotten really great letter, you know, this is off topic a bit, but I continued to teach now for a decade because I get these incredible emails where they’re like, 5 years later, someone will be like, hey, I just realized that like, I learned this thing that I’m using, like, in my job. I learned it in your class, like, awesome job, thanks for, you know, helping me out, or I’ll get people being like, I have an interview next week at this company, like, I think I know what these depth tools means, but like, can we chat about it? And I’m like, this is amazing, this is a different level of impact. So it gives you a lot of satisfaction on a long term basis. 00:22:58 - Speaker 3: Yeah, that’s really rewarding. 00:23:01 - Speaker 2: So our topic today is building on platforms, and especially building a business on a platform. And we have some interesting collective experience here in this group, Joe, you’ve been on the kind of platform provider side at GitHub, you’ve been on the platform, let’s say, consumer or developer side at Eventpot or building on the Slack platform. Obviously, Wulf, you’ve been on the various Apple platforms in different forms for a decade, more than that. So, I thought it would be a good chance to compare some war stories here and understand better what it means, what sort of trade-offs you’re making when you do build for a platform. But as always, I like to start with a definitions, I’d love to hear from you, Joe, and then maybe from you, Wulf, when you think platform, what does that mean to you? What are some that you think of as maybe good or bad examples, and what does that mean for a business? 00:23:54 - Speaker 3: When I think of platform, I think of A company with existing customers that wants to let other companies have access to those customers. And somehow takes money from both sides. And so it it ends up being most good for the platform provider. And then secondarily good for the companies that get access to those customers. 00:24:21 - Speaker 1: Yeah, I think that the customer focal point, I think it’s probably the best starting point because, you know, whether it’s a product or some sort of just customer relationship, that’s the value that they can bring to other ecosystem partners who want to see an opportunity, and I’ve talked to a lot of larger companies that are considering just creating an API itself, like that is a starting point. And part of the reason they do it is, you know, a product can only fill maybe 80 85% of any customer’s needs, but there’s always gonna be those edge case requirements that might not be in the company’s best interest to build, but you still want your customers to be happy. And so I think an ecosystem provides the ability to have happier customers while maybe ceding some part of the pie or the product portfolio to a third party. 00:25:11 - Speaker 3: Yeah, and ironically I think in seeing that to a third party, you almost Entrench yourself to your customers, because now the customers to leave your platform have to leave not only you, but also all of these other extra companies that are building on your platform. So it’s a lot more difficult for me to walk away from Google, because Google is everywhere and everything integrates with Google. Yeah. And similarly for Apple, it’s really hard to leave Apple because of the iPhone and the Mac, and the App Store, and the TV and the, you know, etc. etc. 00:25:44 - Speaker 1: Yeah, it really creates a second network effect, in addition to whatever product, you know, pull you have primarily, it adds an entirely different layer of, you know, wanting to stay, and, you know, there’s lots of times where maybe the primary product is, you know, maybe lacking, but the ecosystem is super strong, and so it keeps people engaged and helps people really feel like, oh, I can’t leave, where else can I get these very customized ecosystem tools, and it’s hard to build. Once it’s built, it’s a machine. 00:26:14 - Speaker 2: The platform play is one that, you know, investors love as a holy grail of money printing machine, you know, Microsoft in their glory days, the Windows glory days was probably one of the most prime examples of this, maybe even to your point, Wulf, where it’s not necessarily that people loved Windows, the operating system, or would have chosen that above other choices available in the market. It’s just when all the programs you need run on it, of course. You’re gonna use that, and then, of course, that’s also a nice circular thing where if you’re a developer, you, of course, want to build for where your customers are. And when I think of platforms, obviously operating systems like Windows, iOS, Mac come to mind. The web is sort of a more open, loose collection of technologies that does represent a platform. And then maybe some more recent examples that are maybe more specialized might be something like Shopify or WordPress, right? Building a WordPress plugin or building a Shopify app, there’s actually quite a lot of possibility there, especially for a small developer within that ecosystem, and you can find customers that you would not be able to find if you were building something standalone. 00:27:22 - Speaker 3: Almost makes me think there’s a Maybe a gradient between an application that has plug-ins and a platform that has apps like WordPress is an interesting example where it is a platform, but it’s also just an app that I can install on a server and kind of do my own thing with. 00:27:41 - Speaker 1: I think you are onto something where there is a spectrum of how the integration happens, you know, there’s platforms where you don’t need to even know who’s using the platform. It’s just you provide the surface area and other people can build on top, or there’s something that’s deeply integrated where it’s like, you know, in the user interface. We saw this at GitHub where we had a lot of people who used Chrome extensions that like injected UI into the screen and It was weird for us to consider, like, are they plug-in partners because they don’t really talk to us, but they are in our customers' eyes, so we have to care about that, but I do agree there is a spectrum there. 00:28:20 - Speaker 2: Well maybe that’s a good chance for some storytelling here. So yeah, GitHub, you helped build out the marketplace. What was the drive for that and what was that experience like? What did you learn on the platform creator side of the equation, I guess. 00:28:33 - Speaker 1: Yeah, so the GitHub Marketplace was a multi-year kind of dream of mine, and uh to be honest, I think it’s because working at GitHub made you really see how undervalued, underestimated developer tools were as a broader category, and this is 2010. In terms of context. So we saw that people were using developer tools like GitHub, but we knew that we were going to be a best of breed company. We were going against the like single suite approaches. And so, to really shine in a best of breed, you need a lot of breed, like you need a lot of people. You want to let a 1 1000 flowers bloom in that space. And devtools were a difficult thing to grow. And so, in general, they get a marketplace was kind of like a long term intention of how do we grow the DevTools space with the position and kind of responsibility that we have as being on the version control side, which is a very base layer for a lot of developer tools. So we were building a platform that really intended to help developer tools blossom. And take away, you know, some of the parts that they really didn’t want to do, which was sales and marketing. So, we can definitely talk a little bit more about how that happened. It took a couple of years internally to get some buy-in and then externally to build the trust, but it was a really fun project which now, you know, get up marketplace is thriving and booming, so I look back pretty fondly as like, ah, cool, we helped do that. That’s a pretty nice feeling. 00:30:07 - Speaker 3: Yeah, one thing I’m really curious about is That step from 0 people on the marketplace to 1 person on the marketplace, right? Just getting that very first use case and that very first business to buy in and get going, to start things off. What was that like and what was the process to kind of maybe find that business or make sure that you had enough there for them to integrate with? What was the minimum viable product, so to speak, of A platform. 00:30:40 - Speaker 1: Yeah, I think that’s a really good question because we started by having an API that people were already using, so people were able to get information in and out of the GitHub system. It wasn’t super well loved in terms of resources, but we had people using it, and there were businesses that were created, they were just very, very small. And so that the primary example when people think about the GetUp ecosystem is a CI tool, a continuous integration tool like Travis or Circle. And for folks who are not familiar with what CI tools do, they basically do a check on your code. So they are looking at your code to see if there’s any errors, does it pass the test that your own developers have written, and it just gives you back like a hey, pass or fail. And so those tools existed in the market and used our API, but they were basically totally separate entities. People would come to GitHub, buy GitHub subscription. Use it, and then go to these independent websites directly, you know, find them, hope, and look for a logo that said, hey, integrates with GitHub, and be like, OK, great, like, maybe I can also use this in addition to my version control software. And so, my first V1 was really to create something very lightweight. At GitHub that allowed some traction and kind of proof of value to exist, to kind of build towards this marketplace ideal. And so our V1 was really simple and it’s kind of embarrassing, but we just did a simple static page. It was like GitHub.com/sh apps or app directory. There was a bunch of users who had apps, so we had to change the URL, but the original static web page was just a single page where we just hot linked out to every single tool that we knew that was reputable enough to be recommended, but also integrated with GitHub directly. And it was an important first step that I kind of didn’t really appreciate at the time. It was just mostly like, hey, how do I make progress? Well, this seems like a good way. But it accomplished two big things. One, it gave direct traffic to these providers. So, you know, Travis CI, Circle CI are common ones. They were starting to get a lot of traffic. You know, GitHub at the time was a top 10 website in the world by traffic. And so us redirecting even. In a small sliver was able to give them, it’s a huge boost for devs who, you know, are looking for CI tools. They’re like, well, why don’t I start here at this GitHub app page and then go out. So we were getting a lot of goodwill by those companies who are getting free traffic and likely, you know, a lot more revenue from it. But it also served the purpose internally, where we had, you know, lots of management to convinced that it’s worth building a bigger marketplace, because now we can see how many people click through. We actually requested from the folks who are on that static page, like, hey, could you send us a report at the end of the year on like, how many people bought subscriptions through you? We’d love to know cause we’re gonna put in a referral link, so we wanna know how much it converts. So it was twofold. It was really helpful from the inside to kind of validate like, will people click, like, and if so, which partners will they click on, like which ones do they not care about? And on the external side, we gave people almost a full year where, you know, we just drove traffic. It was also just a really good time. Once you start driving traffic to people, then they start wanting to talk to you more. They’re like, hey, can we be higher up on this marketplace, and what are the rules and what can we do to help? Do you guys talk to your sales teams about us? I guess that’s a third benefit I kind of failed to mention is our sales teams loved it. They used it in like every sales pitch. They pull up the page and they’d say, hey, listen, you’re not just buying a single best of breed tool, you’re buying into a network of tools. And showing them this kind of wide world that existed. So, it was a good use case for a lot of people and really low lift. We’re talking just a flat HTML page with some links and icons, so it was great. 00:34:36 - Speaker 2: Yeah, that points to one of the first big benefits that comes to mind for me with building on a platform, and that’s distribution. And that could come in the form of direct traffic driving, but it could also come in the form of, I don’t know, you’re making a plugin or an extension to a thing the customer already knows and you benefit from the fact that they’re already a user or a customer of X where X is GitHub, and so you say, OK, so this works with a product I’m already using, and so it’s easier for me to imagine how that plugin or app or integration fits into my life. So, just by itself, you’re already benefiting from that, but then there’s the additional huge distribution benefit of having some kind of a marketplace or an app store, even this static site you mentioned, where you have really direct distribution channel right out of the box. 00:35:26 - Speaker 3: That story is really a perfect summary of how I think about two-sided markets and platforms like that, where GitHub was already extremely valuable to the developer, just as source code repository. But then adding in those extra partners, it becomes exponentially more valuable for those developers and exponentially more valuable for those partners, where it’s really a multiplying effect. When you bring in those extra companies, those third parties, make it so much more valuable than just the product alone, and it’s even much more valuable than me going to GitHub and then me going to Travis, but having that integration makes both of those. More than twice as valuable when they actually integrate and talk to each other. 00:36:15 - Speaker 1: Yeah, it was definitely good timing for the developers themselves. We had a lot of devs come to us, run these big, you know, annual conferences that could have at the time. They’d say, hey, like, I want to build this business, but like, nobody in our team wants to do sales. We’re like, OK, we totally understand that. Like, we as a company of dev tools, like, as developers, we understand not Wanting to take care of this business, let us help you with that piece, and at least make that a lot easier. And then you focus on building the best developer tool and trying out something. So, I do think that you’re right. It helps multiply efforts. And then if you have an app store, it attracts more people to want to start a developer tool or at the time, you know, a plug-in. And so it creates a bit of a flywheel in terms of creating more people in the ecosystem, which attracts more people to the ecosystem and really. Making the whole better bit stronger. 00:37:09 - Speaker 2: And maybe if I can offer a similar origin story from my own experience, maybe just a few years before you were working on the GitHub Marketplace there, Joe, I was working on the Hiroku add-on system. Oh yeah. And this is basically a way that you can, yeah, you have the same storefront, you can provision services of different kinds, databases, logging and things people need for their apps through this little store. And the way we bootstrapped that was, we went out and did well business development. One of my colleagues did a great job identifying some three really good examples of this would be an incredibly useful service, and it shows the kind of shape of Of the overall add-on system we would picture, and one of those was New Relic, which is analytics, one of them was SendGrid, which helps you send emails, both things that a lot of apps need, and the third one’s actually escaping me right now, but it was like a good sampling. And we worked with them directly to do the integration. We didn’t have any kind of provider API we just kind of sat down with our developers and figured out how to plug it together, and from that, that served two purposes. One, we could see some patterns on what we should actually do in terms of making the API for more broad use, but second, now getting new people on board, we can point to the. Businesses that were already reasonably successful in their own right, people could picture other developers or businesses could picture, oh yeah, I can see why Sendrid and Hiroku or a new relic and Hiroku working together. That’s exactly as you said, Wulf, greater than the sum of its parts saying I want in on that, and then that’s the bootstrapping point and you go forward from there. 00:38:43 - Speaker 1: Oh yeah, Kauna’s add-ons were a big inspiration for what we were doing at GetUp, to be honest. I think we saw the ability for customers to like point click, and then add things to their bill that, you know, wasn’t previously there, but went through a different, you know, procurement model and added on to an existing subscription, like that was just a beautiful. Way to integrate that on a sales side but also on a technical ability just to know like, hey, these things are all gonna work together. I don’t have to worry about compatibility and stitching versions together. It was really nice. 00:39:19 - Speaker 2: Yeah, it’s great to hear. Now that probably does also point to one of the risks or downsides of being on a platform, which is potentially the platform owner owning the customer relationship, which there’s a lot of value in that, whether that’s the billing or just the sense of the trust kind of goes there, you know, maybe. Amazon for its third party sellers is a good example. When you buy something from Amazon, you’re really trusting Amazon and you’re paying Amazon and you think of them as the provider even though maybe the vast majority of stuff on Amazon’s site actually comes from third party sellers. And so overall, you have a power dynamic between the people making the platform and the individual developers that is pretty asymmetric, and there’s certainly a lot of historical examples in the tech industry, I think of Facebook and Zynga as being a pretty famous one, but also Twitter, they at one point early on were more of a platform thing. They had an API and building Twitter bots and Twitter clients and things, and at some point they decided, you know, we actually don’t really want to be a platform, we want more control. We want to be a product, we want more control over the end user experience. They bought Tweety, which is one of the bigger clients, and they basically overnight essentially made their API not very valuable, and they’re explicitly telling their business partners to go take a hike. 00:40:37 - Speaker 3: The risk of being on someone else’s platform should not be downplayed, because Whoever is running the platform has a favorite, and their favorite is very likely their own customers. And so if their customers in that business model need to take a left turn or right turn, they’re gonna do that. They’re not gonna consult you. And so it’s very easy to be building on a platform and then suddenly realize that you’ve been left in the dust, either explicitly cut out like as in the case of Twitter. Or there’s uncountable numbers of Apple Sherlocking other apps and kind of saying thank you, that’s a great idea. I will build that instead and taking all of the market share for themselves for particularly successful apps. 00:41:27 - Speaker 2: And I think it is tough for platform creators because they do have to balance things that can and should be platform features that are built in first class things because they’re useful to everyone and so forth versus things that are in that extended. Ecosystem. The term Sherlock, of course, is interesting because that was basically a search app, I think, for Mac, and at one point, Apple comes along with Spotlight and makes it so that that app is now sort of a feature of the platform. And I think sometimes that sort of thing can be overrated, that, you know, the built-in feature in a platform can be kind of like a really simple stripped down version. And then you can, an app that does a similar thing, but a much more sophisticated version or targets a different audience or something like that, there’s still possibility there. But you’re basically always at risk for that. Yeah. Joe working on GitHub, did you have any places where you had to balance that, like, gosh, this should really be kind of a feature of the platform, but we actually we have this pretty important developer and we don’t wanna screw them over. 00:42:31 - Speaker 1: Oh yeah, yeah, I think every platform. Kind of has this tipping point where you start to see like, hey, this feature, this product is getting a lot of traction, and people building on any platform should realize they are doing R&D for the primary platform at all times. Every feature you release, every experience you have is an opportunity for the original platform to be like, hey, that’s a great idea. And yeah, GitHub we had this exact same thing where We were just a year into creating our app directories, so we got a lot of internal buy-in around, hey, this ecosystem is important, but we noticed that issues, GitHub issues specifically was a feature that was left behind in a lot of the development we did on the platform, so it hadn’t gotten a lot of upgrades it needed, and specifically, there is a way to view issues in a combo board that people really wanted and were flocking to these external providers. I mentioned some of the providers were plug-ins. These plug-ins were Chrome extensions that injected information onto the screens, and we had lots of big customers say like, hey, we love this feature, but we can’t have people injecting into our employees' browsers. Like, that is dangerous, and we don’t want to continue doing it. So we want you to build it. And so that was one of those moments where GitHub realized like, hey, we’re gonna have to build something in this space, it’s hugely important to all of our customers. And I’d like to say that we did a great job, but I’d truthfully say we did an OK job of letting our ecosystem partners know that this was coming. Basically, when it was halfway realized on an engineering front, we reached out to that team and said, listen, I’m just telling you now, we’re going down this path, we’re gonna build something. And of course it wasn’t the months of advance notice that they would like, but it was at least some heads up. And I think this is part of what The responsibility is for platforms that are trying to really encourage growth, is that you kind of have to take communications and transparency as a really important value. So for us that meant just telling them this existed, this is the feature set, because it allows ecosystem partners. To adjust. It doesn’t have to be the death of their business, and in in our case it wasn’t. The ecosystem partner that we told was like, OK, thanks, we’re gonna create communications just for this new release, so that we can talk to our customers and say, listen, this is a good thing, we’re happy. And it allows them to adjust their roadmap. Now if they’re gonna make more investments for the next couple of months or years, they can now say, hey, this base product might be taken, but what advanced features can we do? And that’s exactly what this provider did. They created a ton of new premium features that we knew we were never going to build. Like that was a full-on project management suite, and we couldn’t, I didn’t want to build that. We just needed to have some of the visualization stuff taken care of. So they created a fully thriving business, they ended up getting acquired down the road, but that heads up has a lot of value in terms of just goodwill, honesty, and then just better investment and resource allocation. 00:45:43 - Speaker 3: Makes me think that, especially early on in a platform’s lifetime. A lot of the Businesses and players on that platform are not necessarily building businesses, they’re building features. And so then it’s easy for them to get kind of obliterated by the platform maturing and implementing those features, as opposed to what you just described where it was someone who had a business. They were project management business, and they happened to also implement this feature. And so when GitHub kind of pulled the rug out and stole that feature from them, Well, they still had a viable business and so that, yes, of course, things changed. But they were able to continue adding value on top of the platform. 00:46:28 - Speaker 1: Yeah, and I’d say for us, those early days when we were trying to create this ecosystem and eventually the marketplace, a lot of it is rides on goodwill and people seeing that you can create a business, that it won’t just be, you know, outsourced R&D that just gets gobbled up. So having some kind of shining lights and Good examples where like, hey, we did something that was in our ecosystem, but also that provider is saying good things about us, like, that’s a really strong signal that makes people feel like, oh, I can spend the time and build something on this. So in the early days, transparency is so critical, and I will say the other thing we did was, we were really human about it, so we started doing these in-person meetups with our ecosystems. So we got to know them personally, they got to know each other, so that kind of glue was really helpful when we were doing something like this, cause they knew us as people, not just like the other end of an email address, so I think Also, you know, as many other things comes down to like human relations, and I think this is just a piece of that. I’ve been on the other side, you know, on the slack side, and maybe it hasn’t gone as well, but there’s definitely moments where that human side is just critical. 00:47:41 - Speaker 2: Well, maybe that’s a good transition to talking about event pot and your experience building on the Slack platform. So Slack’s a good example of something that was an incredibly successful product. It had reached kind of market saturation, even certainly among certain kinds of power user and technically oriented Silicon Valley teams, and they came along with not just an API but a marketplace and a way to essentially build a pretty full featured app on that platform. Did you start with the idea for the business and then think maybe we should build it on this platform, or was it actually the other way around is seeing this new platform rising you saw as a business opportunity and then thought about what to build on it? 00:48:21 - Speaker 1: For us, it was definitely more seeing the platform exist and do very well, and then just having the context of having so many calendar startups, you know, behind me realize like, hey, I can put these two things together and maybe create something unique here. There’s always these moments where I would go home for like Christmas. I’m from the East Coast, I’m originally from New York, but I’d go home for Christmas and be like, oh man, I’m like in slack all day, and like, you know, people my age working at other companies would be like, what’s slack? I’d be like, wow, the difference between me in the valley and like people in slack overload between like 10 different slack workspaces and then coming to the east coast and having to explain what it is. I was like, wow, there’s still a lot of opportunity left here. So I think that was a good prompt for like, hm, if we’re gonna build a business, this might be a good place to go. And so that we started down that path and realized this was an area that was overlooked and highly, highly valuable. At the time there was like some basic integrations for calendars that Slack themselves had built. This was an interesting tactic as well. They were seeding their own ecosystem by creating their own plug-ins, so they created a plug-in for Outlook and a really bad plug-in for Google Calendar, among many other tools that they built for, but they did these things as a way to Cover the kind of product needs that their customers would have until the third party themselves built that tool, and I think that was a really interesting thing to see. I also had a lot of, to be honest, a lot of GitHub employees went to Slack, and so they would be like, hey, like this is going really well, this business is is booming, and so that’s not gonna say that that didn’t affect a little bit of my, you know, choice of where to build. 00:50:05 - Speaker 2: On the point of a platform creator making their own apps. Obviously Apple does that, Microsoft does that, game consoles do that, but we did a bit of that at Eroku, and it was partially the seating, as you said, where we would see there was just something needed, that was pretty foundational, and in some cases we would go find entrepreneurs we who that we thought would be qualified and essentially talk them into to start. maybe the first Redd add on was kind of done that way, but in many cases we would build ourselves, but trying to use the discipline of we don’t get any privileged access, we’re working through the same API as everyone else, that team is a The business unit would be a strong way to put it, but we kind of try to envision them as a little in-house company that is on the platform and then learn from that. What are the frustrations, what are the pain points, what are the ways that this is not a good experience for the developer. So, in doing so, we serve both those purposes, kind of plugging a hole, but also dog fooding our own platform. 00:51:05 - Speaker 1: Yeah, absolutely. I know that on the slack team they did this where they built the calendar integrations and then regularly sent usage reports to those companies being like, here’s how many people are using it, like, is this worth it now? Is it worth it now? And I think, you know, eventually it works, but it takes a while sometimes. 00:51:23 - Speaker 2: Now you spoke about trying to be a good communicator and be human and all that sort of thing and when you were on the platform creator side of the equation, being on the other side of that, how do you think Slack did or what was your experience like? 00:51:35 - Speaker 1: Yeah, I think Slack had a lot of great things that they did, and overall were very net positive as an ecosystem and platform creator. They were able to allow a lot of businesses to thrive, but I mean like all companies, it’s not all great and they had some missteps. I think for us specifically we experienced, you know, this exact kind of like encroachment into our space that every kind of platform creator. Fears. So we were building a lot of features, especially around the Google Calendar product, and kind of unbeknownst to us, Slack had been working on their own second Google calendar integration. I think I remember this very vividly cause we actually were invited to speak at their conference. It was called Slack Connect, and I did my panel and it was great, and then later that day they unveiled this calendar integration that Really, really was a bit of a gut punch to us. I think these are times where, you know, you wish communication were a little bit more open and trust was built up, you know, we know that we are one of many. At the time there was probably 4 or 500 apps in their Slack directory. So we knew that we weren’t, you know, the only folks there, but These are the moments where having a little bit of goodwill goes a long way, cause we saw, you know, our installs dropped huge percentage, and customers were reconsidering cause they were like, well, maybe I don’t need eventbot. So it kind of put us on our heels, and it took us a very long time to readjust our roadmap to figure it out. I mean, we’re a team of two at the time, so you can imagine like, If you are changing any investment in roadmap, like, you can only do a couple of features at a time. It’s really hard to do, to be resourced and strap right there. So, it was tough. I do think Slack has gotten a lot better. Their ecosystem team has done a really great job now of literally creating a combo board of features they are building, and they’re pretty public about this, so they are at least giving folks a heads up into spaces they will go. They also do this for infrastructure, you know, hey, to be on the slack platform, you’re gonna have to have this technical back end, and so they’ve given people a lot of notice that these things are gonna change. We had an incredible experience with people finding us organically, and then being able to take that interest and create products around it. But I think it’s always been a challenge to see further than a couple of months or 6 months down in the road map, because you don’t know what Slack is gonna do. They’re under deep competition with Microsoft Teams, and so you kind of are hoping that like, hey, I hope my niche isn’t too interesting to them, that they want to take it over, but interesting enough that they think that we’re valuable and want to like help us out on the sales side. There’s a fine line there, but Overall, I think that they did a pretty good job of allowing entire businesses to form, and many of them, you know, have now been acquired and have spun out to very large things. I was just talking to the folks who ran Disco, which was acquired by CultureAmp. And then Troops, which I think was maybe the largest Salesforce add-on, got acquired by Salesforce directly. And so there have been definitely some strong successes that came out of that, and Slack was smart about it. They even had a fund, I think that’s probably one of the more unique things I saw. They created a venture fund attached to their ecosystem, so they would definitely try to be financially aligned with their ecosystem as much as they could. 00:55:04 - Speaker 3: I’m curious about your experience. Building on Slack, but also building a Google calendar. It almost strikes me as building on two platforms at once, to some degree. One very stable, it’s been around a long time. Google Calendar is probably not gonna like shift underneath you. But do you see that being very common? Maybe in the GitHub world as well, or in other interactions you had with creators on Slack where they had feet in multiple platforms, and if any one of them changed. Then they were in a tough spot. Does that increase the risk, or do you think in that case, well, Google Calendar is stable enough, it really didn’t increase your risk. The momentum of slack and the dynamic nature of that platform is really where all the risk was anyway. 00:55:49 - Speaker 1: Oh no, I think you’re right, it dramatically increases the risk. You’re, you know, toxing your ability to keep up and even just to do maintenance and keep it running, like you have lots of risk of it blowing up from either side of the connection. I will say that it’s actually pretty common in a lot of the bigger ecosystems to have these kind of two-sided integrations. They’re essentially just like really beefed up zappier plug-ins, like this could be, you know, something you could automate, but like, here’s a tool that does it. We actually took out a lot of that risk, because what we did is we integrated with Slack directly via their API. But then when we integrated with every other calendar, we used the dot ICS kind of Cal format, which is an international standard that almost every calendar can integrate with. So we kind of intentionally didn’t go the even deeper route with Google Calendar, knowing that it was going to be much more difficult to like maintain and increase, and customers every year would give us these like top requests, and that was probably one of their biggest requests is I want it auto populating. Instead of like, hey, you just have to connect this ICS calendar and it’ll populate in under an hour. So we kind of took the customer dissatisfaction to give ourselves a little bit more breathing room. But yeah, it’s a really good point that those two sided integrations can be a gold mine if you find a really good niche and build it out, but it’s a risk that, you know, either side ends up saying that’s a great idea, we’re gonna do it. 00:57:20 - Speaker 2: And coming back to what I mentioned in the beginning, which is sort of the technical side of a platform to build on, and the business side, called the distribution aspect or the partnership aspect. I’m curious for the case of building eventpot. How much was Slack’s API and the technical infrastructure and the fact that maybe you don’t need to worry about user identity or you have a bunch of existing kind of UI concepts like channels, for example, that your users already know and you can skip forward to some unique value that you’re providing versus, you know, making basic login pages or onboarding flows, how much was the value in that versus Either one, you’re in their marketplace and people just search there and find you, or even just that they Google Slack group calendar and they find you. 00:58:08 - Speaker 1: Oh yeah, we ran a lot of those ads too, very successfully in the beginning, but the ability to not have to deal with common overhead for us was a really big boon to creating our company. Knowing that we didn’t have to worry about maintaining user databases and Keeping track of like every workspace and all the details that essentially Slack takes care of because that’s their products, bread and butter. We could essentially use that and bootstrap off of that. So it saved us countless hours of time, and also I think for a lot of our customers, some of them are, you know, very big businesses, they would have really deep requirements if we even wanted to build that for ourselves. So, knowing that Slack like has the resources and has the kind of edge cases filled out, great, it allows us to focus on much more. Unique value adds on top. And I think also channels as a concept was new to people. I mean, they understood threads of email, and then when you move to a channel-based kind of topic discussion forum, they didn’t know how to react and so it allows you to take that space where it’s not defined on what it should work like, and then add to what it could work like. As an example, a lot of people had a Happy hour type slack channel that they would just use for happy hours. And so we would say, oh, we can create a calendar behind that, and every channel gets its own calendar, so everyone can create their own events that live inside of that channel. And so we started pushing the boundaries of what people thought a channel was. It wasn’t just chat, it’s also a calendar, and we introduced a visual calendar system in our second year, where you could see a visual calendar of that channel’s activity. So people were like, oh great, every Monday morning I know exactly what’s going on for the rest of this week as it relates to this topic. So I do think that Slack’s kind of basics gave us the jumping off point to build some really cool stuff. Even if we wanted to build it, we wouldn’t have been able to recreate it, but seeing that it was there, it gave us just, you know, nice constraints to create some innovative stuff. 01:00:16 - Speaker 2: And certainly our experience on news and well you probably also can speak to this for other apps and companies you’ve been a part of, but, you know, the Apple platforms at this point, particularly the iOS, is just one of the most filled out in the w