Podcasts about Yak shaving

Foundations of Amateur Radio Have you ever come across a solution to a problem that you sort of knew you had, but didn't really appreciate until that moment? I had one of those recently. To set the scene, fair warning, we're not going to solve this today, we're still very much shaving yaks, but there's plenty to take away. So, the scene. I'm hosting my weekly net. It's going well. All the internet links are up and running again, thanks to the hard work behind the scenes of several unsung heroes, I can name a few, Bob VK6ZGN, John VK6RX and Rob VK6LD, but there are plenty of others whom I don't know and who have yet to stick up their hand to say, I was there. Regardless, thank you. Anyway, I'm hosting my weekly net, F-troop. A curious thing is occurring. Two of the stations are emitting a tone during their transmission. I'm pretty hot on how things sound, so I ask. We talk about it for a bit when Allen VK6XL comes in and tells us that according to his spectrum analyser it's a 1 kHz tone with harmonics and it's on all transmissions, just audible on two. This starts a conversation about spectrum analysers when Allen mentions that he's using an audio spectrum analyser, a piece of software running on his computer. The software has a copyright from 1999 and based on the documentation I saw, has lots of excellent functionality. I might even be able to run it on a Linux machine using WINE, but that's an adventure for another day. Randall VK6WR points out that I could use the spectrum display on Audacity. This is a much more current piece of software, but it's not intended for real-time use, it's what I use to edit the audio after recording my podcast. Not even sure if the spectrum display can show during recording, I've never tried. In the past I've used SoX, the Swiss Army knife of sound processing to create sonograms, but that too isn't real-time. Then it hits me. I have a real-time tool. I've been playing with it for weeks. GNU Radio. Surely it has a spectrum display, and indeed it does, several. So, I already have a tool, purpose built for processing signals, that can do all the things I'm looking for and some I've not yet imagined. Before I proceed, I'll remind you that we're in the middle of the Bald Yak project, so named because by the time we're done there won't be much hair left, if any. In case you're unfamiliar, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. So, boldly clicking about, I set on the notion of making a block called "fosphor" work. Depending on which description you use, it's an Open Source, GPU-accelerated FFT and Waterfall display tool. What that means is that it uses a graphics processor to do the heavy lifting and has the ability to show signal levels across frequencies and on a waterfall display. Apparently it's a block for RTSA-like spectrum visualisation. I'm fairly sure that doesn't mean Railway Technical Society of Australasia or has any relationship with Reverse Total Shoulder Arthroplasty or the Road Transport and Safety Agency of Zambia. I'll admit that I didn't see the GPU part of that description until several days later. Had I seen it at the time, I would likely have carefully backed away and shelved the idea, but that's all water under the bridge. To cut to the chase, I have yet to make this show a single pixel. I smelled trouble for the first time when I discovered a post asking if anyone had gotten this to work on a current release of Debian. I came across a lovely post by what appears to be the author helping some hapless user, and I'll confess that's the camp I'm currently in, to make it work. I have no doubt that I can make it work, but that's going to take some effort. Now, at this point you might ask me why I wasted your time with this tale of woe? Well, the answer is simple. This is what "Yak Shaving" looks like. You solve a thousand little problems, one at a time, and if you manage to keep track of what you're doing and why, you can get stuff done. This applies here, but it also applies in your life, in radio, in antenna building, in making a contact, in participating in a contest, in activating a park. Each activity reveals myriad issues that you'll each need to resolve. The more practice you have at this, the better you'll get. I will point out that for me it's not without stress. When I go though intractable problems I'm often as grumpy as a bear with a sore tooth whilst my brain is running like a hamster in a wheel generating kilowatts of power. This too shall pass. Oh, because I know it's bothering you. RTSA, Real Time Spectrum Analyser, obvious, right? I'm Onno VK6FLAB

There was a time when William Shakespeare was just another little seven-year-old in school. Classes in his day were demanding — and all in Latin. A new book argues that this rigorous curriculum actually nurtured the creativity that later flourished in Shakespeare's writing. Plus, why do we refer to an unpredictable person as a loose cannon? The answer lies in the terrifying potential of a large weapon aboard a warship. And when a delivery driver's wife teases him about cavorting with strumpets, he asks: What exactly is a strumpet? All that, plus picayune, sit on a tack, the many meanings of fell, a Spanish idiom about oysters and boredom, pickthank, a puzzle about rhyming words, a terrifying passage from Victor Hugo, tacos called mariachis, the juice was worth the squeeze, and more. Read full show notes, hear hundreds of free episodes, send your thoughts and questions, and learn more on the A Way with Words website: https://waywordradio.org/contact. Be a part of the show: call 1 (877) 929-9673 toll-free in the United States and Canada; worldwide, call or text/SMS +1 (619) 800-4443. Email words@waywordradio.org. Copyright Wayword, Inc., a 501(c)(3) corporation. Learn more about your ad choices. Visit megaphone.fm/adchoices

Have you heard of Django? It's this little web framework that, well, kicked off much of Python's significance in the web space back in 2005. And that makes Django officially an adult. That's right, Django is now 18. And Django continues to lead the way on how community should be done for individual projects such as web frameworks. We have Carlton Gibson and Will Vincent back on the show this episode to discuss a bit of the Django history, Django trends in 2023, a little HTMX + Django, and lots more. Links from the show Guests Will Vincent: wsvincent.com Carlton Gibson: @carlton@fosstodon.org Button.dev: btn.dev Learn Django: learndjango.com Django News: django-news.com Yak-Shaving to Where the Puck is Going to Be Talk: youtube.com Open Source for the Long Haul: fosstodon.org Django 4.2: docs.djangoproject.com Django 5: docs.djangoproject.com Environs: github.com Neapolitan: github.com Django Template Paritals: github.com Jinja Partials: github.com Django Chat Podcast: djangochat.com Locality of Behavior Essay: htmx.org HTMX: htmx.org You're Fullstack Now Meme: twitter.com Deployment Checklist: docs.djangoproject.com Django-HTMX: github.com Django @Instagram DjangoChat: djangochat.com Talk Python HTMX Course: talkpython.fm Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors Sentry Error Monitoring, Code TALKPYTHON Talk Python Training

Brandon Williams from Point-Free comes on to talk about what dependencies are and managing then whether in testing or dealing with scaling.Guest Brandon Williams @mbrandonw Mastodon @mbrandonw@hachyderm.io Point-Free Point-Free @ Github Related Episodes Episode 80 - A Tour of Software Testing with Christina Moulton Episode 144 - Yak Shaving with Tim Mitra Episode 137 - Humane Development with Jill Scott Episode 133 - The Composable Architecture with Zev Eisenberg Episode 123 - Microapps Architecture with Majid Jabrayilov Episode 93 - Test-Driven Development in Swift with Gio Lodi Episode 107 - Expert Swift with Shai Mishali Related Links  Swift AST Explorer NYSwifty 23 | Take control of your dependencies, don't let them control you Social MediaEmailleo@brightdigit.comGitHub - @brightdigitTwitter BrightDigit - @brightdigitLeo - @leogdionLinkedInBrightDigitLeoInstagram - @brightdigitPatreon - empowerappshowCreditsMusic from https://filmmusic.io"Blippy Trance" by Kevin MacLeod (https://incompetech.com)License: CC BY (http://creativecommons.org/licenses/by/4.0/) (00:00) - EmpowerApps.Show (00:03) - What's a dependency (03:28) - Testing and Dependencies (07:45) - Mocking Dependencies (12:16) - Testing VS Persistance (15:31) - Testing and the Community (18:34) - Simulator and Dependencies (21:18) - Testing Spectrum (23:00) - Safety and Ergonomics (33:11) - WWDC 2023 ★ Support this podcast on Patreon ★

Ben and Matt finish shaving the yak from the prior episode. While waiting for DNS certificate validation to complete, our hosts discuss the "branch based environment" approach to infrastructure, and consider how serverless services make that model a bit cheaper.

Matt and Ben hit the record button while shaving a yak and then attempt to pass it off as a podcast episode. Join our hosts as they troubleshoot DNS problems, fiddle with makefiles, and fail to remember the things that their prior selves did.

Yak Shaving is a term used to describe the conclusion of the often frustrating trail of seemingly never-ending tasks that becomes apparent when trying to complete one simple task - that you thought was going to be quick and easy. In the podcast, we apply it to software coding, project management, family holidays, winning The Apprentice and more... Jono also references another sketch that covers Hofstadter's Law. Let us know when you've ended up Yak Shaving by leaving comments for this sketch on Instagram or Twitter. You can find all three of us on Social Media here: Jono Hey, Tom Pellereau, Rob Bell. Find many more sketches at Sketchplanations.com All Music on this podcast series is provided by Franc Cinelli. Find many more tracks at franccinelli.com Hosted on Acast. See acast.com/privacy for more information.

Mohammad Azam (aka Azam Sharp) talks about RealityKit and how to get started as well as his recent article exporting large-scale SwiftUI app development.Guest Mohammad Azam (Website) Twitter (@azamsharp) YouTube Channel - azamsharp Building Large-Scale Apps with SwiftUI: A Guide to Modular Architecture Related Episodes Episode 144 - Yak Shaving with Tim Mitra Episode 142 - Mobile System Design with Tjeerd in 't Veen Episode 135 - Behind the Scenes of SwiftUI with Aviel Gross Episode 121 - Server-Driven UI with Mohammad Azam Episode 82 - Game Development with Tammy Coron We talked about  (00:00) - RealityKit (10:52) - SwiftUI Architecture (24:01) - SwiftUI Navigation (27:22) - SwiftUI Testing Social MediaTwitter Leo - @leogdionTwitter BrightDigit - @brightdigitLinkedIn - @leogdionGitHub - @brightdigitGitHub - @leogdionTikTok - @brightdigitMastodon - @leogdion@c.imYoutube - @brightdigitCreditsMusic from https://filmmusic.io"Blippy Trance" by Kevin MacLeod (https://incompetech.com)License: CC BY (http://creativecommons.org/licenses/by/4.0/) ★ Support this podcast on Patreon ★

Tim Mitra comes on to talk about the some skills which are helpful for large teams, also how to gauge Apple's rumors and of course yak shaving.Guest Tim Mitra (website) Mastodon  @timmitra@mastodon.social GitHub @Timmitra Twitter @TimMitra More Than Just Code Podcast  Spockcast Podcast Pragmatic Hero's Journe‪y RoundaboutFM Related Links Learning Domain Driven Design ATP Episode 520 Stringslint Related Episodes E142 - Mobile System Design with Tjeerd in 't Veen E137 - Humane Development with Jill Scott E123 - Microapps Architecture with Majid Jabrayilov E76 - Scaling and Security with Jeroen Leenarts E87 - Core Data Fun with Tim Mitra We talked about  (00:00) - Help? (01:09) - Video Games (04:15) - Buzzwords and Trends (09:36) - QA and Testing (16:35) - Multi Disciplinary Engineering (17:54) - Programming Language for Getting Started (21:58) - Breaking Things Down (26:40) - Domain Driven Design (35:25) - Apple Rumors Social MediaTwitter Leo - @leogdionTwitter BrightDigit - @brightdigitLinkedIn - @leogdionGitHub - @brightdigitGitHub - @leogdionTikTok - @brightdigitMastodon - @leogdion@c.imYoutube - @brightdigitCreditsMusic from https://filmmusic.io"Blippy Trance" by Kevin MacLeod (https://incompetech.com)License: CC BY (http://creativecommons.org/licenses/by/4.0/) ★ Support this podcast on Patreon ★

Victor is a software consultant in Tokyo who describes himself as a yak shaver. He writes on his blog at vadosware and curates Awesome F/OSS, a mailing list of open source products. He's also a contributor to the Open Core Ventures blog. Before our conversation Victor wrote a structured summary of how he works on projects. I recommend checking that out in addition to the episode. Topics covered: Most people should use Dokku or CapRover But he uses Kubernetes anyways Hosting a Database in Kubernetes Learning technology You don't really know a thing until something goes wrong History of Frontend Development Context from lower layers of the stack and historical projects Good project pages have comparisons to other products Choosing technologies Language choice affects maintainability Knowing an ecosystem Victor's preferred stack Technology bake offs Posting findings means you get free corrections Why people use medium instead of personal sites Victor VADOSWARE - Blog How Victor works on Projects - Companion post for this episode Awesome FOSS - Curated list of OSS projects NimbusWS - Hosted OSS built on top of budget cloud providers Unvalidated Ideas - Startup ideas for side project inspiration PodcastSaver - Podcast index that allows you to choose Postgres or MeiliSearch and compare performance and results of each Victor's preferred stack Docker - Containers Kubernetes - Container provisioning (Though at the beginning of the episode he suggests Dokku for single server or CapRover for multiple) TypeScript - JavaScript with syntax for types. Victor's default choice. Rust - Language he uses if doing embedded work, performance is critical, or more correctness is desired Haskell - Language he uses if correctness and type system is the most important for the project Postgresql - General purpose database that's good enough for most use cases including full text search. KeyDB - Redis compatible database for caching. Acquired by Snap and then made open source. Victor uses it over Redis because it is multi threaded and supports flash storage without a Redis Enterprise license. Pulumi - Provision infrastructure with the languages you're already using instead of a specialized one or YAML Svelte and SvelteKit - Preferred frontend stack. Previously used Nuxt. Search engines Postgres Full Text Search vs the rest Optimizing Postgres Text Search with Trigrams OpenSearch - Amazon's fork of Elasticsearch typesense meilisearch sonic Quickwit JavaScript build tools Babel SWC Webpack esbuild parcel Vite Turbopack JavaScript frameworks React Vue Svelte Ember Frameworks built on top of frameworks Next - React Nuxt - Vue SvelteKit - Svelte Astro - Multiple Historical JavaScript tools and frameworks Underscore jQuery MooTools Backbone AngularJS Knockout Aurelia GWT Bower - Frontend package manager Grunt - Task runner Gulp - Task runner Related Links Dokku - Open source single-host alternative to Heroku Cloud Native Buildpacks - Buildpacks created by Heroku and Pivotal and used by Dokku CapRover - An open source PaaS-like abstraction built on top of Docker Swarm Kelsey Hightower's tweet about being cautious about running databases on Kubernetes Settling the Myth of Transparent HugePages for Databases Kubernetes Container Storage Interface (CSI) Kubernetes Local Persistent Volumes Longhorn - Distributed block storage for Kubernetes Postgres docs Postgres TOAST Everything I've seen on optimizing Postgres on ZFS Kubernetes Workload Resources Kubernetes Network Plugins Kubernetes Ingress Traefik Kubernetes the Hard Way (Setting up a cluster in a way that optimizes for learning) How does TLS work Let's Encrypt Cert manager for Kubernetes Choose Boring Technology A Linux user's guide to Logical Volume Management Docker networking overview Kubernetes Scheduler Tauri - Build desktop applications with web technology and Rust ripgrep - CLI tool to recursively search directory for a regex pattern (Meant to be a rust replacement for grep) angle-grinder / ag - CLI tool to parse and process log files written in rust Object.observe ECMAScript Proposal to be Withdrawn Ruby on Rails - Ruby web framework Django - Python web framework Laravel - PHP web framework Adonis - JavaScript NestJS - JavaScript What is a NullPointerException, and how do I fix it? Mastodon Clap - CLI argument parser for Rust AWS CDK - Provision AWS infrastructure using programming languages Terraform - Provision infrastructure with terraform language URL canonicalization of duplicate pages and the use of the canonical tag - Used by dev.to to send google traffic to the original blogpost instead of dev.to Transcript You can help edit this transcript on GitHub. [00:00:00] Jeremy: This episode, I talk to Victor Adossi who describes himself as a yak shaver. Someone who likes trying a whole bunch of different technologies, seeing the different options. We talk about what he uses, the evolution of front end development, and his various projects. Talking to just different people it's always good to get where they're coming from because something that works for Google at their scale is going to be different than what you're doing with one of your smaller projects. [00:00:31] Victor: Yeah, the context. Of course in direct conflict with that statement, I definitely use Google technology despite not needing to at all right? Like, you know, 99% of people who are doing like people like to call it indiehacking or building small products could probably get by with just Dokku. If you know Dokku or like CapRover. Are two projects that'll be like, Oh, you can just push your code here, we'll build it up like a little mini Heroku PaaS thing and just go on one big server, right? Like 99% of the people could just use that. But of course I'm not doing that. So I'm a bit of a hypocrite in that sense. I know what I should be doing, but I'm not doing that. I am writing a Kubernetes cluster with like five nodes for no reason. Uh, yeah, I dunno, people don't normally count the controllers. [00:01:24] Jeremy: Dokku and CapRover, I think those are where it's supposed to create a heroku like experience I think it's based off of the heroku buildpacks right? At least Dokku is? [00:01:36] Victor: Yeah Buildpacks has actually been spun out into like a community thing so like pivotal and heroku, it's like buildpacks.io, they're trying to build a wider standard around it so that more people can get involved. And buildpacks are actually obviously fantastic as a technology and as a a process piece. There's not much else like them and you know, that's obvious from like Heroku's success and everything. I know Dokku uses that. I don't know that Caprover does, but I haven't, I haven't really run Caprover that much. They, they probably do. Like at this point if you're going to support building from code, it seems silly to try and build your own buildpacks. Cause that's what you will do, eventually. So you might as well use what's there. Anyway, this is like just getting to like my personal opinions at this point, but like, if you think containers are a bad idea in 2022, You're wrong, you should, you should stop. Like you should, you should stop. Think about it. I mean, obviously there's not, um, I got a really great question at an interview once, which is, where are containers a bad idea? That's probably one of the best like recent interview questions I've ever gotten cause I was like, Oh yeah, I mean, like, you can't, it can't be perfect everywhere, right? Nothing's perfect everywhere. So it's like, where is it? Uh, and of course the answer was networking, right? (unintelligible) So if you need absolute performance, but like for just about everything else. Containers are kind of it at this point. Like, time has born it out, I think. So yeah, I always just like bias at taking containers at this point. So I'm probably more of a CapRover person than a Dokku person, even though I have not used, I don't use CapRover. [00:03:09] Jeremy: Well, like something that I've heard with containers, and maybe it's changed recently, but, but something that was kind of holdout was when people would host a database sometimes they would oh we just don't wanna put this in a container and I wonder if like that matches with your thinking or if things have changed. [00:03:27] Victor: I am not a database administrator right like I read postgres docs and I read the, uh, the Postgres documentation, and I think I know a bit about postgres but I don't commit right like so and I also haven't, like, oh, managed X terabytes on one server that you are making sure never goes down kind of deal. But the stickiness for me, at least from when I've run, So I've done a lot of tests with like ZFS and Postgres and like, um, and also like just trying to figure out, and I run Postgres in Kubernetes of course, like on my cluster and a lot of the stuff I found around is, is like fiddly kernel things like sort of base kernel settings that you need to have set. Like, you know, stuff like should you be using transparent huge pages, like stuff like that. But once you have that settled. Containers are just processes with name spacing and resource control, right? Like, that's it. there are some other ins and outs, but for the most part, if you're fine running a process, so people ran processes, right? And they were just completely like unprotected. Then people made users for the processes and they limited the users and ran the processes, right? Then the next step is now you can run a process and then do the limiting the name spaces in cgroups dynamically. Like there, there's, there's sort of not a humongous difference, unless you're hitting something very specific. Uh, but yeah, databases have been a point of contention, but I think, Kelsey Hightower had that tweet yeah. That was like, um, don't run databases in Kubernetes. And I think he called it back. [00:04:56] Victor: I don't know, but I, I know that was uh, was one of those things that people were really unsure about at first, but then after people sort of like felt it out, they were like, Oh, it's actually fine. Yeah. [00:05:06] Jeremy: Yeah I vaguely remember one of the concerns having to do with persistent storage. Like there were challenges with Kubernetes and needing to keep that storage around and I don't know if that's changed yeah or if that's still a concern. [00:05:18] Victor: Uh, I'd say that definitely has changed. Uh, and it was, it was a concern, depending on where you were. Mostly people who are running AKS or EKS or you know, all those other managed Kubernetes, they're just using EBS or like whatever storage provider is like offering for storage. Most of those people don't actually have that much of a problem with, storage in general. Now, high performance storage is obviously different, right? So like, so you'll, you're gonna have to start doing manual, like local volume management and stuff like that. it was a problem, because obviously CSI (Kubernetes Container Storage Interface) didn't exist for some period of time, and like there was, it was hard to know what to do for if you were just running a Kubernetes cluster. I think a lot of people were just using local, first of all, local didn't even exist for a bit. Um, they were just using host path, right? And just like, Oh, it's on the disk somewhere. Where do we, we have to go get it right? Or we have to like, sort of manage that. So that was something most people weren't ready for, especially if you were just, if you weren't like sort of a, a, a traditional sysadmin and used to doing that stuff. And then of course local volumes came out, but I think they still had to be, um, pre-provisioned. So that's sysadmin stuff that most people, you know, maybe aren't, aren't necessarily ready for. Uh, and then most of the general solutions were slow. So like, I used Longhorn (https://longhorn.io) for a long time and Longhorn, Longhorn's great. And super easy to set up, but it can be slower and you can have some, like, delays in mount time. it wasn't ideal for, for most people. So yeah, I, overall it's true. Databases, Databases in Kubernetes were kind of fraught with peril for a while, but it wasn't for the reason that, it wasn't for the fundamental reason that Kubernetes was just wrong or like, it wasn't the reason most people think of, which is just like, Oh, you're gonna break your database. It's more like, running a database is hard and Kubernetes hasn't solved all the hard problems. Like, cuz that's what Kubernetes does. It basically solves a lot of problems in a very generic way. Right. So it just hadn't solved all those problems yet at this point. I think it's got decent answers on a lot of them. So I, I mean, I don't know. I I do it. Don't, don't take what I'm saying to your, you know, PM meeting or your standup meeting, uh, anyone who's listening. But it's more like if you could solve the problems with databases in the sense before. You could probably solve 'em on Kubernetes now with a good understanding of Kubernetes. Cause at the end of the day, it's all the same stuff. Just Kubernetes makes it a little easier to, uh, do it dynamically. [00:07:50] Jeremy: It sounds like you could do it before, but some of the, I guess the tools or the ways of doing persistent storage were not quite there yet, or they were difficult to use. And so that was why people at the start were like, Okay, maybe it's not a good idea, but, now maybe there's some established practices for how you should run a database in Kubernetes. And I, I suppose the other aspect too is that, like you were saying, Kubernetes is its own thing. You gotta learn Kubernetes and all its intricacies. And then running a database is also its own challenge. So if you stack the two of them together and, and the path was not really clear then maybe at the start it wasn't the best idea. Um, uh, if somebody was going to try it out now, was there like a specific resource you looked at or a specific path to where like okay this is is how I'm going to do it. [00:08:55] Victor: I'll just say what I normally recommend to everybody. Cause it depends on which path you wanna go right? If you wanna go down like running a database path first and figure that out, fill out that skill tree. Like go read the Postgres docs. Well, first of all, use Postgres. That's the first tip there. But like, read those documents. And obviously you don't have to understand everything. You won't understand everything. But knowing the big pieces and sort of letting your brain see the mention of like a whole bunch of things, like what is toast? Oh, you can do compression on columns. Like, you can do some, some things concurrently. Um, you know, what ALTER TABLE looks like. You get all that stuff kind of in your head. Um, and then I personally really believe in sort of learning by building and just like iterating. you won't get it right the first time. It's just like, it's not gonna happen. You're get, you can, you can get better the first time, right? By being really prepared and like, and leave yourself lots of outs, but you kind of have to like, get it out there. Do do your best to make sure that you can't fail, uh, catastrophically, right? So this is like, goes back to that decision to like use ZFS as the bottom of this I'm just like, All right, well, I, I'm not a file systems expert, but if I. I could delegate some of that, you know, some of that, I can get some of that knowledge from someone else. Um, and I can make it easier for me to not fail catastrophically. For the database side, actually read documentation on Postgres or the whatever database you're going to use, make sure you at least understand that. Then start running it like locally or whatever. Again, Docker use, use Docker locally. It's, it's, it's fine. and then, you know, sort of graduate to running sort of more progressively, more complicated versions. what I would say for the Kubernetes side is actually similar. the Kubernetes docs are really good. they're very large. but they're good. So you can actually go through and know all the, like, workload, workload resources, know, like what a config map is, what a secret is, right? Like what etcd is doing in this whole situation. you know, what a kublet is versus an API server, right? Like the, the general stuff, like if you go through all that, you should have like a whole bunch of ideas at least floating around in your head. And then once you try and start setting up a server, they will all start to pop up again, right? And they'll all start to like, you, like, Oh, okay, I need a CNI (Container Networking) plugin because something needs to make the services available, right? Or something needs to power the ingress, right? Like, if I wanna be able to get traffic, I need an ingress object. But what listens, what does that, what makes that ingress object do anything? Oh, it's an ingress controller. nginx, you know, almost everyone's heard of nginx, so they're like, okay. Um, nginx, has an ingress control. Actually there's, there used to be two, I assume there's still two, but there's like one that's maintained by Kubernetes, one that's maintained by nginx, the company or whatever. I use traefik, it's fantastic. but yeah, so I think those things kind of fall out and that is almost always my first way to explain it and to start building. And tinkering iteratively. So like, read the documentation, get a good first grasp of it, and then start building yourself because you'll, you'll get way more questions that way. Like, you'll ask way more questions, you won't be able to make progress. Uh, and then of course you can, you know, hop into slacks or like start looking around and, and searching on the internet. oh, one of the things that really helped me out early learning Kubernetes was, Kelsey Hightower's, um, learn Kubernetes the hard way. I'm also a big believer in doing things the hard way, at least knowing what you're choosing to not know, right? distributing file system, Deltas, right? Or like changes to a file system over the network is not a new problem. Other people have solved it. There's a lot of complexity there. but if you at least know the sort of surface level of what the thing does and what it's supposed to do and how it's supposed to do it, you can make a decision on, Oh, how deep am I going to go? Right? To prevent yourself from like, making a mistake or going too deep in the rabbit hole. If you have an idea of the sort of ecosystem and especially like, Oh, here, like the basics of how I can use this thing, that's generally very good. And doing things the hard way is a great way to get a, a feel for that, right? Cause if you take some chunk and like, you know, the first level of doing things the hard way, uh, or, you know, Kelsey Hightower's guide is like, get a machine, right? Like, so, like, if you somehow were like, Oh, I wanna run a Kubernetes cluster. but, you know, I don't want use necessarily EKS and you wanna learn it the hard way. You have to go get a machine, right? If you, if you're not familiar, if you run on Heroku the whole time, like you didn't manage your own machines, you gotta go like, figure out EC2, right? Or, I personally use, hetzner I love hetzner, so you have to go figure out hetzner, digital ocean, whatever. Right. And then the next thing's like, you know, the guide's changed a lot, and I haven't, I haven't looked at it in like, in years, actually a while since I, since I've sort of been, I guess living it, but it's, it's like generate certificates, right? So if you've never dealt with SSL and like, sort of like, or I should say TLS uh, and generating certificates and how that whole dance works, right? Which is fascinating because it's like, oh, right, nothing's secure on the internet, except that we distribute root certificates on computers that are deployed in every OS, right? Like, that's a sort of fundamental understanding you may not go deep enough to realize, but if you are fascinated by it, trying to do it manually would lead you down that path. You'd be like, Oh, what, like what is this thing? What is a CSR? Like, why, who is signing my request? Right? And it's like, why do we trust those people? Right? And it's like, you know, that kind of thing comes out and I feel like you can only get there from trying to do it, you know, answering the questions you can. Right. And again, it takes some judgment to know when you should not go down a rabbit hole. uh, and then iterating. of course there are people who are excellent at explaining. you can find some resources that are shortcuts. But, uh, I think particularly my bread and butter has been just to try and do it the hard way. Avoid pitfalls or like rabbit holes when you can. But know that the rabbit hole is there, and then keep going. And sometimes if something's just too hard, you're not gonna get it the first time. Like maybe you'll have to wait like another three months, you'll try again and you'll know more sort of ambiently about everything else. You get a little further that time. that's how I feel about that. Anyway. [00:15:06] Jeremy: That makes sense to me. I think sometimes when people take on a project, they try to learn too many things at the same time. I, I think the example of Kubernetes and Postgres is pretty good example, where if you're not familiar with how do I install Postgres on bare metal or a vm, trying to make sense of that while you're trying to into is probably gonna be pretty difficult. So, so splitting them up and learning them individually, that makes a lot of sense to me. And the whole deciding how deep you wanna go. That's interesting too, because I think that's very specific to the person right because sometimes you wanna go a little deeper because otherwise you don't understand how the two things connect together. But other times it's just like with the example with certificates, some people they may go like, I just put in let's encrypt it gives me my cert I don't care right then, and then, and some people they wanna know like okay how does the whole certificate infrastructure work which I think is interesting, depending on who you are, maybe you go ahh maybe it doesn't really matter right. [00:16:23] Victor: Yeah, and, you know, shout out to Let's Encrypt . It's, it's amazing, right? think Singlehandedly the most, most of the deployment of HTTPS that happens these days, right? so many so many of like internet providers and uh, sort of service providers will use it right? Under the covers. Like, Hey, we've got you free SSL through Let's Encrypt, right? Like, kind of like under the, under the covers. which is awesome. And they, and they do it. So if you're listening to this, donate to them. I've done it. So now that, now the pressure is on whoever's listening, but yeah, and, and I, I wanna say I am that person as well, right? Like, I use, Cert Manager on my cluster, right? So I'm just like, I don't wanna think about it, but I, you know, but I, I feel like I thought about it one time. I have a decent grasp. If something changes, then I guess I have to dive back in. I think it, you've heard the, um, innovation tokens idea, right? I can't remember the site. It's like, um, do, like do boring tech or something.com (https://boringtechnology.club/) . Like it shows up on sort of hacker news from time to time, essentially. But it's like, you know, you have a certain amount of tokens and sort of, uh, we'll call them tokens, but tolerance for complexity or tolerance for new, new ideas or new ways of doing things, new processes. Uh, and you spend those as you build any project, right? you can be devastatingly effective by just sticking to the stack, you know, and not introducing anything new, even if it's bad, right? and there's nothing wrong with LAMP stack, I don't wanna annoy anybody, but like if you, if you're running LAMP or if you run on a hostgator, right? Like, if you run on so, you know, some, some service that's really old but really works for you isn't, you know, too terribly insecure or like, has the features you need, don't learn Kubernetes then, right? Especially if you wanna go fast. cuz you, you're spending tokens, right? You're spending, essentially brain power, right? On learning whatever other thing. So, but yeah, like going back to that, databases versus databases on Kubernetes thing, you should probably know one of those before you, like, if you're gonna do that, do that thing. You either know Kubernetes and you like, at least feel comfortable, you know, knowing Kubernetes extremely difficult obviously, but you feel comfortable and you feel like you can debug. Little bit of a tangent, but maybe that's even a better, sort of watermark if you know how to debug a thing. If, if it's gone wrong, maybe one or five or 10 or 20 times and you've gotten out. Not without documentation, of course, cuz well, if you did, you're superhuman. But, um, but you've been able to sort of feel your way out, right? Like, Oh, this has gone wrong and you have enough of a model of the system in your head to be like, these are the three places that maybe have something wrong with them. Uh, and then like, oh, and then of course it's just like, you know, a mad dash to kind of like, find, find the thing that's wrong. You should have confidence about probably one of those things before you try and do both when it's like, you know, complex things like databases and distributed systems management, uh, and orchestration. [00:19:18] Jeremy: That's, that's so true in, in terms of you are comfortable enough being able to debug a problem because it's, I think when you are learning about something, a lot of times you start with some kind of guide or some kind of tutorial and you follow the steps. And if it all works, then great. Right? But I think it's such a large leap from that to something went wrong and I have to figure it out. Right. Whether it's something's not right in my Dockerfile or my postgres instance uh, the queries are timing out. so many things that could go wrong, that is the moment where you're forced to figure out, okay, what do I really know about this not thing? [00:20:10] Victor: Exactly. Yeah. Like the, the rubber's hitting the road it's uh you know the car's about to crash or has already crashed like if I open the bonnet, do I know what's happening right or am I just looking at (unintelligible). And that's, it's, I feel sort a little sorry or sad for, for devs that start today because there's so much. Complexity that's been built up. And a lot of it has a point, but you need to kind of have seen the before to understand the point, right? So I like, I like to use front end as an example, right? Like the front end ecosystem is crazy, and it has been crazy for a very long time, but the steps are actually usually logical, right? Like, so like you start with, you know, HTML, CSS and JavaScript, just plain, right? And like, and you can actually go in lots of directions. Like HTML has its own thing. CSS has its own sort of evolution sort of thing. But if we look at JavaScript, you're like, you're just writing JavaScript on every page, right? And like, just like putting in script tags and putting in whatever, and it's, you get spaghetti, you get spaghetti, you start like writing, copying the same function on multiple pages, right? You just, it, it's not good. So then people, people make jquery, right? And now, now you've got like a, a bundled set of like good, good defaults that you can, you can go for, right? And then like, you know, libraries like underscore come out for like, sort of like not dom related stuff that you do want, you do want everywhere. and then people go from there and they go to like backbone or whatever. it's because Jquery sort of also becomes spaghetti at some point and it becomes hard to manage and people are like, Okay, we need to sort of like encapsulate this stuff somehow, right? And like the new tools or whatever is around at the same timeframe. And you, you, you like backbone views for example. and you have people who are kind of like, ah, but that's not really good. It's getting kind of slow. Uh, and then you have, MVC stuff comes out, right? Like Angular comes out and it's like, okay, we're, we're gonna do this thing called dirty checking, and it's gonna be, it's gonna be faster and it's gonna be like, it's gonna be less sort of spaghetti and it's like a little bit more structured. And now you have sort of like the rails paradigm, but on the front end, and it takes people to get a while to get adjusted to that, but then that gets too heavy, right? And then dirty checking is realized to be a mistake. And then, you get stuff like MVVM, right? So you get knockout, like knockout js and you got like Durandal, and like some, some other like sort of front end technologies that come up to address that problem. Uh, and then after that, like, you know, it just keeps going, right? Like, and if you come in at the very end, you're just like, What is happening? Right? Like if it, if it, if someone doesn't sort of boil down the complexity and reduce it a little bit, you, you're just like, why, why do we do this like this? Right? and sometimes there's no good reason. Sometimes the complexity is just like, is unnecessary, but having the steps helps you explain it, uh, or helps you understand how you got there. and, and so I feel like that is something younger people or, or newer devs don't necessarily get a chance to see. Cause it just, it would take, it would take very long right? And if you're like a new dev, let's say you jumped into like a coding bootcamp. I mean, I've got opinions on coding boot camps, but you know, it's just like, let's say you jumped into one and you, you came out, you, you made it. It's just, there's too much to know. sure, you could probably do like HTML in one month. Well, okay, let's say like two weeks or whatever, right? If you were, if you're literally brand new, two weeks of like concerted effort almost, you know, class level, you know, work days right on, on html, you're probably decently comfortable with it. Very comfortable. CSS, a little harder because this is where things get hard. Cause if you, if you give two weeks for, for HTML, CSS is harder than HTML kind of, right? Because the interactions are way more varied. Right? Like, and, and maybe it's one of those things where you just, like, you, you get somewhat comfortable and then just like know that in the future you're gonna see something you don't understand and have to figure it out. Uh, but then JavaScript, like, how many months do you give JavaScript? Because if you go through that first like, sort of progression that I, I I, I, I mentioned everyone would have a perfect sort of, not perfect but good understanding of the pieces, right? Like, why did we start transpiling at all? Right? Like, uh, or why did you know, why did we adopt libraries? Like why did Bower exist? No one talks about Bower anymore, obviously, but like, Bower was like a way to distribute front end only packages, right? Um, what is it? Um, Uh, yes, there's grunt. There's like the whole build system thing, right? Once, once we decide we're gonna, we're gonna do stuff to files before we, before we push. So there's grunt, there's, uh, gulp, which is like grunt, but like, Oh, we're gonna do it all in memory. We're gonna pipe, we're gonna use this pipes thing to make sure everything goes fast. then there's like, of course that leads like the insanity that's webpack. And then there's like parcel, which did better. There's vite there's like, there's all this, there's this progression, but how many months would it take to know that progression? It, it's too long. So they end up just like, Hey, you're gonna learn react. Which is the right thing because it's like, that's what people hire for, right? But then you're gonna be in react and be like, What's webpack, right? And it's like, but you can't go down. You can't, you don't have the time. You, you can't sort of approach that problem from the other direction where you, which would give you better understanding cause you just don't have the time. I think it's hard for newer devs to overcome this. Um, but I think there are some, there's some hope on the horizon cuz some things are simpler, right? Like some projects do reduce complexity, like, by watching another project sort of innovate so like react. Wasn't the first component, first framework, right? Like technically, I, I think, I think you, you might have to give that to like, to maybe backbone because like they had views and like marionette also went with that. Like maybe, I don't know, someone, someone I'm sure will get in like, send me an angry email, uh, cuz I forgot you Moo tools or like, you know, Ember Ember. They've also, they've also been around, I used to be a huge Ember fan, still, still kind of am, but I don't use it. but if you have these, if you have these tools, right? Like people aren't gonna know how to use them and Vue was able to realize that React had some inefficiencies, right? So React innovates the sort of component. So Reintroduces the component based model component first, uh, front end development model. Vue sees that and it's like, wait a second, if we just export this like data object, and of course that's not the only innovation of Vue, but if we just export this data object, you don't have to do this fine grained tracking yourself anymore, right? You don't have to tell React or tell your the system which things change when other things change, right? Like you, you don't have to set up this watching and stuff, right? Um, and that's one of the reasons, like Vue is just, I, I, I remember picking up Vue and being like, Oh, I'm done. I'm done with React now. Because it just doesn't make sense to use React because they Vue essentially either, you know, you could just say they learned from them or they, they realize a better way to do things that is simpler and it's much easier to write. Uh, and you know, functionally similar, right? Um, similar enough that it's just like, oh they boil down some of that complexity and we're a step forward and, you know, in other ways, I think. Uh, so that's, that's awesome. Every once in a while you get like a compression in the complexity and then it starts to ramp up again and you get maybe another compression. So like joining the projects that do a compression. Or like starting to adopting those is really, can be really awesome. So there's, there's like, there's some hope, right? Cause sometimes there is a compression in that complexity and you you might be lucky enough to, to use that instead of, the thing that's really complex after years of building on it. [00:27:53] Jeremy: I think you're talking about newer developers having a tough time making sense of the current frameworks but the example you gave of somebody starting from HTML and JavaScript going to jquery backbone through the whole chain, that that's just by nature of you've put in a lot of time right you've done a lot of work working with each of these technologies you see the progression as if someone is starting new just by nature of you being new you won't have been able to spend that time [00:28:28] Victor: Do you think it could work? again, the, the, the time aspect is like really hard to get like how can you just avoid spending time um to to learn things that's like a general problem I think that problem is called education in the general sense. But like, does it make sense for a, let's say a bootcamp or, or any, you know, school right? To attempt to guide people through the previous solutions that didn't work, right? Like in math, you don't start with calculus, right? It just wouldn't, it doesn't make sense, right? But we try and start with calculus in software, right? We're just like, okay, here's the complexity. You've got all of it. Don't worry. Just look at this little bit. If, you know, if the compiler ever spits out a weird error uh oh, like, you're, you're, you're in for trouble cuz you, you just didn't get the. get the basics. And I think that's maybe some of what is missing. And the thing is, it is like the constraints are hard, right? No one has infinite time, right? Or like, you know, even like, just tons of time to devote to learning, learning just front end, right? That's not even all of computing, That's not even the algorithm stuff that some companies love to throw at you, right? Uh, or the computer sciencey stuff. I wonder if it makes more sense to spend some time taking people through the progression, right? Because discovering that we should do things via components, let's say, or, or at least encapsulate our functionality to components and compose that way, is something we, we not everyone knew, right? Or, you know, we didn't know wild widely. And so it feels like it might make sense to touch on that sort of realization and sort of guide the student through, you know, maybe it's like make five projects in a week and you just get progressively more complex. But then again, that's also hard cause effort, right? It's just like, it's a hard problem. But, but I think right now, uh, people who come in at the end and sort of like see a bunch of complexity and just don't know why it's there, right? Like, if you've like, sort of like, this is, this applies also very, this applies to general, but it applies very well to the Kubernetes problem as well. Like if you've never managed nginx on more than one machine, or if you've never tried to set up a, like a, to format your file system on the machine you just rented because it just, you know, comes with nothing, right? Or like, maybe, maybe some stuff was installed, but, you know, if you had to like install LVM (Logical Volume Manager) yourself, if you've never done any of that, Kubernetes would be harder to understand. It's just like, it's gonna be hard to understand. overlay networks are hard for everyone to understand, uh, except for network people who like really know networking stuff. I think it would be better. But unfortunately, it takes a lot of time for people to take a sort of more iterative approach to, to learning. I try and write blog posts in this way sometimes, but it's really hard. And so like, I'll often have like an idea, like, so I call these, or I think of these as like onion, onion style posts, right? Where you either build up an onion sort of from the inside and kind of like go out and like add more and more layers or whatever. Or you can, you can go from the outside and sort of take off like layers. Like, oh, uh, Kubernetes has a scheduler. Why do they need a scheduler? Like, and like, you know, kind of like, go, go down. but I think that might be one of the best ways to learn, but it just takes time. Or geniuses and geniuses who are good at two things, right? Good at the actual technology and good at teaching. Cuz teaching is a skill and it's very hard. and, you know, shout out to teachers cuz that's, it's, it's very difficult, extremely frustrating. it's hard to find determinism in, in like methods and solutions. And there's research of course, but it's like, yeah, that's, that's a lot harder than the computer being like, Nope, that doesn't work. Right? Like, if you can't, if you can't, like if you, if the function call doesn't work, it doesn't work. Right. If the person learned suboptimally, you won't know Right. Until like 10 years down the road when, when they can't answer some question or like, you know, when they, they don't understand. It's a missing fundamental piece anyway. [00:32:24] Jeremy: I think with the example of front end, maybe you don't have time to walk through the whole history of every single library and framework that came but I think at the very least, if you show someone, or you teach someone how to work with css, and you have them, like you were talking about components before you have them build a site where there's a lot of stuff that gets reused, right? Maybe you have five pages and they all have the same nav bar. [00:33:02] Victor: Yeah, you kind of like make them do it. [00:33:04] Jeremy: Yeah. You make 'em do it and they make all the HTML files, they copy and paste it, and probably your students are thinking like, ah, this, this kind of sucks [00:33:16] Victor: Yeah [00:33:18] Jeremy: And yeah, so then you, you come to that realization, and then after you've done that, then you can bring in, okay, this is why we have components. And similarly you brought up, manual dom manipulation with jQuery and things like that. I, I'm sure you could come up with an example of you don't even necessarily need to use jQuery. I think people can probably skip that step and just use the the, the API that comes with the browser. But you can have them go in like, Oh, you gotta find this element by the id and you gotta change this based on this, and let them experience the. I don't know if I would call it pain, but let them experience like how it was. Right. And, and give them a complex enough task where they feel like something is wrong right. Or, or like, there, should be something better. And then you can go to you could go straight to vue or react. I'm not sure if we need to go like, Here's backbone, here's knockout. [00:34:22] Victor: Yeah. That's like historical. Interesting. [00:34:27] Jeremy: I, I think that would be an interesting college course or something that. Like, I remember when, I went through school, one of the classes was programming languages. So we would learn things like, Fortran and stuff like that. And I, I think for a more frontend centered or modern equivalent you could go through, Hey, here's the history of frontend development here's what we used to do and here's how we got to where we are today. I think that could be actually a pretty interesting class yeah [00:35:10] Victor: I'm a bit interested to know you learned fortran in your PL class. I, think when I went, I was like, lisp and then some, some other, like, higher classes taught haskell but, um, but I wasn't ready for haskell, not many people but fortran is interesting, I kinda wanna hear about that. [00:35:25] Jeremy: I think it was more in terms of just getting you exposed to historically this is how things were. Right. And it wasn't so much of like, You can take strategies you used in Fortran into programming as a whole. I think it was just more of like a, a survey of like, Hey, here's, you know, here's Fortran and like you were saying, here's Lisp and all, all these different languages nd like at least you, you get to see them and go like, yeah, this is kind of a pain. [00:35:54] Victor: Yeah [00:35:55] Jeremy: And like, I understand why people don't choose to use this anymore but I couldn't take away like a broad like, Oh, I, I really wish we had this feature from, I think we were, I think we were using Fortran 77 or something like that. I think there's Fortran 77, a Fortran 90, and then there's, um, I think, [00:36:16] Victor: Like old fortran, deprecated [00:36:18] Jeremy: Yeah, yeah, yeah. So, so I think, I think, uh, I actually don't know if they're, they're continuing to, um, you know, add new things or maintain it or it's just static. But, it's, it's more, uh, interesting in terms of, like we were talking front end where it's, as somebody who's learning frontend development who is new and you get to see how, backbone worked or how Knockout worked how grunt and gulp worked. It, it's like the kind of thing where it's like, Oh, okay, like, this is interesting, but let us not use this again. Right? [00:36:53] Victor: Yeah. Yeah. Right. But I also don't need this, and I will never again [00:36:58] Jeremy: yeah, yeah. It's, um, but you do definitely see the, the parallels, right? Like you were saying where you had your, your Bower and now you have NPM and you had Grunt and Gulp and now you have many choices [00:37:14] Victor: Yeah. [00:37:15] Jeremy: yeah. I, I think having he history context, you know, it's interesting and it can be helpful, but if somebody was. Came to me and said hey I want to learn how to build websites. I get into front end development. I would not be like, Okay, first you gotta start moo tools or GWT. I don't think I would do that but it I think at a academic level or just in terms of seeing how things became the way they are sure, for sure it's interesting. [00:37:59] Victor: Yeah. And I, I, think another thing I don't remember who asked or why, why I had to think of this lately. um but it was, knowing the differentiators between other technologies is also extremely helpful right? So, What's the difference between ES build and SWC, right? Again, we're, we're, we're leaning heavy front end, but you know, just like these, uh, sorry for context, of course, it's not everyone a front end developer, but these are two different, uh, build tools, right? For, for JavaScript, right? Essentially you can think of 'em as transpilers, but they, I think, you know, I think they also bundle like, uh, generally I'm not exactly sure if, if ESbuild will bundle as well. Um, but it's like one is written in go, the other one's written in Rust, right? And sort of there's, um, there's, in addition, there's vite which is like vite does bundle and vite does a lot of things. Like, like there's a lot of innovation in vite that has to have to do with like, making local development as fast as possible and also getting like, you're sort of making sure as many things as possible are strippable, right? Or, or, or tree shakeable. Sorry, is is is the better, is the better term. Um, but yeah, knowing, knowing the, um, the differences between projects is often enough to sort of make it less confusing for me. Um, as far as like, Oh, which one of these things should I use? You know, outside of just going with what people are recommending. Cause generally there is some people with wisdom sometimes lead the crowd sometimes, right? So, so sometimes it's okay to be, you know, a crowd member as long as you're listening to the, to, to someone worth listening to. Um, and, and so yeah, I, I think that's another thing that is like the mark of a good project or, or it's not exclusive, right? It's not, the condition's not necessarily sufficient, but it's like a good projects have the why use this versus x right section in the Readme, right? They're like, Hey, we know you could use Y but here's why you should use us instead. Or we know you could use X, but here's what we do better than X. That might, you might care about, right? That's, um, a, a really strong indicator of a project. That's good cuz that means the person who's writing the project is like, they've done this, the survey. And like, this is kind of like, um, how good research happens, right? It's like most of research is reading what's happening, right? To knowing, knowing the boundary you're about to push, right? Or try and sort of like push one, make one step forward in, um, so that's something that I think the, the rigor isn't in necessarily software development everywhere, right? Which is good and bad. but someone who's sort of done that sort of rigor or, and like, and, and has, and or I should say, has been rigorous about knowing the boundary, and then they can explain that to you. They can be like, Oh, here's where the boundary was. These people were doing this, these people were doing this, these people were doing this, but I wanna do this. So you just learned now whether it's right for you and sort of the other points in the space, which is awesome. Yeah. Going to your point, I feel like that's, that's also important, it's probably not a good idea to try and get everyone to go through historical artifacts, but if just a, a quick explainer and sort of, uh, note on the differentiation, Could help for sure. Yeah. I feel like we've skewed too much frontend. No, no more frontend discussion this point. [00:41:20] Jeremy: It's just like, I, I think there's so many more choices where the, the mental thought that has to go into, Okay, what do I use next I feel is bigger on frontend. I guess it depends on the project you're working on but if you're going to work on anything front end if you haven't done it before or you don't have a lot of experience there's so many build tools so many frameworks, so many libraries that yeah, but we [00:41:51] Victor: Iterate yeah, in every direction, like the, it's good and bad, but frontend just goes in every direction at the same time Like, there's so many people who are so enthusiastic and so committed and and it's so approachable that like everyone just goes in every direction at the same time and like a lot of people make progress and then unfortunately you have try and pick which, which branch makes sense. [00:42:20] Jeremy: We've been kind of talking about, some of your experiences with a few things and I wonder if you could explain the the context you're thinking of in terms of the types of projects you typically work on like what are they what's the scale of them that sort of thing. [00:42:32] Victor: So I guess I've, I've gone through a lot of phases, right? In sort of what I use in in my tooling and what I thought was cool. I wrote enterprise java like everybody else. Like, like it really doesn't talk about it, but like, it's like almost at some point it was like, you're either a rail shop or a Java shop, for so many people. And I wrote enterprise Java for a, a long time, and I was lucky enough to have friends who were really into, other kinds of computing and other kinds of programming. a lot of my projects were wrapped around, were, were ideas that I was expressing via some new technology, let's say. Right? So, I wrote a lot of haskell for, for, for a while, right? But what did I end up building with that was actually a job board that honestly didn't go very far because I was spending much more time sort of doing, haskell things, right? And so I learned a lot about sort of what I think is like the pinnacle of sort of like type development in, in the non-research world, right? Like, like right on the edge of research and actual usability. But a lot of my ideas, sort of getting back to the, the ideas question are just things I want to build for myself. Um, or things I think could be commercially viable or like do, like, be, be well used, uh, and, and sort of, and profitable things, things that I think should be built. Or like if, if I see some, some projects as like, Oh, I wish they were doing this in this way, Right? Like, I, I often consider like, Oh, I want, I think I could build something that would be separate and maybe do like, inspired from other projects, I should say, Right? Um, and sort of making me understand a sort of a different, a different ecosystem. but a lot of times I have to say like, the stuff I build is mostly to scratch an itch I have. Um, and or something I think would be profitable or utilizing technology that I've seen that I don't think anyone's done in the same way. Right? So like learning Kubernetes for example, or like investing the time to learn Kubernetes opened up an entire world of sort of like infrastructure ideas, right? Because like the leverage you get is so high, right? So you're just like, Oh, I could run an aws, right? Like now that I, now that I know this cuz it's like, it's actually not bad, it's kind of usable. Like, couldn't I do that? Right? That kind of thing. Right? Or um, I feel like a lot of the times I'll learn a technology and it'll, it'll make me feel like certain things are possible that they, that weren't before. Uh, like Rust is another one of those, right? Like, cuz like Rust will go from like embedded all the way to WASM, which is like a crazy vertical stack. Right? It's, that's a lot, That's a wide range of computing that you can, you can touch, right? And, and there's, it's, it's hard to learn, right? The, the, the, the, uh, the, the ramp to learning it is quite steep, but, it opens up a lot of things you can write, right? It, it opens up a lot of areas you can go into, right? Like, if you ever had an idea for like a desktop app, right? You could actually write it in Rust. There's like, there's, there's ways, there's like is and there's like, um, Tauri is one of my personal favorites, which uses web technology, but it's either I'm inspired by some technology and I'm just like, Oh, what can I use this on? And like, what would this really be good at doing? or it's, you know, it's one of those other things, like either I think it's gonna be, Oh, this would be cool to build and it would be profitable. Uh, or like, I'm scratching my own itch. Yeah. I think, I think those are basically the three sources. [00:46:10] Jeremy: It's, it's interesting about Rust where it seems so trendy, I guess, in lots of people wanna do something with rust, but then in a lot of they also are not sure does it make sense to write in rust? Um, I, I think the, the embedded stuff, of course, that makes a lot of sense. And, uh, you, you've seen a sort of surge in command line apps, stuff ripgrep and ag, stuff like that, and places like that. It's, I think the benefits are pretty clear in terms of you've got the performance and you have the strong typing and whatnot and I think where there's sort of the inbetween section that's kind of unclear to me at least would I build a web application in rust I'm not sure that sort of thing [00:47:12] Victor: Yeah. I would, I characterize it as kind of like, it's a tool toolkit, so it really depends on the problem. And think we have many tools that there's no, almost never a real reason to pick one in particular right? Like there's, Cause it seems like just most of, a lot of the work, like, unless you're, you're really doing something interesting, right? Like, uh, something that like, oh, I need to, I need to, like, I'm gonna run, you know, billions and billions of processes. Like, yeah, maybe you want erlang at that point, right? Like, maybe, maybe you should, that should be, you know, your, your thing. Um, but computers are so fast these days, and most languages have, have sort of borrowed, not borrowed, but like adopted features from others that there's, it's really hard to find a, a specific use case, for one particular tool. Uh, so I often just categorize it by what I want out of the project, right? Or like, either my goals or project goals, right? Depending on, and, or like business goals, if you're, you know, doing this for a business, right? Um, so like, uh, I, I basically, if I want to go fast and I want to like, you know, reduce time to market, I use type script, right? Oh, and also I'm a, I'm a, like a type zealot. I, I'd say so. Like, I don't believe in not having types, right? Like, it's just like there's, I think it's crazy that you would like have a function but not know what the inputs could be. And they could actually be anything, right? , you're just like, and then you have to kind of just keep that in your head. I think that's silly. Now that we have good, we, we have, uh, ways to avoid the, uh, ceremony, right? You've got like hindley Milner type systems, like you have a way to avoid the, you can, you know, predict what types of things will be, and you can, you don't have to write everything everywhere. So like, it's not that. But anyway, so if I wanna go fast, the, the point is that going back to that early, like the JS ecosystem goes everywhere at the same time. Typescript is excellent because the ecosystem goes everywhere at the same time. And so you've got really good ecosystem support for just about everything you could do. Um, uh, you could write TypeScript that's very loose on the types and go even faster, but in general it's not very hard. There's not too much ceremony and just like, you know, putting some stuff that shows you what you're using and like, you know, the objects you're working with. and then generally if I wanna like, get it really right, I I'll like reach for haskell, right? Cause it's just like the sort of contortions, and again, this takes time, this not fast, but, right. the contortions you can do in the type system will make it really hard to write incorrect code or code that doesn't, that isn't logical with itself. Of course interfacing with the outside world. Like if you do a web request, it's gonna fail sometimes, right? Like the network might be down, right? So you have to, you basically pull that, you sort of wrap that uncertainty in your system to whatever degree you're okay with. And then, but I know it'll be correct, right? But and correctness is just not important. Most of like, Oh, I should , that's a bad quote. Uh, it's not that correct is not important. It's like if you need to get to market, you do not necessarily need every single piece of your code to be correct, Right? If someone calls some, some function with like, negative one and it's not an important, it's not tied to money or it's like, you know, whatever, then maybe it's fine. They just see an error and then like you get an error in your back and you're like, Oh, I better fix that. Right? Um, and then generally if I want to be correct and fast, I choose rust these days. Right? Um, these days. and going back to your point, a lot of times that means that I'm going to write in Typescript for a lot of projects. So that's what I'll do for a lot of projects is cuz I'll just be like, ah, do I need like absolute correctness or like some really, you know, fancy sort of type stuff. No. So I don't pick haskell. Right. And it's like, do I need to be like mega fast? No, probably not. Cuz like, cuz so I don't necessarily don't necessarily need rust. Um, maybe it's interesting to me in terms of like a long, long term thing, right? Like if I, if I'm think, oh, but I want x like for example, tight, tight, uh, integration with WASM, for example, if I'm just like, oh, I could see myself like, but that's more of like, you know, for a fun thing that I'm doing, right? Like, it's just like, it's, it's, you don't need it. You don't, that's premature, like, you know, that's a premature optimization thing. But if I'm just like, ah, I really want the ability to like maybe consider refactoring some of this out into like a WebAssembly thing later, then I'm like, Okay, maybe, maybe I'll, I'll pick Rust. Or like, if I, if I like, I do want, you know, really, really fast, then I'll like, then I'll go Rust. But most of the time it's just like, I want a good ecosystem so I don't have to build stuff myself most of the time. Uh, and you know, type script is good enough. So my stack ends up being a lot of the time just in type script, right? Yeah. [00:52:05] Jeremy: Yeah, I think you've encapsulated the reason why there's so many packages on NPM and why there's so much usage of JavaScript and TypeScript in general is that it, it, it fits the, it's good enough. Right? And in terms of, in terms of speed, like you said, most of the time you don't need of rust. Um, and so typescript I think is a lot more approachable a lot of people have to use it because they do front end work anyways. And so that kinda just becomes the I don't know if I should say the default but I would say it's probably the most common in terms of when somebody's building a backend today certainly there's other languages but JavaScript and TypeScript is everywhere. [00:52:57] Victor: Yeah. Uh, I, I, I, another thing is like, I mean, I'm, of ignored the, like, unreasonable effectiveness of like rails Cause there's just a, there's tons of just like rails warriors out there, and that's great. They're they're fantastic. I'm not a, I'm not personally a huge fan of rails but that's, uh, that's to my own detriment, right? In, in some, in some ways. But like, Rails and Django sort of just like, people who, like, I'm gonna learn this framework it's gonna be excellent. It most, they have a, they have carved out a great ecosystem for themselves. Um, or like, you know, even php right? PHP and like Laravel, or whatever. Uh, and so I'm ignoring those, like, those pockets of productivity, right? Those pockets of like intense productivity that people like, have all their needs met in that same way. Um, but as far as like general, general sort of ecosystem size and speed for me, um, like what you said, like applies to me. Like if I, if I'm just like, especially if I'm just like, Oh, I just wanna build a backend, Like, I wanna build something that's like super small and just does like, you know, maybe a few, a couple, you know, endpoints or whatever and just, I just wanna throw it out there. Right? Uh, I, I will pick, yeah. Typescript. It just like, it makes sense to me. I also think note is a better. VM or platform to build on than any of the others as well. So like, like I, by any of the others, I mean, Python, Perl, Ruby, right? Like sort of in the same class of, of tool. So I I am kind of convinced that, um, Node is better, than those as far as core abilities, right? Like threading Right. Versus the just multi-processing and like, you know, other, other, other solutions and like, stuff like that. So, if you want a boring stack, if I don't wanna use any tokens, right? Any innovation tokens I reach for TypeScript. [00:54:46] Jeremy: I think it's good that you brought up. Rails and, and Django because, uh, personally I've done, I've done work with Rails, and you're right in that Rails has so many built in, and the ways to do them are so well established that your ability to be productive and build something really fast hard to compete with, at least in my experience with available in the Node ecosystem. Um, on the other hand, like I, I also see what you mean by the runtimes. Like with Node, you're, you're built on top of V8 and there's so many resources being poured into it to making it fast and making it run pretty much everywhere. I think you probably don't do too much work with managed services, but if you go to a managed service to run your code, like a platform as a service, they're gonna support Node. Will they support your other preferred language? Maybe, maybe not, You know that they will, they'll be able to run node apps so but yeah I don't know if it will ever happen or maybe I'm just not familiar with it, but feel like there isn't a real rails of javascript. [00:56:14] Victor: Yeah, you're, totally right. There are, there are. It's, it's weird. It's actually weird that there, like Uh, but, but, I kind of agree with you. There's projects that are trying it recently. There's like Adonis, um, there is, there are backends that also do, like, will do basic templating, like Nest, NestJS is like really excellent. It's like one of the best sort of backend, projects out there. I I, I but like back in the day, there were projects like Sails, which was like very much trying to do exactly what Rails did, but it just didn't seem to take off and reach that critical mass possibly because of the size of the ecosystem, right? Like, how many alternatives to Rails are there? Not many, right? And, and now, anyway, maybe let's say the rest of 'em sort of like died out over the years, but there's also like, um, hapi HAPI, uh, which is like also, you know, similarly, it was like angling themselves to be that, but they just never, they never found the traction they needed. I think, um, or at least to be as wide, widely known as Rails is for, for, for the, for the Ruby ecosystem, um, but also for people to kind of know the magic, cause. Like I feel like you're productive in Rails only when you imbibe the magic, right? You, you, know all the magic context and you know the incantations and they're comforting to you, right? Like you've, you've, you have the, you have the sort of like, uh, convention. You're like, if you're living and breathing the convention, everything's amazing, right? Like, like you can't beat that. You're just like, you're in the zone but you need people to get in that zone. And I don't think node has, people are just too, they're too frazzled. They're going like, there's too much options. They can't, it's hard to commit, right? Like, imagine if you'd committed to backbone. Like you got, you can't, It's, it's over. Oh, it's not over. I mean, I don't, no, I don't wanna, you know, disparage the backbone project. I don't use it, but, you know, maybe they're still doing stuff and you know, I'm sure people are still working on it, but you can't, you, it's hard to commit and sort of really imbibe that sort of convention or, or, or sort of like, make yourself sort of breathe that product when there's like 10 products that are kind of similar and could be useful as well. Yeah, I think that's, that's that's kind of big. It's weird that there isn't a rails, for NodeJS, but, but people are working on it obviously. Like I mentioned Adonis, there's, there's more. I'm leaving a bunch of them out, but that's part of the problem. [00:58:52] Jeremy: On, on one hand, it's really cool that people are trying so many different things because hopefully maybe they can find something that like other people wouldn't have thought of if they all stick same framework. but on the other hand, it's ... how much time have we spent jumping between all these different frameworks when what we could have if we had a rails. [00:59:23] Victor: Yeah the, the sort of wasted time is, is crazy to think about it uh, I do think about that from time to time. And you know, and personally I waste a lot of my own time. Like, just, just rec

Episode Summary: In this episode, Phil shares his favorite thing about PowerShell: the community. As a leader of the RTPSUG, Phil encourages Andrew and Jordan to submit for Summit while not committing himself fully. Phil loves the PowerShell community and troubleshooting. He doesn't define Yak Shaving but says other stuff worth listening to.    Guest Bio and links: Phil is a Systems Architect with less than 75 years of experience. He has been helping run and organize the RTPSUG for over 6 years and can be heard asking questions during RTPSUG meetings. Phil is an author, speaker, community leader, and more!     https://twitter.com/schlauge  https://github.com/pbossman  https://rtpsug.com/  https://rtpsugmembers.github.io/  http://schlauge.com/  https://www.youtube.com/c/RTPSUG/featured  https://www.youtube.com/watch?v=65Zl7mUGR3U  See the episode on YouTube: https://www.youtube.com/watch?v=sEUGEVpIFPI

In this episode, Daniel shares his experience with PowerShell. We discussed his experiences with Raspberry Pi's, IOT, and how that played a role with his getting involved in the PowerShell community. Daniel shares his thoughts on learning, teaching, and accidentally defines Yak Shaving for us.    Guest Bio and links: Daniel Silva is a DevOps Engineer with a passion for automation and helping others. He loves automating processes and advocating for PowerShell, Terraform, Docker, and Kubernetes. From time to time, he also spends time inventing new projects to work on.  https://github.com/DanielSSilva  https://twitter.com/DanielSilv9  https://danielssilva.gumroad.com/l/NotionGameLibraryIntegration  https://github.com/DanielSSilva/blog/tree/main/content/post  https://blog.danielssilva.dev/ 

Welcome to Code Completion, Episode 97! We are a group of iOS developers and educators hoping to share what we love most about development, Apple technology, and completing your code! Follow us @CodeCompletion (https://twitter.com/CodeCompletion) on Twitter to hear about our upcoming livestreams, videos, and other content. Today, we discuss: - JIRA and project planning terminology - How to plan a software project - Linear (https://linear.app/) - Shit User Stories (https://twitter.com/shituserstory) - Yak Shaving (https://sketchplanations.com/yak-shaving) - Commented Out: LEGO are really cool - LEGO NES (https://www.lego.com/en-us/product/nintendo-entertainment-system-71374) Your hosts for this week: * Spencer Curtis (https://twitter.com/SpencerCCurtis) * Dimitri Bouniol (https://twitter.com/DimitriBouniol) Be sure to also sign up to our monthly newsletter (https://codecompletion.io/), where we will recap the topics we discussed, reveal the answers to #CompleteTheCode, and share even more things we learned in between episodes. You are what makes this show possible, so please be sure to share this with your friends and family who are also interested in any part of the app development process. Sponsor This week's episode of Code Completion is brought to you by Huuungry. Search for Huuungry on the iOS App Store today to give it a try: https://apps.apple.com/app/apple-store/id1448552588?pt=14724&ct=CodeCompletion1&mt=8

On today's episode we're looking at the work we need to do before creating sustainable habits, and exploring the unhelpful stories our inner critic often has us believe. Click here to find out more about the Rebel Habits Season Pass! Find out more about the Fuck the Cobwebs Workshop!

* Read "Working Identity" for career change https://www.amazon.co.uk/Working-Identity-Unconventional-Strategies-Reinventing-ebook/dp/B004OEIQ7C* Maybe not an agency business...* The contract market is recovering* Yak Shaving - https://seths.blog/2005/03/dont_shave_that/* Trying to build a SaaS in one evening with NoCode (fail)* What's [not very] new in ES6* Why should software be free? - Cloud vs local compute.* Syncthing - https://syncthing.net/Excuse the coughing, I've edited out a few but I am genuinely fighting a bloomin' cold.

[קישור לקובץ mp3] שלום וברוכים הבאים לפודקאסט מספר 423 של רברס עם פלטפורמה - התאריך היום הוא ה- 11 באוקטובר, השנה היא 2021, אם אני לא טועה . . . . נכון, עדיין? (אורי) תלוי אם אתה סופר את 2020, “השנה המחוקה” . . . (רן) יאללה, נקפוץ ישר ל-2021-וחצי . . . . השעה היא תשע בערב ואנחנו באולפנינו אשר בכרכור בבית של אורי - ויש לנו את הכבוד לארח את אסי מחברת Cloudinary - הי אסי! - (אסי) אהלן, שמח להיות פה - (רן) ברוך הבא, תודה ושבאת - והי אורי! מה שלומך? - (אורי) הכל בסדר.(רן) היום אנחנו הולכים לדבר על נושא ששמו B2D, או Business To Developers - שזה נושא שאסי מתעסק בו די הרבה בעבודתו ב-Cloudinary.אז לפני שנצלול לנושא, בואו נלמד קצת על אסי - ספר לנו קצת עליך . . .(אסי) אז אני אסי ואני מנהל פיתוח ב-Cloudinaryאני אחראי על אחד המוצרים של Cloudinary שהוא Developer-orientedבנוסף אני אחראי על צוות של ה-SDK של Cloudinary, שהוא Cross על כל המוצרים ואחראי על צוות האינטגרציות (Integrations) . . .בתעשייה לפני כן הייתי הרבה שנים ב-HP ב-Mercury, נגעתי בהמון מוצרים והמון אנשים והמון טכנולוגיותאחר כך כמה שנים ב-Trax - שם עבדתי עם Mobile ו-Cloud ו-Scale וכל מה שקשור לזה.ובשלוש השנים האחרונות אני ב-Cloudinary . . . מבסוט אש (רן) וקצת על Cloudinary? בטח כמה מכירים, אבל למי שלא מכיר - מה עושים?(אסי) אז למי שלא מכיר - Cloudinary היא חברה שמפתחת מוצרים ופתרונות לחברות באיזורי המדיה - לפתור בעיות בעולם המדיהכשהחלק המעניין - אנחנו עושים הרבה דברים, אבל החלק המעניין, שמשם החברה התחילה וזה ה-Core של החברה - הוא פתרונות למפתחיםוהמטרה היא - הייתה במקור ומאיפה שהחברה התחילה - להוריד מהמפתחים את כל הכאב ראש כשקשור למדיה, מתוך הבנה של ה-Founders, שלושת הפאונדרים - איתי, טל ונדב - שכמעט בכל פרויקט תוכנה היום יש אלמנט מאוד גדול של מדיה ויש סט שחוזר על עצמו של שאלות, שהמון מפתחים נתקלים באותן שאלות.איפה לשמור? איך לשמור? ?Small? Medium? Large . . .איך לדלבר (Deliver)? איזה CDN? איך עושים Responsive? אילו פורמטים לדלבר? . . . איך אני עושה את הבאלאנס הזה, שבין איכות של תמונה שתיהיה מצד אחד קטנה ומצד שני תיהיה תמונה איכותית שתייצר Experience טוב ל-User?אז מתוך הבנה שלא היה באמת איזושהו פתרון אחד, הוליסטי, שאומר למפתחים “עזבו אתכם . . . “היה איזה סט של Libraries וסט של דברים שאתה שאתה יכול לעשות כדי להתמודד עם השאלות האלה - אבל Cloudinary באה באמת כדי לתת איזשהו פתרון אחד שאומר “שים אצלנו את התמונות ואת ה-Video-ים, ואנחנו נותנים את כל השאר, אנחנו נספק את כל השאר”.זה Storage ו-Delivery ואופטימיזציות וטרנספורמציות, והיכולת . . . . אפשר לעשות דברים מאוד מאוד מורכבים עם Cloudinary - “ולהתעלל בתמונות”, אני קורא לזה “להתעלל” בתמונות בזמן ה-GET, בזמן ה-Fetch שלהן - ולעשות דברים מאוד מאוד מורכבים על התמונה.(אורי) כמה, ככה, מה-Business היום זה תמונות וכמה וידאו? או ש . . . .אם אתה יכול להגיד?(אסי) אז אין לי את המספר “בשלוף” - אבל הוידאו רק גדל . . . . מן הסתם תמונות נמצאות All-over, אבל אין היום שום Business עם eCommerce וכל העולם הזה זה וידאו-ווידוא-ווידאו . . . TikTok והכל הופך להיות יותר וידאו והנתח של וידאו בתוך ה-Business רק הולך וגדל כל הזמן.(רן) . . . למרות שהתחלתם, במקור, מתמונות - אז זה הגיוני שהוידאו רק יגדל, כי התמונות כבר גם ככה גדולות.אבל בוא, שנייה, נחזור אחורה - אני מניח שכל מפתח יודע שאין יותר קל מאשר לשים את התמונה נניח ב-AWS S3 ואחר כך לקרוא את הקובץ ישר משם, אבל גם כל מי שפיתח Web אי-פעם יודע שלא בזה זה נגמר - צריך תמונה שמתאימה לכל Device בנפרד, לרזולוציות שונות ופורמטים שונים וכו' - וזה כבר כאב ראש גדול.ואת כאב הראש הזה אתם בעצם פותרים, או שפתרתם כבר לפני כמה שנים והיום אתם עושים כבר דברים הרבה יותר מתוחכמים, אז זה למעשה ה-Value Proposition המשמעותי של Cloudinary . . . (אסי) נכון(רן) עכשיו - יש פה עוד משהו מעניין בסיפור ההיווצרות של החברה, וזה שהיא התחילה Bootstrap - איך זה משפיע על האופי של החברה, עד היום?(אסי) זה משפיע מאוד . . . נסביר על Bootstrap - בעצם, הסברתי ש . . .(רן) Bootstrap זה אלגוריתם שבו אתה תופס בזנב של עצמך ולאט-לאט עולה . . . מאוד פשוט.(אסי) בול . . . אז Bootstrap היא חברה שבעצם אין לה משקיעים, והיא מחזיקה את עצמה מהכנסות של לקוחות, וזה בעצם מראה את החוזק של המוצר מהיום הראשוןכששלחו את המייל הראשון לחברים של “בואו תראו מה עשינו” - כבר אז התחילו להצטרף לקוחות ו-User-ים לתוך המערכתומאז ועד היום, עם כל הגדילה המשוגעת של החברה - הכל מוחזק ע”י הכנסות מלקוחות, מאלפי לקוחות משלמים שיש לנו.וזה מאוד משפיע על הווייב בחברה - הדבר שאני תמיד אומר שהוא מאוד מורגש זה שאין משקיע, שמישהו מכר לו איזשהו חלום של “הנה - תשים פה $100M ואני מראה לך איך אני מחזיק לך פי-10 בעוד ככה-וככה זמן”אז בגלל שאין את המשקיע הזה, שיושב ומצפה לגדילה הנורא גדולה, אז אפשר לשים את הדגש על Healthy-Growth, ולעשות את הדברים בדרך שבה הפאונדרים רואיםולא רק הפאונדרים - זה מאפשר לחברה לעשות דברים שהם מאוד Unique-יים לחברה זו - פעם בשנה לכנס את כל העובדים, מכל העולם - לפני הקורונה בארץ, בקורונה זה היה ב-Zoom, אני מקווה שזה יחזור להיות במקום אחד - לכנס את כולם ולעשות Brainstorm משותף - ככל שהחברה גדלה זה הופך להיות מורכב-לוגיסטית, אבל זה בסוף אותו הקונספט של Brainstorm של כולם - ולבנות ביחד את ה-Roadmap ולאן החברה הזאת הולכת.ולעשות את זה בצעדים מדודים, ולמדוד לאן אנחנו הולכים, ולקבל החלטות שקולות ולא לרוץ לשום כיוון בצורה מופרזת.זה מאפשר לאנשים באמת . . . אנחנו נמצאים היום במקום שבו יש לנו מיליון Developers שמשתמשים, Account-ים שרשומים אצלנו, וזה מאפשר לנו באמת לשים דגש ולהקשיב ולאסוף פידבקים ולעשות את הדברים שעונים ללקוחות על הצרכים ולא להתפזר.(רן) אני חושב שאת “הגוספל” הזה שומעים הרבה פעמים מפאונדרים (Founders) של חברות . . . לשמוע את זה ממישהו שהוא לא פאונדר - AKA אתה . . . - זה כיף וזה מרענן, אז אני מניח שמשהו מכל הקסם הזה עובד שם.(אסי) . . . שזה מה שקורה . . .(רן) אבל אנחנו התכנסנו פה כדי לדבר על הנושא של B2D, שזה Business To Developers - מקודם באת ואמרת “אוקיי, המוצר שלנו הוא מוצר למפתחים”, ונשאלת השאלה - אז מה ההבדל בין לפתח מוצר למפתחים לבין לפתח מוצר ל . . . Whatever, למישהו אחר - ספרים, מכונאים או נדל”ניסטים?איך זה נראה? האם זה משפיע על האופי של החברה? האם זה משפיע על היום-יום שלך? מה המשמעות של לפתח מוצר למפתחים אחרים?(אסי) אז תיכף ניגע באיך שזה משפיע על החברה - אבל זה אחד הדברים שאני מאוד נהנה מהם בעבודה ב-Cloudinary, זה שאני מפתח מוצר לאנשים שאני מאוד מאוד מבין אותם - אני אחד מהםמצד אחד, מפתחים הם User-ים - משלמים כסף על מוצר, רוצים לראות תוצאות, רוצים את כל מה ש-User רגיל רוצה מכל מוצראבל מהצד השני, אנחנו מבינים שהם חיה קצת מוזרה - אני קורא לנו “חיה”, קצת מוזר . . . (רן) “מפלצת”, בוא נגיד . . . (אסי) . . . אבל מפתחים הם “עם” שמאוד מאוד Focused על תוצאות ורוצים . . . הם מאוד לא Driven by Marketing, אתה לא יכול להגיע למפתחים על ידי זה שאתה עושה Marketing, שולח להם מייל או שעושה איזושהי פרסומת . . . אני תמיד שם לב בעצמי - אני מקבל Newsletters טכניים, וכל מה שכתוב עליו “Sponsored by” - אני מדלג עליו, העיניים שלי מדלגות עליהם, כי אנחנו מאוד לא Driven by Marketing, מאוד חיים את ה-Community ואת מה שקורה בקהילה ודברים חדשים ומאוד חשוב למפתחים להגיע לתוצאות מהר - אנחנו כולנו היינו במקום הזה, שאתה יושב ויש לך משימה ואתה צריך לפתור איזו בעיה, ואתה עוצר לרגע ואומר “בטח מישהו פתר את זה קודם, בטח יש איזה משהו שיכול לעזור לי פה” - ואז אתה נכנס לאיזושהי סאגה שבה אתה מחפש ב-Google ונכנס ומוצא כמה Libraries ומוצא כמה פתרונות ועושה להן Evaluation . . . אז החברה היא מאוד Tuned וכל מה שאנחנו עושים . . . אנחנו מאוד Tuned לקטע הזה - שהוא זמן די קצר - מהרגע שנתקלת ב-Cloudinary - לא משנה אם מצאת ב-Google או שמעת ברבסים או שמעת באיזשהו Conference -קראת, הכרת, דרך חברים, לא משנה - מהרגע שאמרת “רגע, Cloudinary - אני רוצה לבדוק האם זה פותר לי את הבעיה” - כי מעניין אותי שתפתרו לי את הבעיה שלי, זה לא שאנחנו פותרים את כל בעיות המדיה בעולם.מהרגע שהבנתי שזה פותר לי את הבעיה, אני רוצה להבין ש”I can read the manual”, אני יכול To get onboard די מהר - npm install, יש לי SDK, משחק עם זה - ועד הרגע שהחלטתי אם אני אוהב את זה או לא אוהב את זה, יש זמן מאוד מאוד קצר, ואנחנו רוצים להיות שםעם SDK מצויינים, עם דוקומנטציה (Documentation) ו-Content שמספר איך לפתור את הבעיה שלךכמה שיותר כדי באמת להביא אותך לנקודה הזו, שאמרת I like it.(אורי) אבל זה נכון, כמו שרן אמר, בעצם לכל מוצר שאתה . . . ב-Outbrain אנחנו קוראים לזה Time To Optimize - הזמן עד שאתה מקבל את ה . . . עד שאתה רואה את ה-Return on Investment, בעצם - ותכל'ס, אתה דיברת על זה שזה מהרגע שהחלטת שאתה רוצה לנסות את Cloudinary, ושם אתם עוצרים או מורידים את כל מה שאנחנו קוראים לו, כל מי שמתעסק עם ספריות - “לגלח את היאק”, ה-Yak Shaving - מה שאתה צריך לעשות כדי תכל'ס להצליח להפעיל את הספרייה שלך . . . אז את זה אתם מקצרים, אבל זה מתחיל עוד לפני, נכון? זה מתחיל מ”רגע, יש פה מישהו שיש לו בעיה - איך אני מגיע אליו?” - אם זה Marketing . . . . הבעיה לא מתחילה כשהבנאדם מתחיל לנסות את Cloudinary, אלא הבעיה מתחילה כשיש לו בעיה וצריך לדאוג “לצוף לו” כמה שיותר מהר . . .(אסי) אתה שואל איך אנחנו - או איך אני - מגיע למצב שבו כשמפתח נתקל באיזושהי בעיה, אז הוא נתקל ב-Cloudinary?, או איך הוא מגיב . . .(אורי) בבעיה רלוונטית, אתה מבין? כאילו “יש לי בעיה עם ה-Image-ים שלי”, או ש”אני צריך Fast Delivery ל-Image-ים שלי . . .”(רן) אני אתרגם . . . אני אנסה לתרגם את השאלה שלך, אורי, ברשותך, ותגיד לי אם אני צודק - אם מפתח בא ואומר “אוקיי, אני רוצה לייצר אפליקציה חדשה, אני רוצה לייצר App חדש”, והוא אומר “אולי אני רוצה פה גם תמונות” - איך אתה מצליח לעשות את ה-Marketing campaign הנכון? איך אתה מצליח להיכנס בנקודת ההחלטה הזו שבה הוא אומר “רגע-רגע, בעצם לא כדאי לשים את הקבצים ב-S3 ולא כדאי ללכת לאיזשהו שירות אחר - כדאי ללכת ל-Cloudinary!” - האם אתם, כמפתחים, מעורבים בזה, או שזו לא בעיה שלכם? או שזו בעיה של איש ה-Marketing בחברה ואתם רק אחראים על זה שה-API יעבוד . . . . האם אתם, באופן אקטיבי, מעורבים בלתפוס את הלקוח בנקודת ההחלטה הקריטית הזאת?(אסי) זה מאוד . . . בעולם שבו אתה מדבר עם מפתחים, שוב - Marketing הוא מאוד מאוד שונה - לעשות סתם “רעש” זה לא תופס מפתחים, הם מפלטרים את הרעש הזה.זה הכל עניין של Brand awareness - שאנשים יכירו את השם, ידעו לעשות את החיבור הזה שבין . . . כמו שאתה עושה Twilio לכל מיני SMS-ים ול-Comunication בתוך ה . . . אתה רוצה שהחיבור הזה ישאר לאנשים בראש.ואתה רוצה שאנשים יבינו, לאט לאט - וחברות כבר מבינות יותר ויותר - שבתוך המערכת שלהן, יש איזורים שהם לא ה-Core Business שלהן, ויש חברות שהמדיה היא סופר-חשובה להן, אבל לא ה-Core Business שלהן - ואלו האיזורים שבהם נכון לתת לשירותים חיצוניים, כמו למשל גם Twilio, לתת לשירותים חיצוניים, שלהם יש את ה-Expertise, לפתור את הבעיה הזאת.אז יש המון מפתחים Out there, שמכירים את Cloudinary ולא יצא להם - אבל כשהם יגיעו לנקודה שבה הם מתעסקים במדיה אז Cloudinary “תצוף” - ולשם אנחנו רוצים להגיע, ופחות לאיזשהו Marketing . . .(אורי) מה שנקרה “בשביל זה אתה פה . . . “ (אסי) זה חלק מהסיפור . . . (רן) אבל השאלה שלי היא כזו - האם היום אתה מטריד את עצמך באיך להגיע לאותם מפתחים, או שאתה מטריד את עצמך באיך ה-Performance של ה-API יותר טוב איך נעשה API יותר טוב או Rendering יותר טוב? האם חלק מדאגות ה-Marketing הן גם על שולחנך?(אסי) אז על שולחני - ועל שולחן ה-Product, כמובן - כי בסוף אנחנו רוצים מוצר שהוא גם Focused לבעיות שקורות בעולם סביב מדיה, ואנחנו רוצים לתפור פתרונות להם.ואז אתה מפתח Section-ים בתוך המוצר, Widget-ים, אתה מפתח כל מיני יכולות שמוכוונות לכל מיני Use-Case-ים שאנחנו מכירים ושהלקוחות שלנו עושים, ואנחנו מפתחים משהו שהוא Dedicated אליהם.אנחנו משקיעים ב-Content וב-Conference-ים ובללכת ולדבר ולספר על Cloudinary [הננו כאן…], אבל כמובן שבסופו של דבר אנחנו R&D ואנחנו רוצים מוצרים עובדים ו-Scalable ו-Robust וכל מה שצריך.(רן) מקודם דיברנו על האספקט של ה-Marketing, וחלק נוסף זה האספקט של ה-Support - למשל איך נראה Support בחברה שמשרתת מפתחים? אז אני מניח שרוב השאלות אלו דברים שהם Hardcore-technical? האם ב-Support צריכים להיות גם מפתחים מן המניין או . . . . איך אתם מכשירים את אנשי ה-Support שלכם? מה האינטרגציה שלכם איתם? איך נראה היום-יום שלהם?(אסי) אז ה-Support שלנו . . . העובדה שאנחנו מפתחים למפתחים משנה את הכל, את כל הארגון הטכנולוגי.לא מוזר למצוא את עצמך בארוחת צהריים עם מישהו מארגון ה-Sales ולדבר איתו על React, על הגרסא החדשה של Reactכולם הם אנשי פיתוח וכולם בסוף מדברים עם מפתחים.ה-Support הוא דוגמא טובה כי ה-Support הוא מאוד מאוד טכנולוגי - יש לנו צוות Support מפוזר בעולם שהם כולם נינג'ות טכנולוגיות . . . הם מכירים את המוצר מאוד מאוד לעומק - אבל גם מכירים כל ה-Setup-ים של כל הלקוחות ומה עושים ואיך עושיםזרוק אותם ב-React או זרוק אותם ב-NET. או זרוק אותם ב-PHP - והם שוחים ויודעים לתת פתרונותזה אחד הדברים שאנחנו מקבלים עליהם פידבקים אינסופיים, על ה-Support של Cloudinary - שהוא גם מקצועי וגם מהיר.האינטראקציה איתם . . . דבר ראשון ברמת ה-Onboarding אני יודע שיש Onboard מסודר גם לתכנים של Support אבל גם לתוך הטכנולוגיות שלנו.ספציפית בצוות ה-SDK - כל איש Support מגיע לשבוע בתוך הצוות SDK ומתמחה ב-SDK ספציפייושב עם המומחה בתוך הצוות SDK, פותר, פותח PR-ים . . . אנחנו רוצים להגיע לנקודה שבה איש Support, כשהוא נתקל ב-Bug ו-He can Solve it - שיעשה PR ואנחנו עושים Mergeוה-Support לפעמים גם לוקחים משימות מתוך ה-Backlog של ה-SDK . . .(אורי) אז מה עושים המפתחים? . . . (אסי) מה עושים המפתחים? . . .(רן) זה כמו הפרסומת לפריגת . . . . [לא, שלהם זה עוקץ אפילו יותר מעניין - אתה זוכר פריגת אבל הפרסומת היא של פרימור . . . ](אורי) “סוחטים אנשי Support טובים” . . . .(אסי) אז ה-Support שלנו זה באמת סיפור הצלחה - והוא באמת דוגמא לזה שכל הארגון, כולל ה-Product, זה אנשים טכנולוגיים, שיודעים תוכנה ומכיריםוזה נורא כיף לעבוד בארגון כזה - כולם מסביבך יכולים . . . אתה יכול לדבר איתם “בגובה בעיניים”.(אורי) יש לי שאלה אחרת: גם הלקוחות הם מפתחים - מן הסתם, בגלל זה אנחנו מדברים על B2D - בהגדרה, מפתח פוגש לקוחות?(אסי) לא יודע אם בהגדרה, אבל יוצא לפגוש לקוחות - וזה עוד יותר כיף, כי אתה מדבר עם מישהו, גם, “בגובה העיניים”, זה משהו . . . אתה יכול לעשות שיחה עם לקוח שהיא סוג של Brainstorm והיא לא כמו לקוח בחברה שמספקת שירותים.הרבה מהדברים שקרו ב-Cloudinary קרו כי אתה יושב בשיחה עם לקוח והוא בא עם רעיון טוב, כי . . . .אנחנו כולנו מכירים את זה - ה-Product אומר לך אני צריך 1,2,3 . . .10 - ואתה ב-3 כבר איבדת אותו כי אתה חושב איך אתה עושה את זה ב-Database ואילו End-points אתה הולך לחשוף . . . אנחנו מאוד Solution-oriented - וגם הלקוחות שלנו באים עם פתרונות: “אתם עושים ככה . . . אל תעשו ככה”ה-SDK שלנו הם הכל Open-source - הם שוחים שם והם באים או עם PR-ים, שזה כבר ממש הפתרון, או עם עם שיחה, שמובילה לדברים מאוד מאוד יפים.(רן) בוא נדבר קצת על אתגרים בפיתוח למפתחים - אמרת את המילה “API” כמה פעמים, ובסך הכל Cloudinary זה “API אחד גדול”, נכון? “להביא תמונה בגודל הזה, ברזולוזציה הזאת” או “תביא את הוידאו” או דברים כאלה - אבל ה-API הוא SDK, לכאורה . . . יש הרבה כאלה, אני מנחש - אחד ל-React ואחד ל-Angular ואחד שהוא Vanilla ואולי שלושה ל-iPhone, אני לא יודע כמה יש ולאנדרואיד וכו' וכו' . . . .(אורי) ואחד שלא מוצאים עד היום . . . .(רן) . . . איך מתחזקים את כל הדברים האלה? איך דואגים לזה שהתיעוד יהיה אחיד, שה-API יהיה קונסיסטנטי (Consistent)? אם צריך לעשות Deprecation לאיזשהו End-point - איך מתחזקים את כל “המפלצת” הזו?(אסי) אז אכן זאת מפלצת . . . ומאוד מאוד חשוב לנו שהיא לא תיהיה רק כמות הטכנולוגיות, אלא שאנחנו נתמוך בכמה שיותר מפתחים בסוף, זו המטרה שלנו - שכל מפתח out there שרוצה להשתמש ב-Cloudinary - תיהיה לו את היכולת.אז זה מעלה הרבה Challenge-ים, לדוגמא - אתה רוצה “לתמוך אחורה”, טכנולוגית - אנחנו תומכים ב-Java 7, כן? . . .יש עדיין מספיק אנשים בעולם שמשתמשים ב-Java 7 ואנחנו רוצים לתת להם פתרוןזה Tradeoff מול זה שאנשים בסוף נכנסים ל-GitHub ורואים את ה-Java SDK ואומרים “רגע . . . זה חסר, זה נראה מאוד מיושן . . . “ - אבל זה Tradeoff שאנחנו עושים כל הזמן בכל הטכנולוגיותאיך אנחנו מתחזקים את זה? יש לנו אנשים שמתמחים - לא אחד-פר-Technology אבל אנחנו בצוות ה-SDK לפחות בנויים מאנשים שהם מומחי JavaScript, אנשים שהם מומחי Mobile, אנשים שהם מומחי Backend Technology - אם זה PHP ו-Python ו-Ruby ו-NET.ושם אנחנו מאוד מאוד מנסים לעשות . . . לשמור את על Alignment מצד אחד, שכל ה-SDK ידברו פחות או יותר באותה שפהמצרכים . . . גם ללקוחות אבל גם פנימיים - אנחנו רוצים ש-Support שתומך ב-NET. יהיה מסוגל גם לתמוך ב-PHPומהצד השני - אנחנו גם מאוד מנסים להבין ולתת פתרונות Per-Technology ולהסתכל על . . .לא יודע . . . Android - להגיד “ב-Android יש את Glide - אני לא רוצה לכתוב Downloader שמתחרה ב-Glide, אין לי מה להתחרות ב-Google” - אז אני עושה אינטגרציה לתוך Glide.ואם אתה מסתכל על iOS, אז ב-iOS אין את זה, אז שם אתה כותב Downloader ו-Caching וכל מה שאתה צריך.אז אנחנו מאוד מנסים “לתפור את ה-Experience” לטכנולוגיה ולמי שעומד מולנו, להיכנס לנעליים שלו.(רן) נחזור לרגע לשאלה המוצרית ונחפש את האתגרים המעניינים שם - איזה Bias אתה מרגיש שקיים כשאתה שומע, נגיד, איזשהו פידבק ממפתחים או מהמפתח על איזשהו פיצ'ר? לצורך העניין, אני יכול לדמיין את זה ש”וואלה - אתה מבין בדיוק מה אתה רוצה, לא צריך פה איש פרודקט שיפתח את זה - אני כבר אפתח את זה” . . . אז, אתה יודע - כשמסתכלים על זה רגע מהצד אז ברור שזה מסוכן, אל תעשה את זה . . . אבל מצד שני, אני יכול לראות איך זה קורה . . .(אורי) איזו “בינה אלוהית” ניתנה לאנשי פרודקט?(רן) לא . . . לא בינה אלוהית . . . (אסי) לא בינה אלוהית . . .(רן) אבל זה עוד בנאדם שיכול לתת אספקט - אם אתה אומר “עזוב, זוז הצידה, אני מבין את הכל”, אז אני חושב שכן, יש בזה . . .(אורי) אני לא חושב שזה נכון תמיד . . .(רן) כן, סבבה, לא . . . (אסי) אני חושב שבעולם של B2D, אז השאלה הזו הופכת להיות יותר עמוקה, כי בהרבה מהפיצ'רים והרבה מהדברים - בסוף האיש שהוא מומחה NET. הוא זה שיבוא ויגיד מה צריך מפתח NET. בעולם המדיה ו-He knows best . . . באמת, איך ש-R&D עובד יחד עם Product זה מאוד מענייןאיזו בינה ניתנה לאנשי ה-Product? אני לא יודע אם “בינה”, אבל אנשי Product לפעמים יוצאים מה-Challeng-ים של הפיתוח, כי המפתחים הרבה פעמים נמצאים עמוק בתוך ה-Challenge של הפיתוח ואנשי Product - יש להם ראיה יותר רחבה.זה Alignment בין ה-SDKs ו-Alignment בין ה-APIs - אז זה מהמקום הזה, ה-Roadmap המוצרי, השיחות עם לקוחות . . .אז זה המקום הזה - ש-Product… יש ל-Product מקום בתוך הארגון - אבל באמת כשאנחנו מפתחים למתפתחים אז יש הרבה מקומות שבהם הקו הוא מאוד Blurאיך נקרא ה-API - יש שאלה של Product, ואיך נראה ה-App Engine בתוך ה-API יכול להיות שזה משהו שיבוא מתוך הפיתוחויש פה הרבה הפרייה גם, יש פה הרבה דברים שקורים ביחד.(רן) אחד הנושאים שעולים הרבה פעמים, כשמסתכלים על APIs ועל SDKs, זה קלות השימוש בהם, או אולי נקרא לזה . . . בעולם ה-UI זה יקרא Usability, ובעולם ה-API אפשר לקרוא לזה Usabili-יות . . .(אורי) כמה יאק אתה צריך לגלח עד שתצליח לעבוד עם ה-API . . .(רן) . . . האם אתם מוצאים את עצמכם מפתחים מתודולוגיות של, לצורך העניין אני ממציא - “בוא נעשה A/B Testing, נעשה גרסא כזאת ל-API כזה וגרסא אחרת ל-API כזה ונראה מה יותר תופס” - זה נשמע לי קצת כמו מדע בדיוני, אז אולי דברים אחרים, אבל נגיד - לקבל חוות דעת של מפתחים, של משתמשים שלכם, על גרסאות חדשות של API . . . האם יש לכם דרך לעשות Usability testing ל-API ול-SDK שלכם?(אורי) ואגב, אני אוסיף פה עוד משהו - לפחות ממה שזה נשמע, לתקן Usabili-יות של ה-API זה לא משהו שאתה עושה כלאחר יד, כי יש לך . . . (אסי) זנב ארוך?(אורי) . . . 15 טכנולוגיות שבהן אתה צריך לשנות את ה-Usabili-יות עכשיו, כי ה-APIs כולם Compatible . . .(אסי) נכון, אז באופן כללי, בעולם של SDK-ים, קשה לך להבין מה ה-User-ים עושים עם ה-SDK עצמו . . . ה-SDK עצמו לא שולח לך Analytics, אתה לא רוצה להשתמש ב-Library, שמאחורי הקלעים תתקשר עם הבית . . .(רן) אבל כולם עושים את זה . . .(אסי) כן . . . אז אנחנו עוקבים בעיקר אחרי הקריאות ל-API עצמן - זאת אומרת ה-SDK בסוף קורא לאיזשהו API - וה-SDK שלנו, יש בו עולם ומלואו שמייצר . . . Cloudinary, יש לה Delivery API שמאפשר לעשות טרנספורמציות על תמונות דרך ה-URL, ויש לנו עולם ומלואו בתוך ה-SDK שמייצר URL-יםוגם שם יש לנו איזושהי יכולת לשים איזשהו Token על ה-URL שנוצר, כדי שנוכל לדעת מה ה-User עשה ואיך הוא השתמש.אבל זה עולם שמאוד מאוד קשה להבין בו מה ה-User-ים עושים.בכל זאת, אנחנו כן אוספים פידבקים ואנחנו כן מבינים ואנחנו נמצאים באיזשהו Shift שבו את ה-SDK-ים שלנו - לפחות את ה-section הזה של ה-URL Building - אנחנו הולכים יותר לכיוון של לשנות את השפהלדבר יותר בשפה של ה-User - הוא רוצה לקחת תמונה, הוא רוצה לסובב אותה, הוא רוצה להוריד לה את ה-Background, הוא רוצה לצבוע אותה באדום . . . לדבר בשפה הזאת, וקצת פחות . . . היום ה-URL-Based שלנו הוא קצת קריפטי (Cryptic) כי הוא נכנס ב-URL . . .אז אנחנו מנסים לייצר פה איזושהי שפה חדשה בתוך עולם ה-SDK - מה שמאפשר גם Discoverability -אם אתה רוצה גם לתת את האפקטים, אז “Effect.” ובום! - רשימה של אפקטים שתוכל לבחור מתוכה את כל מה ש-Cloudinary יודעת לעשות, בלי ללכת לדוקומנטציה (Documentation) - וכאלה.אז יש לנו כל מיני אג'נדות, כשהמטרה שלהן בסופו של דבר זה באמת Developer Experience וזה UX - זה DX! - כל מיני אג'נדות שזו המטרה שלהן.לעשות על זה A/B Testing זה קשה, ולהבין באמת מה ה-User-ים . . . זה גם קהל שפחות זורם על “בוא, קח תעשה Usability Testing ונעקוב אחרי איפה שהעיניים שלך מסתכלות” . . . . זה לא זה.(רן) מפתחים לא “זורמים”, אתה רומז . . .(אסי) פחות . . . (רן) תגיד, אסי - אתה אוהב מוסיקה? (אסי) טיפה . . .(רן) מה אתה עושה? מה אתה מנגן?(אסי) מה שיש . . .בגדול אני מתופף, אבל מנגן גיטרה, בס , קלידים, מה שצריך . . .(רן) ושמעתי שיש עוד כמה מוסיקאים ב-Cloudinary . . . (אסי) כן, גיליתי - לא רק ב-Cloudinary, גיליתי לאורך כל הקריירה - שיש מלא Talent בתחום שלנו, מלא . . .איפה שלא הגעתי, כשאני נכנס לחדר זה הדבר הראשון שאני עושה - עושה סיבוב בחברה של “מי מנגן?” - ומלא ידיים עולות באוויר(אורי) בגלל זה, אבל . . . הם לא שליחים, אתה יודע, מוסיקה זה שליחות, אז מוסיקאים עושים שליחויות . . . לא, יש באמת המון Talentכי זה בא עם Talent, בגלל זה אני לא מנגן . . . (אסי) יש מלא, ואנשים לא, אתה יודע, אנשים שנגנו על גיטרה במדורה - אנשים ברמה מאוד מאוד גבוההוגם ב-Cloudinary כשהגעתי, שאלתי “מי בעניין? בואו נקים להקה!”ו-Cloudinary, כמו Cloudinary - תומכת בכל שגעון שנביא וזרמו איתנו - אנחנו נפגשים ויש לנו מפיק מוסיקאלי ואנחנו מקליטים . . . (רן) גם הוא מהחברה, אגב?(אסי) לא - הוא דוידי, הבסיסט של שבק”ס, אחד האנשים הכיפיים [תתקעו בחצוצרה!]נפגשים כל שבועיים, מנגנים, שרים, מקליטים, קליפים . . . הוצאנו קליפ New Virtual Team Member, שקצת תפס בתעשייה, שמדבר על מישהו שמצטרף וריטואלית בתקופת הקורונה וה-Zoom . . . ואנחנו מופיעים בחברה, באירועים - וואלה, זה עושה טוב, מעבר לשבעה-שמונה אנשים שמנגנים דברים שלהם זה בטוח עושה טוב, זה עושה טוב לחברה - כיף לבוא לאירוע שבו יש באמת . . . ארגנו סאונד, במה, הכל כמו שצריךואנחנו מנגנים וכולם קופצים - זה כיף גדול, ואנחנו עושים את זה בכל הזדמנות שיש, ואני ממליץ באופן כללי.(אורי) הכי כיף - אצלנו יש גם סאונד ותאורה, אז זה כאילו מהצוות . . . .(אסי) איפה? בתוך ה . . .(רן) בחברה . . .(אורי) בחברה - סתם, האיש אחזקה שלנו, יש לו גם Business לסאונד ותאורה, אז בכלל . . .(אסי) . . . זה Built-in . . .אנחנו עכשיו מקימים חדר בתוך החברה, של מוסיקה, כי יש יותר אנשים ממה שלהקה אחת יכולה להכיל, אז אנחנו רוצים שיהיה מקום בתוך החברה שאפשר להתאמן, ללמוד, לשחק, להשתולל - ובעיקר לתקשר עם אנשים, כי מוסיקה בסוף זה תקשורת.(אורי) נכון - זה גם האירועי חברה הכי כיפיים . . . (אסי) לגמרי, מרים את כולם . . .(אורי) ואז אתה מגלה, פתאום . . . אתה אומר “תקימו הרכב ונעשה ערב” ואתה פתאום רואה וואלה - יש חמישה הרכבים, שישה הרכבים . . .(אסי) לגמרי, ושל אנשים שאתה רגיל שיושבים בכיסא לידך, שקטים, במחשב, ופתאום מקפצים על הבמה . . .(רן) פתאום מתופפים . . . (אסי) נותנים בראש, כן . . .(רן) אפשר לעשות תחרות “כוכב נולד” פנימית פרטית . . .(אסי) פנים-חברתית, כן . . . לשם אנחנו עוד נגיע, אבל בסדר . . . (רן) אצלנו בחברה עכשיו עושים אודישנים השבוע . . . אז מקימים את הלהקה, שוב - כבר הייתה, אבל מקימים שוב.(אורי) Putting the band back . . . (רן) אתה בא? . . . טוב, אז גם מוסיקה זה כיף וגם SDK זה כיף . . . אתגרים לא קטנים - אבל מעניינים.אז אני מנחש שאתם גם בטח מגייסים, פה ושם?(אסי) בטירוף . . . כמו שאמרתי - מיליון מפתחים ועשרות אלפי אתרים יושבים לנו על הכתפיים, עם Delivery משוגע ו-Scale משוגע(רן) מה ה-Stack הטכנולוגי שלכם? ספר לנו, ככה, בקצרה . . . (אסי) אז כל מה שב-Client-side הוא React ה-Backend, ה-Core, כל מה שאיתו החברה גדלה זה Rubyאנחנו עכשיו ב-Transition ל-Service-ים ו-Go ו-Node - אתה יודע, בכל מקום מה שצריך - זה הכיוון.(רן) טוב, אז תודה אסי! היה כיף ותענוג, שיהיה בהצלחה עם ה-B2D וגם עם Cloudinary.(אורי) ותודה רבה על ה-Service! אנחנו גם לקוחות . . . .(אסי) נכון! לקוחות ותיקים וטובים - תמשיכו ככה . . . תודה רבה!להתראות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

There was a time when William Shakespeare was just another little 7-year-old in school. Classes in his day were demanding -- and all in Latin. A new book argues that this rigorous curriculum actually nurtured the creativity that later flourished in Shakespeare's writing. Don't know Latin? You can still adapt those approaches to stretch and hone your own mind. Plus, why do we refer to an unpredictable person as a loose cannon? The answer lies in the terrifying potential of a large weapon aboard a warship. And when a delivery driver's wife teases him about cavorting with strumpets, he asks: What exactly IS a strumpet? All that, plus picayune, sit on a tack, the many meanings of fell, a Spanish idiom about oysters and boredom, pickthank, a puzzle about rhyming words, a terrifying passage from Victor Hugo, tacos called mariachis, and the juice was worth the squeeze. Read full show notes, hear hundreds of free episodes, send your thoughts and questions, and learn more on the A Way with Words website: https://waywordradio.org/contact. Be a part of the show: call 1 (877) 929-9673 toll-free in the United States and Canada; worldwide, call or text/SMS +1 (619) 800-4443. Email words@waywordradio.org. Twitter @wayword. Copyright Wayword, Inc., a 501(c)(3) corporation.

Johnny Sanphillippo wants to get things done. He is a self-identified old-school San Fransisco liberal.  But more than that Johnny is a pragmatist.  Sometimes it seems he has a language seemingly all his own.  Like Yak Shaving.  What the hell is Yak Shaving? On his blog Granola Shotgun he has offered to the willing some ideas of stay-under-the-radar development patterns that may just start a revolution someday.  Or maybe just help you get that ADU in your backyard in without initiating a revolt between you and your municipal authorities. Johnny sites some real world examples of his own making and in doing so he informs us on what we are all capable of doing when we alter our persepctive. Wait until you hear about the condo-ized cow. Why care?  Because we're going to need to do something with all this suburban excess.  It's here.  We're here.  You need to live and work somewhere, right?

Now and then you find yourself on a chain of activities.. subconciously, perhaps, distracted from task to task. Well.. let's talk about that. https://www.twitch.tv/videos/1116710930 --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/cigargoyle/support

This week Inger is joined by Jonathan O'Donnell from the Research Whisperer as Jason is still away on #epictrip2021. Jonathan has given us lots of suggestions for On The Reg, so now is the time to talk to him directly!We start off talking about why innovation is hard inside universities, which have been fine tuned to avoid waste and increase transperency and accountability. This increases their sensitivity to risk. Sometimes the best way to get things done is through what Jonathan calls 'skunk works', which is exactly how Inger started Bootcamp at ANU.We travel over a lot of ground before we get to our reading segment. Inger has been reading Julia Banks' new book 'Power Play' and musing over 'Cognitive Flexibility'. Aside from reading about Anglo-Saxon history in the 900s, Jonathan has a fun read on the ridiculous morning routines of the influencer class and a fascinating article on 'ask vs tell' cultures, which can really help us work with others.There's a two minute tip about email that Inger is definitely going to try and a brief, but enlightening discussion about advanced Google searches - this episode has it all!Links:Potts, J. (2009). The innovation deficit in public services: The curious problem of too much efficiency and not enough waste and failure. Innovation, 11(1), 34–43. https://doi.org/10.5172/impp.453.11.1.34.Potts, Jason. ‘Innovation by Elimination: A Proposal for Negative Policy Experiments in the Public Sector'. Innovation 12, no. 2 (1 August 2010): 238–48. https://doi.org/10.5172/impp.12.2.238.Potts, Jason, and Tim Kastelle. ‘Public Sector Innovation Research: What's next?' Innovation 12, no. 2 (1 August 2010): 122–37. https://doi.org/10.5172/impp.12.2.122.Brandão, Soraya Monteiro, and M. Bruno-Faria. ‘Inovação No Setor Público: Análise Da Produção Científica Em Periódicos Nacionais e Internacionais Da Área de Administração', 2013. https://doi.org/10.1590/S0034-76122013000100010.5 to 9 (Dolly Parton) video on side hustles: https://www.youtube.com/watch?v=y8jF96hoF9M 'IQ tests can't measure it, but ‘cognitive flexibility' is key to learning and creativity' on the conversation “The exact morning routines 18 successful high-achievers implement to start their day.”https://pdfcoffee.com/successful-morning-rituals-2-pdf-free.html Donderi (tangerine), Andrea. ‘This Is a Classic Case of Ask Culture Meets Guess Culture'. Ask Metafilter. What's the Middle Ground between ‘F.U!' And ‘Welcome!'?, 16 January 2007. http://ask.metafilter.com/55153/WLeave us a message on www.speakpipe.com/thesiswhisperer. Email Inger, she's easy to find. You will not be able to find Jason's email (he likes it that way).Talk to us on BlueSky by following @thesiswhisperer and @drjd. Inger is sadly addicted to Threads, but cannot convince JD to join. You can find her there, and on all the Socials actually, as @thesiswhisperer. You can read her stuff on www.thesiswhisperer.com. You can support the pod by buying our Text Expander guide for academics from the Thesis Whisperer website.

It’s a trip down the rabbit hole this week as the RFC agents need to perform a near-endless series of tasks to learn the information they need. Roll For Combat, Agents of Edgewatch Podcast is a playthrough of the Pathfinder Adventure Path, Agents of Edgewatch, and the second book, Sixty Feet Under. Don’t forget to … Continue reading "Agents of Edgewatch S2|03: Yak Shaving" The post Agents of Edgewatch S2|03: Yak Shaving appeared first on Roll For Combat: Paizo's Official Pathfinder & Starfinder Actual Play Podcasts.

How is your Yak Shaving going? You know, those useless activities we all depend on. Seth Godin brought this concept to life back in 2005 and here we are talking about what to avoid and what to implement.  All references and links for this podcast are at the end of Tuesday’s blog Shaving the Yak.  https://seths.blog/2005/03/dont_shave_that/  https://ReloWomen.com/blogs  

חדש! ביום ראשון 6.12 בשעה 13:00 נקיים ״שאל.י אותי מה שבא לך״ (AMA) עם דני, המרואיין של הפרק בערוץ הדיסקורד הבא https://discord.gg/Nzq4w7hY ההרשמה פשוטה ואין צורך בהתקנה. מוזמנים להצטרף לערוץ ולשאול שאלות (ניתן לשאול בכל עת, דני יהיה שם בשעה הנקובה בלייב)פודקאסט מספר 398 של רברס עם פלטפורמה: כבר הרבה (הרבה) זמן שלא נפגשנו ולא הקלטנו - ובקרוב אנחנו ב-400 . . עוד שניים, אלא אם כן זה בבינארי ואז זה סיפור אחר לגמרי.(אורי) ואנחנו כשבוע לאחר הכנס הוירטואלי הראשון שלנו!(רן) שבוע לאחר הכנס הוירטואלי הראשון - והוידאו כבר יצאו, בניגוד לכנסים אחרים, זה אחד היתרונות של כנסים וירטואליים . . . כמעט ולא פרסמנו את זה פה בפודקאסט כי איכשהו זה יצא, ככה, “אורגני”, לא היה CFP כמו בכל שנה - אבל הכנס התקיים בשבוע שעבר והיה מאוד מוצלח, השתתפו כמה אלפי צופים ומאזינים - והיה כיף.(אורי) וירטואלית, מבחינת השתתפות, יכולנו להגיע לקהל הרבה יותר גדול, כמעט 3,000 איש!(רן) נכוןוהדבר האחרון שלא אמרנו - אנחנו תמיד מקפידים לציין את התאריך, אז היום ה-24 בנובמבר (2020 . . .), והאורח שלנו היום הוא דני מ-Snyk. אמרנו נכון את השם? כן? - מעולה.אז כיף שבאת! יכול להיות שחלק מהמאזינים כבר מכיר - דני דיבר כבר בעבר בכנס שלנו (ב-2018 וב-2019), ואנחנו שמחים לארח שוב - היום נדבר גם על Snyk וגם על כמה ממצאים מעניינים שמצאתם אצלכם.אבל לפני הכל - ספר קצת על עצמך: מניין באת, ואולי גם לאן אתה הולך?(דני) אז דני - אחד ממקימי חברת Snyk, ברקע שלי מגיע מעולמות של מחקר ואבטחת מידע, עוד מהתקופה שלפני הצבא ואח”כ בשירות ב-8200 - ומשם דרך כמה סטארטאפים, שרובם היו סביב מוצרי Security, אבטחת מידע.לפני ההקמה של Snyk ביליתי כ-7 שנים בתפקיד CTO של חברת Gita Technologies - חברת Cyber, סביב מחקר על קריפטוגרפיה ועולמות כאלה.ב-Snyk זה כבר חמש שנים מאז שקמנו - עד לפני מספר חודשים הייתי אחראי על כל תחום ה-Security בחברה, מבחינת המוצר, מבחינת המחקר וכל הצד הזה אז גם ניהלתי את סניף ישראל.לפני שלושה חודשים יצאתי לחופשת לידה - והיום אני חוזר, בפוקוס יותר סביב מחקר וסוג הדברים שגם נדבר עליהם יותר היום.(רן) אז עבור המפתחים שעוד לא יצא להם לפגוש את Snyk - כמה מילים על החברה, מה אתם עושים?(דני) אנחנו חברה שבונה מוצרי Security למפתחיםהתחלנו מעולמות של ה-Security של ה-Open Source, של ספריות קוד פתוח 3rd-party שכולנו צורכים, כשהמוצר הראשון עזר למפתחים לתת איזושהי Visibility על אילו ספריות אנחנו בסוף מושכים לתוך הפרויקט שלנו.בדרך כלל אנחנו מכירים את הספריות המיידיות שאנחנו בוחרים - ה-1st level dependencies - אבל כל ספרייה כזו מושכת עוד, וככה ממשיכים להביא עוד ספריותובסוף יש לנו המון תוכנה שמשכנו לתוך הפרויקט שלנו, והיא הופכת להיות ממש חלק מהאפליקציה שלנו.אז אנחנו בעצם עזרנו ב (א) “להאיר בפנס” את כל העולם הזה ו(ב) בעצם להצביע על חולשות אבטחה ופגיעויות שנמצאות בגרסאות מסויימות - חולשות ידועות בדר”כ, מוכרות, שיש להן את ה-CVE, המזהה של החולשה, שנמצאות באחת הספריות שבסוף נכנסו לתוך פרויקט התוכנה.ודבר אחרון, אחד הדברים המשמעותיים ששונים ב-Snyk לעומת מוצרים אחרים זה שגם עזרנו לתקן את זה - ברמה של Pull Requests שנפתחים מול הפרויקט ה-GitHub-י ממש, למשל כדי לעדכן את הספריה לגרסא לא פגיעה.(אורי) מעניין - אתם בדרך כלל עושים את זה אקטיבית? פרו-אקטיבית? או שהפרויקטים באים אליכם ומבקשים “תסרקו לנו ותגידו לנו מה . . .”(דני) כל מה שאמרתי תקף לפרויקט “שלך”, לא לפרויקט של ה-Open Source.אם אתה למשל בונה פרויקט בNode.js, ומשכת ספרייה בשם left-pad, שמשכה ספרייה בשם אחר כלשהו - אז אני סורק בעצם את הפרוייקט שלך, וכשאני פותח Pull-Request ומתקן לך חולשה בגרסת left-pad 3 ומעדכן לגרסת left-pad 5, כי שם אין חולשה - אז זה קורה בפרויקט שלך.לנו יש את ה-Database שבעצם מכיל את כל החולשות של כל הגרסאות, כשיש המון ב-npm או כל Package manager אחר.(אורי) ויש ממש עבודה צמודה גם עם המפתחים של פרויקטי ה-Open Source?(דני) כן, חד-משמעיתזה משהו שהפך להיות ממש פעילות רחבה - כל חולשה שאנחנו מוצאים (שצוות האנליסטים שלנו מוצא), אנחנו לא רק מוסיפים ל-Database שלנו אלא אנחנו ממש גורמים לכך שתיהיה כמה שיותר מודעות לחולשה הזו, בין היתר גם ע”י להצמיד את המזהה CVE לחולשה.אנחנו היום CVE Numbering Authority -יש לנו מעיין “טווח” של Identifiers שאנחנו יכולים לשייך.אנחנו ממש כותבים את התיאור ועובדים גם עם ה-Maintainer - פונים ל-Maintainer, ולפעמים הם אפילו לא מודעים לכך שיש חולשה, כי מישהו פתח issue על הפרויקט ומישהו שלח להם מייל - לפעמים אין להם זמן לתקן את החולשה . . .אז אנחנו בעצם מדברים עם ה-Maintainers ישירות על מנת לעזור להם לעשות איזשהו Process שמקובל בעולם ה-Security, למשל לשייך את ה-Identifier לחולשה, אבל בין היתר גם ממש לעזור להם לתקן, אם הם צריכים איזשהו Expertise של Security ודברים בסגנון הזה.(רן) וכמו שרמזת, נשמע שאתם נמצאים בעולם ה-Node.js - בגדול אם אני מפתח Node.js אז הבנתי, ואם אני מפתח בטכנולוגיות אחרות אז אתם גם?(דני) לחלוטין - אנחנו תומכים היום בכל השפות - התחלנו מ-Node.js אבל מהר מאוד התרחבנו לכל ה-Ecosystem, אנחנו תומכים בכל השפותבעצם אנחנו מסתכלים על Package Managers - אז זה Maven ו-Gradle ובעצם כל ה-Ecosystems הכי גדולים.אבל מעבר למוצר של ה-3rd-party components יש לנו גם מוצרים אחרים - היום אנחנו עושים את אותו הדבר בעצם לעולם ה-Containers, מסתכלים על ה-Container ואילו רכיבים נמשכים לתוכו ומתריאים שם על חולשות, בעצם אותו הרעיון.ה-Container היום הוא הרחבה של האפליקציה, ה-Docker file יושב ב-Git וזה חלק מאותו העולם - והיום גם נכנסים לעולמות של Infrastructure-as-a-Code לא מזמן רכשנו חברה שהיא בעצם נותנת לנו גם את הכניסה לעולמות של הקוד ה-Proprietary שאתה כותב - ה10-20% של הקוד שאתה כותב - אנחנו מסתכלים גם עליהם, מה שנקרא Static Code Analysisאז אנחנו היום כבר מדברים על ארבעה מוצרים, מה שהופך אותנו לפלטפורמה של ממש כל פתרונות ה-Security שהמפתח צריך.(רן) אז אם אני מפתח, ואני כותב קוד ואולי אני חי באשליה שאני משתמש בספריות קוד פתוח אז הכל בסדר ואני יכול לקרוא את הקוד או שמישהו אחר קרא את הקוד והן Secured- אז כנראה שאני באמת חי באשליה וכדאי שאני אשתמש במוצר כמו Snyk, או מוצר דומה לו, שלפחות יעזור לי לדעת שאני בסדר, שלא שגיתי ושאני לא משתמש ב-Dependency שהוא כבר מסוכן.(אורי) אבל האם יש מצב שבו יש סכנה ב-Dependency, אבל הקוד שלי לא מפעיל אותו?(דני) שאלה מצויינת - זה מצב שקורה לא מעט . . .(אורי) אולי אני לא מכיר את האג’נדה לפני . . .(דני) זה באמת מצב שקורה לא מעט - ויש פה כמה דברים:(א) אם אנחנו מאפשרים לך לתקן את הבעיה בקלות, גם אם היא כרגע לא “בעיה” - אתה משתמש בספריה, שיש בה איזושהי חולשה אבל אתה לא משתמש עכשיו בפונקציונאליות הפגיעה - אז מצד אחד אי אפשר לתקוף את האפליקציה, אבל מצד שני אולי מחר מישהו יתחיל להשתמש בפונקציה הבעייתית, אז יש כאן איזשהו אלמנט שאם זה לא עולה לך הרבה אז אתה רוצה להיפטר ממנו ולהוריד גם את הסיכון הקטן הזה.(אורי) במיוחד אם זה בסה”כ שידרוג גרסא . . .(דני) יש מפתחים שכשאתה אומר להם “זה כולו שדרוג גרסא” יענו לך ש”בטח זה שטויות” - ב-npm למשל זה קורה כל הזמן; ב-Java המפתחים בדר”כ קצת יותר רגישים לשדרוג גרסא, אז זה יכול להיות שונה בין ה-Ecosystems - אבל בגדול . . .(רן) זה גם עניין של גיל . . .(דני) זה גם נכון . . .אז באמת מה שאנחנו שואפים אליו זה שתפתור כמה שיותר בעיות שאתה יכול, כל עוד זה קל - וכשאתה באמת צריך בסוף לבחור ואין לך את כל הזמן שבעולם לתקן ולשדרג את הספריות, אז במצב הזה כן יש לנו כל מיני תוספים שאתה יכול לנסותלמשל אנחנו יכולים גם ממש לנתח את הקוד ולהסתכל ב-Run Time מה נקרא ומה לאלמשל עם היכולות החדשות של ניתוח הקוד הסטטי של הקוד שאתה כותב - זה מאפשר לנו גם לעשות את הההצמדה הזו, של מה שאתה באמת משתמש בו ומה שלא.כל הדברים האלה יכולים לעזור, אבל בהחלט יש פה מעניין “משיכת שמיכה” כזו, של כמה אתה מוכן להשקיע ב”הגיינת ה-Security” שלך - וה-Quality בכלל, לאו דווקא Security, כי זה לא רק חולשות: יש גם באגים ודברים שמותקנים בגרסאות - לעומת כמה סיכון אתה יכול לקחת עם לשדרג דברים ולשנות ולהתעסק בזה.(אורי) לעשות Yak Shaving . . . (רפרנס ל Ren & Stimpy?!)(רן) והמוצר עצמו יושב בדר”כ ,טיפוסית, איפה - ב-CI? ב-IDE?(דני) היום האינטגרציות הן לאורך כל הדרך, החל מה-IDE ועד ל Build ,ל-CI - וחלק מהאלמנטים נמצאים גם ב-Run time.השאיפה היא תמיד לשבת כמה שיותר קרוב וכמה שיותר מוקדם - ושם Source code management כמו GitHub או GitLab אלו האיזורים שהם הכי . . . (רן) אז שתי שאלות, לפני שנמשיך - (1) מאיפה השם? (2) מאיפה הלוגו? מה זה בכלל - שועל? כלב?(דני) זה כלב, דוברמן . . .השם? זה התחיל מזה שמצאנו . . .(רן) רק נגיד איך מאייתים את זה - זה S N Y K (בטקסט זה דווקא עובד יותר טוב . . . )(דני) נכון, זה So Now You Know . . .(אורי) Domain פנוי?(דני) אכן Domain פנוי . . . זה התחיל כמובן, כמו כל סטארטאפ טוב, מ-Domain פנוי(רן) סיפור אמיתי, שמתחיל עם שתי בירות . . .(דני) אז זה Domain של ארבע אותיות, אבל מהר מאוד גילינו שזה גם “So Now You Know”, שזה בדיוק . . . אנחנו התחלנו מהמוצר של להראות לך את הספריות שאתה צורך ושאתה לרוב לא יודע שאתה צורך, וכן - משם זה תפס.הלוגו - ניסינו כמה ניסיונות עם לוגואים וכולם היו כושלים, עד שפגשנו איזשהו מעצב, שאמרנו לו שבגדול אנחנו חברת Security אבל אנחנו כלי למפתחים ואנחנו חברת Security לא קלאסית, לא “סייבר-סייבר” והפחדות וכזה, אלא שאנחנו באים באופן קונסטרוקטיבי וטוב לעזור, ושזה צריך להיות כלב עם רצינות אבל גם חמידות - ואני מקווה שזה יצא טוב . . .אבל באמת - הוא ב One shot הצליח לעשות את הלוגו, ומאז לא . . .(רן) זה דווקא אחלה סלוגן - “חברת Security, אבל באים בטוב”, זה יכול לתפוס . . . (דני) שמע, גם אני מגיע מהעולמות האלה - מהסייבר, וזה קצת כזה . . . מכירה בעולמות האלה נראית הרבה פעמים כמו פרוטקשיין - “יש לך עסק יפה, חבל שמשהו יקרה לו . . .”(אורי) “יש לך פנים יפות, חבל . . .”(דני) אז באמת זה מה שהיה שונה אצלנו כבר מ-Day one בגישה - גם מבחינת המוצר וגם מבחינת ה-DNA של החברה, שבאנו לא בהפחדות.אגב - לא היינו באף כנס Security בשלוש השנים הראשונות של החברה, הלכנו רק לכנסים של מפתחים.(רן) מצויין - אז זה אתה וזה Snyk, ועכשיו בוא נדבר על הנושא של הערב: לפני כמה חודשים . . .(דני) כן - אוגוסט . . . פרסמנו באמצע אוגוסט, אבל הפרויקט התחיל חודש אחד לפני - בעצם מצאנו ספריית תוכנה שהייתה זדונית.אז זה אחד האיומים - דיברנו על חולשות ואבטחת מידע - אבל זה לא האיום היחיד שיש בלמשוך קוד מבחוץ: איום נוסף, שממש רואים איך הוא גדל בשנים האחרונות, הוא בעצם קוד זדוני, שמגיע דרך הספריות האלה.(אורי) דרך ספריות קוד פתוח . . .(דני) ספריות קוד פתוח שמשתמשים בהן - ומעניין לראות גם את הגיוון של איך שזה מגיע - לפעמים זה קוד זדוני שממש נכתב כזדוני, שמו אותו ב-Package Manager ופשוט חיכו שמישהו ישתמש בו, ולפעמים זו השתלטות על Account של מפתח של ספריית קוד מאוד פופולארית, למשל השתלטות על Account ב-GitHub, ואז “שותלים” לשם קודלפעמים אלו טכניקות כמו Typo-squatting - נותנים שם דומה לשם הפופולארי - דוגמא קלאסית זה jQuery.js ב-npm, במקום רק jQuery - או פשוט Typo (ומכאן השם Typo squatting), כשאתה משנה איזשהו תו קטן בשם.ואז הרבה אנשים מתקינים את זה - כמו אגב ההתקפה המקורית שהיא Domain Squatting, שבה אתה במקום לכתוב למשל Google עם שני “O” אתה כותב עם אחת וכו’ומה שמצאנו זו ספריית קוד ב-Package Manager שנקרא CocoaPods - זה SDK של חברת פרסום סינית(רן) ל-iOS(דני) ל-iOS ול-Android, לשתי הסביבותובעצם מה שמצאנו שם זה שה-SDK הזה, שנועד לאפשר למפתחים לעשות מוניטיזציה (Monetization) על הפרסומות באפליקציות שלהם - ועל הדרך הוא עשה עוד מלא מלא דברים רעים . . .בהתחלה, המחקר הראשוני העלה רק ממצאים ב-iOS, ומה שמצאנו שם זה שה-SDK התלבש בעצם על כל התקשורת שהאפליקציה עושה עם ה-Backend - והזליג את זה גם חזרה לחברה סינית . . . זה היה דבר אחד.כדי שלא יזהו את זה, הם השתמשו בכמה טכניקות מאוד מעניינות, שממש מזכירות את עולם ה-Malware הקלאסי - בין היתר ניסו לזהות האם המכשיר פרוץ, ואם הוא פרוץ אז לא פעלו; אם יש Proxy שמאזין לדברים אז הם גם לא הפעילו את הפונקציונאליות הזדונית . . .(רן) רגע . . . למה שלא יפעלו על מכשיר פרוץ? מה הסכנה פה? (דני) בעולמות של iOS ואייפונים, מכשיר פרוץ זה ממש סימן למישהו שיודע מה הוא עושה . . . בהרבה פעמים את צריך לפרוץ למכשיר בכדי בכלל להתחיל לנתח שם את הדברים . . .(רן) … אז כדי לא להתגלות, הם אמרו “אוקיי, בוא לא נתעסק עם החבר’ה שמבינים עניין”?(דני) נכון - וככה הם רצו במשך שנה.אגב, מה שהיה חשוד במה שהם עשו - היו הרבה דברים - אבל קודם כל הם עשו אובפוסקציה (Obfuscation) לכל המידע - למשל כשמסתכלים על Strings של Base 64, שנראים Base 64 encoded, ועושים Base 64 Decoding - וזה פשוט יוצא ג’יבריש . . .ואז רואים ששהם עשו איזשהו variant שלהם של Base 64.אז בעצם מה שמצאנו זה שהיה קודם כל את האלמנט הזה של הזלגת מידע - הם פשוט התלבשו על ה - HTTP Request של האפליקציה ושלחו את זה בחזרה אליהם.אבל - הם גם עשו Attribution Froud - בעולמות של פרסום, כש - User צופה או מקליק על פרסומת, נשלח Event ל-MMP, ה - Mobile Measurement Provider, אני חושב שזה הפירוש . . . רן בטח מכיר מ-Appsflyer(רן) כן . . .אז ה- MMP הוא זה שאחראי בסוף להגיד למי “מגיע” ה - Attribution, וכתוצאה מזה גם התגמול הכספי - ובמקרה הזה החברה פשוט שלחה קליק נוסף, מזויף, ל-MMPהם ידעו על הפעילות כי הם מזליגים את ה-HTTP Request ובעצם את כל ה-Events שקורים באפליקציהאז בעצם ה-Event האורגני הראשון נשלח כרגיל, אבל הם מהצד שלהם שולחים עוד אחד - ואיך שזה עובד זה לפי האחרון ששלח, הוא זה שמקבל את ה-Attribution - וככה הם בעצם עשו גם Fraud מול חברות ה - Advertisement.(רן) “חטפו את הקליק”(דני) “חטפו את הקליק”, ואת זה אנחנו רואים מהדאטה - אבל מעבר לזה גם גנבו את כל המידע, ופה זה גם לא כזה ברור האם הם עשו את זה רק כדי לגנוב את הקליק או שהם עשו עוד דברים עם המידע.(רן) עד כמה זה היה נפוץ ה-SDK הזה?(דני) קודם כל, ה-SDK בסך הכל הותקן בכ-1500 אפליקציות iOS ו-2000 אפליקציות Android - שזה מרגיש אולי קצת מספר לא גבוה, אבל כשמסתכלים על מספר ההורדות, אז מדובר בסך הכל על יותר ממיליארד - 1.2 מיליארד הורדות - בחודש. אלו המספרים.(רן) מתחרים ב-Traffic של Netflix . . .(דני) ממש.כל המשחקים, ממש ברמת שני ה-Vendors הכי גדולים של חברות משחקים, השתמשו ב-SDK הזה.שוב - רוב ה-Publishers ורוב האפליקציות שנפגעו מזה הן אפליקציות משחקים, אבל יש גם כמה אפליקציות Dating ואפליקציות Chat ועוד אפליקציות שונות.אבל באמת משחקים זה העניין - כל המשחקים שאתם מכירים מהטלפונים של הילדים (לא אתם, מה פתאום)(רן) אתה, כמפתח, רוצה עכשיו להתקין איזשהו SDK למוניטיזציה (Monetization), מוצא חברה שעושה את זה - לא תגיד “הלכתי ל GitHub ולקחתי איזשהו Package רנדומלי” - הלכת לחברה, הורדת את ה-SDK שלהם, הרשמי - לך תחשוד שיש שם Malware בתוך כל הסיפור הזה . . .(דני) נכון . . . אז החברה, קוראים לה Mintegral, והיא חברת בת של MobVista - זו חברה ציבורית, נסחרת בהונג-קונג, מדובר בחברות רציניות וגדולות.למרות זאת, הן בחרו להתעסק בדברים האלה - ומה שמעניין זה שכשמסתכלים הסטורית, אז זו לא הפעם הראשונה שמוצאים חברה סינית, או איזושהי חברה אחרת, שעושה כל מיני דברים באיזורים האלה.אבל תמיד היה להם א מה שנקרא Plausible deniability - הם יכלו לבוא ולהגיד “טוב, זו ספריה שלקחנו מבחוץ, וזה בכלל לא אנחנו, וזו בכלל טעות של מפתח, והוא בינתיים גם פוטר אז הכל טוב, סליחה”.פה הקוד נמצא ממש אצלם, הם אפילו לא ממש דאגו להסתיר אותו יותר מדי - ברגע שמצאת אותו זה In your face - ומה שמעניין זה שבעצם כשגילינו את זה - ובהתחלה גילינו את זה רק ב-iOS - הסתכלנו ב-Android ולא מצאנו כלום - לא העמקנו יותר מדי, אבל בהתחלה לא מצאנו כלום - אז פרסמנו.ואז קרו שני דברים מעניינים - (א) קיבלנו טוויט ממישהו שאמר שהוא מסתכל ב-Android וגם רואה שם דברים מוזרים, אז התחלנו גם להסתכל שם, ומצאנו שבכל זאת ב-Android יש איזור חבוי ששם לא הסתכלנו קודם, ומה שהם עושים שם זה מנסים לתפוס את ה-Downloads במכשיר - וספציפית Downloads שמגיעים מ-Google - וכשחושבים על זה מבינים שאלו Downloads שמגיעים מ-Google Play, ושככה הם מנסים לתפוס הורדות של משחקים ושוב - לדווח את זה על עצמם וכנראה, פה אנחנו לא יכולנו לוודא ולסגור את המעגל השלם ולראות שהם גם עושים את ה-Fraud.אבל ב-Downloads האלה הם, בטעות או שלא, תפסו גם Downloads של Google Spreadsheets ו-Google Drive ו-Google Docs וכאלה, אז בעצם אם אני שולח היום הודעת WhatsApp או email עם איזה לינק ל-Google Drive או ל-Google Docs - ואיך שזה עובד ב-Android, בגלל שזה גם גלובאלי, האינטנטים (Intents) נשלחים במכשיר, וכל אפליקציה, במקרה הזה ה-SDK, יכול היה להירשם לאינטנטים של הורדות גלובאלית - מספיק שיש לי אפליקציה אחת שהתקנתי ככה לילד שלי (נניח) ולא פתחתי כבר תקופה (נניח) - היא תתפוס את כל ההורדות Google Docs שלי מהמכשיר, זה - בשונה מ-iOS, ששם זה רק בקונטקסט של האפליקציה, כלומר - “רק” ה-Traffic של האפליקציה באמת זלג. עדיין חמור, אבל שונה מ-Google.(ב) דבר נוסף שקרה זה שהחברה, כדי כנראה להציל את ה-Reputation שלהם, שחררו את הקוד כ-Open Source, את ה-SDK - ואמרו ש”אנחנו בעד Transparency, ואנחנו מבקשים מכל התעשייה שככה תעשה את זה” . . .גם כאן(רן) זה היה לפני הגילוי או אחרי?(דני) אחרי . . . (אורי) וכאילו - “אנחנו משחררים אותו כ-Open Source - כדי שתורידו יותר” . . .(דני) כן - תורידו יותר . . אגב, הם לא התייחסו לעובדה שאת ה-Fraud הם עשו ב-Backend, אז זה שהם משחררים את הקוד כ-Open Source זה לא בדיוק פותח את כל הקלפים, אבל עדיין - זה היה צעד מעניין. מה שאנחנו עשינו . . .(רן) רגע, הם שחררו ממש את הגרסא שהכילה את הקוד הזדוני?(דני) לא, הם ניקו, הוציאו גרסא חדשה - ומה שאתה חושב עליו, זה בדיוק מה שעשינו: אמרנו “רגע, בואו נשווה את מה שהם שיחררו, ונשווה את הגרסא החדשה אל מול הישנה”.ראינו שהם באמת העיפו את כל מה שהצבענו עליו - את כל הדברים הרעים.אגב - הם גם פרסמו פוסט שאמר שהם גם ככה תכננו להוריד את הטכנולוגיה הזאת, ושבגדול - “אתם לא מבינים את הטכנולוגיה המדהימה הזאת, כל זה נועד לפרסומות מדהימות ו-Monetization מדהים ובגלל זה אנחנו המובילים בתחום” וכו’ . . .בכל מקרה - הסתכלנו, והם הורידו באמת את כל הפונקציונאליות שאמרנו שהיא זדונית - אבל היה שם עוד איזשהו קטע קוד, שלא היכרנו, וגם הוא ירד . . . שזה באותה נקודה פשוט זעק ”בואו נסתכל על הקוד הזה” . . .(רן) בטח פיספסנו פה משהו . . .(דני) לחלוטין פיספסנו - כי הקוד הזה בעצם היה Backdoor - דלת אחורית להרצת כל קוד על המכשיר, דרך פרסומת . . . צריך רגע לפרק את זה - קודם כל, Mintegral יכלו . . . נניח שאני פיתחתי אפקליציה והכנסתי את ה-SDK הזה לתוך המשחק שלי, עם הצגת פרסומות, הכל טוב ויפה.האפליקציה עברה Review של Apple, ולא אמור להיות שם קוד דינאמי - Apple “חתמו” על הקוד שסיפקתי להם, כולל ה-SDK הזדוני הזה, שלא הסתכלתי עליו בתור מפתח אבל זה המצב.עכשיו, Mintegral יכולים לשלוח קוד JavaScript ככה “מהונדס” ,שבסופו של דבר יריץ קוד Native-י כרצונם על המכשיראנחנו הדגמנו קוד פשוט שגונב את הClippboard, רק לשם המחשה - אבל זה יכול להיות כל קוד שהם רוצים.אבל יותר חמור מזה - כל Publisher וכל מפרסם . . . אנחנו יכולים עכשיו ללכת ולקנות פרסומות, לעשות Bid אפילו על פרופיל מסויים, למשל אנשים בגיל מסויים שגרים באיזור מסויים בעולם, וממש לדלוור (Deliver) איזשהו Exploit שממש יריץ קוד Native על המכשיר . . .(רן) זאת אומרת שלא רק יראו את ה-Image ואת ה-Creative - אלא גם תוכל להזריק לשם קוד, ובקוד הזה תוכל לעשות מה שאתה רוצה.(דני) נכון . . .(אורי) זה מה שקרה לנו בפריצה של . . .(רן) אתה רואה - זו חשיבה על Scale! אנחנו לא מספיק יצרתיים, אז ניתן לצד השלישי להיות יותר יצירתי!(דני) כן - זה ממש Code Execution as a Service . . . ממש.כשמסתכלים על הכמויות של האפליקציות ועל כמה שה-SDK הזה פופלארי, ובסופו של דבר מה הוא פתח באפליקציות האלה - זה די מטורף.(רן) אז מה - בנאדם קם בבוקר, שותה קפה ואומר - “אוקיי, עכשיו אני הולך למצוא Exploit”? כאילו - איך זה קורה?(דני) אז קודם כל, בצוות המחקר אנחנו עשים את זה כבר שנים, כלומר - אנחנו חוקרים את העולמות של ה-Open Source ואנחנו מחפשים חולשותוכשאנחנו מחפשים חולשות, אנחנו לא מחפשים במוצר מסויים, לא קמים בבוקר ואומרים “בוא נחפש חולשה ב - Apache Storm” ככה, כי זה מעניין אותנו, אלא בדרך כלל מסתכלים על ממש חיפוש ב-Scale.האנלוגיה שאני אוהב לתת היא שאנחנו “זורקים רשת אל הים” והרשת היא כזו שאנחנו בונים אותה ככה שתתפוש דברים מסויימים. ובמקרה הזה זרקנו את הרשת לים של CocoaPods, על כל הספריות שיש ב - CocoaPods, וחיפשנו כל דבר שעושה Method swizzlingאז Method swizzling זה ביטוי מעולם ה-iOS ל - Function Hooking, ל-Interception, ל- Instrumentation של פונקציה - כל אפליקציה שבאה “ומתלבשת” על פונקציית מערכת הפעלה ומנסה להיות “באמצע”, בין האפליקציה שקוראת לה לבין מערכת ההפעלה.וזה משהו שקודם כל לא אמור לקרות הרבה - זה באמת קורה לא מעט בעולם הפרסום, לפעמים SDK-ים מנסים לראות אם האוריינציה של המכשיר היא ככה או ככה ולהציג ולהתאים את הדברים, אבל בגדול זה משהו די חריג - ובמקרה הזה זה מה שעשה ה-SDK.וכשאנחנו “מושכים את הרשת מהים”, אז יש שם כל מיני ג’אנק ובקבוקי פלסטיק ודברים מוזרים - אבל לפעמים גם יש דגים, שאנחנו מסתכלים עליהם - במקרה הזה דג זהב ממש.אם אנחנו מסתכלים על ההיסטוריה אז ממש בצורה דומה מצאנו חולשות - אגב ההרצאה שהצגנו ברברסים על Zip Slip, איזושהי חולשה בת 30 שנה שעד היום קיימת בעולם ה-Java, שפשוט לא מצליחים להיפטר ממנה, וגם אז באותה צורה עשינו חיפוש על כל GitHub ומצאנו אלפי חולשות(רן) טוב, נו - מפתחי Java כבר 30 שנה לא משדרגים גרסא, לך תיפטר מזה . . .(רן) אוקיי - אז הרגשתם שיש פה משהו, ראיתם הרבה מופעים כאלו של Method swizzling, אם הצלחתי להגיד את זה נכון (לכתוב יותר קל) - ואז מה? אמרתם “בואו נתפקס”, ועכשיו איך בודקים? מה אתה מוצא שם? אתה מתחיל לקרוא קוד, לעשות Reverse Engineering לקוד? מתחילים להריץ? מה?(דני) שאלה מעולה - אז זה לא היה בהרבה מופעים, ממש הרצנו את זה שוב כדי לראות אם מישהו . . . אם Mintegral, כל השינויים שהם עשו עדיין נתפסים אצלנו - והם לא נתפסו וזה אומר שהם באמת הם ניקו.בכל מקרה, היו עשרות תוצאות, שמהר מאוד אנחנו עברנו על רובן - וזה הספציפי באמת התחיל להרגיש כמו משהו חריג.בדיוק סיפרתי על ה - Base 64 המוזר שהם קצת שינו אותובסוף אפילו לא עשינו Reverse Engineering ל - Base 64, פשוט השתמשנו בפונקציה שלהם לזה, היינו עצלנים . . .אבל לשאלתך - באמת הספרייה הזו היא Closed Source - אין לה Open Sourceהם פתחו אותה ל - Open source אחר כך, אבל זה לא היה ככה קודםזו באמת פעם ראשונה ב-Snyk שלי יצא ממש לעשות Reverse Engineering, כי בדר”כ זה Reverse Engineering לקוד, לא יודע אם זה נחשב כ- Reverse Engineering, ואלו דווקא עולמות שעסקתי בהם הרבה לפני.וכן - זה ממש להסתכל על האפליקציה, על קוד ה - iOS ו . . .(רן) זאת אומרת שעשיתם לו דה-קומפילציה (De-compilation) . . .(דני) כן, אז דה-קומפילציה זה אפילו ה - Luxury . . . עושים Diss-Assembly מסתכלים על קוד Assembly, והיום יש De-compliers ממש טובים, שלא מחזירים את זה לקוד מקור אבל בקירוב די . . .(רן) לא צריך לזכור בעל פה את המספרים של הריגיסטרים (Registers) . . .(דני) לא . . . אז עלינו לא מעט דברים מעניינים - כמו שאמרתי, את חלקם לא מצאנו; מצאנו כל מיני חריגות, אבל למשל את ה-Backdoor הזה לא מצאנו, מצאנו רק כעשינו . . .(רן) כמה זמן לוקח מחקר כזה? כמה זמן לקח?(דני) אגב, צריך לציין שגם במהלך המחקר התחלנו להתחבר עם חברות, עבדנו גם עם Appsflyer למשל.צד הדאטה למשל - לא היה לנו Visibility אליו: כל הקליקים, מה קורה בצד ה-MMP? -על כל זה עבדנו עם שחקנים בתעשייה.אבל המחקר שלנו, אם אני מזקק את זה לנטו-עבודה, זה ממש עניין של אולי שבוע.מהרגע שהתחלנו את הפרויקט עד הרגע שפרסמנו לקח חודש - אבל אז, ככה, באו הגלגולים הנוספים של הפרויקט.(אורי) זה כי אתם לפעמים מפרסמים עוד לפני שאתם מבינים את כל התמונה?(דני) לא - אני אישית משתדל לכתוב . . . כשאנחנו מדברים על פרסום אז זה בדרך כלל על לכתוב בלוג-פוסט, וכשזה משהו די גדול אז עושים קצת PR ומדברים עם Outlets וכזה.במקרה הזה, בדרך כלל אנחנו שואפים לכתוב משהו כשאנחנו מרגישים בטוחים לגבי כל הפרטים - אז גם עשינו את זה פה.לצורך העניין, לא שינינו שום דבר ממה שפרסמנו, אז כן - השאיפה היא לתת כמה שיותר מידע מהפרסום הראשון.(רן) בדרך כלל, לפחות כשמדובר לא בקוד זדוני אלא מדובר בבאגים נגיד - הדוגמא הקלאסית של Stack Overflow וכו’ - סליחה - Buffer overflow - אז יש את העניין הזה של “גילוי אחראי”, נכון? אתה לא הולך וישר מפרסם, אלא קודם כל מגיע ליצרן של הקוד ונותן לו איזשהו Heads-up וזמן לתקן את זה - ורק אחרי שהוא הבטיח שהכל מתוקן ויש כבר גרסא חדשה, רק אז אתה מפרסם.פה המקרה שונה - פה, מדובר על יצרן זדוני.אז איך פועלים? מה הפרוטוקול במקרה כזה?(דני) אז באמת ה - Responsible disclosure לא תקף פה . . הוא בעצם תקף, אבל לא על השחקן עצמו, כלומר - לא באנו בשום שלב לחברה . . . זה מעניין, אגב - הם פנו אלינו אחרי שפרסמנו, והציעו לנו . . רצו לקנות את Snyk בתמורה לכך שנעזור להם לטפל באירוע הזה . . .כלומר - לקנות את המוצר של Snyk, לא את החברה.אבל כן ה - Responsible disclosure תקף לשחקניות הגדולות - לGoogle ול-Apple - כי הן בעצם מחזיקות ב-Marketplace, ולהן יש גם את האפשרות לתקן - זה שאנחנו נותנים להן Heads-up - יש להן מה לעשות, וזה מה שעשינו.זה מעניין - ל-Apple בהתחלה, כנראה שהדבר הזה לא בא להם כל כך בטוב, כי אנחנו קצת ה - Bad news Messenger, כאילו . . .(אורי) אתם חושפים גם חולשה שלהם.(דני) זה בדיוק בא - איכשהו בלי שתזמנו את זה ככה - אבל זה בדיוק בא בזמן שהיה את הבלגן עם Epic Games והייתה הרבה ביקורת על כל מה שקורה שם עם ה-30% . . .מלא שיח על זה - ופתאום אנחנו באים ואומרים: “טוב, חבר’ה, כאילו יש פה כמה מאות אפליקציות מה-Top-500 שיש בהן דברים רעים ממש” . . .(אורי) כמה מאות מה-Top-500 . . .(דני) כן, קרוב ל-200 מה-Top-500, זה אחוז מאוד גבוהבכל מקרה - הם בהתחלה ניסו . . . לא היו פעילים מדי, אפילו לא הודיעו למפתחי האפליקציות - אז בחרנו לעשות את זה בעצמנו.מן הסתם זה משהו שיותר קל ל-Apple לעשות, יש להם את האי-מיילים של כולם וכו’.אבל מה שמעניין זה של-Google דווקא הייתה את התגובה ההפוכה - הם פשוט קפצו לשיחה, הביאו את כל האנשים הרלוונטיים - חוקרים ואנשי Legal וכו’, וגם אמרו לנו שהם מכירים את . . לא את המקרה הזה, אבל את ההיסטוריה עם השחקניות האלה, וממש הגיבו מהר.כן צריך לציין שברגע שמצאנו את ה-Backdoor, אז בעצם ל-Apple זה כבר . . . זה לא היה רק עצם בגרון, הם ממש היו צריכים לפעול, כי זה משהו שהוא . . . מקודם הם אמרו ש”זו אחריות של המפתחים”, בגדול הם שמו את האחריות על המפתחים - “הם בחרו את ה-SDK, הם שמו את זה באפליקציה - אז שיתמודדו עם זה”.אבל כשיש ממש המון משתמשים שחשופים עכשיו להרצת קוד, אז פה הם כבר נאלצו לשלוח הוראות . . .(רן) זו “פצצה מתקתקת”, שגם אם הם יכולים איכשהו להכחיש שזו אשמתם, זה עדיין הולך לפגוע להם ב-PR(אורי) זה מעניין, כי גם Apple לוקחת Stand בעולם של Privacy - ואם יש להם Backdoor כזה . . .(דני) נכון - ועדיין אני מרגיש ש . . כלומר, בסוף הם פעלו ואז שלחו לכל המפתחים את הבקשה להוריד את ה-SDK הבעייתי, אבל עדיין - התגובה שלהם, לפחות הראשונית, הייתה די חלשההם בעצם בחרו ככה לשים את האחריות על המפתחים, שזה . . . יש בזה משהו חשוב, במסר - אבל הם עצמם יכלו לפתור את הבעיה בעצמם מיד, ולא לחכות עד שמפתחים יתחילו . . . עד שאנחנו (Snyk) נפנה אליהם קודם כל, וזה לוקח המון זמן, ולהסביר להם מה קורה וכו’אז במקרה הזה באמת ה - Responsible disclosure היה לדבר עם החברות הגדולות.אגב - כן פנינו לעשרת ה-Publishers הכי גדולים בצורה ישירה, פשוט כי הם ממש . . .זה כזה Pareto Distribution - עשרה מה-Publishers שולטים ב-90% מהשוק, אז זה כיסה לנו ממש את רוב ה . . .(רן) איך אתה יודע מי הם עשרת ה-Publishers הגדולים?(דני) אז יש דאטה . . .(רן) אה - הכוונה באופן כללי, לא לאותו ה-SDK, עשרת ה-Publishers הגדולים בעולם?(דני) על זה ספציפית יש גם דאטה על SDK - שירותים שנותנים ממש סטטיסטיקות . . .Apple ו-Google לא מפרסמים את זה בעצמם, אבל יש שירותים שנותנים את המספרים האלה, כולל גם איזה SDK נמצא באיזו אפליקציה.(אוקי) כמו . . . טוב, זה יותר ל-Open Source בכלל אבל WhiteSource וכאלה?(דני) WhiteSource היא מתחרה של Snyk אז . . .(אורי) WhiteSource נכנסת לעולם של Security ספציפית?(דני) בעצם היא התחילה מעולמות של Legal, אבל איפשהו כשאנחנו קמנו, אז הם עשו Shift, ואני חושב שהיום הם רואים את עצמם כחברת Security ומשווקים את עצמם כחברת Security - אגב, ככה עשו גם כל השחקניות האחרות, למשל BlackDuck, שהתחילה מעולמות ה-Legal וה-Complience והפכה לחברת Security, ונמכרה אח”כ כחברת Security.(רן) טוב, אז קודם כל זה היה סיפור מתח בשלוש מערכות . . .(אורי) חשבתי שתביא לנו משהו איראני כזה . . .(דני) כן מדובר בחברה סינית . . .(אורי) תמר רביניאן עובדת אצלכם?(רן) כן . . . אז יש עוד, ככה, אנקדוטות או חומרים עסיסיים שלא פורסמו שאתה יכול לחלוק עם המאזינים שלנו בקשר לסיפור הזה?(דני) אני חושב שבאמת העניין הזה של זה שפנה אלינו בכיר מהחברה . . . הוא כתב מייל מאוד נחמד שבו הוא . . .קודם כל - זאת הייתה הפעם הראשונה ששמענו משהו מהחברה, הוא שלח מייל “אישי”, מייל ארוך, שבו הוא אומר “תודה על העבודה שלכם, מאוד חשוב לנו לתקן את הדברים, ואנחנו עובדים על זה” - ומבקש מאיתנו לעזור להם בזה- בתמורה לזה שכל הקבוצה - לא רק החברה, זו קבוצה גדולה - שתשמח לאמץ את מוצרי Snyk . . .אנחנו סירבנו להצעה אז - אבל מה שגילינו ממש אחרי שבוע, בשיחות עם אחד ה-Publishers, זה שהם ממשיכים ומספרים את הסיפור של “Snyk בעצם כן עוזרת להם”, שהם כבר משתפים איתנו פעולה ושהכל מאחוריהם.אז כן - זה קצת העולם שאנחנו . . .(רן) תבדוק אם הלוגו שלך נמצא שם, באתר שלהם . . .(אורי) סוג של אמינות סינית?(רן) חבל, אם זה לא היה קורונה עכשיו היו שולחים לך כרטיס לסין, לעשות לך קצת Good time ושתשכח מכל הסיפור הזה . . .טוב, אחלה - סיפור מאוד מרתק, ודרך אגב - אני מניח שעד היום יש אפליקציות שרצות עם הפגיעות הזאת, זה לא נעלם ביום . . .(דני) נכון . . .(רן) איך עוקבים אחרי דבר כזה? עכשיו זה כבר תפקיד של Apple?(דני) אני חושב ש-Apple במקרה הזה … יש פה שאלה באמת של אפליקציות ומכשירים שפשוט לא מעדכנים את האפליקציות, אז גם אם יש גרסא חדשה, ומישהו פשוט לא דואג לעדכן . . .יהיה מעניין לראות האם Apple יחליטו פשוט להוריד את זה - יש להם את היכולת להוריד את האפליקציות האלה, גם Remotely, אבל הם עוד לא עשו את זה.אני חושב שאחד הדברים המעניינים לראות מכל האירוע הזה זה באמת העלאת המודעות לתופעות האלה בקהילת ה-Mobile, כי היא קצת שונה מה-Ecosystems האחרים.כשמסתכלים באמת על . . . יש פה שני (סוגים של) קורבנות באירוע הזה - יש את המפתחים עצמם, שפשוט משכו איזשהו SDK ורצו להרוויח על האפליקציה שלהם - ובעצם הכניסו משהו שהם לא ידעו . . . אגב, שה-Terms of Service שם כמובן שלא אמר להם את כל מה שהם עושים, ה-SDK, ו . . .(רן) למה, אתה יודע סינית?(דני) כן, אז היה להם . . .(אורי) זה סינית בשבילו . . . (דני) הם, אגב, עידכנו מיד אחרי הפרסום, יום אחרי הפרסום, את כל ה-Terms of Service שלהם, Heavy edits - והוסיפו את כל מה שהיה חסר שם, כולל HTTP Request interception ודברים כאלה . . .(רן) אז תבדוק את ה-Diff-ים, אולי תגלה עוד משהו . . .(דני) אז באמת אלו המפתחים - והקבוצה השנייה הם בעצם הצרכנים - אנחנו, אלו שיש להם ומי שהתקין את כל האפליקציות האלה.ואני חושב שממש היה יפה לראות, לפחות בקבוצה הראשונה, איך המודעות שם עולה, ואיך מבחינת השיח והעניין להכיר בכלל בבעיה הזאת . . . זה, אני חושב, היה הדבר הכי משמעותי שיצא מהפרסום, כי לצערי עדיין יהיו חברות שיעשו את הדברים הרעים האלה ועדיין יהיו לנו את העולמות האלה של ריגול - אבל אני ממש שמח לראות את המודעות עולה לבעיות האלה.(אורי) אז רגע, יש לי שאלה - היום, כל Vulnerability, פגיעות . . .(דני) חולשה(אורי) . . . חולשה שאתם מגלים - אתם מפרסמים בבלוג-פוסט?(דני) לא, ממש לא . . .(אורי) רק את המעניינות?(דני) כן, אני חושב . . כפי שאמרתי, אנחנו מסתכלים על דברים ב-Scaleלמשל, אם אנחנו מוצאים חולשה שנמצאת באלפי פרויקטים, אני חושב שזה סיפור מעניין, וזה סיפור מעניין לא רק עבור ה-Publicity שלנו - זה סיפור מעניין באמת למודעות בקרב הקהילה.אז אותה דוגמא שקראנו לה Zip Slip, אותה חולשה של 30 שנה, ממש חולשה עתיקהאגב - כזו שאני יכול להסביר במשפט וכל המאזינים יבינואותה חולשה עדיין נמצאת . . .כשמצאנו אותה אז מצאנו אותה באלפי פרוייקטי Open Source, ממש פרויקטים של אלפי Stars ב-GitHub, וזו תופעה שאני חושב שהיא מעניינת לדווח עליה.אבל אנחנו כל יום מוצאים חולשות, וזה מתווסף ל-Database שלנו שם באתר, אבל לא בלוג-פוסט . . .(אורי) אמרת “ה-Database שלנו באתר” - זה נגיש? אתה יכול להכניס מספר גרסא של SDK שאתה משתמש בו, או Open Source . . .?(דני) חד משמעית כן - זה קליק שאתה יכול לעשות באתרקודם כל - המוצר שלנו הוא חינמי ל-Open Source, והוא גם חינמי עד Usage מסוייםאז כן - אתה יכול גם פשוט לסרוק את הפרויקט שלך בפקודה אחת: npm install snyk ו - snyk test וזהו.(רן) מעולה - תודה דני, אחלה סיפור, נשמע כמו מוצר באמת מעניין לכל מי שאכפת לו מ-Security .תודה שבאת, היה מאוד מעניין. תודה.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

In today's episode I share 8 common programming slang terms that you may have heard... but not quite known what they meant. There are MANY more and I've love to hear some of the ones I missed in the comments. In this video we go over, Yak Shaving, Refuctering, Code Smell, Stringly-Typed, Grok, Magic Numbers, Spaghetti Code, Rubber Ducking. YouTube Video version: https://youtu.be/OmQpyaP5S9U More information about my iOS Development courses: https://seanallen.teachable.com/ Link to my book - How I Became an iOS Developer: https://gumroad.com/l/sean-allen-origin Twitter: https://www.twitter.com/seanallen_dev YouTube Channel: https://www.youtube.com/seanallen Portfolio: https://seanallen.co Book and learning recommendations (Affiliate Links): Ray Wenderlich Books: https://store.raywenderlich.com/a/20866/link/1 Ray Wenderlich Video Tutorials: https://store.raywenderlich.com/a/20866/link/24 Paul Hudson's Hacking With Swift: https://gumroad.com/a/762098803 Learn Advanced Swift Here: https://gumroad.com/a/656585843 My Developer & YouTube Setup: https://www.amazon.com/shop/seanallen --- Support this podcast: https://anchor.fm/seanallen/support

This Week in Amateur Radio Edition #1125 Release Date: September 19, 2020 Here is a summary of the news trending This Week in Amateur Radio. This week's edition is anchored by Dave Wilson, WA2HOY, Don Hulick, K2ATJ, Rich Lawrence, KB2MOB, Will Rogers, K5WLR, George Bowen, W2XBS, and Jessica Bowen, KC2VWX. Produced and edited by George Bowen, W2XBS Running Time: 1:20:16 Download here: http://bit.ly/TWIAR1125 Trending headlines in this weeks bulletin service: 1. 5 MegaHertz Interoperability Channels Designated for Wildfires and Hurricane Sally Response 2. International Radio Stations Now Restricted On TuneIn.com 3. Radio Amateurs Of Canada Announces Its Annual General Meeting and Mini-Conference For 2020 4. FCC Grants ARRL Rules Waiver Request for Fire Emergencies, Hurricanes 5. Hurricane Watch Net Wraps Up Another Marathon Activation for Two Storms 6. ARRL to Seek Changes in FCC Draft Decision on Amateur Nine Centimeter Band 7. Analysis Determines We Are in Solar Cycle 25 8. International Telecommunication Union Releases 2020 ITU Radio Regulations 9. Update: Amateur Radio Exams are Not Going Away in Brazil After All 10. Radar Technology At Millimeter Wavelengths Is Beginning To Show Promise 11. Bill Sexton N1AN, Prominent Member Of New York MARS, SK 12. Virtual Amateur Radio Club Meetings Are A Global Success, And The United Kingdom Is No Exception 13. Visually Impaired Radio Amateur Net Expands Check-In Opportunities 14. Amateurs in West Bengal India Reunite A Missing Man With His Family 15. The ARRL Technical Service Award Is Conferred 16. Hurricane Watch Net Is Tracking New Weather Systems Plus these Special Features This Week: * Technology News and Commentary with Leo Laporte, W6TWT, will answer the question, is it safe to buy third-party lithium-ion batteries, and will attempt to describe Public Key Cryptography. * Working Amateur Radio Satellites with Bruce Paige, KK5DO - AMSAT Satellite News * Tower Climbing and Antenna Safety w/Greg Stoddard KF9MP, will talk about the process of removing rusted bolts from antennas on your tower. * Foundations of Amateur Radio with Onno Benschop VK6FLAB, will describe "Yak Shaving". What's that? Well, that's when you get side-tracked by multiple other tasks before completing what you originally set out to do. * Weekly Propagation Forecast from the ARRL * Bill Continelli, W2XOY - The History of Amateur Radio. Bill returns with another edition of The Ancient Amateur Archives, this week, Bill will take a nostalgic look back at Olsen Electronics. ----- Website: http://www.twiar.net Facebook: https://www.facebook.com/groups/twiari/ Twitter: http://www.twitter.com/twiar RSS News: http://twiar.net/?feed=rss2 iHeartRadio: http://bit.ly/iHeart-TWIAR Spotify: http://bit.ly/Spotify-TWIAR TuneIn: http://bit.ly/TuneIn-TWIAR Automated: http://twiar.net/TWIARHAM.mp3 (Static file, changed weekly) ----- Visit our website at www.twiar.net for program audio, and daily for the latest amateur radio and technology news. Air This Week in Amateur Radio on your repeater! Built in identification breaks every 10 minutes or less. This Week in Amateur Radio is heard on the air on nets and repeaters as a bulletin service all across North America, and all around the world on amateur radio repeater systems, weekends on WA0RCR on 1860 (160 Meters), and more. This Week in Amateur Radio is portable too! The bulletin/news service is available and built for air on local repeaters (check with your local clubs to see if their repeater is carrying the news service) and can be downloaded for air as a weekly podcast to your digital device from just about everywhere, including iHeart, iTunes, Google Play, Spotify, TuneIn, AnchorFM, Stitcher, iVoox, Blubrry, Castro, Feedburner, gPodder, Listen Notes, NetVibes, OverCast, Player.FM, PocketCast, Podnova, and RSS feeds. This Week in Amateur Radio is also carried on a number of LPFM stations, so check the low power FM stations in your area. You can also stream the program to your favorite digital device by visiting our web site www.twiar.net. Or, just ask Siri, Alexa, or your Google Nest to play This Week in Amateur Radio! This Week in Amateur Radio is produced by Community Video Associates in upstate New York, and is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. If you would like to volunteer with us as a news anchor or special segment producer please get in touch with our Executive Producer, George, via email at w2xbs77@gmail.com. Also, please feel free to follow us by joining our popular group on Facebook, and follow our daily feed on Twitter!

Foundations of Amateur Radio Yak Shaving ... Not every adventure gives you an outcome. Today started with reading a thank-you email from a listener who shared their activities and wanted to express their gratitude for encouraging them to get on air and make noise. That in turn prompted the question on the country of origin of that listener and did I know where all my listeners were? For the past few hours I've been attempting to answer that seemingly simple question. Aside from using the opportunity to make an attempt at mapping the distribution of amateurs in Australia, which on the face of it is a trivial exercise, consisting of extracting the postcode from each registered amateur and then putting those on a map. Only the postcodes are not actually single points. They're boundaries defined by Australia Post and they're copyrighted. Not only that, they change. To access them, you have to pay the Post Office. If you want to combine a postcode with a population density, so you can see where amateurs are represented and at what level, you go to the Australian Bureau of Statistics for a population density data-set. At that point you realise that the Bureau uses standardised regions. Mesh-blocks at the smallest end of the scale are essentially the size of 30 to 60 households. The Bureau uses these as the fundamental size for all its statistics. When you attempt to map this onto postcodes you learn that there isn't a one-to-one mapping and even if there was, it would change every time Australia Post changed a postcode boundary. I will note that this is all by way of a side-street in my investigation. I wondered how amateur radio is distributed across the country and I didn't want to end up with essentially a population density map, more people means more amateurs, I wanted to see where amateur radio had the potential to affect more people because there are more of them in a group. Anyway, then I attempted to look at the podcast downloads and map those to countries. I use AWS CloudFront to make the podcast available, so it gets to the user, you, quicker. The logs show which data-centre a request is handled by. Then I needed to map a data-centre to an airport code, look that up in a database so I could extract the country, then count how many requests were made per country. Then I started doing that across time, so you can see how that changes over time. At this point I still don't actually have a map to show. While all this was happening, my computer started running low on disk-space, not because I'd just downloaded some data from the Australian Bureau of Statistics, but because some rogue process was writing a log somewhere, so I spent an hour looking for what process that was, killing it and removing the superfluous log file. If this sounds familiar, there's a name for it. Yak shaving. It's originally named after a Ren and Stimpy episode called "Yak Shaving Day". Essentially you do a whole lot of unrelated activities in the pursuit of the actual activity, essentially a string of dependencies that distract you from the end-goal. In my case, trying to answer which countries are represented within my audience. Why am I not using an amateur radio example? Two reasons. This is amateur radio. For me. Doing charts, wrangling data, massaging stats, finding answers and presenting those are an integral part of the hobby, to me. Just like making this podcast, contributing to discussion, reading and learning. All part of the mix. Second reason is that I wanted to illustrate this with something that wasn't immediately obviously linked to the hobby for most people. A more amateur example might be wanting to go and operate portable, attempting to locate you battery, when you find that it's not charged, so you go looking for the charger which you find has a broken connector, so you drive to the electronics store to get the connector when you run out of petrol, so you pull over, get out of the car and trip over the curb and end up in hospital emergency waiting for a doctor to see you. If you think that's far-fetched, I know an amateur who ended up in hospital from yak-shaving. We've all had days like that. The idea is that any day that you are on the right side of the earth, doing something you love is a good day. Regardless of the end result, this is a hobby after all. I'm Onno VK6FLAB

533 - Small Favors- Aug 20 Join the Zoom Chats: Tuesday is 5am Eastern (for New Zealand and Australia & the UK) Register in advance for this meeting:  After registering, you will receive a confirmation email containing information about joining the meeting. Thursday is 7pm Eastern: Register in advance for this meeting:  After registering, you will receive a confirmation email containing information about joining the meeting. Tuesday Book Chat https://www.wnycstudios.org/podcasts/radiolab/articles/invisible-allies Wanda Linda & the Terrible Underpants: https://amzn.to/3kVgAQf https://www.wired.com/video/series/5-levels Mindhunter (David Fincher) https://www.netflix.com/title/80114855 Yak Shaving: https://www.waywordradio.org/yak-shaving/ Thursday Book Chat Jennifer: The Transcendental Murders by Jane Langton (first of the Homer Kelly books). She also wrote a number of philosophical novels for children, including The Swing in the Summerhouse and The Fledgling. Also, Moon over Soho (Rivers of London #2, thank you Aimee), How to be Good by Nick Hornby and Erebus: The Story of a Ship by Michael Palin (yes, that Michael Palin) Kelly: Carmen - City of Secrets (Counterfeit Lady #2) by Victoria Thompson  Never Split the Difference: Negotiating as If Your Life Depended On It by Chis Voss https://www.goodreads.com/book/show/26156469-never-split-the-difference?ac=1&from_search=true&qid=oSwQGWAhgq&rank=1 (former FBI hostage negotiator, interesting takes on negotiation)  - a friend of Kelly's described the musical this clip is from as "bonkers bad in the best way." (the show is Dance of the Vampires) Jennifer: Sssh. I'm still working on Lou's Christmas socks. The pattern is Frank Lloyd Right Socks by verybusymonkey

There was a time when William Shakespeare was just another little 7-year-old in school. Classes in his day were demanding -- and all in Latin. A new book argues that this rigorous curriculum actually nurtured the creativity that later flourished in Shakespeare's writing. Don't know Latin? You can still adapt those approaches to stretch and hone your own mind. Plus, why do we refer to an unpredictable person as a loose cannon? The answer lies in the terrifying potential of a large weapon aboard a warship. And when a delivery driver's wife teases him about cavorting with strumpets, he asks: What exactly IS a strumpet? All that, plus picayune, sit on a tack, the many meanings of fell, a Spanish idiom about oysters and boredom, pickthank, a puzzle about rhyming words, a terrifying passage from Victor Hugo, tacos called mariachis, and the juice was worth the squeeze. Read full show notes, hear hundreds of free episodes, send your thoughts and questions, and learn more on the A Way with Words website: https://waywordradio.org/. Email words@waywordradio.org. Twitter @wayword. Our listener phone line 1 (877) 929-9673 is toll-free in the United States and Canada. Elsewhere in the world, call +1 (619) 800-4443; charges may apply. From anywhere, text/SMS +1 (619) 567-9673. Copyright Wayword, Inc., a 501(c)(3) corporation.

As one of the founders of the Transforming People Academy, which specialises in accelerated learning, coaching and personal development, Michael Colhoun knows all about what it means to harness the fire in your belly, and turn that passion into something positive. Michael joins Pete on this week’s show to discuss the challenges he faces in bringing about this positive change to a society very much set in its ways, the ways in which yoga has improved his connection between mind and body, how to turn negatives into positives, and how he built his journey upon discovering the secret that makes things work better for everyone. KEY TAKEAWAYS Especially in Northern Ireland, there seems to be a growing need for some way to help people see past the blocks and barricades that may be keeping their desire for personal growth. Michael and his academy are at the forefront of bringing those barriers down.   If you can understand the methods and strategies that enabled someone to achieve success in their life, then you should be able to emulate that formula in order to find success for yourself.   Yoga gave Michael the capability to tap into hitherto undisturbed forces within himself, in order to release energy that restored his flow-status.    If you’re doing a certain thing throughout your life, and you’re good at it, but not necessarily successful as a result of it, it can be difficult to pull yourself away from that “safety zone”   We are responsible for the results we attain. We’re responsible for the choices we make. We’re also responsible for whether we feel good or bad. Each negative can be turned into a positive. We need to have a resilient internal voice in order to do so.   It can be so easy to blame external forces for our sense of inadequacy, or our failures. The reality is that those feelings are just triggers for lessons you haven’t learned yet.   Despite a hugely successful career in IT, Michael recognised that his future was in development, due to his experiences with NLP and the benefits that it can bring. This caused shock to those who knew him, but instinctually he knew that his choice was sound.   One of the greatest pieces of education came through working alongside successful people with complex problems, and solving those problems on their behalf. Most of these issues stemmed from miscommunication, and through his NLP experience, Michael was able to make himself invaluable.   Problem solving for Michael comes through not just getting from Point A to Point B, but understanding the wider issues that caused the problem, and the satellite issues that circle it. by gaining a depth of understanding, he can not only solve Point B, but Point C if asked.   Michael gets direct feedback from teaching when he understands something so well, that his teachings provide “A-ha” moments from his students. By being able to communicate teachings in that spirit, we are truly mastering our subject.   It’s as crucial to prepare your environment for your flow state as it is to be in the flow state itself. “Yak Shaving” is the process by where we do away with the things that will prevent this flow state from occurring, or can distract us once we’re there   BEST MOMENTS ‘If one person can do it, then anyone can do it’ ‘I had a choice whether to feel good, or feel like a victim’ ‘If you’re going to feel bad, then you might as well schedule it’ ‘A big part of it is confidence and certainty’ ‘I call it “deep dive” learning’ ‘If you want to understand something, read it. If you want to know something, write about it. If you want to master something, teach it’ ’The tell-tale is that time disappears’ ‘How do we start to create a better future for everybody?’   VALUABLE RESOURCES Fire In The Belly Podcast - https://podcasts.apple.com/us/podcast/fire-in-the-belly/id1499375061 Transforming People Academy - https://www.transformingpeople.com/home36075388 Transforming People Academy Facebook - https://www.facebook.com/transformingpeopleacademy/ Transforming People Twitter - https://twitter.com/transformingacm ABOUT THE HOST The ‘Mighty Pete Lonton’ from the ‘Mighty 247’ company is your main host of ‘Fire In The Belly’.  Pete is an Entrepreneur, Mentor, Coach, Property Investor and father of 3 beautiful girls. Pete’s background is in Project Management and Property, but his true passion is the ‘Fire In The Belly’ project itself. His mission is to help others find their potential and become the mightiest version of themselves. Pete openly talks about losing both of his parents, suffering periods of depression, business downturn and burn-out, and ultimately his years spent not stoking ‘Fire In the Belly’. In 2017, at 37 years of age that changed and he is now on a journey of learning, growing, accepting and inspiring others. Pete has the ability to connect with people and intuitively asks questions to reveal a person’s passion and discover how to live their mightiest life. The true power of ‘Fire In the Belly’ is the Q&As - Questions and Actions! The ‘Fire In The Belly’ brand and programme is rapidly expanding into podcasts, seminars, talks, business workshops, development course and rapid results mentoring. CONTACT METHOD https://www.facebook.com/mightypetelonton/ https://www.linkedin.com/in/peter-lonton-4b83184 https://www.facebook.com/groups/430218374211579/ Support the show: https://www.facebook.com/groups/430218374211579/ See omnystudio.com/listener for privacy information.

In blog post, "Creating 2020, Yak-Shaving Edition" Malcolm outlines her plans for the upcoming year and describes some of the difficulties she foresees.  Story Listing: 00:00 Malcolm van Delst - "Creating 2020, Yak-Shaving Edition" - blog post - http://malcolmvandelst.com.  Works in progress. Copyright remains with the authors. Image from https://pixabay.com

John is a Ruby developer at GitHub, based in New Jersey. He’s got a ton of other interests including wood & metal working, climbing, beer making, drumming, and his family. Show Notes Phil Sturgeon (https://www.parallelpassion.com/34) The other seejohnrun (https://www.seejohnrun.com/) GothamGo 2019: Interacting with Custom-Made Hardware in Go (https://www.youtube.com/watch?v=j7BXNoy2dwA) Leaning Tower of Pisa (https://en.wikipedia.org/wiki/Leaning_Tower_of_Pisa) Aaron Patterson (https://www.parallelpassion.com/30) Chevrolet C-10 (https://en.wikipedia.org/wiki/Chevrolet_C/K#First_generation_1960%E2%80%931966) Yak Shaving (https://en.wiktionary.org/wiki/yak_shaving) Lathe (https://en.wikipedia.org/wiki/Lathe) SawStop demonstration video (https://www.youtube.com/watch?v=eiYoBbEZwlk) Alex Honnold (https://en.wikipedia.org/wiki/Alex_Honnold) Mr. Beer (https://www.mrbeer.com/) Recommendations Jimmy DiResta (http://www.jimmydiresta.com/) The Da Vinci Code (https://www.amazon.com/o/ASIN/0307474275/parpaspod-20) Grandfather and father John Crepezzi Twitter (https://twitter.com/seejohnrun) Personal Page (http://seejohncode.com/) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits Philip Swinburn (https://unsplash.com/@pjswinburn) for the header photo Tina Tavčar (https://twitter.com/tinatavcar) for Parallel Passion logo Jan Jenko (https://twitter.com/JanJenko) for intro/outro music

Dr. Alan Mead rants about those that get "called into work" and lays forth about a concept called "Yak Shaving." Some links from the show: Yak Shaving Free stuff is awesome. Cool free stuff is even better. Microcopy Dental offers free samples on a lot of it's products. It's there way of letting you try before you buy. But make no mistake, their quality and efficiency will hook you! Why not try a free sample of their newest product called Proxi-check. It's an ingenious piece of interproximal articulating paper that helps to fine tune your contacts with no fuss and no mess! Go check it out at dentalhacks.com/proxichek!  You’ve spent a lot of time on your clinical skills. You’ve figured out the right people to dial in restorative dentistry, implants, endo and everything else you need to keep your patients healthy. Finding clinical education and mentorship isn’t very hard because there are so many resources. Don’t you wish you could find a dental business mentor? Well...now you can! Our friend Dr. Paul Etchison and his partner Dr. Justin Bhuller are both incredibly successful dentists. They’ve figured out the business side of running a dental practice and now they offer it to you through Dental Business Mentor. Dental Business Mentor has online courses for the whole team and is created to take your entire team to the next level. Even better...Dental Hacks listeners can use the code: HACKS350 at dentalhacks.com/dentalbusinessmentor for $350 off the annual subscription! It’s time to take your business skills up a notch and our friends at dental business mentor can do it for you!  

This week, in our Wanderings, Toyam shaves a yak and gets to soldering, I blew up and recovered my Mint install, Tony's been editing audio and LUGing, Josh has been playing with Windows Subsystem for Linux , and Joe finally gets the Note 10 Then, in our news we cover the Linux Mint Monthly News, exFAT in the kernel, iPhone and Android exploits and the new Pinebook Pro In security, we talk Firefox and why you should give it another try Download

This episode is about getting things done and avoiding distracting things that end up on your to do list. The term "Yak Shaving" started as a term about dirty and sloppy code at MIT. Today it refers to many different types of distractions, time wasters, and minutiae that slow us down from accomplishing the primary goal.

We originally sat down to discuss distractions and Yak Shaving. What emerged was more like group therapy for a team struggling to cope with a spate of JS dependency upgrades. We also discuss purchasing an ice cream truck. Buckle up!

This week I get to sit with Jessica Kerr (aka jessitron) to discuss a topic developers love to hate – yak shaving. Jessica takes a different approach to Yak Shaving and sees it not as an inconvenience, but as an opportunity. Listen to learn more!   

Wesley Reisz talks with Jessica Kerr about her focus on developer productivity. Topics include her work at Atomist building Slack Chatbots, an approach to categorizing Yak Shaving (in an effort to prioritize and automate development dependencies), how an innovation culture drives diversity, and, finally, the role of 10x developers in the lifecycle of a company or product. Why listen to this podcast: - There are five kinds of Yak to shave - Atomist uses a Slack chatbot to automate and track commits, builds, push requests etc. - Agile retrospectives are a great way to encourage an innovation culture - Diverse teams flourish in innovation cultures - 10x developers are great for launching products, but teams are needed as products scale up More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2uO60PR You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2uO60PR

068 Pump ‘n' Chug ‘n' Yak Shaving Stephen Rowe aka the one and only smrnov joins us this week where we talk about milestones, leaderboards, Bean Dives, cartoons and pooping in space. Show notes are always available on the Zed to Zed website We are on iTunes, Stitcher and Google Play! Please give us a rating or review, it will really help us and is a free, easy way to support the show! Talk to us! Join our community! Discord Chat Zed to Zed Forums ACTIVE contests on forum Twitter: @zedtozed Zed to Zed Xbox Club Zed to Zed Podcast Leaderboard Email: contact@zedtozed.com Facebook: Zed to Zed Podcast Hosts: Brandon Fream aka "Freamwhole" - TrueAchievements / Xbox / Twitter Randy aka "Crandy" - TrueAchievements / Xbox / Twitter Tarragon Allen aka "zzUrbanSpaceman" - TrueAchievements / Xbox / Twitter Daniel Proulx aka “Proulx”- TrueAchievements - Xbox Stephen Rowe aka “smrnov” - TrueAchievements - Xbox Referenced during the show: Best and Worst April Fools Jokes from Kotaku MST3K Trailer TrueAchievements New Site Leaderboards Are Live Supreme Court Nominee Asked An Important Question Harmonix Lays Off 17 Staff Mad Catz Declares Bankruptcy Kotaku on Mad Catz Gamestop Closing 150 Stores Reddit: Build a PC for me Reddit: PC Master Race Alex (MiserlyPluto459): The Road to 300k Bean Dive Guide Version 2 Maka91Productions Great Wobo Escape: Warning on Save Files with update Resident Evil: Code Veronica remake? All audio production and podcast backend support provided by Tarragon Allen. Songs and sounds that have been used in the show: "Jive Bot", “Dalmation Station (It Gets Better Mix)” by Jake Kaufman and “Jive Bot (Psycho Prismatic Mix)” by cancel from the games Mighty Switch Force! 1 and 2, developed and published by WayForward Technologies Epic Voice Announcements by RJBANKSWA “Accident” by JCH & Morten Kristensen (MSK) Zed use and would like to thank the following products and services for making the podcast and the community possible: Zencastr for their podcast recording solution Adobe Audition for audio editing Audacity for audio editing and recording Libsyn Podcast Hosting iTunes for making podcasts mainstream Audio-Technica Microphones Blue Microphones NAD Electronics Headphones DreamHost Hosting Digital Ocean Hosting Skype chat Discord chat Discourse forum software TrueAchievements for making achievements awesome Microsoft for the Xbox Glossary of Xbox Gamerscore and achievement jargon and terms

Someone chats with Velvet O'Claire on Burlesque Stripped Down podcast! The post #BurlyCookies, One-Woman-Show Prep, and Yak Shaving with Diva Hollywood! appeared first on Burlesque Stripped Down.

In which we discuss the difficulty of making things when your standards are high.

Original video recording: https://www.youtube.com/watch?v=MBl18nUde0U

伊藤直也さんをゲストに迎えて、Heartbleed, Docker, Consul, RubyMotion, 環境構築などについて話しました。 Show Notes Heartbleed Bug xkcd: Heartbleed Explanation 三菱ＵＦＪニコス８９４人個人情報流出か OpenOpenSSL OpenBSD、怒りのコミット Docker Meetup Tokyo #2 Dockerアプリケーションのポータビリティを考える wercker docker DockerCon 2014 Consul - HashiCorp Serf vs. Consul Consul vs. ZooKeeper, doozerd, etcd - Consul Getting Started with etcd GopherCon 2014 Consul関連文書の参考訳、Serfとの違い等 | Pocketstudio.jp log3 RubyMotion @naoya_itoの火を噴いたシェルtips robbyrussell/oh-my-zsh Rebuild: 4: bkノート, Yak Shaving, Code Reviews Development Environment Conference - Shibuya.js Hack your bundle for fun and profit Dash - Documentation Browser, Snippet Manager - Kapeli

Recorded 6 December 2013. You can download the m4a file. This is the last episode of Identical Cousins. Thank you so much for listening! We had a great time, and we loved hearing from people who enjoyed the show. This episode is sponsored by Oxygene from the super-awesome RemObjects Software. See remobjects.com/oxygene and use the discount code ID13 for 20% off. This episode is also sponsored by HostGator. Use the coupon code COUSINS for 25% off. Get your very own .net domain name! (And web hosting. And 24/7 support. And plenty more.) Some things we mention (or just felt like linking to): Gold is Best 24 Atari Xcode Legos Microserfs RIM’s $10K Developer Committment Pull to refresh iOS 7 360 iDev System 7 Romantic Era Modernism Richard Wagner Claude Debussy Paul Cezanne Pablo Picasso The girls would turn the color of an avocado when he would drive down their street in his El Dorado Pablo Picasso was never called an asshole Ernest Hemingway Bauhaus The bats have left the bell tower Fantastical Flipboard iPad Jean Michel Jarre AltWWDC Skype Scott Forstall iCloud Core Data Syncing Letterpress Pinbook Albina Development Collin Donnell Black Pixel Black Pixel Acquires NetNewsWire Rogue Amoeba Vesper Chatology Glassboard Ulan Bator Yak Shaving The Cannonball Run Cannonball Run Bloopers History of the World, Part 1 Dom DeLuise We talk alot about previous episodes. Instead of linking to them in the show notes, we figured you could just visit the Archive.

Daniel rambled, Max murmelt und die Zeit verfliegt nur so hin und her in dieser Folge von Konferenz 28. Es geht um Hinfallen und Aufstehen, die schlimmsten Kunden und die schlimmsten Portfolios, um GitHub und LayerVault, um Mavericks, iOS7 und die Yakrasur der Woche. The Worst Portfolio Ever Yak Shaving Clear OmniFocus Evernote Folgt uns auf Twitter (warum eigentlich nicht?): @konferenz28.de. Und vergesst nicht wieder die Metafolge!

高林哲さんをゲストに迎えて、バッドノウハウ、ソフトウェアエンジニアリング、コードレビューなどについて話しました。 Show Notes bkノート Plack Handbook yak shaving で人生の問題が80%が説明できる問題 Yak Ratio プログラマの三大美徳 リファクタリングという名の現実逃避 タイピングが速いプログラマは腕が立つ説 You are Not Your Code 下から目線のコードレビュー